DIY SOC2 compliance for custom containers and Kubernetes running on Oracle Cloud Infrastructure
Sanjay Basu
Note: My original blog series was published in ORACLE CLOUD INFRASTRUCTURE blog site. I have republished it here with permission.
Official Disclaimer:
The views and opinions expressed in this blog are those of the author
and do not necessarily reflect the official policy or position of Oracle
Corporation.
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.
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.
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.
Comments
Post a Comment