Tools for Meeting and Maintaining SOC 2 Compliance

Meeting System and Organization Controls (SOC) 2 compliance is more than just a simple process implemented once to pass an audit. Permanent procedural changes are tedious and time-consuming but are necessary to ensure that the organization can pass a SOC 2 audit. It’s more than simply supplying a paper trail to a CPA. You must have the right controls and tools in place to maintain compliance permanently or risk violating compliance standards. Losing SOC 2 compliance isn’t an option for most organizations, but the right tools will keep you compliant and help facilitate continual compliance in future audits.

Contents

1. A Brief Overview of SOC 2
2. Meeting SLA Standards
3. Tracking Metrics to Determine Compliance
4. KPIs Affecting other Metrics
5. Tools to Stay Compliant
6. Conclusion

A Brief Overview of SOC 2

For organizations currently looking into SOC compliance, it can be an overwhelming amount of information to consider. It might seem like everything needs an overhaul. Most organizations work towards SOC 2 or SOC 3 compliance. The main difference between SOC 2 and SOC 3 compliance is that SOC 3 audit reports are made publicly available. Requirements for both types are the same, but SOC 3 is usually publicly distributed on the provider’s site. For example, Google’s cloud platform is SOC 3 compliant and reports can be read on their site.

SOC 2 audits focus on your organization’s ability to secure data and the controls used to ensure the continuous availability and integrity of your customer data. The five main principles of an audit are:

• Privacy: Does your organization maintain data privacy using access controls, multi-factor authentication (MFA), and encryption?
• Security: Do you block attackers from accessing data using firewalls, intrusion detection, and MFA?
• Availability: Does your infrastructure include performance monitoring, disaster recovery, and the ability to handle incident management?
• Processing integrity: Does your software development lifecycle (SDLC) and change control include quality assurance and process monitoring?
• Confidentiality: Does data storage include encryption, access controls and firewalls to protect from unauthorized users?

Note that SOC 2 compliance is not a certification like other compliance standards. It’s an audit of your current procedures and infrastructure to ensure you meet a high-level standard of data security and availability. 

Meeting SLA Standards

Often in the rush to review and augment cybersecurity infrastructure, Service Level Agreement (SLA) standards are overlooked. SLAs are the promises that you make to your customers, and these promises are contractual and must be met. For instance, if you give customers a 5-day resolution time for a medium-level issue, it must be resolved within that timeframe or you miss your SLA target.

At KernelCare, we are both a customer and a provider. We provide services to customers, but our internal IT staff must support internal employees and meet SLAs set forth by our own standards and promises made to internal employees. By being both a customer and a provider, we understand the importance of meeting SLAs and also the importance of setting reasonable expectations.

SLAs can be negotiated, but once the contract is signed, it’s imperative that organizations strive to meet SLA requirements. SLA requirements and metrics are usually tracked in internal applications such as ticketing systems. One such SLA requirement is uptime and covers the SOC 2 audit principle for availability.

Tracking Metrics to Determine Compliance

For organizations striving for compliance, one of the first steps is to run reports and collect metrics in the form of Key Performance Indicators (KPIs). KPIs are used to measure several distinct metrics across all IT systems. KPIs can tell you where you excel and where there is room for improvement. They can also tell you where you need to focus on better strategies and eliminate bottlenecks.

A common KPI used in SOC 2 compliance is uptime measurements. Uptime (or system uptime) is the amount of time a system is available throughout the year. The system could be a server, networking equipment, or storage. Any downtime works against this metric including scheduled maintenance that takes the service offline and requires a reboot. 

To achieve excellent uptime availability reviews, providers strive for a number of nines. The more nines in the uptime percentage, the better quality uptime and availability a provider can offer customers. As an example, an organization that can promise only 52.60 minutes of downtime every year has an availability or uptime percentage of 99.99% or four nines. The lower the downtime number, the higher the uptime percentage. All organizations strive for 100%, but the reality is that issues arise that unexpectedly take down a service, even if just for a few milliseconds, and monitoring, alerts and staff response are critical to remediation SLAs.

Uptime isn’t the only metric used in compliance reviews. Usually, organizations have several KPIs they follow to determine effectiveness of current procedures. A few other metrics include:

• The number of applications found to be vulnerable to CVEs (Common Vulnerability Exposures) separated by severity level (e.g. High, Medium, Low).
• Average time it takes to patch vulnerable software including the operating system
• Availability by service
• Host or network load and latency

KPIs Affecting Other Metrics

In some instances, you may find that you have conflicting KPIs that muddy the waters and make it difficult to determine what is going on. A common KPI is the infamous “vulnerability gap,” which is the time it takes to patch a system once a scan finds that software is vulnerable or out-of-date. This gap increases for every hour that goes by and the system is unpatched. 

Organizations that delay patching might find this metric to be too high for compliance. What usually happens is patching is scheduled for a specific day every month (or possibly every week). The issue is that vulnerabilities are now known publicly and some are announced with exploit code. By delaying updates to software, the server remains vulnerable and open to exploits. In 2019, 60% of data breaches were caused by vulnerabilities where a patch was available. 

One KPI metric can affect another and throw off several goals. For instance, the vulnerability gap and the patching that takes place can affect uptime if the server must be reboot. New CVEs are announced and patches are deployed every day, so it can become difficult for organizations to keep up and avoid a reboot, which then creates downtime affecting SLAs. For instance, if you must patch a system within 30 days and every scheduled patch session requires a reboot, your uptime percentage lowers.

Tools to Stay Compliant

A good strategy to meet compliance and stay within SLA requirements is to use automation. Automation can detect many issues before they become critical breaches or compliance violations. They can also be used to remediate some issues such as patching. Patch management automation tools integrate well with many of the vulnerability scanning tools on the market, so they can be used in conjunction to improve the vulnerability gap.

When vulnerabilities are patched manually, it can be overwhelming for administrators. They must read reports, determine the right software version, test the patches, and then deploy to production. For an organization with hundreds of servers, this would require an entire team who would manage patching full-time. This system would be a waste of resources for the organization when automation tools are available. Instead of manually patching, automation tools save time and resources.

Here are some tools KernelCare uses to meet SOC 2 compliance and improve security across every server:

• Tenable Nessus: Nessus is one of the more popular vulnerability scanners on the market. It will scan your network and find vulnerabilities including unpatched software.
• Ivanti: Ivanti will discover assets and manage patching automation. 
• KernelCare: We use our own product to keep software patched including third-party libraries and the Linux kernel. In addition to automatically patching software, KernelCare is a rebootless solution, meaning servers don’t need a reboot after patching. This service keeps our uptime metric as high as possible without losing percentage points due to reboot downtime.

Conclusion

Keeping servers updated with the latest vulnerability patches is required to stay compliant, but so is keeping uptime SLAs. The conflict can make it difficult for organizations to find the right tools and develop procedures that meet all requirements. WIth automation including rebootless patching, organizations can keep a high percentage uptime while still patching vulnerable systems within 30 days. The result is that these tools get you that much closer to SOC 2 compliance after going through an audit.