Confidentiality, integrity, and availability make up the “security triad” as it applies to data. And one of the principal security models dedicated to preserving the integrity of information is the Biba integrity model, which we’ll be looking at today.
Biba Integrity Model – Some History
For years, matters of data confidentiality were largely dealt with by the Bell-LaPadula model, which caters for multi-level security. However, Bell-LaPadula deals exclusively with confidentiality without addressing the question of system integrity, and does not address issues such as information flowing through covert channels. On top of this, the model was created in an era when the mainframe was the dominant computing platform, and lacked the flexibility to effectively adapt to emerging computer technologies.
Released by Kenneth J. Biba in 1977, the Biba Integrity Model (sometimes referred to as Biba77) was created as a supplement to Bell-LaPadula. It was the first major security model built to address concerns about system and information integrity, and its policies are now implemented in parallel with those of Bell-LaPadula to give a more all-embracing assurance of data security.
The Importance of Integrity
In terms of data security, integrity is a means of ensuring that authorized users don’t make unauthorized changes to information or programs, that unauthorized users aren’t able to modify information, and that information flowing to and from databases remains consistent and uncorrupted. Assuring system and data integrity is more of a concern to commercial enterprises and public or private services, while confidentiality is usually the priority for government agencies, law enforcement, and the military.
For all applications, if information or assets at a high security level come into contact with information residing at a lower level of security, or if they’re manipulated by a program having a lower security level, the possibility exists that these high-level objects may become corrupted or downgraded through this interaction. The classic example would be a proprietary or top-secret project document being viewed by an unsecured document reader, which might edit the text in some way (add or delete), corrupt it, or even infect it with malware.
The Biba model was created after it became apparent that under Bell-LaPadula it was entirely feasible for a low-level user to overwrite highly classified documents in the absence of a defined integrity policy.
Integrity strives to attain four objectives, in cyber-security applications:
- Preventing the modification of data by unauthorized parties
- Preventing the unauthorized modification of data by authorized parties
- Ensuring that data in transit and use accurately reflects the real world conditions that it’s supposed to represent
- Maintaining the internal and external consistency of databases and approved data sources
Levels of Integrity
Descriptions may of course vary from organization to organization, and will depend on the type of work being done and information being handled. But a typical hierarchy of integrity levels might include:
- Slightly trusted
- Highly trusted
The Dilemma of Parallel Systems
In a system where both confidentiality and integrity go hand in hand, logic would suggest that information will tend to flow towards the highest security level (as under Bell-LaPadula, lower-level users are only permitted to read information above their own security level). But under the conditions of integrity preservation, this highest security level would also have the lowest level of integrity!
Such a system would also tend to consist of sets of isolated sub-systems, each with their own confined set of access rights and privileges. The combined effect would be that no communication between users at different levels would be permissible. Safe, by design – but information sharing would be impossible. This would defeat the purpose of having an organization with users on the same system.
The Structure of Biba
The Biba Integrity Model has a lattice structure defined on a mathematical basis which allows the security levels dictated by Bell-LaPadula, the integrity levels set out by Biba, and the compartmentalized knowledge established by the military’s “need to know” access privileges to co-exist in harmony.
The Biba model sets out a hierarchical system which compares the integrity levels that are associated with files, processes, and people. It uses a similar principle to Bell-LaPadula in defining objects (documents, raw data, programs, etc.) and subjects (individuals, processes, programs, etc.). Biba policy uses three defining properties to protect objects (or system assets) from being illegitimately modified:
- Simple integrity: The property whereby a subject at one integrity level is not permitted to read an object at a lower level of integrity. It’s also expressed as the simple integrity axiom, “no read down”.
- Star (*) integrity: The property whereby an object at one integrity level is not allowed to write to an object at a higher level of integrity. Also known as the star integrity axiom, “no write up”.
- Invocation: The property whereby a subject at one integrity level is prohibited from invoking or calling up a subject at a higher level of integrity.
The Biba Remit
Simply put, the Biba Integrity Model is meant to ensure that high-value assets with a high level of integrity can remain isolated from lower-grade assets, which might corrupt them in some way. To this end, any new objects created within a system are given the same level of integrity as the process that created them. This effectively prevents any process from giving data a higher integrity than it had previously.
In the context of a computer system, privileged processes having the highest levels of integrity are able only to read data with the highest integrity level, while being shielded from all data with a lower level of integrity. So, for example, a lower level user introducing an executable Trojan into the normal execution path of a privileged process would be denied the opportunity to cause damage, as the privileged process would be unable to access the low-level executable.
Even attempts to archive malware in a directory where higher level processes normally read data would fail, as the low-level perpetrator would be denied access to write to that folder. Similarly, low-level processes are only allowed to look at but not influence system data and files.
It’s not a perfect set-up, of course. Assigning the highest possible integrity rating to all privileged processes to protect them from attacks does introduce complications into the performance of system-wide activities such as backups. Workarounds are typically required for those instances where backup media must store lower level information that these privileged system processes are denied access to. System monitoring may also be affected, as lower integrity processes may be denied access to the system log files which they should normally be updating.
Share this Post