Welcome back to another iteration of Hacking into Cybersecurity! Our previous posts in this series have focused on informing you, the reader, on how to land a job in the cybersecurity career field. We’re going to switch gears in this episode and talk about something every security professional needs to understand: does compliance equal security? Now, the short answer to this question I think (and hope) everyone knows is “no,” but let’s talk about why that is.
Let’s start off by defining compliance. Compliance is the act of being in accordance with established guidelines or specifications. It also entails the efforts an organization puts forth into abiding by industry regulations and government legislation. This may mean following best practices, meeting specified standards, or meeting requirements set forth by legislation, rules, or regulations.
What in the world does all of that mean? Let’s break this down. Basically what happens is we have a group of people who come together to architect some parts of a security program, saying “this is what you need to have a fully functioning security program.” This usually takes the form of legislation or regulatory frameworks. In these, they outline controls – the specific tools, procedures, or policies that should be in place to assist in minimizing risks to the organization.
It’s important to note these regulations and pieces of legislation are intentionally written in an arbitrary way to allow for changes in technology over time. Because of this, we’ll often see controls such as the following: “The organization employs technologies to protect hosts from malware.” We have an antivirus installed. What else do we need?
Dr. Mansur Hasib, the Cybersecurity Program Chair at UMUC (University of Maryland University College), defines cybersecurity as: “…the mission-focused and risk-optimized governance of information, which maximizes confidentiality, integrity, and availability using a balanced mix of people, policy, and technology, while perennially improving over time.” I love this definition because it addresses all the things a security program needs to be. First, a security program needs to advance the mission of the organization, usually providing a certain service to its customers. Hopefully this service is a profitable one. Second, a security program must be risk-optimized. It should be geared toward discovering risks and implementing mitigation strategies for those risks. Those mitigation strategies should be implemented with a focus on maximizing confidentiality, integrity, and availability. We have to create our security programs around the people, policies, and technology within our organization to fully maximize their effectiveness while improving over time.
Let’s return to my earlier example of having an antivirus installed to protect hosts from malware. While this is technically true, an antivirus cannot stop all malware. It’s a good starting point, but as we all know, antivirus is hardly the “end-all, be-all” for securing your endpoints. So, what’s a good example using people, policy, and technology that would apply to this control of protecting hosts from malware? Maybe we implement a whitelisting solution. Where traditional antivirus works by blacklisting “known bad” files or applications, whitelisting works by only allowing “known good” files or applications to be executed. This solution ties into the three groups we mentioned above. We have to implement a whitelisting solution (the technology), we have to create a policy about how and what gets whitelisted (the policy), and then train and communicate to the employees how to follow the policy (the people). Another great example would be a vulnerability management program. Our job would be to put a vulnerability management policy in place and have it followed by employees, using the technology available to us (such as Nessus).
Security vs Compliance
The key difference between compliance and security is this: compliance is a one-size-fits-all snapshot of the bare minimums a security program should have, whereas security is the continued evolution of policies and technologies ensuring our data remains protected. Let’s take the Health Insurance Portability and Accountability Act (HIPAA) as an example. HIPAA is a US legislation that provides the minimum safeguards that should be in place to safeguard electronic protected health information (PHI). This act was written in 1996 and was updated with the HITECH Act in 2009. This means a 23-year old piece of legislation dictates how we secure data in 2019 At least the policy was updated 10 years ago. Think of all the technological changes over the past 10 years.
Think about your own experiences. How do your current or past organizations build their security programs? Do they use the legislation and regulations to build the foundation of their security programs? Hopefully not, because there’s no way to account for all of our security policies in our compliance frameworks. It’s important to note that compliance needs to be a major contributor to our security management and planning, as discussed in our previous blog post covering the domains of security.
Security and Compliance Work Together
As you can see, security and compliance are not equal, but both play a vital part in creating the foundation for our organization’s security program. While compliance does play a vital role in the security management of an organization, it cannot be the entire basis for our security programs. Most compliance policies are outdated and only give the bare minimums needed in the overall security program. Our security departments should work closely with our compliance departments to ensure the controls we intend to implement coincide with our compliance needs.
Other related articles
- Domains of Cybersecurity : A Brief Overview
- Is Information Security the Right Profession for Me?
- The 3 Keys to AWS Account Security