welcome back to CyberRays. It's of course I'm your instructor. Bread roads. So let's talk about the glue that holds all of these things together from needs, uh, to our system requirements to our architecture, er, to our detailed design to implementation.
Ah, lot of this is held together and checked on by assessing information protection, effectiveness.
So in this lesson, we're gonna talk about the ISI tax here. We're gonna look through the activity linkages, and we're going to revisit the CIA Triad and talk about those areas again because those were very much what we're assessing when we're thinking about this process.
So in assessing SC task, they're pretty straightforward. We're gonna look at the results of each of the areas that we've talked about previously. We are going to interment. Whether we're meeting quality on quality is really important. We we don't just do quality for the sake of doing quality. We look at quality
for the operating environment where the system, service capability, element function, whatever it's supposed to be operating in.
Um, if we don't test back to the aerospace field example, if we don't test ah satellite components in a vacuum on, we just launched him into space and hope they're gonna work. I guarantee you they won't work. Right. So we have to. We have to look at that operating environment.
Another important word here is is functions and satisfaction. Right? We're gonna look to see if what we expected of the system, the security, control, the capability of the service. We're gonna look at the functions that it performs and determine whether it actually meets what we specified in the designs
on. Then what would attest to Because if it doesn't meet functional if it doesn't
meet performance functionally, it will clearly probably not be accepted
on then, of course, satisfaction, Satisfaction of mission needs. This goes back Thio. It sounds a lot like validation, but satisfactions just a little bit different. The sense that you could certainly validate mission needs. Right? But if the customer still doesn't like it, they're not satisfied. And so that's the satisfaction of mission needs.
So there's some interesting activity linkages here as well. If you remember the chart that we showed previously, all of these areas needs requirements. Architecture, design and implement are also tied out to assessment because we do assessment along the way like, for example, in the needs area
we're looking at. Did we assess? Did we get the threats? Right?
Right. Are we over assessing on threats or were under promising on vulnerabilities? Whatever the case may be, that's what we're looking at there when we're talking about security requirements, right? We're assessing whether we get the boundaries right, Because if you don't draw the boundaries right, when we develop these very complex systems,
it's likely that you're going thio cause a breach or or open up a vulnerability for exposure. So you gotta pay attention to that
in architecture. Er, we're really looking and assessing our risk analysis process for the different elements and functions we need to we need to use in our security controls. And then, of course, you have developed a detailed security design. Andi, that's where we're assessing again. The mitigation. Right? So we
did in the architecture. We looked at our risk, this risk analysis and the,
uh, design work. We looked at our mitigations and we're assessing whether they're actually going to work.
Then, of course, when we implement, that's when we're checking everything. Implementation really strays off into things we've talked about previously secure operations, operation on and maintenance disposal Decommissioning. We're assessing all of those things. And remember, that's a continuous process, right? We don't just assess once and walk away.
We're gonna go back and assess over the life cycle,
the life cycle of a system.
So C I A. Confidentiality, integrity, availability, and so assessment, especially after we've done implementation, really is gonna look at these three areas it's gonna look at. Are we keeping people that aren't supposed to have access to the data out? That's on the unauthorized access and confidentiality?
I'm in integrity. That's what we're thinking about data
in transit data at at rest. And are we keeping the data itself or the systems themselves from some unauthorized changes? Unfortunately, in today's world, with the complexity added of cloud, that is getting more and more difficult, we are forgetting, and we're seeing a lot of misconceived oration problems across
all of the cloud service providers
because it's it's really hard to ensure that all the users and developers and the administrators understand all of the nuances of those because they're very complex products. They're great products, but they're complex, and so integrity's aerial is a real and growing challenge today. And then, of course, availability. Um, that's the e commerce example. We've got to make sure that
users have the access they need whenever they need it, so that we stay out of that.
The business of spending a lot of time doing help that stuff on DSO that availability thing becomes key. So when we're assessing the implementation after we've done all of our work up front with the system or security, control or whatever, we're actually looking at the CIA Triad in depth.
So activities here for the ISI. We talked about that. The effectiveness of all of those areas, the needs, the requirements, the architecture, er, that designed the implementation. And you notice I'm saying that in order you need to memorize that for the exam. It will definitely help you. But the other things we think about here when we're talking about information protection effectiveness
the I triple A right. Are we are we doing authentic doing the identity, authentication, authorization and accounting? And then are we tracking? And the accounting piece is important because that's where we get non repudiation from which is, you know, user user Bob can't say that?
Oh, no, I did. I totally didn't log onto the system. Well, we've got a log, Bob, that shows that you did. And it may not have been you, but it could have been somebody that stole your credentials. And so
that's important here, too, because it's a holistic approach. It's a multi disciplinary approach. We're doing our assessments. We are looking at every single facet of our systems and the connected systems and that, uh, the information system set that we're dealing with remember the system of interest where we had all of the enabling and all of the external
connections and different services and process system make the whole system work within the operating environment.
Well, we're talking about assessing information, protective effectiveness. That's what we're looking at.
So in this lesson, what do we look at? We looked at ISI tasks. We talked about activity linkages, whereas the assessment process sort of site sits outside of each of our areas of needs, requirements, architectural design and implementation. And then, of course, we talked how
assessment helps us to ensure that our systems, services, elements controls,
whatever the case may be, are fitting within the construct of the CIA triad where it makes sense.
We'll see you next time