State machine models

A computer's state can be described as a snapshot of the system at any point in time. All of the current instances of subjects and objects, and how they are interacting, are a part of the state. When developers are building an operating system they may wish to implement a state machine model. To do this, the developers will examine all of the ways that subjects can interact with objects and how the state of the system may change as inputs are accepted by objects. Every time an object accepts an input, a state transition occurs. If, after examining every possible association and interaction, it is decided that every state transition is concurrent with the security policy of the operating system, then the system is secure and effectively enforces a state machine model. Note that for the purposes of this post, models will be discussed in an abstract manner, while in reality there is a large amount of mathematics involved during development to prove the effectiveness of the model.

A system that successfully implements a state machine model will, by definition, always be in a secure state. The system will boot into a secure state, execute transactions and commands securely, and will even fail in a secure state. It is critical that the system be able to fail in a safe way so that if an error or illegal operation occurs it is able to save itself without leaving itself vulnerable.

Two very well known state machine models are the Bell-LaPadula Model, and the Biba Model.

Bell-LaPadula Model

The Bell-LaPadula model is a state machine model that focuses on maintaining confidentiality. It often serves as the basis for mandatory access control (MAC) operating systems as are used by the government. Because its primary focus is confidentiality, the Bell-LaPadula model uses security labels along with an access matrix to enforce security. It is a multilevel security system because users with different levels of access use the system. There are three rules that are core to the framework of the model:

1. Simple security rule - A subject cannot read data within an object that resides at a higher security level ( the "no read up" rule).
2. * - property rule - A subject cannot write to an object at a lower security level (the "no write down" rule).
3. Strong star property rule - For a subject to be able to read and write to an object, the subject's clearance and the object's classification must be equal.

The first rule is easy enough to understand. If you are give the classification of "secret", and a file is labeled "top secret", you do not have the proper clearance to read it. The purposes of the second rule are to prevent a person from writing highly classified information to a lower level, thus damaging the confidentiality. The final rule ensures that a subject has both the proper clearance and the need to know to access an object. While I may be given "top secret" clearance, I may not have a need to know about a missile program and therefore should not be able to access files associated with it.

Biba Model

The Biba model is similar to the Bell-LaPadula model in that it also has three rules which enforce what states the system may enter. Where the models differ, however, is their focus. While Bell-LaPadula is concerned with maintaining confidentiality, Biba is focused on maintaining integrity. The goal of the Biba model is to ensure that data of high integrity is not corrupted by data of low integrity. This would be useful in systems such that handle financial data, or healthcare information. The three rules for Biba are as follows:

1. * - integrity axiom - A subject cannot write data to an object at a higher integrity level (referred to as "no write up").
2. Simple integrity axiom - A subject cannot read data from a lower integrity level (referred to as "no read down").
3. Invocation property - A subject cannot request service (invoke) of higher integrity.

The first two rules control how data may flow between different integrity levels.  You would not want your high integrity data, or "clean" data, to be mixed with lower integrity "dirty" data. These not only prevent users from traversing integrity boundaries, but processes as well. A process at a lower level should not be able to write data to a higher level. The invocation property also states that a lower level process may not invoke a process higher than it. This means that processes cannot make use of any tools or services that have a higher integrity ranking, they may only use what is below them.