1. Home
  2. Training Library
  3. Security
  4. Security Courses
  5. Fundamentals of Information Security Risk Management

Fundamentals of Information Security Risk Management

Developed with
QA

Contents

keyboard_tab
Risk Management
1
Risk Management
PREVIEW8m 18s

The course is part of this learning path

Risk Management
Overview
Difficulty
Beginner
Duration
31m
Students
689
Ratings
5/5
starstarstarstarstar
Description

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 risks within your organisation.

We then move on to how to assess and identify risks. We look at the difference between qualitative and quantitative risk assessments, as well as considering 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.

Learning objectives

  • Understand the organisational processes needed to manage risks.
  • Learn how to assess and identify risks.
  • Learn about risk reduction, risk avoidance, risk transfer, risk retention, and risk controls.

Intended audience

This Course is intended for anyone who wants to improve their knowledge of risk management in an information security context.

Prerequisites

We recommend taking this Course as part of the IT Security Fundamentals Learning Path.

Transcript

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.

What controls can we use from ISO 27002 to protect our asset against this type of risk? And that's how we go forth and manage it. '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 things, traveling with information. We've all seen people on the train that have everything laid out. I'm not just talking about a laptop, we're also talking about paper, people are looking at things, talking loudly on the phone. We do have a problem with the large mobile workforce, but providing ease of access for them means that our information is then 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 again using policy, technology, and training.

DR and BC: disaster recovery and business contingency. Business contingency being the main component, if you will, looking a bit like this, with BC being there and DR being there.

BC is the most important thing. So BC, business contingency, takes care of all our normal day-to-day stuff - our business stuff, interruptions to networks and all those types of things. And disaster recovery, dealing with actual disruption to our core IT systems and services.

We have banks, for example. They're really good at having disaster recovery sites. They have whole buildings set up exactly the same, where they spend exorbitant amounts of money just to have it up and running. These are called 'mirror sites'. We also have hot sites, warm sites and cold sites. These different types of disaster recovery sites allow us different speeds of recovery, essentially.

Mirror sites, you've got all your information there and it's good to go. You don't have to do anything. With hot sites, you probably need the last backups. Warm sites, you've got a site. It might have connections, you might have to wait for all your backups and make connections. Cold sites, you've got a site. It's bare bones. You've got to put stuff in there, you've got to make connections, you've got to get your backups; it’s just cold, but it is there. These allow us all 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 on 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 hasn't been patched from that... provided extra security procedures, availabilities, and functionalities. So, this is where people often fall down in disaster recovery and business contingency. Simple things like doing backups, making sure the backup actually went through, baselining your systems, and things like that.

How do we find our risks? We find them by our assets. Once we've found our assets, then we can find the threats that are faced by those assets. And once we've found the threats, 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. They exploit the vulnerabilities - they take advantage of them. 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. That's all it is. Impact times likelihood. What's the impact to our organization, and what's the likelihood of that transpiring?

Once we've done that, 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.

And then we have 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 we don't know what we're protecting, we can't build 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, "Yes, that can actually happen". And then they flesh out the scenario and present that 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 will. 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 is the 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 which is 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 that it is vulnerable. A lack of an anti-virus makes that system vulnerable. That's risk, that's threats, and that's vulnerability.

About the Author
Students
5043
Courses
12
Learning Paths
4

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.