We want to examine that link between controls and risk. Why are we using controls? How do they relate to our risk? Very common to hear us talking about risk-based approach to security, we will look at some control frameworks. We'll look at the importance, the need for control assessments, and then we'll look at some concepts or defense in depth, least privilege before moving on to use a lifecycle management. Related to user Lifecycle Management, we have some users that have more capabilities, more power than others. These are our privileged accounts. They too need a set of processes for management and control. Privileged Access Management, often referred to as PAM as an acronym. We will also look at segregation of duties. This is quite a big introductory module. When we want to talk about controls. Really helpful to start with a definition and from NIST Computer Security Resource Center, great resource. You guys can Google this or just use that QR code on the screen there if you have a smart phone handy to visit, it has lots of definitions, not just for a control, it has an entire glossary. Really useful resource, something that I still use today. But the definition it offers for a control is some safeguard or countermeasure designed to protect the C, I, and A of its information and to meet a set of defined security requirements. This is taken from NIST, but there are other definitions available and they all amount to the same thing, something which affects an outcome. When we think about controls in the real-world, think about the remote control for your television. You press a button and it affects that equipment. The volume goes up, the volume goes down, the channel changes and this is what we're doing. We're using a control to affect an outcome, usually to improve the confidentiality, integrity, availability of ultimately information. Now I talk about information. It can be other asset types, but they are usually indirectly protecting information. If we think about offense, protecting a building and the building with a locked door, protecting a server room, with information stored on an encrypted disk, lots of controls there. Encrypted disks, physical barriers, all protecting what's stored on the server. The information usually is what ultimately what we're protecting. Controls, how does this relate to risk? Well, control is an important part of risk mitigation. If you think back to Chapter 1, we mentioned are untreated risk and we have four management responses to risk. The four management responses to risk are to try and share the risk, sometimes called risk transfer. An example of that might be insurance for example, we try and share the risk with another party. We can choose to accept the risk. We know what the risk profile is if the risk level of risk is within our risk tolerance or our risk appetite, then we can choose to accept it. We can continue to operate. We know what the risk is, we are informed. Usually our board would make this decision. One of our C-level officers would make this decision. We could choose not to operate. We could choose to cease operations to avoid the risk. Now this is a fairly drastic response and for example, with information security, one way we can manage this is by turning computers off. Logically that will remove the risk, creates different risks and actually removes the service. Sometimes that's just not viable. The fourth risk management response is to reduce the risk, sometimes called risk mitigation. The more modern terminology is risk reduction. The reason we say risk reduction is because usually we are not mitigating it completely. Mitigation sounds a little bit optimistic. The risk is going away. Instead, what we're doing is managing the risk down. What we're trying to do is to use controls to influence the risk level downwards until the remaining or residual risk is within our risk appetite. You can see that on the right-hand column that we have a reduced level of risk and the difference between the lower risk in the colored green block and the blue block is the impact of control. That's the benefit that the control is giving us. This tells us why it's important. We need to check that the risks or that the controls are operating correctly. If we implement something like a firewall to manage the risk down, to manage the risk of a network-based attack, for instance, downwards until the risk level is acceptable. What happens if the firewall stopped working correctly, the firewall ceases to function. What then? This is why it's important that we check our controls are still effective. We have to review the risks, the threats, the vulnerabilities, and we have to review the impact of the control to make sure it's still working. It's not working correctly we may be closer to the blue column on the left than the green column on the right. In fact, some controls when they don't operate correctly, may not just remove the benefit, they may increase the risk. Just think about an unpatched firewall that has lots of vulnerabilities. Instead of conferring a benefit, might actually create a further vulnerability. It might reduce our protection rather than increase it. We have the idea of a control assessment. Risk reduction. Risk reduction is typically dependent upon the effective function of the control. Lots of things change. This is why we assess controls like anything else this review should be structured. If there's no structure how do we know when it will happen? What will happen? How do we know what will be included or excluded, the scope? We need to document this. What is the frequency of our control assessment? Usually is a reasonable minimum. We're talking annually, but it might be more frequent than that. The scope which controls are we including, which are we scoping in and which are we scoping out? What's our plan? How are we going to undertake this control assessment? How do we get a level of confidence or assurance that things are working as they should? This is a really good example of a set of processes that are ongoing. Quite often as human beings, we like to implement something and move on to the next exciting project. Insecurity, as we talked about in the last chapter, when we looked at incident response, business continuity, disaster recovery, we looked at sets of processes that are cyclical. They have a start, they have an end for that particular cycle. But we looked at the lessons learned which fed forward into the next cycle of activity. Lots of things insecurity follow this pattern. It's not something we do want some forget about risk management, control assessments, incident response, disaster recovery, business continuity, all things that need continual vigilance, partly because of this changing environment.
