Building a SOC for Compliance

Originally published by RegScale.

There are not many things I have hated in my professional life more than getting surprised in an audit. It is embarrassing, damages your credibility, and makes it harder to accomplish your strategic goals as you get distracted by fighting the small forest fires that get set by audit findings. These findings suck up a lot of time and resources, usually result in a fair amount of external reporting, and always cause some unplanned quality time with your boss until they are remediated. What is even more frustrating is that you normally know when the audit is coming, have plenty of time to prepare, and still end up in these embarrassing situations. How does this keep happening and what can be done about it?

When we started thinking about this problem, we realized that cyber incident response could serve as a good analog for comparison. Earlier in my career, cyber security faced the same problem as hackers started to proliferate and become more sophisticated. Organizations were surprised when their devices and data were hacked and as the problem grew, these hacking events became career limiting. The response in the industry was to move towards continuous monitoring platforms to detect anomalous events and to stand up Security Operations Centers (SOCs) to provide Incident Response (IR). Today, most large organizations maintain these capabilities and have a good grasp of what is happening on their networks and devices.

However, compliance is still living in the old world. Paperwork becomes stale very fast and audits then expose these problems as findings that cause a bunch of rework and distraction. Keeping up to date with these changes to paperwork in the age of digital transformation is a losing battle as the changes in the environment happen so rapidly that paper-based processes will never be able to catch up. Once you move to serverless architectures, you might as well give up if your processes still rely on paper. Similar to cyber security, compliance needs to become real-time. What we determined is that the time has come for a SOC for Compliance.

Once we recognized the need for the SOC for Compliance, the next step was to determine the components and their interactions into an overall solution. There are multiple architectural components needed. The system would need to be API centric for real-time communications, machine readable using open standards, interoperable with existing continuous monitoring, supported by modern ITIL workflows, and supportive of existing processes for conducting human-based audits while also delivering a great machine to machine experience. The results is the high level process you see below:

Below we will walk you through each of the architectural pieces and their interactions that are combined to deliver the Compliance SOC:

• Scanners – most organizations have made existing investments in continuous monitoring that they are unlikely to walk away from. Rather than try to build a better mousetrap, layer on top of existing tools to make them more valuable.
• Processors – the next problem is parsing, normalizing, and ingesting data from the continuous monitoring solutions such as Wiz.io and Tenable. A Command Line Interface (CLI) can perform bulk data processing and loading into the core platform. Next, containerize the CLI to allow it to be scheduled as a Kubernetes job that can spin up and down on a schedule to keep data in sync between the scanners and platform. The result is a cloud-native solution for bulk processing compliance data using machine to machine interfaces to avoid the need for manually collected data via logs and screenshots with humans.
• ITIL Tools – once you know there is a compliance problem, you need to fix it. The CLI should also support integration with commercial ITIL tools. The CLI will look at findings from the commercial scanners, create issues/POAMs, and then auto-create tickets in the ITIL tools for remediation. This approach keeps paperwork up to date automatically and avoids the need for manually creating and updating tickets across systems and paperwork. When reviewed later, the auditor can see the tool that found the problem, the ITIL ticket that fixed it, and the associated paperwork updates all in one place with detailed cross-referencing to tick and tie the audit evidence.
• Reporting – even though this process is continuous and self-updating, auditors will still need to review static/point-in-time compliance artifacts. Allow all artifacts to be printed, PDF’d, or exported to Excel to support manual audits. Visualize changes in compliance over time with dashboards and scorecards.

The SOC for Compliance reduces risk by detecting problems in closer to real-time, lowers costs by reducing manual labor to gather evidence and open tickets, and speeds Digital Transformation by allowing new technologies to be introduced into a continuously audited environment without all the manual paperwork.