welcome back to CyberRays is. Of course, I'm your instructor, Brad Roads. So let's now talk about defining the system security architecture. Er
so in this lesson, we're gonna talk about ISI task a little bit different from the previous lesson. We're gonna talk about tools. We're gonna talk about the outputs of this particular task.
So from my added 3.1. So the information assurance, technical framework, there are six ISI tasks in defining the system security, architecture, er, their decomposition. So that's where I take and I take all of those requirements and I functionally decomposed them.
There's interface allocation. We talked about external and internal interfaces. We have to map out where those go.
We're gonna look at our components. We're gonna look at our residual risk assessment. Remember, part of our work as an ISI is to do that risk management process which we started when we were working on this initial design on. We're probably going to need to look at, you know, the controls that we're thinking about that might be tied to this
toe actually start to do some of that risk mitigation work.
Now, we're gonna look at identifying specific security mechanisms that we may or may not use right. And those could be things that we buy. Those could be things that we build, whatever the case may be. So I know there's good question
and the question you're gonna ask me, and you're going to say, Brad, why don't we do the system security architecture er
before requirements so we know what we're building. Thio.
Good question. We that that it's always that cart before the horse argument there,
Um, in my experience, if you don't have requirements first, you have nothing to build in architecture to. I've seen that in in cybersecurity range design. I've seen that in multiple design aspects where if you just start building the architecture, er, that's where you get to scope creep. So it is very important to define your requirements first and then build your architectures.
So there's some great tools when it comes to framing and architectures on doing that system Are the system security architecture er development, Right? Um one. And these are all from the Defense Acquisition University. One is the functional flow block diagrams. Remember, we talked about
function analysis and taking all those requirements and putting them into their
functional bins. Well, after we've done that, we need to map out how those requirements all connect. And we do that via the functional flow block diagram.
The next thing we have is a timeline analysis sheet, and so probably you're all familiar with this. It's called a Gant chart, right? Microsoft Project. Was it? Monday is the online one. The Jura at Lassie and sweet provides support for these kinds of things. Anyway, you do timeline analysis when you're developing
how a system is gonna fit together and how you're gonna develop it, you're obviously not gonna
you know, eat that ton, ton elephant all in one sitting. You're gonna do it one by the time and so, timeline analysis we're doing architecture development is incredibly important. And then we have the requirements allocation sheet, and this is super important where we take across the phase of development of a system and outline where we're going to actually put them together and test them.
And so requirements allocation is another way to take and functionally
define your architecture for a system.
So outputs of our architectural. Right, Well, we're gonna salute. We're gonna we're gonna do some things were gonna select our security mechanisms. What controls we're gonna use
we're going to define
are elements right on bats. What? We're going to find those those interfaces. Okay,
we're going toe allocate security functions, and this is important here. This allocation word is incredibly valuable here, right? We may already have stuff in place. I d s I. P s fire, while whatever right that we don't need to actually build, right? We're just building the next set of elements for whatever new system we're doing. We might rely on other security functions that are already in place, so we're gonna allocate stuffed with them all.
We're gonna identify dependencies now. Dependencies, air important. They're both lateral, so side to side, and then there, up and down, all the way up to the top level system that we're integrating into. If we do not identify dependencies, it's likely that whatever our security architecture is going to look like isn't going to work.
And then we're going to do that. Risk analysis and assessments. That's a super important part here. And this is a great place where we get to involve the customer. Because guess what? The customer is who decides whether they're going to accept our mitigation strategies that we talked about in previous lessons? Um, or not right. And so you got to involve the customer here.
So you see activities in our defining that system security architecture. Er, we're gonna figure out the services. We're going to select our mechanisms. We're gonna identify components or elements that probably there have to be procured or built. We're gonna allocate those functions as appropriate between elements and dependencies. Right? So again, here's a chart. Here is where we've
we're showing where we define our system requirements. Right?
And then, really, what we've done after we define the system requirements is we're drawing inside that black box What the system interfaces air all going toe look like.
So in this lesson, we talked about it. See tasks as relating to defining the system security architectures. We talked about some tools you could use. Um, we talked about the functional block flow diagram, the GAN charter timeline, analysis and requirements allocation.
Then finally, we talked about the outputs, and there's many of them that allow us to get to what we do in defining a system security architectures for a system.
We'll see you next time