Some considerations around encryption key management overall what we need to do. Just kind of wrapping up that thought process we've been talking about. We have to identify clearly roles and responsibilities, how we're going to generate keys, how we're going to store them, how we're going to distribute them, how they're going to be dealt with when they expire, what we're going to do to revoke and or destruct get rid of keys when they're used incorrectly, how we audit and track this whole process. What we're going to do when we have an emergency and we need to get that key back? What's that process to call back the key or invoke the escrow solution so we can get a copy of the key and recover the debt? These are all things to get as considerations that an SSCP would need to be thinking about. You may not be managing or asked to deal with, or interacting with every aspect of what's on this list, but it should be in your mind at all times when you're dealing with key management, when you're setting it up, when you are administering it, when you're being asked to figure out how to implement it. These are things, questions, concerns, that should be popping up, and you should be thinking about answers for that. How am I going to define those roles? What is a user? What is a recovery agent? What's an escrow agent? Got to figure that stuff out if you're going to do key management. You got to know what they are. What's the key generation process? What algorithms am I going to use? Where am I going to store the keys? In the old app directory assigned to individual user accounts? I'm going to store them separately somewhere else on a key server? Am I going to store them on digital identity cards like a CatCard? Write some sort of smart card with a chip embedded in it. There's lots of places you could store keys. You may store them in all those places by the way. How are you going to secure them in each of those locations? What are you going to do? These are things, as an SSCP, you're going to have to contend with. And you're going have to walk down this list and come up with good answers. Obviously, some are going to be harder than others so no doubt about it, but you're going to have to grapple with these problems and these concerns in order to get this right. The earlier in the process you think about this stuff, the better the plan is that you have for it, the more resources you draw in the mix to help you figure it out. You know, it's common sense. The more likely you are to be successful. If you try to win all this stuff, chances are good you're going to get it wrong and so we asked you to focus on considerations. Ask you to be intelligent, step back, be thoughtful, be thinking about these things so that as you go to do them, you're much better prepared, right? Chance, it says, favors the prepared. And what we think about when we hear that statement is ultimately that you need to plan to be successful. There's no such thing as luck, right? I mean luck just doesn't work for us when we're managing complex systems and focusing on IT security. You may get lucky once but the reality is, you're not going to get lucky often enough. It's just not going to happen. You've got to plan to be successful and you have to prepare to fail. And those are two things we often talk about when we talk about security and implementing security properly because you're going to get it wrong at some point. Rest assured, as sure as you can tell that I'm standing here talking to you, you're listening to me, and we're having a conversation. I can promise you, at some point in your career, if it hasn't happened already, you're going to screw something up, and you're going to fail at one aspect of your job with something related to security. It may be a small thing. Maybe a big thing but it's going to happen. Not because you mean to, not because you're careless, not because you set out to do it on purpose although, those things can't happen but hopefully not for you, but it can happen just because it does. Somebody else may make a bad decision. Somebody else may implement a system poorly. And you may not have realized it and you put it in operation, or you're managing it, or you just happen to be the person on call that day when things go horribly wrong. But, do this often enough it will happen. Rest assured. So when it does, the question becomes, what are you going to do and how are you going to do it? Because if you don't plan to fail, you can't possibly plan to be successful. You know these are two sides of the same coin. And, as practitioners, we need to know that. Plan, plan, plan, right? Secure early and secure often. These are important things for you to consider and important mantras for you to have going on in the back of your head. It's tantra as we continue our conversations in this area. Remember, we're talking about security operations and administration in this overall all knowledge area, right? This whole module, this whole domain, knowledge area that we're discussing, the common body of knowledge that we're in for the SSCP. Security operations and administration. It's all about figuring out how to do stuff. If you're not planning to do it right and planning for what happens if you don't do it right, chances are good. You're just not going to be able to do it. It's just not going to work at all and that's a negative outcome you never want to have happen. When we think about Information Rights Management, what's called IRM generically, we think about the ability to be able to create what are called sticky permissions. One of the challenges we have with data that sits in a system is, we put it into a directory. There's certain permissions associated with it. In windows, we may have NTFS permissions. We may have FAT base permissions pending on the format of the file system we're using. And those permissions may be able to stay with the data when we move the data around or they may not. Remove permission or rescues the data from one partition to another with different file systems. We typically don't keep the permissions associated with that data. So, as a result, we may lose those permissions. People may not have access to the data in one location. Move it to another on a different file system and they may, because the permissions may get reset. So we have to be aware of that. What IRM looks to do, is to effectively create what are called sticky permissions. Those permissions are going to stay with the data, regardless of the file system, regardless of the location that we put a file into or move a directory into. And, as a result of that, if we say no access, that no access is going to stay with that data no matter where it is. If we say read-only or print, but only print one page, or you know whatever the IRM permission may be, then that's what's going to happen. And so the nice thing about IRM, is that we can assign these rights to individual documents and then we can send the document to somebody that's outside of our system and email it to them. Those rights are going to stay on the document and those rights are going to allow the user to open the document, and do whatever we've allowed them do because it's going to validate that that user is going to be given permission, and check in typically over the web to assign those permissions to the user, and validate the controls. If they can't do that, the document won't be allowed to open because the document can't validate or we can't validate the permissions, and the rights management that has to be applied to that particular data. Now there's different ways of doing this. Different systems work differently but ultimately, the idea is that no matter where we are, we're going to be able to use that data securely given the rights and the permissions we have. But if we can't for any reason validate that, the document will not be available to us. So if we can't validate that we should only have read-only. The document may not open, and we won't be able to access the data at all. That's going to protect the data, protect the confidentiality, protect the integrity, and ensure that only authorized users are able to see the data, under the conditions or the authorized mechanisms that we've put in place. This is what IRM or Information Rights Management technology is all about.
