Policies

- [Instructor] All right, so let's talk about policies, processes, standards and all this other documentation. So a policy is typically an overarching document. It's typically what we convey the rules of the directives from management to the rest of the organization. And they tend to refer to lower-level, more granular documents, like standards, which have sort of mandatory requirements in them, process or procedure documents, which are more sort of a step-by-step way of doing things, and then guidelines, which tend to be either suggestions or recommendations, or informational documents. Here's some more information on X. We've got the policies up at the top, and then they will refer to those more granular documents. So policies say things like, here at Company X, management dictates that all users should be authorized before they access sensitive data. It's something generic and plain and simple like that. And then it will refer to, say data access standard, which says and you must use this type of multi-factor authentication from this vendor, et cetera, et cetera. That's the more granular document. Or there may be a procedure that that references, saying step-by-step, here's what you do. You type this command, you click this button, and on and on. So let's talk about the different policies and documents that you may see in a typical security program. Now some companies have some of these. Some companies may have all of them. Some we leave out. But either way, here are some of the general ones you should be aware of for the exam. So a master security policy, or a master program policy, is essentially the policy that defines and lists all the other policies. Here are the policies that we will be making here at company X. It's going to define all the organizational roles and responsibilities for the rest of the program. It's going to define how and when and how often we will update other policies and documents within the organization, and typically who is in charge of it. Now an access control policy, as its name implies, defines the controls for granting, revoking, modifying and then validating, to see how often we are correct or to see if we have any stragglers left around, access to stuff, whether it's information, whether it's devices, whether it's software applications. It defines how that access is provisioned and then taken away and validated to see how often we check to make sure there's no authorization creep going on. It typically can lead to other documents like an authorization and identification policy, or a user account and group membership policy. These are more granular documents that outline more specific cases of access control, but you may see any of these in an organization. You may see a password policy that is specific to just how passwords are created and what the requirements are and how we audit them, how user rights are granted and then what privileges they get when they are granted, and then how we monitor user account management. You know, how often people are put into this group, or taken out of that group, et cetera. A data classification policy is one of the hotter policies today. It's become more of an important topic as there's a greater need to classify and protect information, as information breaches are occurring. This is one of those sensitive, hot areas, and there's a lot of consulting going on in this arena. So data classification policies talk about how we classify information, how we declassify information, who the data owners are, who the data custodians are, and how the process looks for classifying information within an organization. Most importantly, it's going to outline what that organization's data classification scheme is. So for example, here at Company X, we have four different tiers of information. We have public information, then we have internal use only information, then we have secret information, and then maybe top secret information. Here are the criteria for each of those tiers, so you can tell what makes something secret, versus top secret; what makes something internal use only versus public, et cetera, et cetera. And that's how you define those layers. It will outline the layers, and then the particular owners for those types of information, and what the requirements are for handling and labeling, et cetera. A communication security policy can deal with any time you're communicating or sending information to and fro. So we have data communications policies, we have wireless communications policies, you may have a specific encryption policy that dictates when it's time to encrypt something. Now that in turn may refer to an encryption standard, which is the more granular document that says not only must it be encrypted, but you must use this tool with these settings to encrypt some data when it's being moved around. You might have a boundary security policy that deals with things like data loss prevention and how we prevent stuff from leaking out of the organization. Communication policies tend to govern all of those things. Security testing policies deal with how often we're going to be doing testing of our own controls. Like vulnerability testing, maybe even penetration testing, application security testing, when you're making your own applications, or whether you're buying something off the shelf that you are responsible for publishing out into the wild. So as the name implies, a security testing policy lists all of the rules for management regarding that type of testing, and when it must be done, the frequency, who the results must be reported to, et cetera, et cetera. Configuration and change management policy, as the name implies, lists the process at the organization for introducing change into the environment, whether that change is a larger change or whether it's just a configuration of an existing thing. It's a way to record, track, document all the changes that are introduced into the environment and typically forces the organization to go through some kind of planning, so that we have a rollback in place ahead of time, before we introduce the change. It requires that sign-off and yes, we've got a rollback, okay, you can now do the change. And if anything goes south, we've got a rollback already. It forces people do to their homework. Physical and environment security policy. As its name implies, deals with the physical security of information assets. It may deal with ingress and egress to a facility. It may deal with heating and ventilation controls, humidity controls, temperature controls, other physical aspects of the environment. Malicious code policies are becoming more and more important these days, as malicious code is rampant everywhere, particularly when it's combined with some kind of phishing attack. So malicious code policies will dictate here at Company X we use this type of anti-malware, of this type of anti-virus product. And if you see this sort of thing popping up on your screen saying you are infected, here's what you should do, here's who you should call, here's how you should escalate the incident. And so these are becoming very important policies so that not only do we have this written down what the rules are from management, but we also have something to train our employees and to help with the awareness issue. Incident management policies, as the name implies, deals with managing incidents as they come up. Now that's something that's important to understand, the difference between an event and an incident. Well, an event is anything that you can measure, detect or observe in some way. An incident is when one or more events are a bad thing, then you've got an incident on your hands, and that's when you employ and incident management policy, or process, to handle that incident. How are we going to handle it? How are we going to escalate. how are we going to track this back to its source and prevent it from happening again, versus just slapping a bandaid on it? So an incident management policy really deals with all of those things. It's typically to determine if we have something that needs to be escalated up to another team, maybe a specialist forensics, et cetera, et cetera. Backup and recovery policies, as their names imply, they deal with making sure we backup our data, making sure we test our backups. Making sure that we protect our backups in certain ways, classify our backups if we have a backup tape and it's full of publicly releasable information, but you put one piece of top secret data on it, now it's a top secret tape. And so you've got to handle it appropriately. Typically these days, we employ things like encryption to our backups. This will also outline how you do recoveries and what the recovery testing requirements are so we can make sure that our backups are actually recoverable and we can actually restore what we've backed up. And then finally, a third-party control policy deals with how you interact with other organizations. Contractors, vendors or anyone that's not typically employed by the organization, like cloud service providers, that's a big one these days. How are you going to establish the business need to reach out to this company, and why are we actually interacting with them in the first place. Who's the relationship owner at the organization for this particular external relationship? How will we maintain compliance with all of our regulations or policies that we have by dealing with them? Are they going to respect our policies? Do we need to talk to them and find out what their policies are? What happens if they have an incident? How will we react? And then finally, how will we terminate this relationship and what are the requirements for terminating it when it is time to do so. And those are the policies.