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 designed and implement, yet some areas were not in 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 are intending to deliver. We’re all familiar with “checking the box” to get through an audit, meeting the letter of compliance and missing the spirit. How can security and compliance teams work together to create a winning alliance, protecting data, developing according to modern practices, and still pass an audit?
Same Goal, Different Actions
When it comes to the goals of both security and compliance, it boils down to one word: risk.
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, and often they are. So why does a situation like our gap analysis occur? Perhaps grammar will point us in a helpful direction; in this case, verbs. Security and compliance are both something you have not something you do.
So what do you do to become secure and compliant?
Secure, prevent, protect, detect. These are the verbs of cybersecurity. Securing 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 20 Critical Security Controls or the MITRE ATT&CK framework, for instance, are technical in nature. Much of the training from groups like SANS focus on technology, and the tools themselves can be extremely complex. This makes sense as many of the processes such as vulnerability, file integrity, or secure access management require technology to be effective and efficient.
A security professional may do asset discovery and vulnerability management with Tripwire IP360, file integrity and secure configuration management with Tripwire Enterprise 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.
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. In order 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.
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 has 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.
Let’s return to our gap analysis. We are doing all the right things from a technical perspective: the code was well-written, architecture 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 isn’t a 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 to always 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 in order to be more successful:
- The Requirements – It may seem obvious, yet in our gap analysis, the dev team didn’t know the requirements upfront. 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 can other approaches like security groups work? Communicating the requirements in a specific, detailed way allows security teams to be compliant 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 compliance-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 – 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 or use something like NIST 800-53 or some combination of the two. Regardless, ensure everything 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’s 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 both the frequency-bound events but also the audit schedule and any time off for the teams. Having a visual representation of what is required when and 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 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, tools like GitHub 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.
- 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 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 processes 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 required documentation is in place come audit time.
If you are interested in solutions that can help with security and compliance, Tripwire’s security solutions can help, including vulnerability management, secure configuration management and FIM, malware detection and log management. Whether you need protection for the data center, cloud or industrial and OT environments, Tripwire can help.
To learn more about this topic, join me on March 30 at 10 a.m. PST as I look at how compliance compliments a security program, the differences between security and compliance, and share tips for how you can build a program that is both secure and audit-ready
You can register here: https://info.tripwire.com/register-tripwire-tips-and-tricks-security-vs-compliance
