our next element that we want to discuss is evaluation criteria. So we've talked about secure architectural design. We've talked about basing or integrating security into the whole process and will continue to talk about that idea. We talked about finding a secure model or, uh, on which to build our systems.
So let's say that we've built our system. Now, how do we evaluate it?
How do we convince perhaps a government agency that this system will meet their security needs? Ah, how do we convince, um or how do we demonstrate that we can provide the appropriate level of security based on our client's needs? It comes down to evaluation criteria. You know, if you think about it,
maybe you are wanting to buy a new car.
You're not gonna call up Ford and say, Hey, do you guys make a good car? I'm just curious. I've got about $30,000. I want to throw around. Do you make a good car? Nobody's gonna do that. What you're gonna do is you're gonna do some independent research. You might use something like a consumer reports or any of the other third party
evaluation criteria that's out there and that's exactly what this information is about.
So we've gone through several different flavors of evaluation criteria throughout the years in the U. S. Or with the U. S. Government back prior to say, maybe the mid nineties. They use something called the trusted computer system evaluation criteria. The Tick SEC
and the Tick SEC was much more commonly referred to as the Orange Book,
and the Orange Book really hasn't been used since the mid 90. So the first question I get is, Why are you still talking about the Orange Book? Well, for two reasons still, talk about the Orange Book because it's still on the test. So that's reason number one, and that's as good a reason as I can give you. So then the follow up is, Well, why is it still in the test? Okay, even though we're not using the Orange Book for evaluation,
so many of the terms so many of the concepts that we were given by the Orange Book
are still in use today. So I think it is relevant to understand what this what this book was about, why we no longer use it, what it did give us All right. So the first thing that it gave us was the idea of trust versus assurance Trust versus assurance.
So, essentially, what this said Waas. When you're evaluating a system there really two pieces you wanna look at,
you want to look at the function of the product. What does the system do?
Does it support a firewall? Does it provide an audit trail doesn't analyze for covert channels? Does it provide cryptographic support? What does it do?
So when we talk about what the product does, that is trust the function of the product. As a matter of fact, later on, they don't call it trust anymore. They just go and call it function. But trust is about the function of the product.
All right. Assurance is about the reliability of the process. So you want to sell me this great product that you've created? Show me how you tested it. Show me your documentation. Show me your configuration management. Show me your design strategy. So the idea is,
um if you've ever bought a product that did really cool stuff for, like, a week and 1/2 and then it broke
and I think we've all done that before
you had a product that had very high trust but low assurance, it provided great function. But because the reliability of the process was poor,
the product didn't work overtime. So ideally, with the Orange Book, we've got these two elements. So what's interesting is, even though the Orange Book defined trust and assurance, it did not give us away to separately evaluate trust insurance,
there was no way with the Orange Book to say it has high function but poor reliability.
It has high trust but low assurance, so it define those terms. It just didn't allow us to break them out. So what this book did is it was essentially a report card for Systems A, B, C and D, where the grades of system could get A was the very highest in the realm of security. D was minimum security.
within each of these grades A, B, C and D, you also had numeric divisions. See one C two,
b one, B two B three.
The higher the number, the greater the security, the more security features it included. So be one was the lowest of the B settings, and then you could go to be, too, which added security and then be three, which added security.
What you need to know for this exam is the purpose of the Orange Book.
I would also recommend that you know a, B, C and D A is verified. Protection be is mandatory protection. See is discretionary protection Thea's minimum protection
so I would have those ideas. And if you go back to Chapter one, where we talk about access control and we talk about discretionary access control versus mandatory access control,
you can see where those terms came from. See, gave us discretionary access control.
So any system that uses dack as its access control model can't get any higher than a C to writing
Mac systems. Mandatory access control systems will all be level. Be OK, so that would be the depth I would go into the Orange Book. Don't go into any sort of elaborate study of what happens at B one versus B two versus B three, but have the basic concepts,
and I would also know that it was a very rigid you didn't have a lot of flexibility, and again it didn't separate out trust and assurance.
Well, the Europeans came along and gave us a model called the It ***, which was the information technology system evaluation criteria. And they renamed Trust to be Function. So they evaluated function versus assurance, and they actually did allow to separate out function from assurance
You had multiple categories of F for function, multiple categories of E for assurance.
And what would happen is you might have an e three f four system, but nobody really knew what that meant was actually too flexible. So we took what was good about the tick sec. We took what was good about the insect. And then ultimately what we wanted to do was to move towards more off a universal
type of criteria, which is exactly what we did
coming up on the next slide, the common criteria.