So we've talked about the significance of a layer defense. And let's talk a little bit more about the various types of medicating controls because this is where you're gonna get your actual mitigation. That's where you're gonna get your laboring.
So I've alluded to this before, but we have administrative, technical and physical controls to choose from,
and the best response is to combine them, right? Don't rely too heavily on technical controls. Don't rely too heavily on physical or administrative. We have a combination.
So when we talk about administrative controls, what we're thinking about policies, procedure standards, baseline guidelines,
training employee handbooks, those things that come to us from senior management.
Thus say it. The managers okay,
technical under cool controls. These were the ones that many people immediately go to, particularly on an information security test. We think we can I enter encryption or firewalls or all these elements, and while they're important,
they are part of a balanced approach
and then physical security, making sure we have locked doors, making sure that we control access to our facility, that we perhaps have closed circuit TV to monitor the perimeter
right? We want a combination of these controls
now, just some examples of technical and physical and managerial. You know, technical could also be called logical controls.
Managerial controls, An administrative controls could be used interchangeably. So, you know, just be aware of that now,
in addition to having administrative, technical and physical or like you see here managerial,
we also have controls that have specific purposes. Earlier, I mentioned proactive controls and reactive
Well, some are directive controls that essentially present a message or an instruction. Then we have a deterrent. And a lot of times people confused, deterrent and preventive.
They are both Proactiv controls. It's just that preventive is much stronger than deterrent.
Deterrent says I'm gonna discourage you.
Preventive says I will stop you.
So, for instance, a well lit area is going to deter an attacker because they think I might get detected,
but a fence will prevent them.
Now I know what you're thinking. Well, anybody can climb, climb a fence. Yes, but
if you want to look at it that way, any defensive mechanism could be compromised. So it's not about can it be compromised? It's about Will it physically stop you?
At least for a time period?
Okay, so offense will physically stop you. A locked door will physically stop you.
A sign that says beware of Pug. That's not going to stop you. Right. But it will discourage you.
all right. Um, Detective after the fact
intrusion, detection systems, audit logs, alarms, there's air, all detective
corrective means we're going to fix the problem. So maybe we will quarantine and infected file. Um, maybe we repair a broken product, whatever that may be.
Recovery means we're gonna restore operations. So brings data back from backups, for instance, or having a disaster recovery site.
And then the compensating control, often with compensating controls. Its there in case the first Control either doesn't work or isn't available.
So I want a security guard, but I can't afford one. So I get a doll.
I want a real doll, but I can't afford one. So I get a pump.
Yes. For whatever reason, it's abused the public. I love my pug dearly, but
if you've ever had a pug,
All right. It is so layer defense. Layer defense, layer defense, physical,
technical, managerial, or administrative controls. Proactive and reacted as well.
And I think this is a good chart. I'm not gonna go through this again, but this just is something good to Paul's on. And take a look at how the controls work together, ultimately to protect our assets, just like what we were discussing.
And we always know that whatever the control we're gonna implement in,
we must have predefined objectives for those controls. And we have to monitor and observe the controls to ensure that their meeting those objectives I'm not gonna go out and spend $60,000 on a firewall and go
right? I'm going to detail. What? The objective for that fire Wallace. Is it going to lessen internal?
internal compromise from an external threat by 3% over the course of the first quarter?
You know, we have those objectives they need to be documented, and we have to measure against those that has to be determined. While we're planning
for the control while we're doing the initial analysis,
as opposed to planning how we're gonna measure it after we've already implemented. That's something that should be decided very early on.
And when it comes down to it
with the system development life cycle. You may also see this in reference to software development. When it comes right down to it, every single step of this life cycle
has risk management activities related to it.
Even in the very beginning, stage of initiation will Here, we're trying to determine. Is this particular system feasible? What are the risks associated with the system? This may be a very high level, but when we're getting those requirements for the system and were initially thinking, Okay, here's the function of the system.
Now, what are the risks associated with? Right, So we'll get the functional requirements from the customer. We will think about you know, you. My customers asked me to develop a database ascend database software that they can use to store patient information.
Well, I have to start doing threat modeling and start to think
Well, how could this system be improperly accessed and who would benefit so immediately? We go in thinking about risks
during that development acquisition phase. So we're looking at actually bringing the system online, actually developing the design,
we're going to want to implement the risk strategies that we thought about during it.
Excuse me during initiation
Phase three. When we implement, we're gonna make sure the security mechanisms and controls are in place and we're going back and making sure that they're mitigating risks appropriately, as they continue to operate, maintain we conduct all its were examining for
new risks because the threat landscapes always changing.
And then last but not least, when we start thinking about disposing of the system or software, we have to think about things like, Okay, what happens if they're remnants of information or what happens if we don't have proper disposal techniques? So risks exist at every level of the software development life cycle,
and we have to account for them
during the planning and throughout all the other stages.