If you help to manage or secure cloud or container environments, you probably don’t look forward to preparing SOC 2 reports. SOC 2 compliance can feel tedious.

However, when you consider that complying with SOC 2 rules helps you avoid penalties and fines that may result from violating other compliance rules, the value of the time and effort required for SOC 2 compliance becomes obvious. By providing early warnings about potential compliance issues, SOC 2 reports allow you to get ahead of problems before they snowball into larger compliance risks.

In this article, we explain what to know about SOC 2 compliance when working with cloud- and container-based environments specifically. As we’ll see, although the SOC 2 rules don’t provide specific guidelines for how to secure data within these environments, there are some core best practices that teams should embrace when preparing for SOC reporting and compliance within these contexts.

What Is SOC 2?

SOC 2 is a set of criteria that businesses should follow when managing customer data. It’s part of the System and Organization Controls (SOC) framework developed by the American Institute of Certified Public Accountants (AICPA).

There are three SOC controls: SOC 1, which deals with financial reporting, SOC 2, and SOC 3, which focuses on system availability and security. However, out of the three SOC controls, SOC 2 has become increasingly important in the context of modern cloud computing because it has important implications for cloud-centric architectures, such as SaaS, that by their nature involve storing or processing customer data on third-party infrastructure or with third-party applications.

What Are the SOC 2 Requirements?

SOC 2 compliance is oriented around five so-called trust services criteria: security, availability, processing integrity, confidentiality, and privacy.

To comply with SOC 2, then, organizations must be able to demonstrate that they adhere to the following rules:

• Security: They implement reasonable security safeguards within applications, networks, and infrastructure.
• Availability: Using techniques and practices like disaster recovery, they maintain systems availability.
• Processing integrity: They monitor data processing to ensure accuracy and deal with data quality problems.
• Confidentiality: They keep sensitive data secure (meaning it is protected from misuse, manipulation, or abuse) using methods like access control and encryption.
• Privacy: They keep data private (meaning that only users who should be authorized to access it can access it) using authentication and access controls and encryption.

For full details on the SOC 2 trust services criteria, refer to the AICPA’s trust services criteria documentation. The documentation specifies a number of “controls” that businesses should implement to meet the trust services criteria.

How Does SOC 2 Reporting Work?

To demonstrate SOC 2 compliance, organizations prepare a report that focuses on demonstrating how their IT architectures and management processes conform to the five trust services criteria.

Unlike many other compliance frameworks, however, the SOC 2 is famously non-specific about which information should be present in compliance reports. It leaves it mostly up to organizations to interpret the ways that the trust services criteria should be applied to their environments.

Who Needs SOC 2 Compliance?

Because SOC 2 is developed by an independent organization rather than a regulatory agency, there is no legal mandate to comply with it. Nor are there penalties for non-compliance with SOC 2.

However, many businesses prepare voluntary SOC 2 reports as a means of identifying risks that could trigger violations of other compliance frameworks. For example, an SOC 2 audit might identify weak access controls over customer data within an application or a lack of encryption when transporting customer data over the network. Problems like these could conceivably become violations of regulatory compliance laws like HIPAA or the GDPR, depending on the type of data involved. By identifying the problem through an SOC 2 report, you can address it before it turns into a regulatory issue.

Along similar lines, organizations may also use SOC 2 reports to demonstrate compliance with security best practices to their customers or partners. Public cloud providers use SOC 2 for this purpose, for example.

SOC 2 Controls for Containers and the Cloud

In general, only two sets of the SOC 2 security controls have implications for containers and the cloud. The first such set are those in the logical and physical access control family, and the second consists of the system operations control family.

The following is a summary of each control family and what it means for containers and the cloud.

Logical and Physical Access Control Family

This control family includes six controls that are relevant for container and cloud environments:

• CC6.1: Within container images and in runtime environments, tools should be in place to protect against security events such as privilege escalation. Tools like Kubernetes RBAC can help here.
• CC6.2: Unauthorized access attempts should be detected and blocked. Kubernetes audit logs are one useful means of detecting such attempts.
• CC6.3: Prevent attempts to defeat access control mechanisms. Here again, Kubernetes audit logs can be helpful for detecting such attempts.
• CC6.6: Unauthorized network connections should be detected. Networking monitoring tools and Kubernetes network policies are helpful here. So are service meshes, which can restrict interactions between microservices.
• CC6.7: Secrets data (such as passwords) must be securely managed. Securing Kubernetes etcd is important for this purpose, as is avoiding hard-coded secrets in container images or deployments.
• CC6.8: Detect malicious software within container images and prevent its deployment. Container image scanning is the key resource for this task.

System Operations Control Family

Under the system operations control family, there are two controls to follow:

• CC7.2: Detect anomalies that could signal security events. To this end, you’ll want to collect and analyze container logs, Kubernetes audit logs, node OS logs, and similar data sources in real time.
• CC7.3: Evaluate security events to understand their impact. The ability to correlate a variety of data sources – such as, again, container logs, Kubernetes audit logs, and logs from node servers – is critical for this purpose because it allows you to interpret relationships between security events and identify root-cause security risks.

Conclusion

Even if you aren’t legally mandated to comply with SOC 2 security controls, the small amount of time and effort required to perform an SOC 2 audit can pay large dividends by allowing you to get ahead of compliance issues that could turn into regulatory fines. SOC 2 is also a valuable means of demonstrating your commitment to security and data privacy to customers.

And, when it comes to containers and security, the SOC 2 rules are not particularly complex or extensive. That’s yet another reason why SOC 2 compliance is an obvious proposition for any organization that manages cloud-native infrastructure.