so kind of defined your security program talked about some best practices. Now let's move on to the requirements. All right, so we want this program to be enterprised. Why, right? Like, I don't want a separate program for I. T. A Separate program for Risk, a separate
program for personnel.
The program should encompass the organization,
all right, and this is going to allow us to build the architecture. And when we talk about architecture's not just technical architecture, conceptual and logical architecture means that
we don't. We're not just looking at hardware pieces were talkingabout concepts like isolation of trusted elements from untrusted elements were talking about groupings of systems by logical needs. You know, maybe how we want to organize them.
So it's a lot bigger than just We're gonna implement a firewall here.
The goal. We're gonna make sure risks or managed to an acceptable level, and we have to be able to define our security programs in terms that our stakeholders understand. You know, I think we've talked about the fact that very few people other than those of us, that our I t nerds really want to talk in acronyms
and I can throw down some acronyms with the best of him.
Okay, But that doesn't get me what I need. I need funding, and I need to support. So instead we have to talk about the business case. How does what we're doing Impact the business in a positive nature? How can I save you money? How can I give you a greater return on investment? How can I mitigate loss?
Hey, give that information to the business owners. But then, ultimately, the business owners make the decisions, right? So if there's a difference between what I recommend from a security perspective and with the business owner needs to make the business run, they're gonna win every time.
Now, document the heck out of that case. I'll say, you know, here the options that I've provided the security the business owner, though, really is the one that has to decide the degree of balance that we get between security and functionality.
All right, Um, nothing much to a security program, you know, just a handful of 15 different things, or however many there are here. But this is a huge encompassing process. So writing a security program is a massive plan.
So we start off with strategic planning and management that comes from senior management, right? They're the ones at the top of the organization that can see our long term goals, and we have to consider continuity. We have to consider physical security how we're going to do, testing what we do with incidents,
vulnerability, management's risk, security controls
and you notice how security controls air. Just one little piece of this broad structure and your security controls air where you start to get technical, like your security devices and so on. So all these pieces do you see how many of these air much more logical and administrative than they are technical? And that's as it should be.
is just a piece of the bigger picture,
all right, so when we're developing our security program, we're looking for these elements that make it work, right?
if you were to have to sum up the purpose of the development of security program, the phrase we love for this exam gap announces and closing the gap
right, so the Gap analysis piece comes from, Here's where we want to be in five years. Here's where we are now. Current state versus desired state. Right? And we might look to the c m m I.
And in that capabilities, maturity model, we might look thio ice or 27,000 won some other framework. But we gotta figure out where we wanna be.
So that's the desire that the outcome. And then you can see we look at current state versus desired state Gap analysis says, Okay, we're pretty far away. How we gonna shrink that gap?
Then we're gonna figure out what our program's gonna be, and we're gonna monitor that security program. Risk management is happening, you know. Really, this says Okay, risk management's looking between our strategy and our program. First management is all over this, right? It's all about managing risks.