Compliance activities are often viewed as frustrating but necessary. That’s an understandable view as teams often have to apply a set standard to existing systems and figure out how to collect enough evidence to answer an audit.
That work requires a lot of documentation, verification, and digging up answers to questions long forgotten. Approaching compliance in this way — while common — does your security practice a disservice.
Let’s ignore the word “compliance” for a bit. Can you answer this deceptively simple question: “Is your security practice doing what you think it is?”
Are the controls you’ve rolled out effective? Do other teams follow the appropriate process for changes? Can you follow a transaction across your systems to respond to an incident?
Are We Supposed to Test?
One area with a shocking lack of attention is testing, and that’s probably because testing in development is always a challenging balance of effort vs. return. But at least within the build process, it’s accepted that code and integrations must be tested.
When was the last time you saw a standardized regular security control test?
At best, teams will engage in a penetration test or a red-team exercise. While these are often a heavy lift, they often generate excellent results, even if they take a significant investment of resources and time. Unfortunately, you won’t see that level of effort applied for each and every deployment to production.
If we keep digging, we’ll find teams that do, in fact, have some testing integrated into the CI/CD pipeline. Vulnerability scanning and infrastructure-as-code (IaC) template scanning are the most common tools implemented here.
Vulnerability scanning aims to find known vulnerabilities in out-of-date software. These issues can often be addressed by updating code dependencies, applying a path to update key software, or rolling out a mitigating control elsewhere in the infrastructure.
IaC template scanning is looking for potential issues before they hit production. Misconfigured permissions, gaps in logging, unencrypted connections, and other issues can be addressed by builders much easier at this stage when compared to addressing them in production.
But these two steps are often the end of any security testing. Why is that?
Too Many Competing Priorities
One simple answer is that it just usually isn’t done. Security testing typically happens when evaluating a control or process but after that, the assumption is that it continues to work.
If you shuddered a bit at “assumption,” you should. As a community of practice, if we want to keep our tin foil hats, testing should be top of mind.
Nothing is ever that simple, though. Testing security controls can be tricky, which makes figuring out how to automate tests even more challenging for teams that historically don’t have a deep bench for development activities.
With the move to the cloud, the barrier to security testing has dropped significantly. We’ve seen the first steps with the inclusion of vulnerability and IaC scanning inside the CI/CD pipelines used by development teams.
It’s time for security teams to implement regular testing not only in the build pipeline but in production.
Simple Wins the Day
Testing doesn’t have to be complicated. Simple checks will go a long way.
Validating that a security group actually prevents access from unlisted IP blocks, verifying access for users and systems, making sure that logs are being written to the correct location, and other tests are a good place to start.
These basic checks provide a safety net beyond vulnerability and IaC scanning to verify that your security controls and processes are working as expected.
What About Compliance?
The bonus? That type of testing and verification is compliance. When you peel back the layers, compliance activities are really just proving that you are doing what you said you were going to do.
Organize the results of these tests with compliance audits in mind, and you’re doing the work as you go. That’s continuous compliance. If you and your team can build that habit, it not only improves your day-to-day security practice, it will greatly simplify your compliance work as well.
This isn’t a different approach to compliance; it’s just a different way to look at it. Hopefully, it’s a perspective that helps you understand the value.
Your next steps are to start to build and automate these simple tests, roll out tools such as vulnerability and IaC scanning, and start practicing continuous compliance.
About the Author
I’m a forensic scientist, speaker, and technology analyst trying to help you make sense of the digital world and it’s impact on us. For everyday users, my work helps to explain what the challenges of the digital world. Just how big of an impact does using social media have on your privacy? What does it mean when technologies like facial recognition are starting to be used in our communities? I help answer questions like this and more. For people building technology, I help them to apply a security and privacy lens to their work, so that they can enable users to make clearer decisions about their information and behavior. There is a mountain of confusion when it comes to privacy and security. There shouldn’t be. I make security and privacy easier to understand.Source: www.darkreading.com