Welcome back to CyberRays. This, of course. I'm your instructor, Brad Roads. Well, now that we've gone through needs, our requirements are architecture. It's now time to develop the detailed security design.
In this lesson. We're gonna talk about the ISI tasks here. We're gonna talk about the ISI effort in this area. We're gonna talk about gots and cots specifically.
So in. I had a 3 to 1 from the NSA in 2002. We have five SC tasks when we're developing our design one, we're gonna allocate security mechanism. So we're gonna take the things that we defined in architecture, and we're gonna allocate those where they need to go. We're going toe look at interfaces,
internal and external. So internal are the connections within our system external or things that connect out of our system, usually to the internet.
Um, we're gonna qualify those. And what qualify means is that we're going to test them in the environment that they're supposed to work in. And if we don't do that, it's likely they might fail. We're going to develop our specifications, and that's tied to the common criteria. Remember those evaluation assurance levels? Those specifications are incredibly important
because that helps us define our level of maturity.
Next, we're going to look potentially at what we're going to use. We're gonna either use commercial off the shelf or we're gonna use government off the shelf. We're gonna talk about those in detail because that's very important to understand those differences.
And then we're gonna look to see if we need to actually design custom security products from a development perspective.
So within the within design, the SCS look at a number of things. And it's the fourth things really here on the slide one, we start with our constraints. Obviously, we probably have things that we can't do The customer tell us that we might have a technical or nontechnical constraint. Nontechnical. Could be that we're not allowed to do it legally.
Um, a technical constraints is something that maybe the tech doesn't exist or the tech won't work the way we thought it would.
I'm the way. Obviously, consider risks. Here we do trade offs. Remember that The magical triangle of cost scheduling performance. Well, guess what It's shown up again, Uh, in an ISI and the design effort. We have to look at that we have to look. It is what we want to do or what we want to design. Cost too much. And if that's the case, when we have to get within, cost me, we give away certain requirements that we're looking at.
We've talked a lot about traceability and why it is important to trace from,
uh, the baseline, the bottom line requirement from the system, security requirements to the system requirements themselves because that traceability allows us to ensure that we're building the right stuff for our customers and then, of course, schedule and and once there, there's two really important things in schedule here. One is life cycle. We've talked about life cycle a lot.
You have got to do life, cycle, work and and management and planning within the design. If you don't, you're going to get to the end of your systems useful life,
and you're probably not gonna have a plan to decommission it or dispose of it, and then you're probably not gonna have the replacement waiting in the wings.
But then there's long lead items and you might go bad. What the heck is long lead items? Well, long lead items are are those things that take a long time to build. So I have some experience in the aerospace industry, and I will tell you, for example, if we're building or buying a component for a satellite, right, it takes a long time to get those, like sometimes years, in many cases,
because those items have to be qualified. Remember that word
like, say, in a vacuum chamber. And there's only so many of those in the world and you have to schedule when you get access to them. And so you've got a plan for that and these very technically complex systems.
So let's talk about cats and God. So God's first of all is government off the shelf. And basically, that's when the government goes out and buys ah license to something and allows all the government workers to use it. So, for example, years ago, the federal government bought ah large enterprise license set for semantic and made
Symantec antivirus available for free to folks that
what access, you know, military or government services from home. So that's kind of like government off the shelf. Um, commercial off the shelf is where you just go and buy something because it's cheaper from a vendor. So, for example, in the nineties, the U. S. Military started to buy an outfit from a nightie perspective. Information technology perspective organizations with
commercial off the shelf computers. Why? Because they were cheaper.
We used to have these mean green machines in the military that we had to buy Special built for that, and they were very, very expensive.
And that's the difference between gods and cots. One is it's on the shelf already, and and the government owns the rights to it, whereas Qatar is a something we buy from a vendor.
So when we develop those detailed security designs, I want you to remember that the ISI does trade offs and the ISI does that life cycle support. And we've got to really pay attention toe lifecycle support here because if we don't work, gonna, you know, we're going to get to the end, and we're just not gonna have the replacement system available because we didn't think about it. And that's something you need to really pay attention to. Here
in this video, we talked about detailed security design work that the SCS do. We talked about the issues, tasks we talked about the efforts and we talked about cats and goats and as a reminder, Cots is something you buy from a vendor. Gods is something that's already available and the rights to use it are owned by the government.