Taking SOC2 From Manual to Automated
Updated February 28, 2024.
Let’s admit it, even though we all know and understand we need regulations and standards like SOC2––these compliance processes are always a hassle to get through. We’ve made A LOT of progress when it comes to compliance, however, there’s still more that we can do to reduce the friction (particularly for engineering teams).
If historically the process of getting through SOC2 compliance involved hiring a consultant who comes in and does a discovery and assessment that takes weeks or months, comes back with findings that they toss in your lap, where you then need to scrape up the necessary engineering resources to remediate all the findings––all of this is a long, arduous and largely manual process. This is particularly true, when we just consider the sheer effort of translating all the findings to actual work, and understanding what's involved with fixing these.
Let’s Rethink SOC2 for the Cloud Native World
It’s no surprise that SOC2 has been quite a good way for many security engineers to make a good living, myself among them. However, I will be the first to admit that it doesn’t have to be this way. We’ve made sufficient progress in security engineering to forge a new path of simpler compliance processes––through automation and DevSecOps.
While it may always seem like a loaded buzzword, by starting with a secure software development lifecycle, you’ll quickly find yourself most of the way through your journey to compliance. What this breaks down to in practical terms is ensuring you have automated security controls, from the secret scanning to the code scanning, infrastructure as code security (IaC security), through cloud and runtime security.
These technical controls––that SOC2 defines as vulnerability management and secure software development––that DevSecOps platforms today will provide out of the box––enable you to have up and running in a day (or even a matter of hours). These are a great first step in your SOC2 compliance process, and provide the most important aspects of achieving the required technical controls in SOC2, as well as many other security standards and even cloud security frameworks like AWS FTR or the Well-Architected Framework.
A DevSecOps Platform as Your Security Team
Many companies will have a limited security team––the security to engineering ratio is oftentimes still quite lacking, yet there is a customer-driven need and demand for security and compliance. Using a security platform is the obvious and recommended first step that often helps to reduce the pressure on smaller security teams or even engineers that are “security champions”, before a security team is established.
A DevSecOps platform is almost like hiring a “security team”, that knows how to translate the security issues to technical work engineers can understand, and remediate. These will help with the core technical controls required by compliance frameworks, such as testing changes before they are shipped, comprehensive vulnerability scans (not just host-based scans), as well as running them early in the process, such as in the CI/CD and dev process, all the way through cloud and runtime scans.
Most engineering managers will attest that’s the biggest hurdle from a SOC2 perspective. Those who have gone through a manual SOC2 process before leveraging a DevSecOps platform, know the direct impact of having to manage such a process manually––and it’s always painful. Even when using compliance automation platforms––you’ll often invest a lot of effort to constantly maintain and configure policies and controls, with an endless laundry list of tasks to attend to. In early stage companies, many times there isn’t even a dedicated security team––either the CTO or engineering team needs to manage this, and the consensus is that it’s very cumbersome to get through the compliance process.
What ends up happening, is the person who gets the prize of “owning the compliance process”, needs to run after developers to ensure they make the necessary changes and then going forward that they continue to write, deploy and run secure code, and follow up on alerts they receive. This tends to break down, especially in early-stage startups, but in more mature organizations as well. Most of the time you either don’t do this at all––as you can’t get to it all, or you do mega sprints twice a year to address your growing security backlog and debt.
Tools that are aimed at providing a great developer experience, will focus on making these types of alerts and fixes as native to the developer workflow as possible––automatically opening remediation PRs with fixes or pointing to the exact line of code that needs to be fixed. This way, the security champion doesn’t have to chase down engineers, and there is greater transparency to issues, and also better security culture for fixing new issues too.
Another aspect that a DevSecOps platform solves in the “time to coverage”. Another thing that often happens, once the dime has dropped, and it’s clear that a security program needs to be stood up quickly––is that teams go down the rabbit hole of qualifying the many tools that will provide them the end-to-end coverage a software stack requires today. This hodge podge of tooling needs to be qualified and then implemented piecemeal, and even after implemented, configured and automated individually.
It’s quite a lot of work to ramp up security without a platform. This is where a security toolkit and program can alleviate a lot of this friction.
A Security Toolkit FTW!
Having a security program and toolkit will provide you with a head start to compliance even if you haven’t started to think about your SOC2 journey yet. These will help you to accomplish three important things:
Provide much needed visibility to existing security gaps
Stand up your security program, particularly if it was limited or implemented piecemeal
Centralize and consolidate controls in a single place
These three critical pieces to security, and as a byproduct compliance, are the highest level of effort. Only after you implement all of these the “old way” and then upload it all to a compliance platform, will you have a real understanding of where you stand vis a vis your SOC2 journey––after the fact. Which may require you to go back and make changes to your S-SDLC and configurations and much more until you get it right. Companies can go through this process numerous times, if their compliance journey comes before a sold security program is defined and stood up.
Out With the Old - In with the New
With the old, manual process of achieving compliance, you have a lot of work to do before you can even know where you stand with regards to your security posture. Your auditors will pull up your results manually, and you better pray to the compliance gods that you checked all the right boxes. Otherwise you’ll have weeks to months of work to close the gaps before you can achieve your compliance goals.
By thinking about security first, you essentially close all your “gaps” even before you start your SOC2 or other compliance process. With modern, security automation platforms, it’s possible to stand up a security program, improve your continuous security posture, while at the same time meeting compliance requirements.
