14 hours 39 minutes
Now we just finish talking about policies, procedure, standards and guidelines, and those management controls will the next piece, and we're kind of wrapping up the section. But, um, we need to make sure that the systems that we put on the network the uh,
systems that we incorporate into our environment are going to fit in from a security perspective. So it's also up the senior management to ensure the proper process for certification and then for accreditation as well. So when we talk about certification, this is the
a technical evaluation of the security features of a product
in a specific environment. So a system that certified toe work in an unclassified environment, of course, isn't automatically certified to work in a classified environment. It's in a specific given situation.
So ultimately, that certification process doesn't meet the developers description.
Does it do what it's supposed to do from a technical standpoint?
Now, if that's the case, then the system is now verified, and verification says this is a correct system,
all right, and then accreditation
and accreditation is the point. In time when senior management says yes, this meat to need that we have,
we're gonna implement it into our environment.
So certification happens from your technical people. Might be quality assurance might be a technical staff, but accreditation
is when management accepts all risks. Associate ID. They say Yep, it meets my needs were gonna implement it.
Now, accreditation is being referred to now as authorization and the government so you could hear either one. It's traditionally been referred to his accreditation, but I think authorization is gonna become more and more popular
now when we look at evaluation criteria. So we're looking thio to certify these systems.
In the past, the U. S is use something called the Tick sec and the tick SEC is trusted computing trusted computer system evaluation criteria and it was known as the Orange Book.
And what the tick SEC did is it evaluated the system based on a certain set of requirements and assigned a Grade A, B, C. D.
And within several of the different categories there might be B one B two, B three
and each number increased security.
Okay, so a was the most secure system.
Then be even see them
now within Be you had one,
then be two was more secure. Be three was even more secure.
All right, So the problem with the tick sec, though, is that it was very, very rigid. It was like a checklist, and there was no wiggle room. So if your system didn't meet every single check box to be a B system than it was dropped down to a C level system, which was actually a pretty big deal because you had to have certain levels of evaluation in order to sell
your system to government entity. So it's a
big deal if you didn't get a lease to see two rating, but some environments needed higher
Well, because that was so rigid. The Europeans came up with something called the its SEC, and that was more flexible, a CZ, a matter of fact that it was almost too flexible because it allowed for a lot of different ratings. It was hard to figure out what they meant.
So ultimately with the tick sec that it's sick.
Um, the CTC peck, which came from Canada. Some government requirements, all those together, are now implemented through what we refer to is ice 0 15 4 away. So international organization of standards that tells you it's not U s or Canada or European Union specific.
So the common criteria is an international standard is specified five by ice. 0 15 4 away.
And ultimately, the way the common criteria works is his followers.
All right, if you look at the common criteria, we start off with what's called a protection profile,
and the protection profile comes from the customer. It's their set of requirements what the customer needs, all right. So they'll write up their requirements in a document called the Protection Profile.
they'll release those requirements to vendors and a vendor is gonna respond by building a system to meet those requirements, right, you're an agency of the government. You need a certain number of systems in this particular environment. I can do that. I'll build a system,
and that system is called the tow the target of evaluation.
So the toe is designed by the vendor to meet the customers protection profile.
Now, in addition to the tone,
the vendors gonna produce a document called the Security Target. And that security target is gonna detail how the target of evaluation meets the protection program
and then the vendors gonna pay to have their product audited against the protection profile and two things function and assurance will be evaluated. And based on that evaluation, something called E. A. L an evaluation assurance level.
I just want to mention function versus assurance.
is what the product does.
Assurance is the reliability of the process.
So the function is the product. What is the product do? Has a firewall. It supports audit. It analyzes for covert channels. Blah, blah, blah, blah, blah. Okay, that's function.
Show me how that product was tested. Show me its documentation. Show me change control configuration management.
That's gonna be assurance. So common criteria allows for the evaluation of each, and that's really important.
Now the evaluation assurance levels we have e a l one functionally tested all the way up through E. A. L seven, formally verified, designed and tested E A L seven means that the requirements are met all the way through the most stringent testing.
A. Usually, when an organization has a product that they won't certified by common criteria, they're usually shooting for E. A l four. That's kind of the de facto standard. That's what's required in unclassified environments tohave a system on the desk you know, in government environments.
So usually that's what an organization shooting for, because to go above and beyond that
cost additional money in additional time.
Now we'll say once your product is certified just going to remind you again that that simply means it's past its technical security requirements. But it's not until authorization or accreditation that that system goes into the workplace
now again. After that happens,
we've already talked about monitoring in metrics, but once that system has moved to production, we continue to monitor right and we monitor to see if the system's meeting its objectives. So in order to know if it's meeting its objectives, we had to have documented objectives. We had to
document how we're gonna measure up against the metrics and make sure that we have a schedule on which we can monitor.
And don't forget. We talked about our different types of gold strategic, tactical and operational.
So when we're looking to monitor strategic objectives here, we're looking at things like our project plans. Those projects are gonna help us meet our strategic goals.
Um, results of disaster recovery tests, audit results, Lord, you know, long term things that will have an impact on the functioning of our organization is a hole.
All right, then. Tactical. More midterm. Our people in compliance with policies. How are change control processes? What's the response? Incident? Response. How's that working for us? And then the operational metrics Those day today. You know, we talked about security operations and we talked about,
you know, reviewing our ideas. And our i p s looking at the firewall logs and honeypot logs.
Are we patching our system? So, you know, again, after certification and accreditation, we tend to say we're done here. Don't forget, we followed those processes. Once the system is implemented, we still have to continue to monitor and try and make sure that we're meeting the metrics that were specified.