Fundamentals of Information Security Risk Management
The course is part of this learning path
This course looks at the key aspects of risk management including risk identification, risk mitigation, and risk controls. We look at the ISO frameworks and the processes you can put in place to manage risk within your organization.
Then we move on to how to assess and identify risks. We look at the difference between qualitative and quantitative risk assessment, and the guidelines set out by NIST. We move on to look at the main tenants of risk mitigation which include risk reduction, risk avoidance, risk transfer, and risk retention, before finally looking at the controls you can put in place to counteract risks.
- Understand the organizational processes needed to manage risk
- Learn how to assess and identify risks
- Learn about risk reduction, risk avoidance, risk transfer, risk retention, and risk controls
This course is intended for anyone who wants to improve their knowledge of risk management in an information security context.
We recommend taking this course as part of the IT Security Fundamentals learning path.
Hello and welcome back. Let’s review risk management.
There's an applicable ISO standard for risk management - ISO 27005. And it’s wholly concerned with risk management.
In fact, it is information security risk management. And what we're doing here is we're just taking care of risk using general risk management, so we're going to be doing our risk assessments. This is going to be based on the context of the organization. That context can be internal or external, and is derived from our organization’s requirements, our goals, legislation, and all of that type of stuff that goes into the context of our organization, internal, external, quality, all that type of stuff that we want to adhere to.
But the terminology for risk or the definition of risk is the effect of uncertainty on objectives. So, when we're doing risk management, ISO 27005 is looking at the context of the organization, where we find our assets, and then actually analyzing the risks to those assets. And then managing the risk to those assets.
Then we use this and connect this one to ISO 27002. What controls can we use from ISO 27002 to protect our asset against this type of risk? And that's how we go forth to manage.
“Managing” comes into play with treating, monitoring and reviewing risk. If you don't review risk, you're not really managing it. If you're not monitoring risk, you're not managing it.
The challenges are that you have to provide a demonstration of secure environments to clients and stakeholders.
Auditing is a common way to prove this. That's how people get their assurance from your organization, because you allow your systems to be audited. That provision of information security that you do, that then provides a demonstration of a secure environment to your clients and other stakeholders.
One risk that we have to manage is the problem of individuals losing stuff, traveling with information. We've all seen people on the train that have everything laid out. I'm not just talking about your laptop, you've got paper there. People are just looking at stuff, talking loud on the phone, those folk. We do have a problem with the large mobile workforce, but providing ease of access for them means that then our information is more available to everybody else that's around them as well. And that becomes a problem for us. So how do we take care of that? We're going to look at it once again using policy, technology and training, aren't we?
DR and BC: disaster recovery and business contingency. Business contingency being the main component, if you like, looking a bit like this, if you like, with BC being that and DR being that.
BC is the most important thing, so BC, business contingency, takes care obviously of all our normal day-to-day stuff, our business stuff, interruptions to networks and all of that type of stuff. And disaster recovery, dealing with actual disruption to our core IT systems and services.
This is often overlooked, let's say large banks, they're really good at having disaster recovery sites aren't they? They have whole buildings set up exactly the same, where they spend exorbitant amounts of money just to have it up and running.
But, we’ve got companies that do that type of stuff and do you know what they forget to do. They normally have mirror sites, banks, where their staff can just walk straight into, sit down and get working straight away.
We have mirror sites, mirror. We also have hot. We have warm and we have cold. These different types of disaster recovery sites allow us different speeds of recovery essentially.
Mirror sites, all you're information is there, it's good to go. You don't have to do anything. With hot sites, you probably need the last backups. Warm sites, we've got a site. It might have connections, we might have to wait for all of our backups and make connections. Cold sites, we've got a site. It's bare bones. We've got to put stuff in there, we've got to make connections, we've got to get our backups; it’s just cold, but it is there. They allow us different time frames for recovery.
Sometimes what we don't do, is we've got a mirror site or a hot site, or something like that. But then we've just not updated the actual firmware on those systems to the same level as we have our primary systems. That poses a security risk because if they're connected, they're a vulnerable system, especially if they're sinking. They're vulnerable because they've got firmware that your primary system hasn't, probably been patched from that... provided extra security procedures, availabilities, functionalities.
So, this is where people often fall down, disaster recovery and business contingency. Simple things like doing backups, making sure the backup actually went through, baselining your systems, and stuff like that.
How do we find our risks? By our assets. Once we've found our assets, then we can find the threats that are faced by those assets. Once we've found the threats, then we can see whether those are deliberate or whether they're accidental because human beings can be both malevolent people and careless people, and sometimes both.
Then we'll find out the vulnerabilities of those assets that could be exploited. Threats exploit vulnerabilities, that's how that works. Threats exploit vulnerabilities. They take advantage of vulnerabilities.
And once we find out those vulnerabilities that can be exploited, then we start to push them into our risk assessment situation, and ask ourselves, “How likely could this be for us and what would the impact be?”
All we're doing when we're calculating risk is we're doing impact times likelihood. Impact times likelihood. What's the impact to our organization and what's the likelihood of that transpiring?
Once we've done that, then we'll say great, what controls could we throw at this situation, seeing that it looks quite likely for us, or the impact is and we're not willing to have that impact on our organization. What controls can we put on this? And how does that affect the impact or the likelihood? That will be our risk management. That's generally what we're doing. What we get out of that risk identification process is a list of the assets, the potential threats, possible controls that we've got in place. Also, controls that we already have in place, some of them already have controls in place.
Vulnerabilities, the four particular assets and their link to no threats or if we're doing horizon scanning, possible new threats as well. And then infinite scenarios, which is what you have to build. The infinite scenarios and their consequences, there you can see it's important to actually understand what it is you're protecting. Because if I don't know what I'm protecting, I can't build my infinite scenarios.
You don't to be as technically proficient as the actual hackers or network technicians. You just need to know, it is a possibility? If it's a possibility, you pose that to those people that have that technical understanding. And they say, "Yeah, that can actually happen, and that can actually happen". And then they flesh out the scenario and present that then to the board.
The ISO 27000 framework defines a threat as the potential cause of an unwanted incident. Whenever you see the term potential, what you're talking about is a threat. It's very different to a risk. A risk is evaluated. A threat is potential. For example, the water could potentially rise. They also use another term sometimes interchangeably but that’s also slightly different, hazard. Hazard is an inactive threat.
It's a threat in its own unactivated state, if you like, hazard. Because you can have a river that is a hazard, which is also a threat but then it becomes realized. It's not a risk until we've evaluated its impact and all the rest of it at the end.
Vulnerability. Weakness of an asset or control. We put controls in place to mitigate against risk. But vulnerabilities can be a weakness of an asset or a control. Now we know that assets themselves have controls put in place to protect them, but sometimes the controls that we put in place can have their own inherent weaknesses. So then we sometimes have to have controls for the controls. It's because of that why we then sometimes have what we call defense in depth. The other term that we can use for a vulnerability is lack of. If something has a lack of something, what we're saying is it is vulnerable. It's vulnerable. A lack of an anti-virus makes that system vulnerable. That's risk, that threats and that's vulnerability.
Originating from a systems administration/network architecture career, a solid part of his career building networks for educational institutes. With security being a mainstay his implementation he grew a strong passion for everything cyber orientated especially social engineering. The educational experience led to him mentoring young women in IT, helping them to begin a cyber career. He is a recipient of the Cisco global cyber security scholarship. A CCNA Cyber Ops holder and elected for the CCNP Cyber Ops program.