Policies are the foundation of our security processes and procedures. In this video, you’ll learn about information security policies, acceptable use policies, business continuity, and more.
One primary goal of every security administrator is to create Confidentiality, Integrity, and Availability, or what we often abbreviate as CIA. To provide this CIA, we need rules or policies that everyone follows to be able to maintain this type of security. These security policies might be very broad goals.
For example, you might have data storage requirements or certain event procedures that have to be followed. But there’s also a need for detailed security policies. For example, you might have a set of rules and regulations on how the Wi-Fi network should be used, or there should be certain requirements to be able to obtain remote access to the network. The security policies are there to provide us with what we should be doing and why we should be doing it. The actual process of maintaining and administering those policies are associated with the technical security controls that we covered in a previous video.
Most organizations with the security team will have detailed information security policies. This is a master list of all of the policies that should be followed to maintain the uptime, availability, and security of the network. In some organizations, these security policies are more than just a recommendation. They may be a mandate that is required for the organization to have and to follow.
These security policies can help the organization answer questions about the security of their infrastructure. For example, what happens when somebody discovers a virus on somebody’s workstation, what happens when someone wants to connect to our VPN concentrator from their home computer, and what happens when we find that someone has taken advantage of a vulnerability to gain access to one of our services? The answers to all of these questions should be found inside of your organization’s security policy.
The security policy also has a list of the roles and responsibilities for everyone associated with security in the organization. This way, we know exactly who we should be communicating with whenever we have questions regarding some of our security concerns. And as with any list of policies, this is simply information that we’ve written down and documented. It’s up to the organization to enforce the policies that they’ve created and written into their security policy documentation.
One set of policies that applies to everyone in the organization is the AUP, or the Acceptable Use Policies. This defines what users are able to do with the technology that’s been provided to them the AUP defines what is acceptable for everyone in the organization, when they’re using their computers, their telephones, their mobile devices, and any other type of technology. This is not only documentation that can be used to inform everyone in the organization of the appropriate use, but it can also be used to protect the organization in the case of any legal liability. If someone is dismissed from the organization because they did not follow these policies, you have documentation that helps describe why this particular person is no longer with the organization.
On a normal business day, we have access to our laptops, our mobile devices, our networks, and any other technology owned by the company. We’re so used to using our technology that we often don’t even think of a circumstance when that technology is no longer available, which is another good reason to have a set of business continuity policies. Let’s say you work for a retail organization, but today, the network that’s commonly used to process credit card transactions is not available. If you refer to your business continuity plan, you’ll know that the process would be to perform manual transactions and use phone calls to the credit card company to manually approve any credit card transactions.
The challenge with business continuity is you have to plan for this before the particular issue arises. There’s normally a great deal of documentation and testing to ensure that all of the business continuity plans you put in place will be able to work properly if a disaster occurs. And if this is the type of disaster that occurs on a very widespread basis or for an extended period of time, you’ll need a formal set of policies as a disaster recovery plan. You can think of this as a business continuity plan that applies to everyone in the organization affected by this disaster.
One of the challenges with creating a disaster recovery plan is there are so many different kinds of disasters that could occur. This could be a natural disaster, such as a tornado, hurricane, or a flood. It might be a technology or system failure, where you lose connection to a particular resource, or it might be a disaster created by a human. All of these can affect the organization’s ability to perform its duties. So we should make sure that we have extensive disaster recovery plans to cover any of these situations.
For example, you may need a separate recovery location, if your primary location is suddenly unavailable. There needs to be some type of method to recover data in the case that data is lost. There should be application restoration, so the systems can get back up and running, and the IT team and employees in the organization would need to be available wherever that recovery location might be.
We should also have detailed documentation on how to deal with different security incidents. For example, let’s say a user receives an email, and inside that email is an attachment. They double click the attachment and run that executable, and now malware has been installed on that person’s device, and that malware immediately begins communicating with an external server. There should be a set of security policies that determines next steps for handling that type of issue.
Of course, that’s not the only type of security incident we need to consider. There might be something like a DDoS, a Distributed Denial of Service attack, or a botnet attack that would cause your systems to be unavailable. We might also want to consider security incidents where the information inside of our organization is made available to others outside of our organization. If any of our confidential information is stolen, we need a set of security incident policies so that we know what to do next.
To be able to react to these types of security incidents, we need a specialized team that knows exactly how to handle each and every one of these situations. We refer to these as incident response roles, and there are many different kinds of roles that may be within your organization. We’ll look at a number of those here.
We’ll start with the incident response team itself. This is a specialized team that has trained and tested themselves to be ready for any type of security event. We might also rely on the IT security management team to be able to obtain the proper resources and people to be able to address these types of incidents. If the organization has a significant compliance requirement, then you probably have compliance officers that are hired by the organization to make sure that all of the data and all of the systems are compliant with the mandates. Obviously, the folks that will be working in the trenches to solve the technical problems that arise when these events occur will be your technical staff, and of course, our user community can provide extensive information about what was seen during this security event.
If you’re curious as to the process that an organization might follow when these security incidents occur, you might want to read through the National Institute of Standards and Technology document called NIST Special Publication 800-61 Revision 2. This is titled “The Computer Security Incident Handling Guide.” This guide steps through a response lifecycle for security incidents, including the preparation prior to the incident occurring, the detection and analysis of a security incident, the containment, eradication, and recovery process, and lastly, the post-incident activity. The details of this document are a bit outside the scope of the Security Plus Exam, but it might help you provide a bit more context for security incidents.
If you’re an application developer, there are a set of processes and procedures associated with creating software. We refer to this as the Software Development Lifecycle, or SDLC. The goal of the software development lifecycle is to move from the idea phase all the way through until we have an application. This might involve creating requirements, working with the end users, and then creating the application, testing that app, and then deploying it, not only on schedule but on budget. And although, there’s not a best way to go through the process of a software development lifecycle, having some type of structure can help keep everyone focused and on track to get that application developed.
Two of the most common application development lifecycles are Agile and Waterfall. The Waterfall lifecycle is a linear cycle that starts with the requirements, follows through the development process, the testing, the deployment, and finally, the ongoing maintenance of an application. The Agile lifecycle is designed to be a much faster way to create applications, and those are usually done by designing, developing, testing, deploying, and reviewing constantly throughout the entire process. Once the Agile process has gone through a number of different cycles to create the application, it can finally be launched.
Another important set of policies in every organization is that of change management. If you need to make some type of change, there should be a process associated with that. For example, there might be an application that needs updating, or there might be a configuration in the firewall that needs to be modified, or it could be a change to a router or switch configuration. In all of these situations there’s a change that needs to occur, and we have to be sure that that change is not going to have a negative effect to the organization.
You’ll also find that this change management process is one that is constantly occurring. It’s not unusual to have weekly meetings on what changes are being planned for the next week. Unfortunately, in many organizations, the change management process is either overlooked or not used at all, and this could have dramatic impacts on the ability of the organization to function. This change management process provides clear documentation on how often this change will be occurring, the duration of the change, the process that’s involved to install this change, and perhaps, most importantly, a fallback procedure if the change does not go as planned. Organizations that have a well-defined change management structure are able to implement these changes with the lowest risk to the organization, and if your organization doesn’t have a formal change management process, you may want to start working now on creating those policies and implementing them in your organization.