Now, having looked at our design features, we need to look at security models to start integrating design ideas with what sort of a model we might be looking at. Now over the next few slides, we're going to be looking at various types of security models that will in their own way, be overlays to our overall system design. Many of these are going to be addressing the kinds of capabilities and features that I've already discussed. They will exist in the operating system, kernel design if we go that deep into the program. They will of course, inform the design and operation of our access controls. They will talk about component interaction and the subject-object interaction between people and the system that they're using.

Now, the models, as I'm sure you know, illustrate a theory about how things are going to work, but we need to model an interaction so that we can see the cause and effect of subject-object interaction so that we can design controls to enable the interaction if it's allowed or wanted and prevented if it isn't.

So we're going to examine some models for how they inform the design process and tell us how subjects and objects are going to interact so that we can develop control structures to try to protect against those we don't want and enable those we do want. So let's begin with this.

This is something that is quite evident throughout all of the systems that we work with. And it's a concept that's been around for many years, but I want to present it to you here in a different way to help you see that these are the things that we're looking at that are characteristics that have to equate to other characteristics in an interaction between a subject and an object.

On the subject side, this is our active entity, usually human, but it can be a process. We look at clearance. Now, this is a parameter that talks about the trustworthiness of the subject. Now this is typically hierarchical such as you might find in a classification scheme, meaning secret includes confidential, top secret include secret and confidential and so on.

Along with this, we have the one that we all know, need to know. Now need to know, is a parameter that talks about the functional requirement for access and performance that a subject will have. These two characteristics together, are what give the subject access to the object. In the case of the clearance as I said, it's typically hierarchical. In the case of need to know, this must match precisely with the corresponding attributes of the object.

Now, the object is the passive entity that is being acted upon by the subject. The subject has a clearance, which equates to the classification of the object. Now, this is the parameter that talks about the sensitivity, the integrity, the confidentiality level, perhaps of the object. And, like the clearance for the subject, classification for the object is typically hierarchical.

Going along with need to know on the subject is compartment or category for the object. Now this is the parameter that, and this march must precisely also with the need to know for the subject. This is the one that talks about the functional use or application of the object in question.

So we have a label, subject with clearance and need to know parameters set and an object with classification and compartment or category parameters set. And between the two of these, we now have the basis for making a match or denying access altogether. Now, the types of security models we have, usually start with some of the very basic ones that talk about subject-object interaction.

So, let's go back to the 1930s when these ideas were actually originated. It started with the state machine model. And this is basically what it sounds like. A machine has a state, a set of conditions, a set of actions and so on. In the state machine model, it talks about functional and nonfunctional attributes.

Nonfunctional are those states of being conditions that exist but are not active in any way. And then the functional ones, which are about actions that will take place utilizing or producing the kinds of non-functional states that will be there. And the idea of a state machine is, it goes from one state to another, through a defined process of change. A program command takes place, it changes by starting an action, acting upon various variables within the machine. And then by doing its action, it causes the state machine to move from state one to state two or whatever state will succeed.

One form of the state machine, is what we call a noninterference model of which there have been several produced. Now, the idea behind noninterference is exactly what the names makes it sound like. One process, one subject-object interaction cannot be interfered with, or for that matter, even seen by another. And the point of it is, each one that is properly authorized, properly executed, should not be in any way seen or interfered with by any other. And this is a form of process isolation control. When it fails, we get the blue screen of death. When it works, systems operate correctly.

An information flow model is a variation on the theme of non-interference. Information enters the system and then flows through it from its point of entry to its point of storage or its point of exit. And the information flow model takes the concepts of state machine and non-interference, to ensure that as the system is being interacted with, by subjects along its path, that those are enforced and that the information flows and the description is, that it flows from one state of security at a defined level, into a state of equal or greater, but never flows against the current so to speak, where it will flow on its own manipulated by the system and not by an overt action on the part of the subject to move it from one level of security to a lower level. This has to be done by system rules, by a specific and carefully defined process.

The point of the information flow model, is also to ensure that all pathways over which information can flow and the rules governing this flow, do not allow for the existence of what we call a covert channel, a channel which by its name, is hidden from subjects and from the system and it's reference monitor so that it can't exist and work as a channel that cannot be either defined or, and this is the concern, controlled. Then we move on to different kinds of models.

One kind, we have as a matrix based, and this is pretty much what it sounds like. This appears to be a two dimensional spreadsheet where it looks like a way of connecting subjects to objects in an explicit authorization format. This is the kind of access control system that we have in many of the common systems we use today. There is also a multi-level lattice model. And although if you looked at it on graph paper, a lattice might appear to be the same thing as a matrix, it isn't.

The way that a lattice works, is it enforces the rules of greatest, lower, and least upper bounds. The point of it being that, so long as the access being attempted is within the scope of that access allowed to the given subject on the object in question, the lattice will determine the maximum level necessary to successfully execute what the subject is attempting to, and enable that level of privilege, but no higher.

Lectures

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