So as we we know, we as part of an ISMS expect an organization to understand its risk and to To understand the risk scenarios. And in response to those risks, an organization will be implementing various security controls. And if we look at Annex A of the standard, we know there's 93 security controls in there. And of course they can add others as well. But controls all have a different purpose. So we're just going to look at security controls by type and function. So let's start by type first of all. We could categorize security controls. According to what they do and their purpose. So we have some controls that you might call technical controls. So technical controls in information security is where we implement some kind of technology to restore respond to a problem. So if we implemented a multi-factor authentication system or a firewall or an intrusion detection system, for example, these would all be pieces of technology designed to achieve some kind of objective, a technical context. control and there's a variety of them that we could have. But I think most people would accept, even with really good technical controls, that a lot of them are dependent on good processes and uh that are followed by an organization. And this is where we talk about administrative controls. So administrative controls are where organizations bring in certain processes to manage risk. So you could have things around people like segregation of duties, job rotations, proper approval processes, your change management processes. These would all be example of administrative controls. But also having adequate procedures in place to manage technical controls. So for example, let's say we introduced a a security incident and event monitoring tool, which is a technical control, we'd probably have a bunch of administrative controls to go with it, such as stating how often the reviews of those logs have having a process that would be followed if we detected something suspicious. Those would be administrative processes. So often these will go hand in hand. And when we think about setting up an ISMS, we also have managerial controls. So managerial controls are very focused on people and management of people within the organization. So having things like management reviews, training and awareness programs, having proper internal audits to check that policy, etc. has been followed properly, disciplinary processes, etc. These would all fit under the the banner of managerial controls. And then we also have legal controls and there's two points of view on that. Legal controls are controls we would implement in order to fulfil our obligations under laws and regulations. And also where we use legal instruments to protect our information and information systems. So for example, if we asked people to sign a non-disclosure agreement, providing it's you know legally sound, that would be a legal control. Or let's imagine you have a supplier and you expect that supplier to meet certain security requirements and that's specified in contract. then that contract is essentially a legal instrument, it's a legal control that's helping to protect us. But as well as talking about the types of security controls, we also need to think about the function and the purpose of different securities. security controls. Now in this course we present this as three different functions, preventative, detective and corrective. I'm aware that in some other security studies etc you might have even more categories But for these we we keep it at three. And I just want to run through those three. The first one then, preventative control, is basically a control that we will implement to avoid or prevent the occurrence of a risk as best we possibly can. So for example, if I put strong access control in place on a system with multi-factor authentication, the objective there is hopefully to prevent unauthorised access. If I put a robust firewall at the perimeter of my network again, you would argue that's a preventative control. Or in the physical world, you know, if we put a you know, a vehicle barrier in place or a a strong entry control, these would all be there for the purpose of preventing things. Also, anything that's there to deter people, what you might call a deterrent, I would put in the preventative book it as well. So if I put signage up outside the building saying we're monitoring you with CCTV or a login warning banner that says you're about to log into a confidential system, you've been monitored. Now some people might say, well that doesn't prevent anything. People can just ignore those things. Well of course they can, but they're still there to to to with an effort to deter the attack Now all of this being said, there is plenty of studies to show that pretty much every preventative control that exists can, with enough time, enough motivation, potentially be compromised. Now I don't say that to frighten people or to imply that preventative controls aren't needed. Of course they are, absolutely they are The point I'm trying to make is that we need to think very carefully, going back to my point earlier, about threat. How capable and how motivated are the threats that you face? Because the larger, the bigger capability and motivation they have, the more we're going to need to do on the preventative front. One of my colleagues puts it like this. He says You're never 100% stopping an attack. What you're trying to do is raise the bar so high that the effort required to compromise those preventative controls is so great that the attackers maybe go somewhere else. Essentially that's what you Trying to do. So all of that being said, yes, we need absolutely robust preventative controls in place, without a doubt. But knowing that some preventative controls could be with enough effort and energy and time be compromised, we need the ability to actually spot when preventative controls have been compromised. And that moves us into detective controls. So detective controls are controls that allow us to see that. So things like monitoring and auditing, a security incident and event monitoring tool. our threat hunting activities, intrusion detection, file integrity monitoring, etc. These are all examples of detective controls Now, personally speaking, as somebody in the security business, I'm very focused in this area because um because of various industry statistics and publications etc. And I wanted to draw your attention to a couple of those. So uh over the last couple of years the National Cybersecurity Centre in the UK uh and totally separately uh HP so the um the the large infrastructure Company HP both did separate studies and without getting into too much detail they both implied that there was essentially a significant gap in general between organizations having a security compromise and spotting it. So approximately, and I'm not quoting the days exactly here, but in the ballpark of uh NCSC has suggested around six months things HP is at seven, you know, give or take a few days here and there. But the point is, um these studies are suggesting that organizations on average are taking six to seven months to notice that a security compromise has happened. Now of course you might be watching this and saying, well that's not true for my organizers, you know, you're we we we're much better organized. And that and if that's true, that's Fantastic. But clearly in the industry at large there is a challenges here. So what's that telling us? It's telling us that some organizations at least have blind spots. So investing in detective controls for me is super important to having an effective ISMS. There was a um a saying that a chief information security officer was quoted as saying that I think the RSA Security Conference when they said it's not a case of if you've been compromised, it's a case of you have, but have you detected it? And I don't say these words again to to frighten anybody or anything like that, but it's just to get you thinking about let's not overlook the importance of detective controls. When anybody tells me we've never had a security incident, I would say I'm quite sceptical and my question is well okay what detective controls do you have and how are you using them. Now equally if we are capable of detecting and we are detecting things or things are happening, then of course we need the ability to respond to that. And that's what a corrective control is. So corrective control seeks to respond to identified problems. So things like disaster recovery plans, business continuity plans. plans, um incident management processes, all of these uh root cause analysis processes, all of these would be good examples of corrective controls. And we'd expect to see again a good mix of those in an ISMS. Now one thing that's really interesting actually to talk about is this slide here which gives you layers of control and I think this is this is really interesting to explain what ISO 27001 gives an organization and what it doesn't. So let me just try and clarify this. So we can see essentially three layers in this diagram. At the top, controls that an organization would implement based on clauses 4 to 10. So you can see those controls are all quite managerial in nature, you know, having proper risk management. having a proper policy in place, conducting management reviews, looking at security from a strategic standpoint. And then of course we have annex A. Now we will say that Annex A are general controls. What I mean by that is When I look in Annex A of ISO 27001, it's not going to tell me how to configure security settings in Microsoft Azure or in AWS or on a Cisco firewall. What it's going to give me is a general set of controls and principles that we need to think about as an organization. What's not in there but still needs to be thought about is then how you apply specific technical controls at the technical level. Now what's this got to do with auditing an ISMS then? So let's imagine I come along as an ISMS auditor and you tell me that you have an access control policy and you require multi-factor authentication. Well of course as an auditor I need to get some assurance that that multi-factor authentication in this example is implemented in an effective manner. That means I'm going to have to take a look at the technology that's being used in your state, whether it's Microsoft Azure, AWS, something like that. completely different and look under the hood. And I need to understand that your organization, who I'm auditing, has uh the necessary technical controls at those levels. So what I'm saying is a good auditor isn't just familiar with the content of ISO 27001. You or somebody in your team will of course need to be familiar with the underlying technology. Otherwise it's going to be difficult to have a reasonable assurance that control those controls are implemented properly. So that's the part that requires you, I guess, outside of this course to get familiar with different technology environments and so forth. But just to sum all of this up, we've got a good slide here that might look a bit busy at first glance but is really trying to explain the relationship between all of these things. So in the bottom corner there we've got assets. In the end, the whole purpose of an ISMS is to protect information assets. And what we're saying, or we're trying to explain here, is that risks can of course cause damage, can harm assets And risks are caused by what? They're caused by vulnerabilities and weaknesses that are being exploited by threats. Now, and of course we respond to this by implementing controls, all the different types I've just been talking about. So some controls will reduce vulnerabilities, that's their purpose. Some can be implemented to reduce the amount of damage that can be done, reduce the impact, and or both. But it is worth noting, as it shows you in this diagram here, that controls themselves can have vulnerabilities. You know, I always say if you can fix one problem, could you be creating another one? So let's say for example we decide to introduce an intrusion prevention system for network security. because we have a number of vulnerabilities. So great, we go and implement this intrusion prevention system which when it detects something suspicious starts dropping network traffic Now if we get that properly tuned and implemented correctly, that's excellent. But what happens if it's not tuned very well and it starts dropping network traffic And causing a denial of service problem. So essentially we could create a new problem by fixing an old problem. So we call that secondary risk. So we're simply saying here, do think about that. When you're responding to risk. think very carefully about any new vulnerabilities that might be being introduced. So this is always in an organization an ongoing thought process. Now the last couple of concepts we wanted to introduce you to in this section were based on the fact that the title of the standard talks about setting up an information security management system. with a focus on cybersecurity and privacy. And sometimes the difference between information security, cybersecurity and privacy can cause a little bit of confusion. So we just want to make sure that we're all sort of on the same. same page. So ultimately cyber security based on ISO's definition of it is this safeguarding of people, society, organisations and nations from cyber risks What we mean by cyber risks, essentially they're technical risks. And if you look at ISO standards, they'll they'll still talk about a concept that I remember being talked about a long time ago called cyberspace. And cyberspace is basically think of it as the internet if you like. So any technologically connected system that processes information for faces potential cyber risks. So for the avoidance of any doubt When we set up an ISMS and we do everything in there that we should be and we implement those technical controls, we are and we should be addressing cybersecurity as part of it. So cybersecurity is not a separate thing from information security. Cybersecurity is an element of information security, protecting the technology, the infrastructure, the applications that form part of it. Information privacy, on the other hand, is also mentioned in the standard. And from ISO's perspective, that's about protecting what they call PII, personally identifiable information. So personally identifiable information is anything that will reveal the identity of a living individual. So of course there's obvious things, your your name, address, telephone number. date of birth, etcetera as PII. But even more subtle things. So things like let's say the the IP address you're using when you're connecting to let's say an online service, if that could potentially reveal your identity. In some cases that potentially could be PII. What we're interested in when we look at privacy is a little bit different to security. So bear with me on this. So obviously security is relevant for privacy, but if we look at look beyond ISO and we look at a definition for say for example from GDPR And it talks about privacy being uh essentially protecting the rights and freedoms of individuals. So there's a subtle difference. Of course, in order to ensure somebody's privacy to respect the rights and freedoms of an individual, we need to have adequate security. We need to protect that data. But privacy goes beyond that a little bit. And I always just try to use a very quick example of a project I worked on some time ago to distinguish between the two. So this project in brief was a road tolling project I was working on a project for a a UK project for a bridge essentially where they wanted to change the road tolling system. So previously people could drive to this bridge, uh pay in cash and drive across across it And the the organization behind that wanted to change to an automated system to stop queues basically. What they wanted was that people could drive across that bridge. have a picture taken of their number plate, automated number plate recognition, and then basically be asked to pay the bill online. So you could pay beforehand, you could pay afterwards If you crossed regularly you could even buy a transponder to put in your car and every time you crossed, there'd be an amount debited off that. So let's think about that. I was on that project as the security architect or one of the security architects. So of course my focus there is very much about the security of the network, the applications, you know, the whole sort of operation. And we had separately to that a privacy officer And the privacy officer did the um the privacy impact assessment. And the discussion in that, yes, there was definitely discussion about security of the system, security of the data, but they were then also looking at rights and freedoms and ethical issues. You know, now we're moving from a system where you could drive relatively anonymously across this bridge to one where there is a footprint, there is a record. And what could the impact be on an individual if uh those records were shared? You know, maybe certain people don't want. people to know that they were travelling on that road at that point in time during the day. So the questions start to become how long should we keep that data for? How much should we keep Who should we be sharing it with? What happens if somebody wants to access that data? You know, so a lot of procedural and ethical questions. And does that get included in ISO 27001? It does. There are some controls in there about that, which is why we bring it up. So all we're saying is if you're processing PIR, you need to think beyond just pure security, we do need to build privacy thinking into our ISMS. If you want further guidance on that, you can extend your ISMS to cover privacy in further depth with an extension standard called ISO 27701. which basically takes everything we have in ISO 27001 and adds further controls from a privacy point of view. But even without ISO 27701 there are some privacy controls. within the standard. So in summary, what we've tried to make sure is here that we're speaking the same language when it comes to security in the world of an ISMS So we know that information is meaningful data. That is an asset to the organization. We are building a management system to protect those assets. We at least focus on the three pillars of confidentiality, integrity and availability. We can go beyond that. We focus when building an ISMS on risk by understanding the threats and vulnerabilities that are relevant to us and the consequences if those threats were to exploit vulnerabilities. We can implement controls in response to that, preventative, detective and corrective controls, with a mix of legal, administrative, technical and managerial controls, or blend of controls to manage risk. And we will take care of both cybersecurity and privacy as part of the overall ISMS. So hopefully this has given you a good flavour of all the things we need to think about. And as we move forward, we'll start to examine as auditors how do we really test whether these things are effectively implemented.