Four Cloud Security Concerns (and How to Address Them)

The cloud can be overwhelming. Counter to the structured and disciplined rigor of old-school, waterfall, data-center-centric application development, there’s code being deployed in a nearly continuous fashion. Traditional servers are history. Penetration tests are so out of date by the time they’re done that CISOs and their teams are left wondering if they actually gained anything from the exercise.

I consistently talk to enterprises that are either beginning or accelerating their move from traditional on-premises infrastructure to the cloud. They anticipate benefits, including increased agility, reduced cost, flexibility, and ease-of-use. But along with this transition comes new security concerns and a bit of fear to top it off. They’ve heard the stories from their colleagues. Many of the security best practices and tools previously relied on are becoming trivialized, like traditional AV endpoint offerings and network scanning, while API-centric security is rapidly gaining traction. Today’s cloud security practices are a big shift from how we’ve been managing security for the previous 30 years.

However, most every organization recognizes the need to adapt and modernize their security policies to continue to achieve corporate goals while taking advantage of everything the cloud can offer. Security, as we know it, can be the ultimate accelerator or the biggest blocker in cloud adoption and technical innovation.

Many security and development professionals are struggling to find the right cloud security approach to fit their modern IT practices. They worry most about the lack of control and visibility that comes with public cloud. But they also don’t want to create the potential for their organization to start falling behind competitors because they’ve slowed or blocked the adoption of cloud or other closely related emerging technologies such as Docker and Kubernetes.

When it comes to cloud security today, there are many issues that organizations are trying to sort through. Here are a few I hear the most and how I suggest addressing them:

1) Viewing the cloud as another product

You can’t assess your cloud security today and assume your assessment holds true tomorrow. Honestly, it probably won’t hold true an hour from now. The cloud is living, breathing, and rapidly changing. Security within this constantly changing environment must be continuous, or it won’t be effective. Traditional security approaches were not created to fit the rapidly changing, elastic infrastructure of the cloud. As attacks become increasingly automated, you need to adopt new security tools and techniques to work effectively in this new ecosystem. Terraform and Ansible are both great options for automating your security stack. Here are a few options to consider.

2)  Realizing that traditional scanning just won’t do

Traditional data center security relies on being deployed within an application or operating system, or on traditional network-based IP scanning techniques. In the cloud, this approach doesn’t work. Users run application stacks on abstracted services and PaaS layers or leverage API-driven services that render conventional security approaches ineffective. Cloud environments are so fundamentally different from their static, on-premises counterparts that they require an entirely new way of administering security practices. This means adopting new cloud security technologies that provide extreme visibility by leveraging a combination of cloud provider APIs and integrations with other 3rd party tools. Learn about how to get visibility and context for your cloud deployments.

3) Differentiating real security issues from “noise”

Teams working in the cloud benefit from speed and acceleration, but it’s important to recognize how the approach to security must be vastly different. A major challenge is discerning real vulnerabilities from infrastructure “noise.” All this change and noise make a manual inspection of the infrastructure too slow to be effective. The API-centric cloud world requires a new way for security teams to protect their environments, but not all cloud and IT teams really understand these security nuances. Security automation is one way to overcome the knowledge and skills shortfall that exists in many development and IT shops.  Learn how to better automate and enable your SOC.

4) Lack of compliance with API-driven cloud security

The emergence of API-driven cloud services has changed the way security needs to be architected, implemented, and managed. Although the API is a completely new threat surface that we need to defend, it also provides the ability to automate detection and remediation. As compliance benchmarks, like the CIS AWS Foundations Benchmark, are released, we will have the means to assess our security posture against industry-defined best practices. These help to ensure we’re taking the right steps to keep our customers, employees, infrastructure, and intellectual property secure. Cloud migrations are happening quickly, and compliance with rapidly-evolving security requirements is an ever-increasing challenge that must be resolved through automation in order to claim success. Learn more about how to meet data and regulatory mandates.

Whether your organization was born in the cloud or is migrating to the public cloud, building out private cloud, or dealing with a complex hybrid cloud strategy, the cloud is happening—and it is an absolute necessity that we adapt our security practices. No longer is security left to the InfoSec team: we all play a part in creating a holistic, continuous, and rapidly adapting security program fit to support the cloud.

Fueling Your Move to DevSecOps

The rapid adoption of containers in the enterprise represents a unique opportunity to shift security left. As a security leader, are you taking advantage of this opportunity? In a previous post, we discussed the intrinsic link between containers and public cloud. In this post, I’ll explain why containers represent one of the most vital opportunities to bridge the divide between development and security teams. Is it possible that containers could move your organization one step closer to DevSecOps? Before we explore this, here’s a brief history lesson to help us appreciate how we arrived at this position.

Brief history

I like to think about computing as going through several evolutions. The first wave was client-server running on bare metal with a single OS and typically one app. The second wave came when VMware entered the server market in 2001. This ushered in the age of virtualized computing. The third wave brings us to the present with containers. Driving container adoption is the speed of DevOps and a desire to make applications portable. Still on the bleeding edge, and not currently widely adopted in the enterprise, is the fourth evolution: serverless or function as a service (FaaS). This represents a complete abstraction of compute whereby the consumer is hardware- and OS-agnostic. The two most recognizable implementations of FaaS are Google’s Cloud Functions and AWS’s Lambda. With the history lesson behind us, let’s dig into the Container Security Triad (see Figure 2) and how it can move security teams toward DevSecOps.

Build security

Getting security into the container build phase means you are actually shifting left instead of reactively at runtime. Think in terms of physical construction. The first thing one does before building a house is figure out what the desired end state looks like. It’s no different with container security. Build phase security should focus on removing vulnerabilities, malware, and insecure code. Since containers are made up of libraries, binaries, and application code, it’s critical that you establish an official container registry in your organization. Without question, one or more already exists. It’s the security team’s job to find the registries and quickly gain buy-in around getting access and setting security standards. The main goal of identifying and creating a standard container registry is to create trusted images. A process needs to be agreed upon and automatically enforced that no container be deployed from an untrusted registry. With over 2 million Dockerized applications, Docker Hub is probably the most recognizable container registry. This means it’s also a great place to begin a conversation with your developers.

Deploy security

In the deploy phase, the focus shifts from making sure the materials used in building the house are without defect to making sure your teams are putting things together correctly. You can have an image that is without vulnerabilities, but if it’s deployed to an insecurely configured Kubernetes pod, you haven’t sufficiently managed your container risk. Case in point: Unit 42 threat research found that 46% of organizations accept traffic to Kubernetes pods from any source. In the on-prem world, this is equivalent to deploying a server and then leaving it open “any any” to the internet. You wouldn’t do this on-prem, so why are almost half of organizations doing it in public cloud? Deploying to a secure configuration can be achieved by adopting a security standard for both your orchestration and container engine of choice. Don’t forget to put the necessary process and tools (i.e., guardrails) in place that will enable you to automate and monitor. The Center for Internet Security (CIS) has done an excellent job creating security benchmarks for both Docker and Kubernetes. They should be your starting point. If you get deploy security right, only the “good” should be making it into runtime.

Runtime security

The house is built, and it’s serving its functional purpose, but systems do tend toward entropy (see the Second Law of Thermodynamics). Runtime security is about identifying new vulnerabilities in running containers and knowing what normal looks like. It also involves investigating suspicious/anomalous activities that could indicate zero-day attacks. If your security team was involved from the beginning (build phase), getting runtime security right is much less complex. If you’re coming late to the game and are reactively focusing on runtime, its best to work backward. Yes, it’s important to make sure the end state is secure, but if your focus is narrowly on runtime, the same issues will likely repeat over and over. Interestingly enough, the IBM Systems Sciences Institute found that the cost to fix a bug during the maintenance phase (i.e., runtime) was 100 times more costly than if found during design.

“Security is a process, not a product.”

Bringing it home

The rapid adoption of containers in your enterprise represents a unique opportunity to shift security left. When security is designed into the development cycle from the beginning, both security and development will feel an increased sense of ownership. This will happen because instead of security being a bolt-on “conversation” at runtime, the collaboration will happen all along the way. Organizations can achieve this by focusing security efforts on the Container Security Triad of build, deploy, and run. Security teams that do this as part of a holistic cloud security strategy may just find containers are exactly what they needed to move one step closer to DevSecOps.