now what process would be complete without documentation? Always we like to document. So once we've done our calculations were gonna update our risk register. And if you recall, there were fields on that register and the register is very proprietary. Each organization has their own thing. But you should
have a field on that register to indicate a quantitative value for the risk,
because again, that'll drive your mitigation. Ah, some other documents all to show you. So there's our risk register here. We don't have a quantitative. We just simply have qualitative analysis on mine. Even if it's a field that I hide for privacy purposes and only distribute on a need to know basis, I still want an idea of the quantitative
Ah, probability and impact matrix. This is sometimes called a, um, temperature matrix, because often they use color codes green yellow, red temperature just indicating red is hot as and this is a big deal, these items in red So what we're looking for when we go back to qualitative
As far as priority risk of prioritization goes,
what are those things that are most likely to happen and have the highest impact, Because if I have a limited number of dollars to spend, it's going to be these events that are going to get going to get my greatest attention. Expected monetary value analysis. Yeah, that's fair game for the exam. And
all this really comes down to is the idea that
risk is probability Times impact.
Now, of course, they're going to give you something a little convoluted and basically what they have here is there telling you you have the potential to choose between project product A
all right now, I'm gonna market these products.
So product A is estimated to make a $30,000 profit. Great
B is estimated to make a $50,000 profit. All right,
now, with product A though there's a 20% chance that it's not gonna be well received
that's gonna be a loss of 2000 right?
All right. A 50% chance that will be well received, and it will increase my profit by 10. I'm sorry. About 20,000.
Okay. 50% chance I'm gonna gain 20,000.
30% chance that it will exceed even greater and profit me 50,000.
I'll lose 10,000. So it's negative too.
50% chance that I'll gain 10,000.
So negative to positive. 10. We've got 8030% chance that it will increase profit by 65,000 animal together, so the potential for risk is 23,000. Now, I will mention to you these in this context,
risk actually takes on a positive note, right? I've got a positive potential to gain $23,000. I was looking at an initial profit of 30,000 plus the opportunity to gain 23,000. Ah, lot of folks not nest. But a lot of folks will consider risk
anything that has an unknown outcome,
positive or negative, and they would refer to a positive risk as an opportunity.
So a lot in this class, we're gonna use risk and threat pretty closely tied together. We're not gonna talk a lot about positive risks, but I do want you to know you may hear that terminology. So basically what we're doing is figuring out okay, we can't just look at the bottom line. We have to take risks into potential
and that's what expected monetary value analysis does.
Another way to show an e m. Calculation. This is a different one. This isn't the same. One
is to look at what we call a decision tree.
So apparently, uh, you know, in this scenario, we have three choices.
And if I'm not mistaken, this vent, this was, ah, scenario where you were choosing between three vendors.
Vendor A gave us a really low bid. 100,000 bucks. That looks good.
Vendor be gave $125,000. That looks good too.
Wow. Sees given us a bit of 135,000. In a way, I'm gonna go with this guy,
except I have to go back and look ATT Risks. Okay, Now I just happen to remember the scenario that goes with this slide. So if you're wondering, where is she getting this information?
A magic and B. I just have a good memory so kind of follow along with me.
So the way the scenario went waas
vendor A is frequently late. He is late all the time. As a matter of fact, he's late 70% of the time.
And when he is late, It cost me an extra $100,000. So I've got a 70% chance of losing 100,000 bucks going with vendor, eh?
Now there's a 30% chance he's gonna deliver early, and if it does, I profit some money.
So I got $70,000 up here, 70% chance of cost me $100,000 but 30% chance of saving me an additional 10,000.
So the risk associated when you had the two together, it's $67,000. That means if I go with vendor, eh, What I can figure I'm going to spend is $167,000. All of a sudden, that bid doesn't look so good.
You can come down here to vender see. And even though he bids the highest, he's hardly ever late.
He's been late a couple of times, just a little bit 20% of the time, and it cost me $20,000
20% chance of losing 20 thousands $4000 laws.
But 80% of the time he is early and that saves me money. Saves me $10,000 of value of eight.
I take those together
135 thousand's theory journal bid. But chances are good. We're going to shave some money off of that. So I've got a total contract for a of
167,000 for C 131,000.
So now all of a sudden, the guy that bid the highest in actuality because of the lowest amount of risk, winds up being my best choice. Now I would know this is called decision Tree analysis. I would get the gist of the way it works, but I don't think they're going to do anything. They're not gonna throw anything, you know, particularly complex at you in relation to that.
Another tool that I might use when I'm discussing risk within my organization
is something called in Ishikawa Diagram and Ishikawa diagram. It's also called a fishbone diagram. So sometimes I call it a fish akala, and that helps me remember both of them together.
Um, cause and effect diagram could also be appropriate. This is a tool, but I could put up and used to convey to my team where, um where risks lie, and our team could use it to brainstorm out what the root causes of these problems are. So, for instance, let's say we're in manufacturing.
We have a particular problem with quality because you see this in manufacturing quite a bit. You see this in project management?
Here's the problem. What are all the main categories that could cause us that problem?
Okay, so maybe our equipment, maybe our equipment capabilities aren't there. Maybe it's poor design. So we would build this as a risk team, and then we would talk about it. And the idea is, let's not just fix this problem. Let's figure out what the root cause of the problem wasn't fixed. That
always if you can choose between fixing a process and a product, always fix the process. If you get a good process, the product will take care of itself. This is not amazingly clear, but it's actually a very good charts. So I decided we'd we'd, uh, take it anyway.
So the idea is all of these terms that we talked about earlier
we've got this idea of a threat event, right? Got a threat of then it's gonna compromise. Our assets were gonna suffer loss. So what do we do about it? Well, we put controls in place. And controls come from a lot of different categories. We can have deterrent controls. Detective
controls prevented. Corrective.
Compensating controls might be one that needs a little more explanation. Ah, compensating control is when, um
the control that you wanted to put in place was not available for whatever reason. So you chose a second plan. So, for instance, I wanted to hire a security guard. He was too expensive. So I got a guard dog instead. I wanted to really guard dog. That was too expensive. So I got a pug,
Whatever. All right. So
threat events, essentially, we put a compensating control in place, and that's going to reduce the likelihood of our threat.
The threat event would exploit the vulnerability
Ah, that we have in our assets again. If we don't have a vulnerability, there is no exploit. So you can just kind of get an idea of a little bit. And when the threat exploits the vulnerability, it creates impact.
The controls that we can put in place understanding controls come from many different categories. Ah, certainly we can put administrative controls, technological controls like cryptography, physical controls in place. Lots of different types of controls. The bottom line is you will always do best with a layered
There is no one device. There is no one mechanism that provides complete and exhaustive control. So what do we do? We layer,
just like if you think about how you protect your home, you don't just have a fence and consider yourself to be safe. You know, I have a fence. I have motion detector lighting. I have an attack pug. I have a sign in my window that says, Ah, this house is protected by a T T alarm system and I have an alarm system.
So we have all of these layers because we know that there is no one mechanism or device that keeps us safe.
Cat it controls generally fall in one of these categories. We often think of controls as either being proactive or reactive, and we need both
so proactive controls, prevent and deter. So a preventive will stop you in your tracks
Doesn't mean that you can't bypass it because you can. You can bypass anything. So, for instance, offense will stop me. That is a preventive control,
a sign that says No trespassing. However,
discourages me. But it won't stop me. That's deterrent.
Okay, Lighting is a deterrent.
Ah, gate is a preventive
now. Corrective controls fix the problem. So maybe there's a malicious file that are any virus program is found, and that file gets moved to quarantine. That corrects the problem,
Detective. So determining. You know, audit logs, for instance, would be good detective controls. Employee handbooks are directive. Do not do this. No trespassing. I've mentioned compensating. And, of course, data backups raid Some of those means would be recovery controls.
Don't forget controls prevented. Present a risk themselves. If they fail or they're not properly configured, they can present a risk. Also, within the software development life cycle, we have to think about security as well, right? We think about all aspects.
So from project initiation, functional requirements system designed developing a choir
installation and implement taste, shun operation and maintenance, retirement and disposal. So what you'll find is, as we move through the stages of software development again, we think about security. Throughout. We designed security into the product. And
if the word security isn't there and the word securities, they're in a lot of places. Still what are we doing here? When we test we're testing for security. We're not just testing for function were testing for functional security. There's a big difference there because for so many years when we design a product,
the question we've asked two questions.
Does it work? And then later we say, Oh, is it secure?
The question that we ask now is, does it work securely? And if you can answer yes to that question than the product does not work. So even though you don't see the word security here, we're doing security testing. That's what certification and accreditation there at the end are all about
monitoring in audits, reviewing security incidents. And then when we retire and dispose of a product making sure we do so securely, I'd mentioned to You controls deterrent detective preventive all those controls. They also should come from three main categories. Administrative, technical and physical
and the international organizations for standardization,
give us three these three categories.
N'est gives us thes three categories. They're saying the same thing just slightly different lingo. What I sow calls, administrative controls, missed calls, management controls what I sow calls physical controls, miss calls, operational technical controls by I. So which could also be called logical
Matt pretty nicely in this category. So
you know, again, it's tomato tomahto. It's, you know, a variance in lingua lingo, depending on which organization you're following. But the bottom line is layer defense layer defense. Let's not focus all our our efforts on encrypting in authentication and firewalls and all these things.
If I can walk into your server room
and walk out with your server under my arm,
we got a pretty big attack on availability and possibly confidentiality and integrity as well. We can't be too focused on any one aspect.
So again, I stress to you defense in depth, these air, some technical solutions. You would also want defence in depth administratively as well as physically as well. So policies those air administrative firewalls, intrusion prevention, routers, switches, applications
middle, where a lot of this stuff will talk about
Ah, when we come to mitigation strategy, other hardware, but again, physical security as well.
All right now, from this particular slide, all these little details around the side or not is important. However, I do have the link to this on her. That's fairly lengthy link, but This is a really good visual off
the threats to an enterprise. And if you think about it from an I t perspective, because that's what the focus here is, Think about all the areas that give us risk in the I t realm. You know, let's talk about Ah, let's not even talk about third party yet. Let's just talk about our data. So
disclosure to sensitive information modification, improper controls in place, uh, unauthorized access about physical security,
you know, poorly trained employees, um, faulty mechanisms, Week mechanisms, the infrastructure itself. You know, you walk into an environment and they've got in T Server four point. Oh, my soldiers turn around, walk right out the door and I say that jokingly. But so many outdated
pieces of equipment operating systems applications out there.
Those all bring in risks. I work for an organization that was paying Microsoft an obscene amount of money to continue supporting X p for that company. Rather than trying to update all their devices and mechanisms, they're throwing Microsoft some cash and continue to support it for us.
Probably not the best idea if you think that through.
All right, so nothing here that's testable, but just kind of a good idea. Thio kind of focus in and think about all the various areas that we can suffer loss in the world of I t. So just a couple of things that come to my mind Hardware Hardware's often poorly maintained um,
You know, sometimes in smaller organizations, they'll steal what they need from one box to, uh, bring another box up to spec or whatever. No configuration management man. This is a big problem. Documentation and controlling the changes to hardware. I ought to be able to know every piece of hardware in your organization
where it is. It's making model bios, revision number.
All of that information should be documented. And if ever there's a change to those essential elements, there should be a thorough process in place.
Often, hardware's physically except inaccessible. You've got an area that allows customers coming and going the general public to come and go. Ah, hardware walks away sometimes and frequently not on its own
software. You know, I don't know of any other product that we buy off the shelf, take home, find a flaw and go. That's what I expected.
All right, I mean, if I were to buy a car and drove it off, the lot in the tires fell off. I would be concerned. What were so desensitized to flaws and software. We simply expect it,
uh, many operating systems. You wait for security patch or to our service pack or two rather to come out before you purchase a software, because again, we're expecting that.
Um, it's difficult to keep up with patches in a production environment. You know, Microsoft has patched Tuesday, you got a lot to keep up with
disclosure of information,
improper control. What about if I have proprietary software that a vendor sold me and that vendor goes out of business? Because when I buy that proprietary software, I rarely buy the source code. So now what do I do? You know doesn't mean there aren't ways to accommodate for that. It just means that these air concerns
bounds checking an input validation if you'll remember that chart that I showed you from white hat of many of the threats like sequel injection, cross site scripting. Ah, a lot of those threats could be very well mitigated with well written code
input, validation, input, validation