Security vs. Compliance: What's the Difference?

Image

Security and compliance – a phrase often uttered in the same breath as if they are two sides of the same coin, two members of the same team, or two great tastes that go great together.

As much as I would like to see auditors, developers, and security analysts living in harmony like a delicious Reese’s cup, a recent gap analysis that I was part of reminded me that too often, the peanut butter and chocolate sit alone on their own separate shelves.

We reviewed a SaaS service with an eye toward compliance. The developers operate according to DevOps principles, which often bump into some of the more prescriptive requirements in control frameworks like the PCI DSS.

While assessing the architecture, software development lifecycle, access, and the myriad processes in place, the auditor determined that the security was well-designed and implemented, yet some areas were out of compliance. We had the peanut butter but were missing the chocolate.

The converse is also common. One can meet the letter of compliance yet miss the security goodness the criteria intend to deliver. “Checking the box” is a familiar way to get through an audit, meeting the letter of compliance, but missing the spirit.

How can security and compliance teams work together to create a winning alliance, protect data, develop according to modern practices, and still pass an audit?

Same Goal, Different Actions

Security and compliance are both looking to manage the same thing: risk. The goal is to protect the company, its data, and its customers.

Managing risk is the reason both groups exist. That shared goal should inspire a combined effort to achieve it. Both groups design, establish, and enforce controls to protect an organization. With so much in common, it seems like these two should be natural allies. So why does a situation like our gap analysis occur? Grammar will point us in a helpful direction, in this case, verbs. Security and compliance are both something you have, not something you do.

What do you do to become secure and compliant?

Security vs Compliance: The Security Part

Some of the verbs of cybersecurity are secure, prevent, protect, and detect. Protecting information assets from damage or theft is the mandate of the cybersecurity team, and the means by which they do that are predominantly technical.

The CIS Critical Security Controls and MITRE ATT&CK frameworks, for instance, are primarily technical in nature. Much of the training for cybersecurity focuses on the underlying tactics, techniques, and procedures. This often includes complex tools and deep technical knowledge. This makes sense as the day-to-day work of the security engineer involves technology to do vulnerability, file integrity, or secure access management to be effective and efficient.

A security professional may do asset discovery, vulnerability management, integrity management, or spend time configuring and managing firewalls. Developing and designing secure architectures to protect data in motion and at rest, preventing and detecting intrusions and monitoring and managing logs are all part of the cybersecurity daily routine.

Security vs Compliance: The Compliance Part

Compliance teams are also interested in managing risk, though their mandate is often broader than information assets. Policies, regulations, and laws go beyond information risk to cover physical, financial, legal or other types of risk. The role of compliance is to ensure that an organization complies with those various requirements. To perform this work, compliance teams audit, interview, report, and communicate. These are very different verbs than what security teams use, yet they are intended for the same purpose: protecting the enterprise.

If a security team lives in the world of technology, the compliance team lives in the world of words and documents.

Words govern the compliance team because they need to understand the rules under which they are governed and develop policies to both follow those rules and protect the business from other known risks. While the security team is tasked with implementing controls, the compliance team is responsible for ensuring those same controls are implemented. The former need only to assure themselves that their controls are in place and functioning as expected; the latter requires proof, which means generating evidence to satisfy a third party.

It is evidence that creates the largest gap between security and compliance, and it can be one of the most challenging aspects of bringing the two together.

Returning to our gap analysis, we are doing all the right things from a technical perspective: the code was well-written, the architecture was well-designed, deployment process well-executed. However, we were missing some critical documentation to prove this was the case one hundred percent of the time as well as policies to codify secure practices. An auditor can observe a point-in-time event, but without a paper trail, there is no guarantee that processes and policies are followed every time.

And therein lies an important challenge. It’s tedious to document processes, and many requirements seem to put roadblocks in the way of rapid development and deployment. There is a tension between the competing interests of security, development, and compliance, as well as trade-offs between velocity, simplicity, and documentation. Or is there?

A Winning Alliance

Does there have to be tension between security and compliance? It’s never been fun to have to show your work, and nobody wants always to be a nag, so what are ways to bring the groups together to create something stronger than the individual parts? Here are a few ways to create that winning alliance.

COMMUNICATE

“Communicate” was one of the verbs attached to the compliance group above. If they do it well, everyone wins. The following are important things a compliance team can communicate to be more successful:

• The Requirements – It may seem obvious, yet in our gap analysis, the dev team didn’t know the requirements up front. The sooner security and development teams understand what is required, the sooner they can find ways to meet those requirements. Building compliance in from the beginning makes audits easier, and that needs to be part of any control design and implementation.
• The Details – When communicating requirements, the people responsible need to understand what an auditor will be looking for. It’s not enough to say, “have a firewall.” Is layer 3 sufficient, or do we need layer 7? How is the firewall defined? Does it have to be an appliance or can other approaches like security groups work? Communicating the requirements in a specific, detailed way allows security teams to be compliant in a way that fits within their current workflow and technology choices.
• The Evidence – The teams that provide the evidence need to know what will satisfy the auditor. Will the auditor be looking for reports, screenshots, or policy documents? There are a variety of different things an auditor will want to see and knowing what these are ensures that nothing is missed come audit time. Developing the processes and artifacts early and often will save a lot of scrambling when an auditor is onsite.
• The Frequency – Many controls and requirements are frequency-bound. Does something have to happen annually or monthly? Perhaps the control is continuous, so how can you show that? Knowing how often something needs to happen allows security teams to plan ahead and schedule those tasks. This is especially important in situations where a missed task will be an audit finding because you can’t go back and make it up. A good practice is to perform frequency-bound tasks twice as often as required to avoid missing a control due to unforeseen circumstances like illness.

DOCUMENT

Documentation can be tedious and time-consuming, yet it is required for a successful audit. Documentation is both an internal reference and evidence an auditor will ask for.

Here are key documents for a winning alliance:

• The Controls – Generate a list of all the controls the enterprise has agreed to follow. These should have an ID, name and description and may also include frequency, environment, compliance, or regulatory framework reference, along with any other information the teams find useful. This is the common list of things the compliance team says are required and the security team says they do. Auditors also like to see these since they make an easy reference for them when performing audit work. You may develop your own set of controls, use something like NIST 800-53, or some combination of the two. Regardless of how you generate your controls, ensure everything in your compliance frameworks require is included.
• The Evidence – In communication, it’s critical everyone understands and agrees on what is considered acceptable evidence. For documentation, the focus is on the artifacts themselves. It is not enough to do the work; you should get credit for it! Meeting notes, access and rule reviews, reports and even email can be evidence. Develop a plan to create receipts for all the good work you are doing and be sure to have a known place to keep it. You don’t want to do all that paperwork and then not be able to find it when someone asks to see it. Even better, find ways to automate and store your evidence without having to think about it. The easier it is, the more successful you will be.
• The Calendar – Frequency has been communicated, so it’s useful to create a shared calendar to track the frequency-bound events, the audit schedule, and any time off for the teams. Having a visual representation of what is required when, along with who is available, makes coordinating all the security and compliance tasks easier.

AUTOMATE

The biggest win of the winning alliance is automation. Much of compliance is about producing the evidence and documenting the great work the security team does. Security benefits from turning manual processes and controls into automated tasks, and compliance can use that automation as evidence.

The three areas of automation that will produce the greatest benefit are:

• Workflows – Workflows are the easiest place to start. How many workflows still require manual steps or hand-offs? Look for opportunities to build documentation into steps and triggers to kick off the next ones. For instance, in a DevOps pipeline, source control repository tools make it easy to show code reviews and pull request approvals.
• Reports – If you are going in and generating reports manually, there is always a risk of failure, particularly in frequency-bound controls. It’s easy to forget or miss a reporting window. Generating and distributing reports in an automated fashion ensures they go out on time, ideally to a group of people responsible for analysis and action. Look for APIs and other ways to automate reporting functions.
• Documentation – I mentioned building documentation into standard workflows, and this is a great way to build security and compliance into day-to-day work. Like reports, there are opportunities to automate documentation. Asset and software lists can be generated based on triggers in the environment and then reviewed for authorization. The same can be done for users in access reviews. Collaboration tools also offer opportunities for automation. ChatOps can be a great way to create documentation based on processes you already have in place by triggering them in a tool already in common use.

The winning alliance comes when a security team has put in place great controls to protect information assets, and a compliance team validates that they are in place and operating as expected. This alliance ensures that security controls don’t atrophy and that required documentation is in place come audit time.

If you are interested in solutions that can help with security and compliance, Fortra’s security solutions can help, including vulnerability management, secure configuration management and FIM, malware detection, and log management.