Security Architecture & Design (part 4.2) Assurance

Video Activity

Before we wrap up the security evaluation topic for our chapter on Security Architecture and Design, we introduce the concept of Assurance, define it and how it's established and used. We also give a thorough discussion on Common Criteria with a an explanation on ISO standards and what they mean, and how all the other elements of common Criteria fl...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

2 hours 5 minutes
Video Description

Before we wrap up the security evaluation topic for our chapter on Security Architecture and Design, we introduce the concept of Assurance, define it and how it's established and used. We also give a thorough discussion on Common Criteria with a an explanation on ISO standards and what they mean, and how all the other elements of common Criteria flow and come together as an effective evaluation strategy.

Video Transcription
And when we talk about trust of the product, we're talking about the function of a product.
Okay, What is the product do? Does it provide cryptographic support? Does it analyzed for covert channels? Does it? This this, this this and this. Okay, that's the trust of a system. And you want to know what the system does, of course.
But there's also another piece that we would want evaluation off. And that's called assurance. And what assurance speaks to is the reliability of the process,
the reliability of the process. So trust tells me the function of the system. Assurance tells me the reliability of the process, trust versus assurance. And that's what this evaluation criteria was designed to create.
Now, to get a good, solid understanding of how a system's gonna work, I want to know what it does. But I also want to know what process you used to develop this product.
Show me your documentation showing your change control. Show me how you tested this product. How thorough the testing process. Waas. All right, so the one of the big drawbacks of the Orange Book is it did not differentiate air did not allow us to separate out trust from assurance so I might have a product that does,
Ah, whole lot of different things.
But if the process to create that product was not reliable, it's not gonna work very well.
So the Orange Book did not allow us to trust separate out trust insurance. So incomes a book called the It's Sick and you'll see here They talk about assurance they renamed Trust Functionality, so that makes perfect sense. It was called Trust With the Orange Book. It's called Functionality from this point forward.
But trust was always about the functionality of a system, so it just makes sure it makes sense to call it functionality.
All right, so the insect was the first model, and this could be testable. This was the first model that separated out trust from assurance, meaning it gave us a way to evaluate what the product does and then a separate means to evaluate how reliable the process waas. Now,
with the Orange Book, you had 10 ratings for function. You had seven ratings for assurance, so you would have an E three F four system. But nobody knew what that meant. Really? You know, it was way too flexible, you could say the orange books too rigid. The SEC is to test is too flexible.
So what we did is we took what was good about the tick sec
we taught took what was good about the its SEC. We let those pesky Canadians have some input with a document called the C T. C Peck, which was Canada's evaluation product. We took some federal guidelines and some needs, and we came up with, and this is important and
international standard, which is exactly what the common criteria Waas
orange book was for the U. S. It sec was for Europe. CTC Peck was for Canada. And now we have ice 0 15 for 08 and international standard might be worth knowing that, And what the common criteria does is it gives a very clear path to get a system evaluated
and raided,
and it allows the separate the separation of trust versus assurance. And it is currently what we're using to determine the value of systems and not just the value of systems, but the degree of protection they provide, as well as the reliability of their process.
we have several elements within the common criteria and you'd wanna have an idea of the flow and how these elements come together. So
what we're gonna start off with is, um is a need. You start off with the need. Okay, So a government agency has a need for system and they have a whole set of requirements. Ah, whole set of problems. They want this system to solve for them
and they release those requirements in a document called the Protection Profile.
And sometimes that will be represented with double P. Okay, so peopie is the protection profile that comes from the client. Here's what I need
now the next step. You know how vendors are when a client releases a need, vendors come out of the woodwork and say, Oh, we could meet that need for you and they divine design a system and the system that they designed to meet the clients protection profile is called a tow. A target
of evaluation. It's abbreviated toe
often so the target of evaluation is the system the vendor provides to meet protection profile.
Great. Now they also provide supporting documentation called the security target.
So both the toe and the security target come from the vendor. The toe is the actual system to meet the needs of security. Target Mint is a document that says, Here's how my system meets the protection profile of the client.
All right, now they'll also throw on additional packages. And as I mentioned, I'm just, uh just purchased a car, and it's amazing all the different packages they want to throw at you with a car, you know, I get a minivan. I don't really need a racing stripe. Don't really need a spoiler on the back, you know?
So they have all these different packages that they want to sell. You say, might He is a vendor.
You know, if you want this package for this environment or these different sets of functionality, you can purchase them as what are called evaluation package. Now, what happens after that? We submit to 1/3 party auditor and the product the toe is assigned one of seven
e a l ratings evaluation assurance level ratings.
Um, I think if they were to ask you about any one of these, I think the one that would be most relevant to us is e a. L four, because that's really kind of the de facto standard of these products. You know, if if I were to release a new firewall, most likely I'd like an e a l four That gets me in the most government agencies for most environments.
You know, we're not talking about high end
Pentagon worthy, but we're talking about the desk cops of government computers. So e a L four's most likely as the values get higher,
you have a more thoroughly verified system, meaning we've verified very tightly, very thoroughly, that this system meets the needs of the protection profile. So the E A L seven means that it meets the protection profile much betterthan e a L one.
Okay, so a quick review here client produces a protection profile. That's their list of requirements. Vendors provide a target of evaluation, which is a system to meet those requirements, as well as a security target that details how the toe meets the requirements in the protection profile. The vendor may also a
include additional evaluation packages,
then submitted for third party audit. The auditor identifies both trust and assurance topics. Remember, they're calling it functionality and assurance and then assigns a rating e. A. L one all the way through E a l seven. That a factor standard is e a L four
now. Ah, lot of times this e a l rating is an important step in determining whether or not we're gonna bring a system onto our network. Right. We're looking for system with certain rating. Now, before we would put that system on our network internally, we would look to go through a certification in accreditation process
When we talk about certification,
what we're looking at internally here is we are evaluating the, um, the security features of a product in a particular environment. It's a technical evaluation. Okay, so this isn't cost benefit analysis. This is doesn't work. Does it provide the degree of security that we need
in our particular environment?
This might be done by que es might be done by testers or engineers. But this is something that tests from a technical standpoint.
Once we pass our product passes certification, it moves to accreditation. And accreditation is where management formally accepts the product. Management says yes. This is the product we want. Let's move forward with it. So it's at the point of accreditation where management accepts all risks associated with the problem
Up Next
Enterprise Security Architecture

A framework for applying a comprehensive method of describing the current and future structure for an organization?s security processes so that they align with the company?s overall strategic direction

Instructed By