Now, I had mentioned the Triple A Services. These are different services that we require to ensure that the systems that we're designing and building are able to meet as part of the plan to keep the software available, and the trusted computing philosophy is actually met. So this, the Triple A Services, is a set of functional requirements that ensure that these actions on the objects are always authorized and associated with a specific subject.

So the first one, and this follows a claim of identity presented to the system in the form of a user name, an email address, or a user ID of some kind, or other identifying credential. And the claim of identity must be authenticated, the first of the three A's. This of course needs to be integrated with other methods to validate all other entities in use of the system.

Our second A, authorization, talks about the establishment and assigning of access and capability that are closely aligned to the claimed, and now, confirmed role's needs.

Our third A is accountability, and this is made up of two other As. First one is the accounting, and that is the recording of all activities to a log within a system that will subsequently be reviewed to make sure that they are what is authorized. Also among these will be the kind of records that show problems, failures, or successes that shouldn't have happened, and help us to troubleshooting, as well as investigation.

The other A is auditing. And this is the act of taking the accounting record of all the transactions that all the subjects have done within the system and verifying that they are correct and compliant, or of course, that they're not, and that we can follow through and look at the behavior of subjects interacting with the various objects in the system to ensure that where they are all compliant, and proper, and authorized, we're content that that is the case. And where they're not, we have the ability to follow them up and investigate further.

Now, the CIA and the Triple A Services are involved in the process. And the process is how we establish the tie-in between the subject and their claim of identity and all of their activities within a system. Now, these are comprised of the technologies and techniques associated with the CIA and the Triple A to make sure that they are preserved and that they ensure that the subject-object interaction that is established and correctly mediated throughout all cases of subject-object interaction.

Now, the process, as I said, begins with identification. Now, to put a little more detail on this, it is logically or physically identifying a claim to identity, and then, through the next step, authentication, validating that claim, and assigning it as a positive identity. This follows authorization.

An authorization is the connection of a subject with a resource and access profile that states the capabilities and accesses that they will have to manipulate any data objects that they're going to process. So the process of authorization begins with a separate process to assign this profile, and then, a second one to implement it, followed by the subject's ability to use it, and get connected to those resources and data objects for which they have a proven need to know. And then we have, of course, the accountability, which then establishes what they're doing, and whether or not it's compliant and authorized.

Now, as part of establishing these requirements, we will have to establish what sort of security model we will need to do the Triple A Services, following the identification, the authentication, authorization, and accountability services that verify subjects and tell us what they're doing. So let's start with a discussion of the security model known as the Mandatory Access.

Now, this is what is referred to as an implied or implicit security model. It is because this model is based on the function of rules governing the mediation between subjects and objects. To begin with, subjects have labels that will be used to identify who they are, and what they're capable of doing within the system. This label will contain a number of different parameters, but the primary ones we are herewith concerned will be clearance, which is a way of measuring the integrity of the subject. This will be allowed to give them authorization to get on the system in the first place.

Following this will be a second attribute known as Need To Know, a term I'm sure you're quite familiar with. This will be the thing that will actually give the subject access to the objects that they're seeking, because this will be about the information that will be relevant to their functional role. Now, in like manner, objects also have labels, and these will be used to permit access. The first part will be a classification. And this will be used to define a confidentiality or integrity parameter.

Second will be a categorization. And this will be to define a parameter that states functional usage or application of the particular object. Now, inside the Mandatory Access Control system is a thing known as the reference monitor. This reference monitor is in fact, a virtual machine type of program. Its job is to mediate, and I mean, absolutely all subject-object interaction. What it will do is compare the subject label to the object label. This is an implicit access control system because the action that it then takes to permit or deny will be based on the conditional rules that it's using to adjudicate the access attempt to the object by the subject.

A far more common model is the Discretionary Access Control. This is typically defined as a two-dimensional matrix, and has the appearance when seen to be much like a spreadsheet might appear. The two dimensions are columns, which define the access control list, which is tied on the column to the object. The other dimension, the row, is what is defined as a capability table. This shows the level of access allowed to the who or the subjects. So columns defining access control lists are tied to objects on the columns, and capability tables are on the row tied to the subjects. And the intersection between the two defines the term that says what access the subject actually has. And it will contain one of the following terms, none, read, write, full, or whatever other attributes for access subjects can have within the given system.

Now, the typical policy found is denied by default. Certainly that is the one that we're emphasizing here. And it means that in the intersection, the cell where the capability table and the access control list meet, the deny by default means the term in there would be none until such time as the resource owner or object owner changes it to some other level. Now, compared to Mandatory Access Control, this is an explicit form because each new entry immediately grants the explicit access defined in the cell.

An increasingly common form of access control model is the Role-Based Access Control model. It is true that Rule-Based also has RBAC as its acronym. Typically though, Rule-Based is called Rule-Based, where this one can be referred to and often is as RBAC. The NON-RBAC, where the subject is allowed to access the applications individually, and the rights are granted individually, and the access control changes are administered individually to the subject.

The Limited RBAC Management shows the subject accessing through applications, and then, accessing through the application, they are then inserted into a particular role based on a profile previously built through another process. But in the Limited, it's entirely possible that they may access an application without having a role assigned, meaning that the roles assigned by application access and roles for which there is no assigned access to a role can peacefully co-exist in the system.

Our Hybrid RBAC shows that the subject is accessing Role A, and through the access of Role A, the subject is given access to Applications 1 and 2. Accessing Application 3 puts our subject into a role. So here we have the forward and reverse of the process. In the one, Role A, access is granted by membership in the role. In Role B, the role that's assumed, is granted by the subject's ability to access the application first, and then, be inserted into a particular role. The final stage, Full Role-Based, is where subjects are assigned to a role. And by that assignment, they are granted access to whatever that role grants them.

Now, let's be clear. Access to any of the applications in Full Role-Based Access Control is accorded to the subject by their membership in a role, not the reverse. If it's not assigned to that role, the subject being a member of the given role has no access to it. We have other security models known as Nondiscretionary. We have Originator-Controlled, in which the originator of the particular object that the subject will be accessing assigns various parameters. And so any subject may be able to get access, but the parameters assigned by that originator or owner governs the usage of any subject.

This is Nondiscretionary because those attributes and parameters are what control access, regardless of who the subject might be or where they are. Another form is Digital Rights Management, sometimes referred to as Information Rights Management or IRM. Now, this is used in most cases to control access to intellectual properties, including music, movies, games, or printed material. And because the objects that these are assigned to are very portable over the internet, they have to follow that object over the internet.

Public key encryption and secret key encryption are oftentimes used to ensure that these features are in place and work consistently. Then we have Usage-Controlled, also called UCON, which often are time-based controls managing quantity and frequency of object access. So to Rule-Based Access Control, this is a form also of nondiscretionary access control that is also an implicit access control. And that is access by a subject is imputed through the functioning of rules rather than an attribute or a configuration parameter assigned directly to the object or to the subject.

Then we have the security model known as Rule-Based, which is a more general type related to the Mandatory Access Control type. This too, is a nondiscretionary form of implied access control. The implied quality comes from the fact that the subject member based on the conditional parameters stated in the rule, usually taking the form of if/then, being the most typical form, comparing various parameters of the subject with those of the object before access is granted.

The rules are normally written by an administrator level privileged user, oftentimes representing the system or application or data owner, and then, are put through rather rigorous change control before implementation. Typically, the rule is written. Then rule is tested and the results are reviewed and accepted or rejected, depending, and then, the rule is actually implemented in production. Now, one thing that is different about Rule-Based Access Control, and this would be equally true of Mandatory Access Control, the rule has global effect over all applicable, that is to say all subjects and objects that fall under it, that have the respective parameters the role requires, and mediation will take place in all of those cases system-wide where Discretionary Access Control works only on the specific subject-object interaction.

Then we have yet another form of Nondiscretionary Rule-Based Access Control that is implied based on attributes. Now, this is slightly different than the previous ones we've talked about. The rules will, once again, compare parameters, but it's looking for a specific match or a specific combination of attributes of the subject with attributes of the object. Once again, the reference monitor will work to do its mediation between subjects and object, based on the parameters that have been read by the rules and what is allowed for the subject to do.

Now, the third A, as we mentioned earlier, of the Triple A Services is accountability. Now, this particular A actually contains two others. Accountability, of course, is establishing responsibility, access, or guilt, if you will, over a particular subject that has taken action on a particular object. It is the result of an accounting that is recording to the logs, all the activities that the given subject has taken, and all the objects over which that subject has taken those actions. And then, the act of auditing, which takes the log with these records and reviews them, and then, applies a policy to judge whether or not the interactions they're looking at in the logs are in fact allowed by policy, or if some other action needs to be taken.

The thing that accountability does, as I said, is it establishes the responsibility and the behavior of a subject in a given session over the various objects that they've touched in that process. Now, this is to determine a level of appropriateness and compliance about the subject's behavior. It also is a protection against the subject's ability to repudiate that, "Hey, I didn't do any of those things that this log is saying I'm doing."

A log can only record what it is assigned to record, but it cannot falsify records. And so we take it as a true and fair representation of what subjects do in their interactions with objects. And as long as the log writer itself has not been in any way tampered with, it is a level of proof that we can trust. It also of course has great operational value because it will record everything else that goes on in the system. So what it will do is it will record these behaviors, but it will also record anomalous, unexplained events, and provide the basis for doing proper problem discovery and resolution.