SOC 2: Where Linux Live Patching Fits In

SOC 2 is everywhere, and everyone has it; customers ask for it; enterprises need it. But what is it? And where does Linux kernel live patching fit in?

We provide a concise description of what SOC 2 is, what it consists of, and why organizations running Linux servers might be thinking about it.

An Introduction to SOC 2 ®

SOC 2 is a procedures, systems, and data management certification developed by the AICPA. It is a sign of good data governance, and a way of getting a well-regarded quality certification. It audits system and organization controls (hence ‘SOC’), and is a public declaration by an enterprise to its customers, saying that:

• your data is secure (1) and private (2),
• the system processing it is available (3),
• and the system maintains the integrity (4) and confidentiality (5) of your data.

These are the five categories that arrange a larger number of Trust Service Criteria, a set of principles forming the backbone of a SOC 2 audit report. These guide external auditors, helping them to measure the effectiveness of the policies and systems an organization uses to execute its objectives.

The result of an audit is a report that lets your company claim bragging rights to SOC 2 compliance, assuring customers that their data is well looked-after, and the services they need are reliable, accurate, and available. Audits are usually valid for a year, so organizations serious about attaining SOC 2 compliance show their long-term commitment by hiring specialists and implementing system design changes, making future audits easier.

SOC 2 has become a popular route to compliance because it is pragmatic: it is flexible and voluntary; it sidesteps legal considerations and their associated expense; you can choose which parts of an organization it is for; you can choose which systems it is for. It is this last aspect that appeals to organizations offering SaaS, e-commerce, web hosting, and similar public-facing, data-centric services, giving them an adaptable, scalable, and cost-effective way to become compliant.

Trust Service Criteria (Principles)

The Trust Services Criteria are grouped into five categories.

• Security: Information and systems are protected against unauthorized access that might threaten the availability, integrity, confidentiality and privacy of data.
• Availability: Systems and data are accessible and available.
• Processing Integrity: Data is complete, accurate, and timely, and changeable only by authorized processes.
• Confidentiality: Data is protected from unauthorized access, and confidential data has been identified.
• Privacy: Personal Data is acquired, stored, used, and deleted in agreement with local protocols. (Distinct from confidentiality which deals with any sensitive information, not specifically personal.)

Not only do these broadly describe which aspect of a system are being inspected, they also help the auditor and the subject of the audit (called the entity in SOC 2 documentation) decide what the scope of the audit should be.

Each trust service criterion has one or more points of focus assigned to it. These are aide-memoire for the audit process, helping to draw attention to aspects of the criteria, and define a common language with which to evaluate them.

Types of SOC 2 Reports

A Type I report says that an organization meets the selected criteria; a Type II report says that an organization has been tested and shown to meet the selected criteria. The difference between them is that Type I is seeing that your controls and procedures are in place, while Type II means these have also been tested, and proven to be effective.

The benefits of being SOC 2 compliant

SOC 2 has become a brand, one that service users recognize and increasingly ask for from their service providers. It is an open and well-respected certification scheme with a large following in North America. Big-name data companies have opted for it, making it the de facto standard for best practices, encouraging smaller ones to follow suit and attain the certification.

Even without customer or peer pressure, organizations can benefit from an independent perspective of their operations, and an opportunity to uncover oversights in policies and procedures, or faults in the design of system architectures. A SOC 2 report can be an input into a company’s continual improvement process, serving as a benchmark, a measurable baseline against which other companies, or a company’s own future audits, can be compared against.

Get a FREE 7-Day Supported Trial of KernelCare 

The role of Linux kernel live patching

Linux servers power significant portions of the Internet, and underpin many online service infrastructures and data centers. In large enterprises, the number of unique Linux instances can number in the tens of thousands, (or millions, if they happen to be a major search engine). It is safe to assume they are not employing armies of system administrators to perform manual kernel updates—they are automating. Without automation of Linux kernel patching, compliance would be impossible because hundreds of Linux kernel vulnerabilities appear every year.

Batching up kernel patches to a convenient maintenance window is no longer acceptable under SOC 2, and because SOC 2 inspections are repeated, additional systems administration work can’t be done manually. So, in almost all cases, systems must change to become compliant. Simplicity and automation have to be the guiding principles behind those changes—there is no sense in making an already complex system even more so.

Live patching technology steps in as one part of this change process, replacing a small but essential system administration function, the installation of Linux kernel security patches, with one that automates it, eliminating the service interruptions normally associated with this effort. To dive deeper into the role of Linux kernel live patching, we are hosting a webinar with AWS on exactly this topic.

How Live Patching fits into the SOC 2 Trust Services Criteria

For organizations that make the effort to get a SOC 2 certification, the experience can be daunting and terrifying, yet liberating and insightful. At the end of all the hard work, of documenting system and business processes, of cataloging servers and interviewing staff, is a better understanding of how a company does business, and a clearer picture of the systems driving it.

The stepping stones on the road to SOC 2 compliance are the elements of the Trust Services Criteria, the points of focus. Of them, two stand in direct opposition, when seen from the perspective of Linux system administration.

• Focus points in CC5.2 look to see that controls are in place to ensure availability of services.
• Focus points in CC7.4 focus on security, obliging you to install critical kernel security patches as soon as they are available.

Anyone familiar with Linux system administration will see the conflict. Keeping a Linux kernel compliant by installing the latest security patches means taking it offline, and making it unavailable. There are other ways to keep servers compliant without sacrificing availability, but they require additional redundant servers and architectural planning, an additional cost for many enterprises.

Live patching is the only technology solution for Linux servers that squares this circle. It automatically installs Linux kernel patches, keeping them at the latest security patch level. It does this with no downtime whatsoever—no reboots are necessary.

Conclusion

While it is difficult to attain SOC 2 compliance, it brings only benefits. An audit is a process of self-reflection, forcing an organization to examine the way its technology manages data, and identify any weak spots.

To be in compliance for the long haul, to be able to satisfy auditors year-on-year, an organization must look for effective ways to automate resource-intensive tasks. One of the easiest to tackle with a Linux-based information infrastructure is the routine updating of kernel patches. This is where KernelCare fits in.