This article contains useful tips to implement SOC 2 compliance for containers and Kubernetes.
The Service Organization Controls (SOC) reports are the primary way that service organizations provide evidence of how effective their controls are for finance (SOC 1) or securing customer data (SOC 2, SOC 3). These reports are issued by the American Institute of Certified Public Accountants (AICPA).
You, as a service organization, may be asked to be SOC 2 compliant by another company requesting your services (user entity), as the final responsibility on how customer data is managed relies on the service organization.
The most important SOC report regarding security is SOC 2 type 2. SOC 1 is about financial reporting, and SOC 3 and SOC 2 type 1 are only subsets of SOC 2 type 2. With this in mind, let’s introduce SOC 2 (type 2) and how it applies to containers and Kubernetes security.
Creating a custom SOC 2 compliance report
One differentiator of SOC versus other compliance standards is the lack of a predefined control list to implement. SOC reports are tailored to the services relevant for a user entity. As such, service organizations (the ones providing the service) can have different SOC reports for different services and user entities. When designing a SOC report, an auditor must review and approve your specific list of controls.
The AICPA, in the “SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy” guide, defines some trust areas, services principles, and sections descriptions that help design controls for SOC 2.
In this article, we’ll follow an example report, with the typical controls that any company working with containers and Kubernetes would design.
SOC 2 compliance cost implications and consequences
Validating compliance is the number one blocker for faster application delivery. Regulators are increasingly enforcing financial penalties for failure to comply.
Studies have shown that:
- Annual cost of non-compliance to businesses runs an average of $14.8 million.
- The cost of compliance, on the other hand, was found to average $5.5 million.
Kubernetes is a dynamic environment in which it’s difficult to detect when assets fall out of SOC 2 compliance. Without a clear mapping of SOC 2 guidelines to this new environment, your teams won’t be able to prove they meet compliance requirements. As a result, meeting a SOC 2 audit becomes an expensive fire drill, slowing down application delivery for your cloud teams. Kubernetes compliance requires a new approach.
Your teams need to have a clear mapping of controls to their containerized workloads and the ability to continuously track compliance over time. This will let them be confident in their ability to manage security risk and pass security audits. Ultimately, you need to ensure that compliance is not blocking cloud adoption, so your business can ship cloud applications faster.
SOC 2 compliance for containers and Kubernetes
Luckily for you, not many of the typical SOC 2 controls are related to containers and Kubernetes security. The two major control families that have influence are Logical and Physical Access, and Systems Operations.
| SOC 2 family | Number of controls | Relevant to containers and Kubernetes |
| CC1 | 26 | 0 |
| CC2 | 26 | 0 |
| CC3 | 34 | 0 |
| CC4 | 11 | 0 |
| CC5 | 16 | 0 |
| CC6 | 35 | 60% * |
| CC7 | 33 | 42% * |
| CC8 | 15 | 0 |
| CC9 | 14 | 0 |
| A1 | 15 | 0 |
| C1 | 4 | 0 |
Table: Example SOC 2 report, containing families, number of controls,
and percentage of controls relevant to cloud, container, and Kubernetes security.
* Note: You can cover all these controls with Sysdig Secure.
Logical and physical access control family
Control group CC6.1
Control summary: Logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
For containers and Kubernetes: Implement detections for processes or users trying to break beyond the security constraints of their assigned user and service accounts. Do it at container image or runtime level.
Control group CC6.2
Control summary: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.
For containers and Kubernetes: Detect administrative actions using wrong credentials or unauthenticated, or the when new administrative roles are assigned to users.
Control group CC6.3
Control summary: Authorizes, modifies, or removes access to data and software functions based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties.
For containers and Kubernetes: Detect actions that try to undermine role-based control mechanisms.
Control group CC6.6
Control summary: Logical access security measures to protect against threats from sources outside its system boundaries.
For containers and Kubernetes: Detect opening unsanctioned network connections and traffic.
Control group CC6.7
Control summary: Restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal.
For containers and Kubernetes: Detect secret exfiltration, tampering with logs or command history, or execution of unsanctioned data transmission binaries at runtime. Prevent secrets from being present in Dockerfile container images.
Control group CC6.8
Control summary: Prevent or detect and act upon the introduction of unauthorized or malicious software.
For containers and Kubernetes: Detect malicious software and stop it from being deployed. Use image scanning or runtime detection, prevent deployment of unscanned images, or detect creation of unsanctioned binaries on runtime.
System operations control family
Control group CC7.1
Control summary: Detection and monitoring procedures to identify changes to configurations that are susceptible to or introduce new vulnerabilities.
For containers and Kubernetes: Benchmark reports for misconfigurations and recommended secure practices on containers and Kubernetes configurations. Implement runtime detection of unexpected changes to software components and configuration files.
Control group CC7.2
Control summary: Monitor system components and their operation for anomalies that are indicative of malicious acts, natural disasters, and errors to determine whether they represent security events.
For containers and Kubernetes: Having a centralized security real time event feed that is a single source of truth for the state of all containers and clusters, with meta information about severity, scope, and commands executed on runtime.
Control group CC7.3
Control summary: Evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes action to prevent or address such failures.
For containers and Kubernetes: Have a centralized security dashboard that is a single source of truth with information with a global view of all security measures; these are broken down by severity, with real time data and recent history variation. Set up notification channels for high severity security events.
Sysdig Secure helps you validate SOC 2 compliance
Sysdig Secure helps you validate SOC2 compliance, covering all controls relevant to containers and Kubernetes security to ensure that compliance is not a blocker for cloud adoption. Here are a few examples of how we address SOC2 controls.
Example 1: Kubernetes network topology maps – SOC 2 CC6.6
“The entity implements logical access security measures to protect against threats from sources outside its system boundaries.”
Sysdig will dynamically generate topology maps of all hosts, containers, and processes on your infrastructure, and map any network connection they make inside and outside your network. These topology maps can also be customized to show the logical services and how they’re connected.
Example 2: Asset inventory management – SOC 2 CC7.3
“Evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.”
Sysdig comes with an explore feature that will give you a view of all hosts, containers, or any process grouped by metadata running on their system. They can use this table to slice and dice all system components however they choose.
Example 3: Security dashboard with recent history – SOC 2 CC7.3:
“The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.”
Sysdig Secure dashboard shows a global picture of the current state of security on all workloads, with detailed information about severity and recent history to highlight when, and if, a spike in condition change has occurred.
Example 4: Kubernetes audit trail – SOC 2 CC7.2:
“The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.”
Sysdig provides a continuous audit of all container infrastructure events to facilitate incident response and NIST 800-53 compliance. Use this as proof of compliance for your third-party auditors, even after the containers are gone.
Runtime analysis and Falco rules
Sysdig runtime detection engine uses Falco rules, and can detect suspicious behavior by analyzing events from the host kernel, the Kubernetes audit log, AWS CloudTrail, and more.
Sysdig Secure provides a set of out-of-the-box Falco rules tagged against seven SOC 2 control groups.
| SOC2 Controls | Tagged Falco rules | Examples of provided Falco rules |
| SOC2 CC6.1 | 28 | Disallowed SSH Connection
Terminal shell in container Launch Privileged Container |
| SOC2 CC6.2 | 3 | System ClusterRole Modified/Deleted
K8s ServiceAccount Created |
| SOC2 CC6.3 | 10 | ClusterRole With Wildcard Created
Create Symlink Over Sensitive Files |
| SOC2 CC6.6 | 6 | Network Connection outside Local Subnet
Create HostNetwork Pod |
| SOC2 CC6.7 | 1 | Launch Remote File Copy Tools in Container
Search Private Keys or Passwords |
| SOC2 CC6.8 | 21 | Detect outbound connections to common miner pool ports
Detect crypto miners using the Stratum protocol |
| SOC2 CC7.1 | 13 | Write below etc
K8s Secret Created Full K8s Administrative Access |
Conclusions
SOC 2 guidelines were created to heighten the security of the information systems used within the financial sectors. The controls apply to any component of an information system that stores, processes, or transmits financial records.
Use container security tools that have already mapped the relevant controls to containers and Kubernetes, and provide out-of-the-box checks, dashboards, and reports that save you time.
To dig deeper into how Sysdig Secure can map and address many more SOC2 controls, check out the following resources: