So now that we've talked about confidentiality, integrity, and availability. We just need to focus on some other terminology that ISO brings to us, which is related to the topic of risk, because ultimately managing information security risk is what having an ISMS is all about. So let's just have a look at these terms again just to make sure we're all on the same page, so to speak. And the first one of those I wanted to speak about was the term vulnerability. And we'll look straight away here at the ISO definition of the term vulnerability, which says the following. A weakness of an asset or control that can be exploited by one or more threats. So what I tell people generally if I'm talking about vulnerability is exactly that, the definition, weakness. Let's go with a very simple example of vulnerability. Let's imagine I go out the house in the morning and leave my door unlocked uh you could argue that we have a security vulnerability. There is a weakness in security in that case. If I was to connect my laptop to the internet without any uh firewall or without any anti-malware control, I would have a series of vulnerabilities. or weaknesses. Now for those of you who've been in information security for some time and maybe have worked in the technical part of security, maybe you've done things like vulnerability scans using tools like Aqualis or OpenVAS and S's something like that. And of course if you've done that, you'd be very familiar with a lot of common technical vulnerabilities, you know, missing patches, misconfigurations. you know, default manufacturer passwords left on systems and various things. And you'd be correct to point out that all those things would be weaknesses or vulnerabilities. But I must point out that vulnerabilities are not just technical when we think about an ISMS. We can have vulnerabilities in multiple places. So if for example we have an organization that uh has flaws in its background checking process when it hires people, that would be a vulnerability. If I have an organization that has gaps in its physical security, in its buildings and premises, those would also be vulnerabilities. So what we've got here is a a table from ISO 27005, well more to the point, an extract from ISO 27005 So ISO 27005 is a guidance document on information security risk management. And when you look up a vulnerability in that guidance document, you can see there's a number of categories and some examples of vulnerability. Now this is not of course an exhaustive list, it's just there to help you understand the terminology. So we can see examples of vulnerabilities in multiple areas in hardware, software, networks, with people with buildings, etc. And so the real thing is in the the real world when we're looking at an ISMS we'll be looking at where we have vulnerabilities in an organization. Now one key thing I always tell people on this about wording is you can work out if something's a vulnerability by the kind of language we use. So this is true for the real world and if you're taking the exam and you see any questions that might ask you about vulnerabilities, for example, the key words we're looking for there is usually words like, as you can see, insufficient. missing, absent, uncontrolled, poorly controlled, etc. If I hear things like that, that typically tells me those are my weaknesses or my vulnerabilities Now, of course the question is from a practical point of view in the real world how do organizations identify vulnerabilities Well for non-technical vulnerabilities like say flaws in the human resource processes or physical security there may be specific assessments and reviews of processes that can reveal that. But if we think about technology, the security testing and evaluation is where we might look at particular components, let's say in a network. network equipment so let's take a switch or a firewall and we basically have uh some experts sort of take a look at that and identify weaknesses So for example, one piece of work I sometimes do for organizations is exactly that. So we'll take a firewall and we're not going to try and break into that firewall, for example. in this example but we're going to take a look at the rule set. We're going to look for potential holes if you like traffic that that's being allowed through that possibly shouldn't be. Perhaps we'll look for misconfigurations that we can see that may be open to manipulation or misuse. So security testing and evaluation is one way of doing that. We can also do more deep dive tests, you know, as well as doing vulnerability scans, we can try and prove whether vulnerabilities exist For vendors who are producing products that they're selling, they can go through quite a rigorous process of security testing and evaluation. One particular scheme that you may be familiar with is something called Common Criteria. So Common Criteria is a global standard. It's based on an ISO standard called ISO 15408. What this is, is a security testing and evaluation process. So let's take a vendor. So take one at random, let's say a company like Cisco, for example. So let's say that they produce a new firewall that they want to sell, and maybe they want to sell it to very specific sectors like healthcare or government, etc. They may make a number of claims about the security of that device. They can then take that device to a common criteria lab and there are a number of those listed, an official lab, and that lab will set about doing a number of very rigorous tests to validate the claims that are being made and at the end of those tests we'll produce a report and also an i an evaluation level rating. And the evaluation level rating isn't necessarily about how good the security is, it's more about the level of tests that have been done. done. But the vendor, assuming it's successful, can then state our product is listed on the Common Criteria Portal and it's had this level of evaluation. And a customer can then go and look at the report and understand what testing's been done and what vulnerabilities may or may not have been addressed. So that's Obviously a very specific example. There are other schemes out there like that. So you can do your own testing, but there are independent security tests available. Another way that organizations discover vulnerabilities, not so much in products like the example I've given there, but in their environments more widely, is through a topic of what we call penetration testing. Now penetration testing is is worthy of uh possibly many hours of discussion, but I'll try and keep this as uh brief and to the point as I can. So in penetration testing This is where an organisation will invite qualified professionals to come and essentially probe their systems and essentially attempt to act in a similar way to a potential attacker. So not only will they ask the penetration tester to try and find vulnerabilities, they'll actually ask that test team to see if they can exploit those vulnerabilities. To then give advice on how we might remove those vulnerabilities to stop a real-world attacker taking advantage. There are different types of pen tests that can be done. depending on what you're trying to understand. And you may have heard of the term white box and black box penetration testing. So for example in a black box test This is where you might be concerned about, let's say, an unauthenticated attacker on the internet who doesn't have any existing access to your systems. So you're asking the tester to see what they can do without any information, without any credential. That's one extreme. On the other extreme where we talk about white box testing, that's where you give the testers information about your system. maybe even standard login credentials because what you're doing in a white box test is maybe looking at the system from an internal perspective. You know, so could somebody who already has access, legitimately or not, for example, elevate their privilege or do something that um they shouldn't be doing. So you choose which scenario is appropriate. You can also think about does the security team that are monitoring networks, for example, need to know about the the test? In other words, do we want them to be aware so they can be aware that when there's strange logs, etc. that's something Something's happening. Or are we using the pen test to test their capability to detect? A lot of organizations now are good are using this idea in something you may have heard of called red and blue teaming, for example where you've got the blue team that essentially defends the network and systems and the red team which is essentially pro-bring and testing all of the time There's a lot more we could say about that. The only thing I'd say right now is we need to be very careful with pen testing to make sure that we get best value from it by focusing it on those systems. that need that level of scrutiny and making sure we select testers who are competent. So maybe having a look at whether your testers are uh properly registered under schemes such as Crest or Tiger. There's many of other other schemes out there. So you can be sure that when they are giving you a report that there's a level of accuracy around it. The only limitation I would tell people about Pentel testing as well before I move off this is of course a pen tester has a limited amount of time because you buy their time based on a budget. A real-world attacker is not limited by a number of days, a number of hours, etc. So that's always something to bear in mind. But certainly security testing of products, doing your own security reviews and vulnerability tests and penetration testing can all come together to help us understand the kind of vulnerability. We have from a technical perspective. Now, of course, that all being said, we could produce lots of reports about all the vulnerabilities that exist, and some people would be correct to say, well Why is that an issue? Is somebody really going to take advantage of those vulnerabilities, etcetera? And that's where we move on to the concept of threat The ISO definition of threat, the potential cause of an information security incident that can result in damage to a system or harm to an organization. So think of the threat or threats as things that will potentially take advantage of those vulnerabilities. Now what I tell people before we have a look at the list from ISO is that you could break threats down really into three categories. You've got your deliberate or malicious. So this is groups of people who are deliberately aiming to gain unauthorized access, conduct any denial of service, conduct fraud, wherever it might be. So the deliberate and malicious threats We've got our accidental threats and there's plenty of those. So that's you know things like human errors. Imagine the employee who accidentally sends confidential data to the wrong email address or you know, copies data to Dropbox by mistake or something silly like that, but still extremely serious, but just not malicious, accidental threats. And then of course from the availability point of view we might have natural threats, things like fires, floods, weather events, etc. So we do need to think about all of them And if we take a look at this table from ISO 27005, again an extract from the table, this gives us some examples of threat. And you can see that they're bunched into multiple areas. And also you can see this column that talks about risk sources. So within ISO 27005, a risk source is basically saying where essentially a risk comes from So for example, you know, if you had a building and in that building you're you're um storing lots of um let's say dangerous chemicals, for example, that's that's a source of risk. That those are there give rise to risk. Now, one thing I'd like to say is if you're doing this in the real world and thinking about threats, you might want to think very carefully, particularly about the deliberate threats about the source of those threats. So you might want to think just for a moment about as an organization based on the type of organization you are and the type of data you're processing How interesting might your organization or its business be to certain threat sources? So for example, we could say threat sources are things like organized criminal groups, competitors. foreign governments or intelligence services, media outlets and journalists, and so on. And we could we could add many more to that list. And what you want to ask yourself is, well, do are we doing anything or do we have anything that might be interesting with those groups and how capable and how motivated are they? Now I can't just come up with the answer to that out of thin air. Often we'd need to look at the threat intelligence, we'd need to to do a lot of research around this. So why bother to do that? Well if we do that, then we understand the kind of threats we face, of course we can can uh put in a level of protection that's suitable, you know, protecting yourself from a determined advanced persistent threat. such as a foreign intelligence service, is a very different matter to protecting yourself against, let's say, your trivial technical hackers. They're both uh offer a level of threat, but those levels of threat are very different. So I do think it's worth thinking that through. It's also worth thinking through uh threat scenarios, that is to say, how maybe a s a threat source could influence what we call a threat actor. And I always just use a real-world incident just to just to call this out. And it's it's a little dated one, but I think it still really helps. This was a real-world story of a bank based in London uh quite quite some time ago now, but long story short, a um organised crime group who were looking to commit fraud and essentially They basically bribed a cleaner who had access to the office after hours unsupervised. They bribed this cleaner to install keylogger devices on a number of machines. Now today that attack probably wouldn't work because you would imagine most organisations would then put restrictions in place around USB, etc. But at the time restrictions weren't there. And then essentially with the login details they'd gleaned through these keyloggers, they were able to log in and basically commit large amounts of um data transfers. So but the point about that story is is that you have different people involved. You have a threat source uh essentially uh affecting the behaviour of an insider in this case. So that's a threat scenario. So it is worth thinking about that in the real world and really sort of doing some work to get under the hood as to how threats might you know manifest themselves in reality. We could say a lot more about that, but we'll park that there for the moment because beyond that we're getting into the realms of threat hunting, threat intelligence. etc. But what I want to just uh sort of point to here on this table is the relationship between vulnerability and threat. Now we've deliberately done it here as more of a one-to-one mapping just so that the the you know it's understandable. Like the first line, if we have a warehouse that's unprotected without surveillance, that's a vulnerability that could be exploited through theft. Or if we're using pirated software, then that software might be vulnerable to malware and other such things like that. In real life it can of course be a lot more complex than this. You know, one vulnerability might be exploited by multiple threats, or the other way around, you know, a threat might attempt in order to launch its attack to attack several vulnerabilities. However, for the sake of where we are now, these are the things that we need to be clear about. So let's imagine then, just uh hypothetically, a threat takes advantage of a vulnerability. When that happens and an incident takes place, we have what we call a consequence. Now here I'm not talking about business consequences like cost or legal action or reputational damage. First, we're going to talk about the consequences to the three tenants of security. So is the scenario affecting or could it affect availability of bringing a system offline? interrupting uh performance. Could it be a consequence on confidentiality, you know, a data leak, unauthorized access to data, unauthorized sharing of data Or could it be something that has an integrity impact? You corrupts data, allows people to make changes without authorisation, allows fraud, for example, to take place. And the reason we're bringing this up is when we think about risk in ISA 27001, this is what we're trying to look at each time. Now there may be some scenarios that affect all three tenants of security some that are very specific, but of course understanding that can allow you to think very carefully about the prioritization of risks And in this next table, now you've got the vulnerability and threat and the consequence in the column here as well. So if we had the unsupervised warehouse and we had theft, of course we would suffer from a financial loss. If we were transferring passwords across a network in the clear and we had some kind of eavesdropper or hacker, whatever their motivation, you know, intercepting that traffic, we could have potential information thing. I would argue we could have a lot more problems as well. But the idea is there's a relationship between all of these. And when we look later on at risk management, This is the important aspect. Now as an auditor, um you're not necessarily conducting the risk assessment for the organization, but what you are doing is validating that their risk scenarios make sense. So to be familiar with these things These concepts is really important. So the final thing to say on these terminologies is these all play into the concept of risk. And according to Weissot 27005, the definition of risk, information security risk, is the effect of uncertainty on objectives. So what we mean is um Risk is something that hasn't happened yet. It's an uncertain situation. And the study of risk is to try and think about the likelihood of some of these scenarios that we're talking about playing out. and the impact of them, the damage that can be done. And we have further discussion here based on the the NIST standards, the special publication 830 And it has a definition of information security risk which says the risks of organizational operations, organisational assets, individuals, other organisations and the name the nation in this case, due to the potential for unauthorised access, use, disclosure, disruption, modification, or destruction of information and or information system That's quite a long definition, but in a nutshell, what it's saying is it is the uncertainty related to the potential compromise of information. Now in this case where it mentions the nation, just to be clear on that, that's because NIST is a federal government standard in the US that focuses not just on organisational security. But national security, but even if you're not concerned about in your organization national security, I think everything else in that definition is absolutely perfect. So that's what we're trying to do in an ISMS And as an auditor, we're trying to validate that the organisation has got their approach right and they really do understand these issues and they really have identified the right kind of risks that's relevant to them.