welcome back to CyberRays. It's of course I'm your instructor, Brad Roads. So now let's talk about implementing system security. So we've after we've designed it, we're actually gonna actually build it implemented, do all of that work.
So in this lesson, we're gonna talk about SC tasks. We're gonna talk about one of those technical processes integration. We're gonna talk about testing.
So there's six task CSC does per eye out of 3.1 in our implementation area. Inputs to Sienna or today we call it our getting our authority to operate our interim authority to operate Sienna is certification and accreditation.
We're gonna provide information to the assessors, the folks that are gonna be testing system testing the controls. We're gonna provide a lot of that support in the information protection assessment. We're gonna verify the system pretty straightforward. We're gonna track and test
as an information systems security engineer because you are in these systems engineering family. You're gonna do a lot of tracking and testing.
That's not your stick. You probably should should get excited about, because that's one of the things you're gonna do. You're gonna spend a lot of times looking at test plans, operations, procedures and training materials. Why? Because sometimes it's the issue that actually builds the control itself. And so guess what
we have to do that good documentation work. And then, of course, you know, we've talked about the fact that systems engineering as a whole is an interdisciplinary process. Well, so is information systems, security, engineering. And so we're gonna look at, you know, the system on issues and the services and the controls and the elements and whatever it is we're doing for our system,
we're gonna look at all of those
it from many different angles from that multi disciplinary aspect.
So there's three things you remember. When it comes to integration, it's form, fit and function. So form, eyes pretty straightforward form is, does the product or the capability or the whatever it is we're doing? Is it in the right form or format that we need? So
the way I like to remember this from a from A system security and information systems security perspective is form
when we're building an A P I and application programming interface on let's say you're doing cyber threat intelligence, and the customer says, I want that in sticks,
which is a standardized format for sharing threat intelligence, or I wanted to miss. But which is another format? Well, that's the form they're asking for. The form
fit. So again, back to our A P I model, um, the folks we're gonna want that to fit in a certain way. Maybe they want it as a command line capability. Maybe they wanted as a gooey right. So that's sort of the fit
on, then. Obviously, the data that we're using out of our say threat intelligence feed their coming in a particular form
have to fit into our, uh, extract of via the A p I and then function. It has to work right and function typically deals with the idea that, um, it's going to be up a certain amount for a certain amount of time. It's going to allow you to pick and choose what you want, right? So remember
integration of products, capability, services, whatever,
a lot of times comes down to form, fit and function
when we're testing. This is where we're talking about the two V s. And we've talked about these many times verification and validation and remember verification, especially here in our systems Engineering V construct, um, is all about Did we meet the requirements? Did we build
to the requirements If Widget X was supposed to actuate 16 times in a second?
If we if we if which it x does that, we have met the requirement. Now if Widget X fails directly after that and has to be replaced, guess what? We probably haven't validated it, right? So that's where we talk about validation. Validation meets those customer needs and expectations and super important here.
You sort of see across the systems. Engineering via is an example is that
we need to be able to trace requirements up and down all the way through, from the needs to the requirements to the architecture, to the design to now the testing and vera the testing, verification and validation right after we implemented that system, and and and even when we're in operations and maintenance, so that
we can ensure the system continues to work and meets the needs of the customer.
SC activities in three implementation side cover the entire gamut of the system for the ISI, we're focused on. Those were focused on those information systems security requirements and that could be threats and vulnerabilities that's going back and assuring that were mitigations air meeting the risk management
items that we put in place.
We're looking at all of our life cycle. Support all the procedures off maintenance training needs all of that stuff right today, as we've morphed away from the certification and accreditation processes, we now look at the risk management framework, the RMF, and that's where we find
the discussions of things like authority to operate or interim authority to operate. And so rmf is a huge piece of what you see is need to know today
on. I certainly encourage you to get into that as you're studying for the exam.
So in this lesson we talked about the SC tasks we find and system implementation. We talked about integration, which is where that form, fit and function come in. And then we talked about the testing piece, which is our verification and validation, which we've talked about many, many times. So you might get that That's kind of important
We'll see you next time