So we've arrived at the security models and there are many different security models that provide for us an architecture in which to design our systems so we could base our architecture on the security models dependent on what type of security mechanisms were trying to
the system that we're building. These are just a couple of them. And honestly, I really don't anticipate questions on the exam on these. Having taken the C. I. S s P exam, he will have seen these models. But if you haven't taken that exam, you may not have heard of them.
The bottom line is they're models out there that provide us a structure for implementing certain elements of security
One of the better known ones is called the Bel Lapa Djula model. And each of these models were made up of a series of rules. Now, the bell, a popular model, is all about confidentiality, and most people find that Bella Padula makes the most sense
now. This was designed for the US government in order to protect state secrets.
So obviously confidentiality is gonna be the main purpose of Bella Podgy.
There are three basic rules of Delta Padula, and there are some other rules as well. There's a lot of, um,
there's a lot of periphery information to Bella postulate that we're not going to go over. We're just gonna kind of hit the heart and so love it. But again, for test prep, I wouldn't spend a lot of time here. But having heard of Bella Pasta and knowing its essence, I think it's always been official. So basically Bell apostles about
So the first rule is called the Simple Security Property
and the simple security property says no read up,
meaning. If I've got secret clearance, I can't read top secret information
Now that's very much what we would expect, right? You wouldn't expect to be able to read above your boundaries. And that's what the simple security property says now, the reason that we excuse me back out there. The reason we expect that is because we're used to working environments than enforced confidentiality, and we'll see that their other environments
that may not do the same thing.
All right, the star security property that could also be used is basically says no right down.
Okay, no, right down And what that does is that keeps me at top secret from writing top secret files down to a secret folder. So no right down. That's way of preventing someone in upper level from leaking secrets down below.
All right now, um, the final property or room is called the Strong Star Property, and the strong Star Property says, Stay where you are
no read or right up or down
now. Like I said, Bella popular tends to make sense to most people because we're used to working in confidential environments. Now Bella popular makes sense. Great. Let's take it and flip it on its head. And that's where we get Deva. And usually Debra doesn't make a lot of sense to people. And yet, unless you have a little more explanation,
the big thing about Biber is that its goal is totally different than Bella, Pa. Jules,
it's goal is integrity.
We're gonna enforce the integrity of the system rather than the confidentiality. We're worried about the integrity of our death. So there are three words that kind of sum up with the FIBA integrity model states, and it's something up by
So when you look at the rules of Ebola down, that is dirty. The first rule, this simple integrity acts him, says no Reed down.
Why no read down? Because reading down is untrusted. Information at a lower level is not as trustworthy is information at a higher level.
All right, so no reed down
thes star integrity Axiom says no right up
again. You shouldn't be colluding the knowledge base. So if I have a lower level of intelligence, I shouldn't be writing to files that are top secret or secret family. Not have the legitimate information there. So it's all about protecting the integrity of the data, keeping the data for staying, keeping it
ensuring its integrity. Remember, the phrase down data is dirty. Now the invocation property is pretty close to what the strong star property waas with Bella Padua, then vacation property says no read or right up or down. So essentially,
and actually let me back up on that. It's really no reader right
up. It does not enforce what you could do down lives, so I misspoke. No reader right up.
Okay, So those air two models for use in very specific environments for use in the government. Bella, Pa. Chose about protecting government secrets. Bimba is about protecting the integrity and the sanctity of the death.
Now the first commercial level. Ah, and one of the most important ones. And you'll see Clark Wilson all over the place in the world and systems in life. Whatever.
Now I'm gonna give you just a cheapie definition for Clark Wilson. Then I will say it more eloquently. Ah, the cheapie definition for Clark Wilson is. Keep users out of your stuff or they'll break it.
Keep users out of your stuff or they'll break it.
Think about when I get to make a purchase on Amazon. For instance, when I go and purchase, uh, you know, I go and purchase a book. That book needs to come out of Amazon's inventory. They're sending me that book.
The same was on. Give me the password to log into their database so that I can remove that book from their inventory. Of course not. You know why I'll mess it up.
So what his aim is on do they give me a front end application that I can use? I interface? I I used the interface. The interface access is the back end database. So basically a better way or more eloquent way of describing Clark Wilson
is that Clark Wilson enforces
well formed transactions
through the use of the Access Triple
Clark Wilson and forces well formed transactions through the use of the access triple
and the access triple. Is the user
the interface in the back end database or data item that we want to protect?
Okay, those three elements or Clark Wilson?
Long story short. What Clark Wilson says is Keep what you want to protect. Your trusted resource is away from untrusted elements.
Cheap applications away from directly accessing memory.
But applications need access. Memory. That's fine fortune through an interface. If you're familiar with something called an AP on an application programming interface, that's exactly the purpose is to provide that safe. You know, middle man, if you will, from the untrusted apt to the trusted,
uh, resource of memory.
But you'll see this in the world is well, you know, if I'm a brand new bank teller and I just get a deposit for $10,000 well, that money needs to go in the safe. It shouldn't be sitting here in my drawer, but as a brand new bank teller, I don't have a key to get into the safe. So what do I do?
Take this money and give it to my,
The bank manager accesses the safe.
The bank manager is our trusted entity.
Eyes the teller among trusted.
Okay, So keep an untrusted teller out of your safe.
Forced all interaction with the safe to go through an interface, the bank teller
and you can see how that separation of duties it's about preventing conflict of interest. It's about preventing any sort of abuse of power. That's what the Clark Wilson model does for it. It's very, very helpful
now. There are many other security models on which systems can be designed, but I just wanted to mention those three because those are three of the most commonly used Bella popular, which addresses confidentiality ***, which is all about integrity, and then Clark Wilson, which creates well formed transactions
now our access control models. This is another element of system design,
and we have to think about the degree of security we want our system to provide.
Some systems are designed to be more user friendly and to promote sharing other systems or more designed to protect confidentiality of information. Um, S O, the first system that will look at is called a dak system. A discretionary access control system. This is what your Windows system would be.
Excuse me there. This is what your Windows systems would be. And really, any client based operating systems would be Dax Systems. And when we say dak discretionary access control
and the reason it's called, that is the security of the object is based on the discretion of the objects owner.
So any time you talk about discretionary security, that could be a little concerning.
But the idea is it's designed for an environment to promote sharing in these of use. So think about a window's environment when I create a folder and I'll call that folder Mine.
Who's folder Is it meat?
Who does it belong to me
Who could do whatever they want with it? Me, I am the owner.
Well, could I give permission to that folder to somebody that shouldn't have access to what's in the folder? Sure, it's at my discretion
and through the use of access control lists, are how we control access in Adak model. So the heart and soul of Adak environment is the access control list, which is why sometimes you'll hear them referred to as Dacca. Lt's discretionary access control list
because these air primarily used in dak environments.
Now this is an identity. Excuse me, an identity based system. So you're given a user account based on your identity, who you are. You know you can account Kelly H. Or K Hander Hand or John Smith or whatever that might be. And the user account is bound to you and your identity.
Now, that being said, um, you know, again think about how Windows is established and created, how you get your account. Ah, how we control access to resource is But it's not just windows, you know, most versions of limits and UNIX and any of the other operating systems that are out there
primarily used dec environment.
However, if you want a more secure environment, you have a mandatory access control model. Ah, Mac, and just listening to the names mandatory security versus discretionary security night and day, right, mandatory sounds much more secure.
Now you would see this on systems for use in the government or systems that need to enforce, Ah, higher level of confidentiality, the heart and soul of a Mac environment,
the heart and soul here labels.
So when I create a user object in a Mac environment, they get a label.
And so I'll create Bob Smith and his label is secret because he has secret clearance.
Then I'll create a folder, and the label for that folder is top secret.
So we don't expect somebody that has secret clearance to access a top secret folder.
So the decision as to access in a mandatory access control environment is made based on, um, evaluating the labels and the objects label. Or let me say this. The subject's label must dominate the objects like
so I can't access anything above my level. I can access at my level and below. I have to dominate.
But the big difference here is this is all decided by the data owner. You know what type of classification the data is, and it's enforced by the data custodian or the Security Department.
So ultimately, these labels are written in stone, so to speak, they can't be changed without a very formalized very stringent process and it's the operating system that compares the labels and makes the decision. So this is much more secure.
So Ah, secure Lennox, Or you might see Solaris with trusted extensions. Those would be Mac environments.
Now, another environment that tends to be a very good environment to, um, uh, enforce rights and permissions. Role based access control. You might see this is our back,
because in an organization one of the problems we can have something called Privilege Creek.
So, for instance, if I'm a custodian and I work in building A, I get a key to building a,
Then I go to building B. I get a key to building B.
I start work in building C. I get a key to building scene.
But what piece have we missed along the lines? We've missed getting those keys to building A and B back
same thing when you have users in an environment. So I'm the database administrator of database A. When they move me to a different role, we need to make sure that my credentials get revoked.
Well, instead of doing that, one of the things that we can do is use role based access control as opposed to identity based access control, which DAK is in a role based system. The accounts are based on function within the organization.
So with that function come a set of privileges and permissions, and they can't be changed.
This is a good way to prevent a problem called Authorization Creek,
because your account is based on your role within the organization and the account doesn't change. Permissions and privileges don't get added removed.
You might be given a new role in the organization, therefore a new role account, but you wouldn't have rights and permissions heaped on the user based accounts. So those are the three main security models, DAK, which the securities at the discretion of the owner
Mac Ah, higher level of security, where security decisions are made based on labels and then our back, which is based on the role of a user within an organization. And this is a good means to provide high end tight security as well as preventing authorization creep. So those were the security models
that I would consider when I'm designing a system