For IT directors and the departments we run, achieving SOC 2 compliance is not a one-off challenge. It’s a commitment to continual improvement and constant vigilance; it means making a lot of changes to our organization’s processes and protocols.
Change is necessary but it can unsettle staff and cause them to suffer increased workloads for what seems a pointless and purely bureaucratic endeavor: meeting the terms of the compliance specification.
The problem isn’t so much the work needed to get SOC 2 compliance as the challenge in keeping it. Whatever changes we make to satisfy the auditors must stay in place. They must be repeatable and become a natural part of our organization’s functions. If we add procedures, we must automate them; if we add tools, they must be effective.
At KernelCare, we’ve been working on gaining SOC 2 compliance. As the company’s IT director, I’ve been participating in the efforts and seeing the effects first hand. In this article, I’ll be sharing some of the approaches we used to get compliant and stay compliant.
SLAs: When Promises Become Contracts
Anyone working in DevOps will have come across an SLA, a Service Level Agreement. A SLA is effectively a contract that describes the service one party provides to another. In our case, we are both supplier and consumer. This isn’t as strange as it sounds. Many organizations work with internally-negotiated SLAs, so that everyone knows where they stand and what they are responsible for.
SLAs need to be expressed in measurable terms. An example of a popular common metric is system uptime, often expressed as a percentage, or less formally, as a certain number of nines. A SLA is then an agreement that uses these figures as a basis on which to document how an IT department and its systems must perform – it is an objective view of performance.
KPIs: Pointing the Way to Compliance
SLAs can seem like adding yet more layers of complexity to the already difficult task of dealing with and adhering to compliance policies, especially when the contracts are among departments in the same company. For organizations in the process of attaining compliance, or intent on keeping it, SLAs are a technical formalization of compliance requirements, essentially a translation of the legalese of the compliance specification into numbers and facts the IT department needs to satisfy compliance regulations.
Like an aircraft’s instrumentation, KPIs tell you if you’re heading in the right direction to meet your SLAs.
Service providers need internal measures, ones that focus on the systems and processes providing the services that aim to satisfy SLAs. These internal measures are Key Performance Indicators (KPIs). A KPI unambiguously measures the performance or effectiveness of a system component, be that software, a process or a person. KPIs make it clear whether or not an SLA will be met, and if not, what needs to be done about it.
Examples of KPIs
- Counts of software vulnerabilities for each CVE severity (LOW, MEDIUM, HIGH) for each software category and system component
- Average time to patch components by software category
- Availability by service
- Host/network loading
KPIs in Conflict
A key KPI that appears in most IT SOC 2 compliance efforts is the so-called ‘vulnerability gap.’ This is the time between when a software patch is available and when it’s correctly installed on a system. As this gap gets bigger, so does a system’s risk of being exploited by the vulnerability the patch addresses.
Like trimming the legs on a wobbly chair, getting one KPI within limits can affect others, sending them outside defined thresholds and thereby threatening the integrity of the SLAs they define. For example, with our Linux servers, if we patch the kernel every time a CVE comes along, our uptime KPI falls below the level defined as the minimum for SOC 2 compliance. In such cases, at least when managing Linux server compliance, SLAs containing such conflicting KPIs will always fail. This is because installing a Linux kernel patch means rebooting; rebooting means downtime, and downtime means lower availability.
An example of conflicting KPIs:
- You must install patches within 30 days of release
- Uptime must be greater than or equal to 99.99% availability (‘four nines’)
Tools for Compliance
When you’ve proofed and approved the SLAs to meet your compliance objectives, when you’ve identified and implemented the KPIs that fulfill your SLAs, then you’re ready to automate. You’ll do that with tools, and it’s here that you can use your own tools and development skills as well as those from outside.
To explain further, here’s my own experiences with making our Linux servers compliant.
Nobody knows when the next Linux kernel vulnerability report will come. If we tried to measure and monitor KPIs manually, with every new batch of vulnerability reports my staff are overwhelmed, and our continued SOC 2 compliance status is at risk.
Naturally, as system engineers, we don’t do things manually when we can automate, either by inventing tools ourselves, or by buying them in. At KernelCare, we already know that Linux kernel vulnerability detection and management can be easily automated. Here are some of the tools we use:
- Tenable Nessus is a popular vulnerability scanner. We use it to regularly inspect our system’s software inventory and tell us when any component has a patch available
- To reduce the vulnerability gap to its absolute minimum, we automate the installation process using Spacewalk
- For dealing with the problem of conflicting KPIs mentioned above, we naturally turned to our own KernelCare product to live patch the kernels on our Linux servers without stopping or interrupting them – KernelCare patches Linux kernels without rebooting
Conclusion
People and processes are both key elements of change on the road to compliance, but if processes change too much, they impact your people. That’s when you see the point of automation, and realize it isn’t an option, it’s a necessary part of compliance-driven change, as is the intelligent selection of products.
KernelCare is just one product in an armory of solutions that compliance practitioners can use to enable continuous and efficient attainment of compliance protocols such as SOC 2.
The irony is that a key part of our SOC 2 compliance solution was right in front of us. Perhaps you already have in-house software that can be repurposed to help automate the processes to keep your system and your organization compliant.
‘Dogfooding’ is using your own products. I find that phrase a trifle unsavory. I prefer to think of it not as having your cake and eating it, but baking your cake and eating it. Enjoy!
