Welcome back to another iteration of Hacking In To 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, but we’re going to switch gears in this episode and talk about something that every security professional needs to understand: Does Compliance equal Security? Now, the short answer to this question that 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 the following of best practices, meeting specified standards, or meeting the requirements set forth by legislation, rules, or regulations.
What in the world does all of that mean? So, 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, usually through legislation or regulatory frameworks, that says “this is what you need to have a fully functioning security program.” In these, they outline what we call controls, which are the specific tools, procedures or policies that should be in place to assist in minimizing risks to the organization.
Now, it’s important to note that these regulations and pieces of legislation are intentionally written kind of arbitrarily to allow for changes in technology over time. So, we’ll often see controls that are written like: “The organization employs technologies to protect hosts from malware.” Ok, we have an antivirus installed, we’re good, what else do we need?
Dr. Mansur Hasib, the Cybersecurity Program Chair at UMUC (Univerity 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 of the things that a security program needs to be. First off, a security program needs to advance the mission of the organization, usually providing a certain service to its customers, hopefully, a profitable one. Secondly, a security program must be risk-optimized, as in it should be geared towards discovering risks and implementing mitigation strategies for those risks. Those mitigation strategies should be implemented with a focus on maximizing confidentiality, integrity, and availability. And 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.
Going back 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, sure, 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 ties in the three groups we mentioned above. First, 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 implement a vulnerability management policy in place and followed by employees, using the technology available to us (such as Nessus, for instance).
Security vs Compliance
So, the key difference between the two is this: compliance is a one-size-fits-all snapshot in time of the bare minimums that a security program should have, whereas security is the continued evolution along with the technologies that ensure our data remains protected. Let’s take HIPAA, for instance. The Health Insurance Portability and Accountability Act (HIPAA) is a US legislation that provides the minimum safeguards that should be in place to protect electronic PHI (protected health information). This act was written in 1996 and was updated with the HITECH Act in 2009. So, we have a piece of legislation written 23 years ago (and updated 10 years ago), that dictates how we secure data in 2019. Think of all the technological changes that have happened over the past 10 years.
Now, think about your own experiences, how do your current (or past) organizations build their security programs? Do we use the legislation and regulations to build the foundation of our security programs? Hopefully not, because there’s no way to account for all of our security policies to be accounted for in our compliance frameworks. It’s important to note that compliance needs to be a major contributor to our security management and planning, as we discussed in our last blog post that covered the domains of security.
Security and Compliance Work Together
So, 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. Compliance does play a vital role in the security management of an organization, but cannot be the entire basis for our security programs, as most are outdated and only give the bare minimums that are needed in the security program overall. Our security departments should work closely with our compliance departments to ensure that the controls we intend to implement do 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