We need to have data retention policies as part of this overall architecture as well. Data retention policies tell us how long data will stick around in the organization, under what conditions, and with what level of access, and what level of usage. Normal data that's created at any point in time will be in a system until we decide to get rid of it, but it's not going to be managed with a specific policy that says, I'm going to keep that data under these conditions for that period of time, that's different. And data retention policies is going to give us that capability. When we create a file on the desktop, and let's just take a look potentially at what we may do. So if we come in here and we go into a folder like this, and we go to our desktop, and we right click, and we create new, and we create a folder, and we'll call this, 'Test For Data Retention'. And we'll go in here. And inside, let's just go ahead and let us create a new, and let's create a new text document and we'll call this, 'Retention 1'. That document is mine, I just created it. I'm the creator owner and it's going to sit there. I can modify it, I can put something into it. Type a little item in there. I can save that. I can close that. And when I bring it back up, our data is still there. Pretty straightforward. Nothing earth-shattering and revelatory here. This is all stuff that we would all be aware of already. But my point with this little demonstration is not to show you that I can type, because I'm a little challenged by that I can't always do that. But what I'm trying to show you is the following, I can create the data but there's no policy managing how long it's going to stay here. If I come along and say you know what, let's get rid of that and I delete it, nothing preventing me from doing that. If I decide I didn't really mean to do that I want to put it back, I can put it right back. Nothing's preventing me from doing that. I can take that data and I can decide that I want to copy it, and I want to move it somewhere. So, instead of in this folder right here, I decide that I want to go into the computer and I want to go to the C drive. And in the C drive, I want to go to a test for long filenames. And I want to put it right in here. There's nothing preventing me from doing that. Retention policies are designed to address these concerns, because I may not with the policy have the right or the ability to access this folder, this directory called test for long filenames because it's not a secure storage site. I may not be able to put the data there, because the data may become compromised. And if I move this data, this Retention 1 file into this location, I may risk exposing confidentiality or integrity, and compromising or breaching them. So, retention policies are going to help me to deal with these things, because what they're going to do is help me to address these concerns. So, retention policies become very important. Retention policies are also going to go ahead and help us to stipulate, to decide what level of protection. Not just don't move here, store over there, only view using this application. We can do all that, but we also can decide how long to keep the data for. So no matter what somebody does, we have a record of it for this period of time. And based on that, we also can decide through procedures that implement the policy, what level of protection to give the data for that period of time. So data retention policies serve lots and lots and lots of things in terms of management, and focus on requirements in the organization. They can tell us or help us understand what algorithms to use because of the strength involved in the algorithm. The ability to keep the data secure during the retention period and keep it from being seen or being compromised, is going to be directly related to the choice of algorithm that we use to implement the cryptographic solution. If we're going to safeguard and store the data with encryption, we may or we may not, but just if we do. So we have to think about that. These are all things that the retention policy would stipulate and would help us to manage through. Just like with retention, we also have to think about procedures and policies that implement deletion and the mechanisms that we may choose to do that when we get to the end of the data life cycle. We say, it's been seven years, data's there, it's been monitored, it's been managed, we've used it. At the end of the useful life, we now need to go and get rid of that data. So, if I want to get rid of that Retention 1 folder and file and all the stuff I just created, I have to have a procedure in order to go in and do that. So data deletion, it's all about removing data, but it's about removing data in a way that doesn't allow me to call it back. And this is important because a key part of data protection is the safe destruction of data once it's no longer needed. And if you remember when I went in, and I accessed this data just now. Let's just go back here and take a look one more time. Let's put this in the middle of the screen so you could see. You'll see that I went ahead and I still have our Retention 1 file. I went ahead and I deleted it. You saw me do this. I want to delete it, hit the delete key, hit yes, and it's gone. But you also saw me bring it back with a keystroke. All I did was that, and I was able to bring it right back. Data deletion procedures may indicate that that's not acceptable and say, when you delete something you shouldn't be able to bring it back. You shouldn't have a record of it anymore. You shouldn't be able to use control Z to undo for instance, which is the keystroke I was just using to be able to bring that data back. Instead, when you delete data, you should be able to go in and permanently delete it as it says on the screen. Not move it to the recycle bin, not leave it there in case we want it back, but permanently delete it. Get rid of it. If we do that, and let's say, I hit yes here, I shouldn't be able to bring it back. So, if I do control Z, it doesn't come back. This is the idea with data deletion procedures should stipulate for us. Hey, Adam when you go to delete it, do it this way. Don't use the delete key only and go to the recycle bin. Hold down the shift key and hit delete, permanently delete it off the system. By doing that, you're going to go ahead and you're going to get rid of it. And then we're not going to be able to see it again, we're not could recover and bring it back. That's the value of having a data deletion procedure. That's what we need to be thinking about. And that's why we have to go through, and as security professionals as SSEPs, we have to be thinking about the fact that when we do something and instruct others to do something, we have to be prescriptive. We have to be specific. We have to be able to provide guidance that shows them and tells them what they need to do and explains why, to give them context. When I say to a user delete data, the first response is, "Okay, I got this key that says delete. That's what I'm going to do." It's probably not going to work the right way. If I give them a quick understanding of the fact that delete sends data to a special container called the recycle bin, it's like that garbage pail that you're used to seeing in your room. What happens when you throw garbage in there? Well, it doesn't just magically disappear. It sits in that garbage pail, in the bag for a period of time. If you want it, you can go back in there and take it out. I didn't mean to throw that paper away, I need it. Take it out, smooth it out and it's there. But, if you don't throw it in the garbage but rather you take it and you burn it and it's just disappeared, it's gone. If you make a mistake, you're not getting it back, that's just the way it is. So we have to give users the context to understand the actions we're asking them to undertake and the reasons why, and then we're successful. And procedures help us to do that. We have to keep that in mind and be aware of that.
