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.