Hi and welcome back to course nine. But this time we're going to be talking about information security, my name is Robert Brian, absolute pleasure to be speaking with you again today. Just start our little journey for information security by saying that actually Information Security is a topic in its own. I do five, six or even 10 day courses on various aspects of information security. We're going to try and cover it in a couple of short sessions, only in a very high level. I recommend for those people who really want to get involved in Systems Security to take a much deeper look at it. But he cannot be a privacy professional without looking at security, you really can't be. We're going to start the first session, you looking at, what is appropriate security and I think that's key because quite often we see in a law. Again, I'm going to use the GDPR as my background here. Probably the most well-known global privacy law is that's really what the law says. When we look at controller and process or obligations. We can see down here, Article 32, there's a number of different things includes about security that improves the fact you've got to have appropriate technical and organizational security. You've got to tell people about your data breaches and actually, this isn't just a controller obligation, is a controller and process obligation. Clearly security is going to move all the way down the supply chain as well. It can't just be limited it to yourself. It's really important to understand what the law says about security. But actually, perhaps most important is to understand what's important to you. What's important to you as a business. I mean, this is where terms of the law. All the law says is control around processor shall provide an appropriate technical and organizational measures to ensure a level of security appropriate to risk. A level of security appropriate to the risk was that, he doesn't actually tell you anything and watch out for this and exam questions. An exam question might say something like, oh, you've got an eight character password , is that okay. Now my answer to that is it depends. An eight character password might be good practice today, might not be good practice tomorrow, it might be good practice five years ago, might might not be good practice today. Do I need encryption? Well, it depends. It depends on what your risk is. It depends on what the cost is, depends on the cost-benefit of you as an organization. What's the risk and what is appropriate to that risk. Now, clearly the more to determiner, that's up to you to determine that and guess what the regulator might feel differently. The data subject might feel differently. What the law does tell us, and I'm referring to the GDPR here, is you've got to take into account what is possible. The state of the art, what is the cost to you of implementation? There'll be a cost and a benefit both in terms of cost of implementing that security control and also in the bad cost it has to your business. You imagine you are met force one case study. Well, you come up with a audit report and the audit report says that your army of nurses who are working from home don't have good access control in the database, anyone can access anyone else's records. What do you do? You said, Well, we'll secure that. We'll shut down the access, make sure they only have access to their own patient's record. But almost immediately the nurses come back to and go, what have you done? I now can't access someone else's record. If someone else goes on holiday and I've got to cover their shift and I now don't know what medication that person needs and that's going to cause a risk of harm to life. Yes, well I could ask you for every new time I need access to record, but that would take too long. It would slow down business process. I just want to think about security is actually bad for business. The more security you have, the less your business can operate. I mean, who's been frustrated here by their inability to get into their machine because password is not working or some code that you don't have, it's frustrating. What we're going to find is to get that balance right, the balance between the cost and the benefit. The balance between what we're trying to protect and the measures we're going to take to prevent against it. This is why the law doesn't give us an answer. The law in terms of GDPR doesn't say how secure you've got to be. You have to remember and all other GDPR is not even sector specific. It's got to apply across sexes and it's got to apply to a large corporate multinational and a small organization. Your local corner shop. Free people in the garden shed making furniture. Now we would hope that level of security of a free people in the garden shed making furniture would be vastly different from the nuclear bunker or a multinational corporation. What can I tell you for the training course, what would you be asked? You'll be asked what the security is about. We have to understand that security is about not just -- Everybody games is all about confidentiality? Everybody, what it gets on about confidentiality, this idea that if our data is disclosed, it's going to cause us harm and that's probably all the data breaches we see in the newspaper what they really mean data breaches. But the GDPR goes a little bit further than that and so does most information security. It talks not only about disclosure, but about what happens if the data has been damaged. Damage to the Data. What happens if we can't gain access to that data and our business operations are disrupted. I'd like to think of the three days, disclosure damage and disruption, disclosure damage and there's disruption. In information security. Well, if we prevent against those three days by using the CIA, that's not the, Central Intelligence Agency. My apologies. It's about confidentiality, integrity and availability. Confidentiality, integrity and availability. We prevent against disclosure by using confidentiality, we present against damage by making sure that data has integrity, it's complete, it's up to date. We make sure that data is protected from disruption by protecting its availability. Now this CIA, if you like, the CIA, is quite often what we call our core attendants to information security. We are protecting the CIA, but the CIA of what? Well, protecting the CIA of our assets. Assets in financial terms, these are things of value to the organization. It might well be personal data or it might be non-personal data and information security that has a value to you, it might be buildings, it might be IT equipment, it might be people. These things have a value to them too. We're protecting the CIA. What we've got to demonstrate then is how we've done that appropriately, how we got the right level of security. The regulator will probably ask you something along the lines if you do have a data breach of well, what did you put in place? But not only what did you put in place, how did you determine what you've put in places right? Now, that's what we call accountability under the GDPR as in accountability. This is how do we know that we have got a level of security that does reflect the nature of the scope, the context, the purposes of processing. How do we know we've got that risk decision rights? The answer is to do some risk assessment. We'll be talking about risk assessments within our, the third look at the next elements of the security course. But essentially with our security much the same as we do with anything else, it's about understanding the risk, understanding what those risks are, using some risk assessment methodology to identify those risks, identify how many of those risks are? To identify how big those risks are? By Scaling or quantifying those risks. We don't risk some impact and likelihood matrix and you've got, some impact and likelihood matrix, then we know how big the risks are, both in terms of how much they can hurt us, and in terms of how vulnerable we are to that risk occurring. The risks to our assets, how big the risks are using impacts of likelihood, then we have to decide what we want to do about those risks. Generally speaking, we've got some risk-management options there; treat, terminate, tolerate, transfer it to another party, the security control options you have the fantastic, I mean, I've got a door here to my room if I wanted to secure the door, well, there's a number of things I could, I could change the material of that door. I can put a guard standing on the other side of that door, I could contract, have a third party look after the door for me I could put a key in, I can have an access control log. I could remove the door entirely if I don't think the risk warrants having it all, I could rick the wall up if I think it's too risky and I don't want to do that. But of course, I then lose access to my assets within. A number of different risk-management options. Those risk-management options, once we decide on what they are, adding more controls for moving those controls will result in some restricting plan. With restricting plan will require some level of approval. Why? Because we have to prove it on behalf of the management who will have some risk leftover, some residual risk, and of all she got to give us the resources to be able to operate our security environment, and they'll have to sign off on that cost. That risks, that cost risk benefits through the restricting plan. Once we've done that, well, it's time to implement, it's time to add in all those changes to our controls, putting those controls up or down, making sure the risk is managed effectively. How do we do that? Well, Plan-Do-Check-Act. We monitor, measure, and then repeat the process after 6-12 months. Identify the risks. Make sure whenever, how big the risks are. Decide what we're going to do about them. Implement those controls up or down. Have a restricting plan, monitor and measure to see that restricting plan has been ineffective and the controls are effective. Then we go back and revisit the risk. We go back and revisit a risk. What can we do? We can implement some security controls. Those security controls will be extremely interesting and I often talk about the securities dynamic standards guys. I talk about 27,001 and 27,002 here. We've eaten 27,002 we've got lots of different ideas for security controls we can implement. This is just a top-level domain. It's actually the standard 27,002 contains about a 130 security controls. There are other standards, 27006, 27019, 27701. We have other standards that look at other controls for specific environments. But the more generalized standard day at 27,002, you might need to know. I have seen exam questions that say things like which of these is not in 27002? For example, which of these is not a top-level security domain? Looking at the security domains, we've got management direction for information security. We might find in their policies and procedures. HR security so contracts. What else will we find in HR? Giving people stuff, taking it away from them when they leave. Confidentiality agreements, asset management. That then is about marking what you have and where it is and who's got it, and then what you have to do with it depending on that marking. Access control, so who can get in where both technically, technologically and our access to the network, access to the computers, access to mobile devices. Cryptography, encryption, and key management. Physical environmental security. How do you get in and out your building? What are public areas? What are private areas? What are really secure areas? What about power and water or that type of stuff? IT operations security, that's where you'll find your anti-viruses and your password controls, and your configuration management database if you're in IT. Com securities, that's network security. Also things like email security, internet security, that type of stuff. Systems acquisition development and maintenance. That's your software development. How you go about defining security for new systems, how you go about implementing that security for new systems, how you go about having good relationships, there with different people who might be creating software for you, and how you test that software and the costal, the source code. Then managing your supply relationships, managing your second parties. This is where your data processes will come involved. This is where your data processes will come involved and how you manage those relationships. Some of that in a future session. We'll do about instant management or sweat a future session. What happens if it goes wrong? And then there's business continuity management, what happens when it goes very wrong? Business survivability, if you like. Finally, there's compliance here as well. What compliancy it actually includes data protection law. When you think about it from an information security practitioner's concerns. We're just one law buried in their compliance section out of 150,160, 200 controls. However many controls or frameworks they might be putting in place for ISO or SOC 1 or SOC 2 for example. But when we look at it from a data protection angle, we have to think that security, which is one article of the 99 contained in the GDPR or, or whatever other laws that you're applying. The two could actually look down on each other. It's very important to work with each other. The final thing I want to mention. We'll talk about this more in third-party management here. But so the final thing I want to discuss is data processes. This is when we're dealing with our third-party or second-party organizations that we contract with. Article 28, very good article in the GDPR. It looks exactly about what we need to say to our subcontracted second parties. They're documented instructions only. They must ensure confidentiality. They must have appropriate security in place. Now that's not you don't just write appropriate security in the contracts. That's actually up to you as the controller to define what that level of security as you expect in your processor and hold them to it. Don't just say appropriate security. It's ridiculous. That's what the law says. They're going to need to talk to you about if they sub-process and what level of security you expect down the supply chain. What happens if there's a data breach? What happens at the end of the contract? How they're going to assist you if you've lost your rights requests? How they're going to generate compliance and law and submit your audits. Lots to think about insecurity and this one, as we say, is just the overview, a real overview and not to cover. Most importantly, with security, we have to understand exactly what people expect of us as stakeholders. What are their requirements and expectations, and what do they expect in terms of delivery, the managed security we have in place? Very much like we've seen elsewhere, plan, do check, act. Security much like data protection, needs its own monitoring, its own measuring, its own understanding of where we're failing or could do better, and to feed that into our new plans for the future. The next section we'll look at is about data breaches and notifications. A lot in that first section, a lot in that first section, CIA, appropriate security risk assessment, levels of security control, all questions you can be asked upon in the exam. Thank you.
