Five things CISOs can do to make containers secure and compliant

Chances are, if you’re not already moving applications to containers and Kubernetes, you’re considering it. However, it’s likely that security and compliance implications are something you haven’t fully thought through.

Addressing container security risks later in the development life cycle negatively impacts the pace of cloud adoption while simultaneously raising security and compliance risks.

The use of containers and Kubernetes changes your security calculus. Legacy tools and processes aren’t adequate, as they do not provide visibility into dynamic container environments. Fifty-four percent of containers live for five minutes or less, which makes investigating anomalous behavior and breaches extremely challenging.

Container environments can be more secure, but only if security is explicitly designed in. In the absence of best practices, mistakes create openings for attackers. Weight Watchers had a breach of a Kubernetes instance that revealed root credentials for an administrator and more than 100 access keys for the company’s domains, plus information on how to access dozens of S3 buckets holding company data. Tesla fell victim to cryptojacking — hackers stole compute cycles to mine cryptocurrency — after it failed to adequately secure a Kubernetes console.

Software vulnerabilities in the container and Kubernetes code are discovered at a steady rate.

One of the early vulnerabilities discovered was a critical Kubernetes security hole that enabled attackers to escalate privileges by using a special network request to access a back-end server through a Kubernetes API. Through this mechanism, attackers are able to control the Kubernetes cluster.

Since then, there have been others, including two high-severity Kubernetes vulnerabilities discovered by engineers at Netflix last summer, both of which would enable attackers to launch denial-of-service attacks. A few months later, a pair of high-severity bugs were discovered that, if exploited, enable attackers to bypass container authentication controls.While these and other container and Kubernetes vulnerabilities have been addressed, new ones will emerge. As attackers see organizations increase their use of containers and Kubernetes for critical applications, efforts to exploit these technologies will escalate.

To counter the risk, you’ll need to ensure your security tool set integrates specific security and compliance safeguards into DevOps processes. In addition to scanning for vulnerabilities, it’s important to also address runtime security and incident response. Here are five key priorities you can work toward in your organization:

1. Scan for vulnerabilities in the build process.

“Shifting left” involves building security checks into development so vulnerabilities are addressed before the container is deployed in production. These checks, which can be automated, help identify vulnerabilities faster and earlier and enable you to validate build configurations and image attributes. They can also scan third-party container libraries before applications are deployed to production. To put the importance of this critical step into perspective, my company recently reviewed a sample of more than 2 million containers scanned for our customers before going to production. We found that more than half of the images had known vulnerabilities with a severity of high or greater. Typically, companies will fix these issues before production release.

2. Secure against runtime threats and attacks.

Shifting left will help ensure the container is not deployed with vulnerabilities, but you also need to protect against emerging threats that can compromise your environment during runtime. This requires runtime detection of violations spanning a wide range of policies, such as unauthorized user activity, excessive privileges to containers, unauthorized network connections and so on. Since it’s difficult to create manual policies for comprehensively detecting runtime threats, leveraging community-sourced and machine learning policies will become critical. Another critical element is having automatic runtime prevention that leverages capabilities within Kubernetes, such as pod security policies, which have the ability to prevent new containers from starting if they have excessive permissions.

3. Continuously validate compliance.

CIS benchmarks provide a minimal set of hardening guidelines for containers. In addition, regulatory requirements are stringent and getting more so, and regulators are increasingly enforcing onerous financial penalties for failure to comply. However, meeting GDPR, PCI-DSS, HIPAA, et al. requirements can be complex in fast-changing container environments where containers change continually — according to our customer study linked above, only 6% of containers live longer than a week. Validating compliance requires mapping each regulation and its associated controls to specific policies and checks during the build phase of the software development life cycle and runtime checks to ensure continual compliance.

4. Embed security alongside operational monitoring with a single source of truth spanning operations and security.

In container environments, visibility is a major challenge. You cannot secure what you cannot see. Therefore, building a data repository that provides deep visibility to support both security and monitoring teams is a necessary foundation. Going further, building unified workflows for security, compliance, monitoring and troubleshooting facilitates collaboration and faster decision making across operations and security teams. For example, a memory utilization change or a spike in CPU usage is typically a monitoring metric but could be indicative of a denial-of-service attack on an EC2 instance. Having a single source of data and a single workflow for handling that data makes it possible to speed correlations and reach decisions quickly.

5. Ensure you have a way to audit activity and investigate security events.

With such a short life span, it’s imperative to establish a way to record detailed container activity that is retained after the container has disappeared. In the event of anomalous behavior, you want to know what processes were spawned. What connections were made? What files were modified? What HTTP requests were processed? And then you need to be able to correlate this system activity with user activity. What users accessed the container? What did they do? With access to this type of deep container activity, you can effectively triage what happened and quickly respond. If you don’t, you are blind to what is happening.

CISOs who rethink their security processes with these five things in mind will be better equipped to face container security threats, especially as attacks on Kubernetes and containers become more sophisticated.

Read more about security

Interested in container security and compliance? You might enjoy these other resources:

• Dig deeper with our comprehensive Kubernetes security guide.
• Learn why PCI compliance is so challenging for containers.
• And finally, discover how Sysdig Secure can help you, try it today!