Organizations looking to regulate access to the information they routinely work with, and computer systems and communications networks seeking to preserve the confidentiality and integrity of the data they store or transmit will typically require some kind of formalized framework to govern how this is done.
Information classifications such as Universal, Unclassified, Confidential, Secret, and Top Secret are one manifestation of this. So too are network security protocols based on the concept of a layered defense around the heart or kernel of a system.
These examples (and others like them) create a manageable security environment through the definition of distinct processes and rules which apply to transactions (information requests, data transfers, etc.) between one part of a system and another. In many instances, it’s a multilevel approach based on formally established protocols and models.
The Architecture of Security
To safeguard their information and assets, organizations will usually draw up a security policy, setting out the rules, protocols, and intentions/expectations that all the protection mechanisms they put in place are supposed to uphold or enforce. In essence, the policy is a checklist outlining the organization’s security goals, without going into fine detail about how these goals are to be accomplished.
A security model provides this fine detail, by delving into specifics on each point of the security policy. The model will describe the objects or entities which are to be governed by the security policy, and give a clear statement of the rules which make up the security policy. So a security model furnishes the “nuts and bolts” procedures for translating the goals of a security policy into the techniques and data management options needed to enforce that policy.
Types of Security Models
Typically, a security model will consist of a set of analytical ideas and mathematical procedures. These can be mapped to their relevant network or system specifications, and/or translated into applications, scripts, or processes through programming code.
Security models (more formally referred to as “security models of control”) establish how security should be enforced, which subjects (people, applications, organizations, or processes) can access a system or network, and which objects (files, data, programs, processes, etc.) they’re allowed access to.
The “controls” in question are usually fundamental security attributes like confidentiality or integrity. So for example, security models such as the Bell-LaPadula are used to capture and implement policies for confidentiality, while models like Biba and Clark-Wilson are concerned with policies to guarantee integrity.
Multilevel Security Models
In cyber-security, creating an environment of dense and complex defenses is a desirable thing, as it requires potential attackers to have to work that much harder to penetrate these barriers and get to what they want. It’s the guiding principle behind the layered model of network security set out in the OSI (Open Systems Interconnection) framework for application security.
It’s also the principle underlying multilevel security models, as for example in military or national security circles where documents are labeled according to their sensitivity levels. In simple terms, designations like “Unclassified”, “Confidential”, and “Secret” are levels corresponding to the perceived risk associated with the unauthorized release, theft, or compromise of information at those defined tiers of a multilevel classification system.
Multilevel Lattice Security Models
With mathematical constructs and analytical concepts serving as the basis for security models, it’s hardly surprising that the idea of a lattice structure has been adopted as the foundation for several such frameworks.
In this sense, a lattice is a mathematical construction built on the concept of a group consisting of a set of elements having a partial ordering relation. Any two elements in the group must have a unique set of binding limits, defined as their least upper bound and greatest lower bound.
How does this translate into a security application? Well, in a latticed security model, each of the lattice elements is a security label which consists of a security level and a set of categories. A security lattice can provide protection that’s both multilevel (applying to several “layers” or security designations) and multilateral (with protection drawing in security contributions from, or extending security protection to many parts of a system or organization).
Analysts at the US National Security Agency (NSA) draw an analogy between a multilevel security lattice and a filing cabinet used to store a collection of classified technical documents. The filing cabinet can be viewed as a collection of compartments and drawers. Each drawer may be seen as a collection of folders. And each folder holds a collection of classified documents, of varying security designations.
The Bell–LaPadula Model
First published in 1973, the Bell-LaPadula Confidentiality Model was the first notable example of a formal mathematical model for multilevel security. It’s a “state machine model” which can capture the state of a system at any given time to verify its security. This state would typically consist of all existing permissions, and all current activities involving subjects accessing objects within the system.
At its heart, Bell–LaPadula is dedicated to making sure that subjects with different security clearances are properly authenticated, and assigned access to objects at different classification levels under formalized rules, and on a “need to know” basis. The following rules are enforced:
- The “no read up” or simple security property prevents a subject at one level of confidentiality from reading information at a higher confidentiality level.
- The “no write down” or star (*) security property prevents a subject at one level of confidentiality from writing data to a lower confidentiality level.
- The strong star (*) security property ensures that a subject can’t read or write to an object of higher or lower sensitivity.
- The discretionary security property (which is very rarely used) employs an access matrix to allow users at a certain security level to grant access to other users at the same clearance level.
The Biba Integrity Model
The quality of “integrity” ensures that unauthorized users on a system don’t modify data, prevents authorized users from making unauthorized changes to data, guards the internal and external consistency of information in the system, and makes sure that databases always balance.
First published in 1977, the Biba model was the first multilevel lattice security framework to formally address the issue of integrity. Its properties are laid out in a way similar to the Bell–LaPadula rule set:
- The simple integrity property prevents a subject at one level of integrity from reading objects at a lower integrity level.
- The star (*) integrity property prevents a subject at one level of integrity from writing to objects at a higher integrity level.
- The invocation property prevents a subject at one level of integrity from invoking (calling up) a subject at a higher level of integrity.
The Information Flow Model
Consisting of objects, state transitions, and lattice (or flow policy) states, the Information Flow Model created by Dorothy Denning actually forms the conceptual basis for both the Bell–LaPadula and Biba models.
Lattices are integral to its operation, whose goal is to prevent the flow of unauthorized or insecure information in any direction through a system. The model can use mechanisms known as “guards” to enable information exchange between different systems.
All of these multilevel security models face the threat of information making its way to unauthorized entities via covert channels, or information flows that aren’t controlled by any of the model’s security mechanisms.
Covert channels may be created by the manipulation of process timing within a system, where for example an unauthorized process can modulate its use of system resources to mask a relay of information to a receiver.
Covert channels may also be created via ad hoc storage, with a process directly writing data to a storage location and another process, or indirectly reading information it shouldn’t have access to.
Share this Post