All right, let's go and pick up with our our second module after the introduction, risk identification in this particular module, What we're gonna covers. We're gonna talk about the standards and the frameworks in the practices that we have to think about when we're looking at first addressing risks.
And then how do we identify those risks? Where do the risks come from? How do we go about documenting them?
What are some tools that we can use? We'll talk about the difference between threats and vulnerabilities. A lot of times people use those words interchangeably. They're very different. They're kind of two sides of the same coin, but they have very distinct meanings. Um, no. Here stakeholders are
one of the biggest risks for a project. Success is not having the proper requirements. Documentation. Well, if I don't identify my stakeholders, I don't know what their requirements are. And then, of course, my project's gonna fail.
All right, we'll talk about some risk scenario, development tools and techniques, some ideas behind risk management, just kind of some broad ideas. And then we'll look at one of the most important tools with risk management, the risk register and will create a risk register in the identification piece, but we will continue to use that document.
It's really one of the most important documents you'll have in relation to risks.
And then, of course, being aware of risks as they come up and monitoring those for existing risks. We've got several different frameworks, and per I sacha, you do not have to memorize thes framework so you don't have to know all the requirements of co bit five. You don't have to know I so 27,000 or any of the n'est ce
What you do, wanna understand and really the references to them are more for your edification
so that as you want to continue to go grow in the risk management field, you'll know some supporting documents and frameworks that you can look to her. Um,
but I would not spend if you're prepping for the exams. Don't spend time here. One of the first things that I'll mention is the plan Do check Act model on it goes counterclockwise Plan Do Check Act. W. E. Deming is credited with popularizing this model, though it actually existed before
he did so. Ultimately,
this model perfectly applies to risk management.
Because we start out in our planning piece, we gather information. What am I protecting? What's it worth? Water threats and vulnerabilities? Hey, we're planning gather information. Next thing we're gonna do is part of our planet's figure out howto protect those assets, how we're going to make them less vulnerable.
So we come up with mitigation strategies, and we put him into place.
We checked to see if the mitigation strategies protect our assets to the degree that's appropriate and if they didn't react upon it.
So Plan Do Check Act is exactly the world of risk management. The whole point they're being You're never done with managing risks. There is always more to do in risk management. The capability maturity model integrated. This comes from Carnegie Mellon, the security engineering institute out of Carnegie Mellon.
And ultimately it's a way of evaluating
the project management maturity within an organization. And that speaks to the risks associated with choosing one vendor over another.
For instance, if I choose a vendor that has a very immature process, then I can expect less than quality product. However, if I choose a vendor with a very mature process
on a big believer that a good process will yield a good product. The better the process, the better the product. So Essie I essentially evaluates vendors. Usually this is around the world of software development based on their maturity. Most organizations are looking for a three,
meaning that we have a clearly defined set of processes in place
and that we have a very standardized and methodical approach to project management. An organization like NASA, for instance, will have departments that optimize Lockheed Martin Boeing, some of the higher organizations, but usually based on cost benefit analysis. Most companies strive for a three
I. So 27,000 is also a framework that essentially lays out some different concepts in relation to risk,
part of the 27,000 Siri's that addresses configuring an information security management system. And so an extension of that talks about the different elements of risk management again thes air documents that you could go white papers that you can pull information that you can collect to build your own knowledge.
They're not necessarily they're not necessary to pass the
I am. You should see no reference to any of these, but the philosophies air sound and the principles of risk management are pretty universal. I So 27,005 again kind of sets the groundwork talks a little bit about the C I A triad in relation to information, security, confidentiality,
integrity and availability.
Ah, places the responsibility on senior management. Ah, here they talk a little bit about the risk contact text and that's back toe icer 27,005 meaning that the amount of risk that will tolerate really depends upon the context of that risk
and the value inherent to the organization.
So ultimately, we need to figure out what our risk context is before we set about the work of managing risks. Again, senior management really sets the tune. Ah, With their governance and their risk appetite, they set the tune for the organization. So
once we understand the security, governance, the risk management government or the risk governance,
we should understand the context in which we operate
27,005 starts with risk assessment. Now, I'll tell you this congee tricky because risk assessment is defined a little differently with I Sacha
and again I sacked as a British organization. So you will see some of the things that perhaps our international standards or nous standards. The terminology may be a little bit different. So, like I said, this is not testable. This is good background information for you. We're going to really hone in on my sack of terms,
so I don't want you getting too caught up in risk assessment here.
Every process of risk management
will always start with, identify your assets and then evaluate
always. That will always be your first step.
Okay, um, if I don't know what I'm protecting and if I don't know what it's worth, I don't know how much money I'm willing to spend, so we will always start with risk identification.
Frequently, we then go into risk analysis, which says, Give me a value for the risk.
The value for the risk is gonna help us figure out what we have in place and what's it worth.
And then how we're going to respond to the risk. And this is what I said. 27,005 is Say so. Those air couple of frameworks. You could do some additional research or not. Now, back to the world of ice, aka risk management with the sea risk. Uh,
before we get to in depth into the program things that we want to make sure that our risk management program is,
and hopefully these should be pretty self explanatory. We want to make sure that we're comprehensive and complete. Remember, risk governance for an organization is for an organization. It's not just the i t department
risk management, not just for the i T department. So I know that you and I are primarily I t based, which is why we're in this class together. But ultimately what we really have to do is we have to get our heads out of the I T basement, so to speak, and realize that we're just one entity that helps sustain the organization.
So our job is to make sure that we're dealing with risk appropriately.
As part of the bigger picture,
we have to be able to justify the mitigating strategies that we put in place for security.
A big theme is gonna be
There is no security for the sake of security.
It's on Lee security as it supports the business. So what we'll talk about is the question how much security is enough and it's a very important question is when we have to be able to answer well,
we need to make sure our risk management programs legal.
I'll give you that. Not as obvious as it sounds. Let me give you. For instance,
do I as an employer, have the right to monitor my employee's email?
Hey, pretty straightforward question.
They're my employees. They're my systems.
They're accessing through the Internet through my stuff.
Do I have a right to access their emails in to monitor it?
And the answer as the answers For most things concerning the law, the answer is maybe,
um, jurisdictions. Very laws change. So rather than necessarily spend a lot of times focusing on this is legal or this is not. Let's focus on best practices. Best practices. Say, if you're gonna monitor employee email, what do you do?
You give him a waiver to sign
and another important pieces. Not only do we do that,
but we also make sure that we apply that policy uniformly within the organization.
As in, I don't just have that policy tucked away in my back pocket in case someday I want to evaluate John Smith's email. What I do is I've written the policy. I'm gonna do it. So I have a periodic audit, an assessment of employees email,
so that if I do need to monitor a particular employee's email at some point in time, I'm not just pulling out a policy and applying it to that single individual, I can show a history in the workplace of having monitored other employees email. So the law is a tricky thing. Ah, that's why,
uh, you know, we rarely right policy.
We don't write policy without someone, some sort of representation from our legal department, some sort of insight that can help us make sure that what we're doing is within the confines of the law.
if we're gonna have policy, enforce it.
And if you're not gonna enforce your policy, don't write it. If I have a policy that says you must swipe your card to enter the building, I need to go back and review those logs. I need to make sure that people aren't piggybacking in and out of the building. If I have policies that say, um,
the only access to this building is from 8 to 5, I want to try. I need to see. So I was trying to get in the building. 6 p.m.
If you put a policy in writing, monitoring and enforce it,
you got to keep these up to date. And a change management policy will help me keep these up to date and manage change. Management is essentially a program that will help me go back and evaluate policies, strategies, decisions that I've made, maybe once per year. We go back and we look at these things and we say, Yep,
this is still up to date or
no, this is no longer valid. So change management is very helpful for keeping things up today.
Methods to identify risks. So we have an organization. Where do our risks come from? Well, this could be, you know, a huge, huge task. So the first thing that I will mention to you is this is not what you're doing on your own. You will have a risk team,
and that risk team will be cross functional. And by that I mean you'll have representatives
across the departments. And if you leave the department out, that's a department that's not represented. You will miss risks.
All right. So from there, what will probably do is we'll categorize are risks. Maybe you've seen a risk breakdown structure that kind of shows the hierarchy of risks. But like we said, risks come from a lot of different departments and a lot of different areas. So maybe we're concerned about data risk, the risk of disclosure.
Maybe we're concerned about modification of data.
Maybe. Ah, our current infrastructure poses a risk, but we're essentially going to classify and categorize are risks. Um, you can do this through a facilitation meeting, a workshop brainstorming session. But ultimately, what you're gonna look to do is bring your risk team in and just start brainstorming.
What are our assets and water? All those things that have the potential to threaten our asset.
Now, from the i T world, those could come in many different directions. You know, we see a lot of damage with viruses and worms. Trojans. So Trojans masquerade is something benign. Download this screen saver, but instead, when you download the screen saver attached with, that would be some sort of malicious code.
Uh, so the Trojan makes it look like it's harmless. Based on Greek mythology. If you're familiar with that
root kits. Rude kids are particularly nasty because they get integrated with the operating system kernel to be very difficult to detect and eradicate. And they'll allow an attacker continued access to a system.
So we want to get rid of the root kits. Um, other threats. You know, this just types of malicious software logic bombs lay dormant until specific logical event. Until somebody does something, Um,
uh, you know, scans the payroll system and, uh, long as my name's and payroll it lays dormant. Everything's good. But if my name is missing from payroll, it unleashes a virus on the network. That's a logic bomb
time bombs are set to go off in a specific date. So the idea is you got this malicious code just biding its time on your system. That can be difficult, because the first response if you get a compromise, is let's just restore from backup
chances. Air good. Depending on how far you go back, the code may still be there.
Fork bombs. These are processes. The thing about a fort mom is every operating system has a certain number of processes that can be open at any given time. So what a fork bomb does is it opens up that maximum number of processes.
What that means is you can't do anything on your system. You can't close it down because you can't open your any virus program to close it down because all the processes are available.
You can't shut things down because task manager is a process and you can't open another process. So those can really be a pain.
Bots and botnets are important because we really need to understand. We're not always the target.
So I run a small company. No one's gonna target me. I don't need security. Well, yeah, you do, because it's not about you. Um, many instances where unprotected systems are used. Tow launch downstream attacks on other organizations and we can be held liable if we haven't taken the necessary steps to protect our system.
Spyware used to be very harmless, very innocuous. Let's just track your purchase history or your online browsing history, whatever that might be but can also include anything from key loggers, orm or intrusive monitors. Another big concern. A big threat to network security is rogue
And we could spend a week talking about this. So the point that I want to make with rogue infrastructure.
If you have a live report on your wall,
I can get a system on that pork.
Maybe I can't get on your domain, but I've got a port on your wall.
I might then bring in or install a D H C P service.
Well, the HCP signs I p addresses.
The closer you are to me, the more likely you're gonna get an I P address for my d h E P service.
Not only did clients get I P addresses from D H cp, they get their d n a server, their default gateway. They get a lot more information. So just by having one lone port on the wall, I can install a lot of service. Is denial of service your network redirect Do some spoofing all kinds of miss directions.
Other threats, passive attacks.
Sometimes we talk about Eve and Mallory, usually in cryptography. We've got a couple of names we throw around. We've got Alison Bob that air usually communicating A and B Allison Bob. And then Eve is usually the evil eavesdropper. And Mallory usually is injecting herself into the communication maliciously. So
Alice, Bob, even Mallory,
usually when we talk about passive attacks, were talking about eavesdropping. Sniffing the network is what it's more frequently referred to. Tools like wire shark make this very easy. And again, if I could get a *** in your wall, I may be able to an intercept network draft.
Encrypt your traffic,
you know, And I'm not saying encryption is full proof it is not, but it's a step in the right direction.
Um, malware, uh, or active attacks with Mallory. Our friend Mallory often would be injecting themselves into communication, modifying data and transit. Doing session hijacks something of a little higher level,
just an example from common vulnerabilities and exposures. Nothing on here is testable, but I just want to point out that there plenty of resource is out on the Web to gain information about some weaknesses that air out there. Lots of different sites. This is the C V E databases pulled from that miter search.
Ah, lots of different organizations published these lists
as a risk manager going through the risk identification process. Several tools I'm going to use. I mentioned a risk register earlier. I'm also gonna conduct risk audits, vulnerability assessments and pen testing. That's good to find out if what I've put in place is working. Keep communications open with your manager's look to the media.
If you want to find out what the current threats are
as well as what's on the horizon, looking to resource is out and about to be very helpful.
But let's talk about the risk register.
Okay, and this is just an example of a risk register. I've pulled off line. Ah, and this is Ah, very helpful one. It's a CZ good as anything that's out there. Um, so what we have is an Excel spreadsheet. You can use this in any format that you want.
I like the spreadsheet format, though, because it's easy to look at. You could kind of get an assessment
of the information so we have our risks what they are, and usually we aside
a risk i d. Number, how likely they are to happen. And if they do what that impact will be
and we signed them a risk score and that risk or generally this is all qualitative analysis, and I'll talk about that just a little bit high medium and low, and that will help us determine where our funds go. So what are we gonna put in place as a mitigation strategy? We assigned the risk to an individual because it's important
that we have someone directly responsible for measuring the risk.
Now, I'm not saying all of these elements get filled in as part of risk identification. Really, Our first step identification is just going to be where we're brainstorming with the risks could be,
and then assigning them an I. D number. We'll get to the later pieces with different steps off the risk management process.