DIY SOC2 compliance for custom containers and Kubernetes running on Oracle Cloud Infrastructure

December 2, 2020 | 4 minute read
Sanjay Basu
Sr. Director, AI/ML GPU Services
Text Size 100%:

This blog post provides a guide for any managed service provider (MSP) or independent software vendor (ISV) software-as-a-service (SaaS) provider using Oracle Cloud Infrastructure Services (OCI), looking to make their microservices-based containers and custom Kubernetes infrastructure SOC2 compliant. As a service organization, customers might require these MSP or ISV providers to be Service Organization Controls (SOC) compliant according to the end-companies’ industry regulations.

Understanding Service Organization Controls compliance

SOC reports have the following levels:

  • SOC1, covering internal control over financial reporting (CIFR)

  • SOC2, covering trust services criteria

  • SOC3, covering trust services criteria for general use reports

As specified by the SSAE no. 18, each SOC report fall under one of the following types:

  • Type 1 describes a service organization’s systems and whether the design of specified controls meets the relevant trust principles.

  • Type 2 addresses the operational effectiveness of the specified controls over a time, usually 9–12 months.

The reports generated as part of the SOC compliance provide evidence of how effective their controls are for securing customer data (SOC2 or SOC3). SOC1 covers the financial compliance report and is outside of the scope of this blog. The SOC reports are issued by the American Institute of Certified Public Accountants (AICPA). Among these reports, SOC2 type 2 compliance is the most important report that the regulators and consumers focus on for security.

The controls addressed in the SOC reports can overlap between the main categories of trust service principles. The trust service principles support the CIA triad of Information Security.

A chart showing the trust service principles of privacy, security, availability, processing integrity, and confidentiality.

This blog explores the SOC2 type 2 controls most pertinent to the custom containers and Kubernetes deployment by the MSP or ISV SaaS providers to support their end consumers.

A chart of the SOC2 family, the number of controls, and pertinent self-managed Kubernetes and custom containers.

Logical and physical access control family

Control group CC6.1

Control summary: Implement protected information assets across logical access security software, infrastructure, and architectures over to protect them from security events.

Kubernetes: Implement detection at container image or runtime level, for processes or users trying to break beyond the security constraints of their assigned user and service accounts.

Control group CC6.2

Control summary: Before issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.

Kubernetes: Administrative actions using wrong credentials are detected. Any new administrative roles that are assigned to users are recorded.

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, considers the concepts of least privilege and segregation of duties.

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.

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.

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.

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.

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.

Kubernetes: Have a centralized security real-time event feed that’s a single source of truth for the state of all containers and clusters, with meta information about severity, scope, and commands 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, acts to prevent or address such failures.

Kubernetes: Have a centralized security dashboard that is a single source of truth with information with a global view of all security measures; these measures are organized by severity, with real-time data and recent history variation. Set up notification channels for high severity security events.

Working together toward compliance

Now we know what security controls to configure for generating a SOC2 type 2 compliance for self-managed Containers and Kubernetes on Oracle Cloud Infrastructure. Let’s delve into the Oracle Partner solutions that can help us with meeting the SOC2 compliance.

NeuVector provides the following security and compliance services:

  • End-to-end vulnerability management: Scanning and admission control during build, test, and deployment

  • Run-time scanning: Scans containers, hosts, and orchestrations platforms during run-time

  • Automated risk scores and compliance reports

Twistlock, now part of Palo Alto Prisma, provides the following security and compliance services:

  • Vulnerability management

  • Compliance

  • Run-time defense

  • Network visibility

  • Incident response and forensics

  • CI/CD security

Aqua provides the following security and compliance services:

  • Vulnerability scanning

  • Dynamic threat analysis

  • Automated developer security operations

  • CI/CD integration security

Sysdig provides the following security and compliance services:

  • Secure builds: image scanning

  • Run-time protection: Run-time security of containers and Kubernetes

  • Rapid response: Incident response and forensics

For more information regarding accessing metrics, refer to the OKE Monitoring documentation.

Sanjay Basu

Sr. Director, AI/ML GPU Services

Sanjay focuses on OCI's NVIDIA GPU offerings for large scale model training and inference. He also works with Oracle AI, Blockchain, Microservices along with Cloud Security and Compliance.

Previous Post

First Principles: Shrink wrap the cloud scale

Pradeep Vincent | 10 min read

Next Post

MySQL Database Service Analytics Engine and Oracle Cloud Infrastructure: Run applications and analytics with better performance, scale, and efficiency

Leo Leung | 6 min read