The Illusory Security of BIP: A Brief Technical Analysis of Security Measures

[Context for English readers: BIP (Biuletyn Informacji Publicznej / Public Information Bulletin) is Poland’s official electronic platform where all public institutions must publish information about their activities, spending, and decisions. It’s similar to government transparency portals in other countries, mandated by Polish freedom of information laws.]

Today’s brief technical article was prompted by Watchdog Poland’s comments about the Public Information Bulletin. Based on my knowledge and experience, I’d like to examine whether we’re really dealing with a trustworthy tool.

The Public Information Bulletin (BIP) is an official electronic publisher that serves as a key source of information about public spending and provides access to processes regulating local government activities. This is where we should find all information about tenders, contracts, and local government expenditures - matters that directly affect each of us. Having implemented such systems, I’ve learned about the principles and requirements for data integrity and event auditing. How does it work?

Currently, to my knowledge, most BIP implementations are deployed by IT companies through tenders or requests for proposals, usually as part of larger IT projects. According to the Act on Access to Public Information, each BIP must be maintained as a separate website, and the IT company implements a system that meets the following formal requirements, of which let’s list the most important ones:

1. Password-protected administrative module with delegation of permissions and content management access assignments
2. A journal mechanism (Change Register) automatically recording changes to public information content and attempts to make such changes by unauthorized persons
3. Recording checksums for event records, e.g., online changes, published documents with event versioning so that changes can be verified
4. Mandatory database backup creation at least once per day
5. Maintaining a backup server in case of failure

In 2017, the Ministry of Digital Affairs took a step toward centralization by introducing the Centralized System of Access to Public Information (SSDIP). It was meant to solve authorization problems by introducing Trusted Profile login instead of local accounts, providing a free application for running BIP sites, and implementing a centralized permissions system. However, the centralization of login alone, without transferring data and control mechanisms outside the unit, doesn’t solve the fundamental problem because the law still allows for creating custom systems. Using SSDIP is voluntary.

I simply want to show the illusion of security. Since the CMS/BIP system implemented locally by an institution is either handled by IT outsourcing or, in most cases, maintained on the institution’s servers after implementation, this means that someone from the institution has access to the database (including the entire system with records and the journal mechanism, grandly called the Change Register) and the system administrator account. Let’s not be afraid to say it - from the institution whose employees are supposed to be audited.

I see a huge problem with the potential for record manipulation, which I tested for fun during implementations to check if and how it’s possible. It’s remarkably simple - to modify content in BIP, we don’t even need access to the CMS system; database access is sufficient. Most commonly, it’s the popular MySQL/MariaDB. Through either an appropriate administrative interface or direct database connection, one can modify or delete any record… and there will be no trace, I repeat, no trace of this, because MySQL/MariaDB service login events are not part of the CMS system audit. Theoretically, of course, regulations and so-called best practices require proper security, and the server administrator shouldn’t do this. But they can not only remove editing traces from MySQL logs but also modify all other traces because they’re located within the same server.

Let’s analyze the checksum mechanism now. The system works as follows: when creating or modifying a BIP entry, a new record is created in the database with an assigned position number, relationships, and a checksum for that version. This checksum theoretically guarantees the entry’s integrity - we can check whether its content hasn’t been changed. However, this is an apparent security measure for two reasons:

First, with database access, we can simply delete the selected entry, modify its content, and generate a new checksum for it.

Second, the checksum is created only for the entry’s content, but not for metadata (like date or database index). This opens the door to manipulating entry history - we can create a new entry with any historical date, copy other records’ content into it, and delete the original entries. This might sound complicated, but in practice, it’s a simple operation that can be automated with a basic script that cleans all traces.

The solution to the problem could be delegating administrative privileges outside the unit responsible for content publication. Alternatively, minimal security should at least include creating an external log server where all system records would be automatically replicated. Then, any unauthorized modification would leave a trace that couldn’t be hidden because a copy would exist outside the local administrator’s control. However, the current checksum system is, in my opinion, fiction: checksums are stored in the same database as the content, so they can be modified at will. Even if they were stored on an external server, they should additionally be relationally linked to entries in a way that prevents their modification without leaving a trace.

These formal security measures, required by law, prove insufficient in practice. What can be done about this? Here are some practical proposals that probably go beyond current legal requirements:

1. External log server - all system events should be automatically replicated to an independent server, outside the unit’s control. Ideally, this should be a service managed by an external provider with appropriate security certifications.

2. Distributed checksums - instead of keeping checksums in the same database, blockchain technology could be used to create an unmodifiable change register or relational checksums. Each change would be recorded in a distributed network, making history manipulation practically impossible.

3. Independent audit - regular, unannounced inspections conducted by external security specialists who would check not only system logs but also database integrity.

4. Automatic archiving - cyclical backup creation of the entire system, stored in an external, trusted repository.

Attempts at partial centralization, like SSDIP from 2017, show that the direction is good, but the implementation is insufficient. In my opinion, we need full centralization of control mechanisms and data integrity, not just the access layer.

It seems to me that in the reality of IT staff shortages with experience, such control mechanisms are rather fictional, and personally, I would see some form of partial centralization in the context of, for example, security system elements. I don’t have the appropriate competencies to create the architecture of such a system; there are proper specialists for that. However, I see a serious problem and wanted to just point out how apparent the security requirements for BIPs are. It was fun, however, to play with these pseudo-security measures, knowing what great possibilities for manipulating the tender process a delay or lack of completeness of certain information can have…

I would just like to add in conclusion that after implementing many deployments for the public sector, I avoid this segment.

• Security