Now the security models deal with, as I've said, state and a mode. Now state reflects the security level of a system. Typically we see it as stratification of the system, essentially high, medium, and low sort of stratification. Now this breaks things out so that a subject clearance, its trustability or reliability, is what gives it level access to higher or lower levels. And objects then correspond with their sensitivity label and their integrity setting.

Then we have mode, which reflects the partitioning of a system and data into the various compartments, such as different departments, different functions within an organization. The system itself has partitioned in somewhat of a vertical fashion, built along functional lines. This equates to the subject's need to know, or their functional role, and the object's compartment to its functional use or application.

Now in various combinations, when we have state and mode combined, what we have is we have the matrix that you see there. We have our high, medium, and low stratification for state, and then the various compartments for accounting, HR, and project management office as the various partitions. And in each one of these partitions, there may be multiple levels of access possible, which all depends on the kind of work that is then being performed. It is certainly possible for a subject, either by themselves or as a member of a role, to have access to more than one level and to more than one partition. But the various design features we've talked about will work in each and every one of those cases of interaction between the subjects and objects.

One of the classic models is the Biba Model, which has to do with integrity. And here you see the way that it was conceived. It was designed as a formal state transition model showing the state machine as it moves from one state to another, that enables the subject to get access and to do various operations based on what it was, what its label said about it, and what operations and objects it intended to perform on while it was in the system.

Now, of course, this being an integrity model, contamination or corruption were the basic compromises that it was working against. And it defined a rule of interaction, basically that a subject could be authorized, and that only authorized subjects internally would have access to objects in the system and only be able to perform authorized actions.

Now, as you see here, there are two basic interactions, a read and a write operation. The read operation is concerned with contamination by subject action, where the write operation is concerned with contamination of subject space. This model had to do with how integrity was being protected by controlling the interactions of subjects and objects, and preventing those things that were defined by the set of controls and rules built within the model to prevent contamination or corruption.

Now, one that is very famous and has been popularized for a great many years by the CISSP, the complimentary certification to the CSSLP, is the Bell-LaPadula Confidentiality Model. Its design was based on Biba in that it is a multi-level lattice type of a model, and it follows it by about a year. This one was developed by scientists and mathematicians at MITRE Corporation in response to a government requirement. This one dealt with confidentiality and that the compromise was uncontrolled or unauthorized disclosure of sensitive data. This one went a bit of a step further than Biba did by talking about read operations, preventing unauthorized disclosure to the subject by the system or others, the write operation, which had to do with preventing disclosure by the subject to the system or others. And in doing so, exposing data to those subjects that they were not authorized for. And then a strong Star Security Property, which prevented either the read or the write failure, and keeping that subject's actions, both read and write, isolated to its level of authority and nothing beyond on either side.

Now, the security models also developed further in what was called the Brewer-Nash Model. The Brewer-Nash Model, developed in 1989, was a mathematical model that recognized various conditions inside systems having to deal with prevention of conflicts of interest, but also having to deal with rapid dynamic change within the conditions that existed within the system and the interactions between subjects and objects.

The Brewer-Nash Model created something that we know commonly as a Chinese wall or a kind of a screen or a firewall between different enclaves where data exists. And this firewall would allow or deny access by subjects to objects, depending upon what the conditions were at the time. It could be that during the day, subjects accessing the two different repositories for Bank A and Bank B, as you see there in the graphic, it could be that they were able to access both sides. And then, if certain conditions changed, then access to one or the other would be cut off, because to be able to continue to access both in the changed conditions would create a conflict of interest. And in fact, what was being prevented here was the ability to see data that would give insider trading capability and thus illegal profits to whomever had the rights to both. And so this one we find in financial types of organizations quite often, but this is one that is in widespread use today.

Now the Operational Security Model you see here relies on three primary elements, which has to do with prevention, detection, and response. The prevention, detection, and response of these is making sure that first we have controls in place that prevent. And these, of course, work for those circumstances that we can define clearly and explicitly, and can craft controls that will work in opposition to whatever is being attempted.

Along with prevention, we must have detection because undoubtedly access will be attempted that will be denied because the rules or the matrix controls will prevent it. But of course, for security needs, we have to have the ability to detect that this is done, but detection does not itself mean that action will follow.

So we have to be able to detect and then to be able to respond. And the response will make sure that we are able to, where possible, prevent, where prevention is not possible, detect, and then respond to provide the kind of control that was not possible before.

Lectures

Security Basics: CIA Triad and Functional Requirements (AAA Services) - Design Principles - Security Models - Security Models: Access Controls - Threat/Adversary Analysis