An Essential Guide to Cloud Native Security: Part 2

Part 2 of 3: Cloud Native Security for the Enterprise

In our previous post, we discussed how a cloud native environment differs from a traditional IT architecture. To summarize: cloud native is microservice-centric, portable and automatically managed. This raises a new set of cloud native security challenges, ones which we’ll explore here.

What Are the Security Considerations for Cloud Native?

While enterprises begin experimenting with the benefits of cloud native applications, the practical side of managing and securing such application environments is less understood.

Are the implications of security truly different in a cloud native environment than a more traditional one? How does that impact your security strategies and controls? That’s the topic of this blog, part 2 of the three-part series, “An Essential Guide to Cloud Native Security”.

Building on the discussion in part 1 of the blog series – “What is Cloud Native”, some of the top security considerations for cloud native environments are:

  1. Continuous delivery requires continuous security: As microservices and containers replace monolithic and traditional  multi-tiered applications in cloud-native environments, software delivery and deployments are becoming continuous. Organizations like Amazon and Target are doing hundreds of deployments per  day. In these types of environments, security checks must be lightweight, continuous, and embedded into the deployment tool chains, or they risk being bypassed.
  2. Protecting server workloads is imperative: Traditional enterprise security is about securing the endpoints, segmenting the network, and protecting the perimeter. In a cloud-native environment, you may not be able to rely on fixed routes, gateways, network perimeters, or even the presence of an agent — the forefront of threat is now at your datacenter. Your server workloads are more exposed to the surface of attack than before. Shifting focus to securing the data center and server workloads is therefore imperative.
  3. Run-time detection at speed and scale: In a microservices model, end-to-end visibility, monitoring and detection become more complex and difficult to execute, especially when deployment and upgrades are continuous. Attack detection needs to work dynamically (e.g., less reliance on static signatures), scale in real-time, and do so without jeopardizing the performance and stability of the production environment.  
  4. Hybrid stack protection: Some microservices applications run in containers on a virtual machine, while others are on bare metal Linux. But, today’s security functions protecting the host, the VM layer, the container, and the applications are often separate and bereft of integration. This approach introduces complexity and unnecessary barriers to executing real-time security response and actions. For instance, would you deploy a mission-critical container to a VM that needs patching? But how would you know that VM needs patching if you don’t also have the VM-level visibility? There is a distinct need to integrate visibility, monitoring, and protection across this hybrid stack including the Linux host, VM, containers, and finally the application and its services.  

What Does the Ideal Cloud Native Security Platform Look Like?

Before enterprises design a security strategy to enable cloud native transformations, they need to consider these additional requirements:

  • A high degree of security automation: Traditional alert-based security operations simply cannot keep up with the near-limitless scale, and the far more dynamic nature, of cloud native systems. As such, manual workflows are simply not an option.  Automated detection and response at scale is a must-have requirement for cloud native security.
  • Design with “Chaos” in mind:  In a microservice architecture, any function may involve many software components stitched together at runtime. From a security standpoint, this means detection logic and controls cannot rely on a priori understanding of the operational state and security health. Rather, cloud native security must embrace chaos engineering principles –  experiment proactively, test often, and remediate fast.
  • Detect fast, contain locally, and recover rapidly: Cloud native applications are ultimately distributed computing applications. In such an environment, it is often not possible to execute global security decisions in a timely manner. Thus, you would do well to prioritize actions that allow you to detect fast, recover rapidly, and contain impact locally before system-wide, malicious behaviors manifest. Even if your security decision is not 100% precise (they rarely are), acting locally and recovering fast will give you a more resilient system overall.

Finally, what features should your cloud native security solution have? To make it concise, I am focusing on runtime features in this post. The top feature sets, in my opinion, are as follows:

  • Visibility and decision support across the hybrid stack: In the cloud native datacenter, you need visibility across the host, VM, containers, applications, and API services, even when the applications are distributed, services dynamic, and containers short-lived. Information gathered on these different layers should go into an engine which enables a real-time decision making process.
  • Rapid detection and response functions that minimize the “blast radius”: Your security solution must ensure that if there was a security incident, the fallout is minimized and contained. This logic leads to rapid decision making and smart controls that stop the malicious behavior before it affects irrevocable damage. In a cloud native world, it is entirely possible that a smart detection system can spot the onset of an attack and affect local controls.
  • Continuous monitoring and support for investigation at scale: Security investigation for cloud native workloads can be complex because of  all the distributed components and API services, so monitoring and security investigation must minimize the impact to performance and demand for storage. This necessitates a monitoring/investigation architecture that is distributed, lacks system bottlenecks, and can scale with the workloads.
  • Integration with orchestration or automation tools: In a cloud native environment,  you may have Kubernetes, Openshift, Amazon ECS, or Google GKE orchestrating your container workloads. Alternatively, you may use Chef, Puppet, or Ansible to automate deployments. Seamless integration with these components means the security tool can be deployed automatically alongside of the workload being protected — a must-have for the cloud native environment.

As containers and event-driven computing replace physical servers and first-generation virtual machines, security must find the right insertion point in this new setting to gain visibility and mitigate risks, while enabling innovations and adjusting to the complexities of continuous delivery in a cloud native environment.

In a cloud native environment, enterprises need to detect fast, recover rapidly, and contain the impact. In the next installment of this blog series, I will explore security detection in a cloud native environment more deeply – what does it take to detect security events at scale and amid dynamically changing workloads?

Dr. Chenxi Wang is vice Chair, OWASP vice chair as well as founder and general partner, Rain Capital. Dr. Wang is also on Capsule8’s Advisory Board.