Virtualization Technology News and Information
Article
RSS
Organizational Shift is an Imperative for Cloud Native Security

By Rani Osnat, VP Strategy, Aqua Security

In observing hundreds of organizations in various stages of their cloud native journey, I've seen how organizations struggle with making the necessary organizational changes in their security team structure and processes. There's often an underestimation of just how profound the change needs to be. Since many start by thinking of cloud migration as simply a move from data centers to cloud provider-managed infrastructure, they often perceive security as something that merely needs to address that change - a change in the perimeter, or in how access is controlled, or anomaly detection mechanisms such as EDR that simply need to be "cloud compatible".

While the move to the cloud certainly requires adapting some existing and familiar security concepts to what is simply a different kind of infrastructure or a different locus, the true adoption of cloud native technologies and methods requires a much more fundamental change, and those who ignore this are putting their organizations at risk, or simply postponing the inevitable. Here's why.

First, cloud native applications that are based on microservices architectures (or even "mini-services" architectures) are getting updated and deployed with a velocity that is orders of magnitude higher than traditional apps. We've seen companies move from quarterly updates to weekly deployments, or even several daily updates. This change requires a lot of automation in the CI/CD pipeline that can enforce policy and flag, or stop, code and infrastructure changes that violate it. Not only that, but an application that previously might have been limited to one clearly defined and easy to locate server (because it was always on the same server), might now run as hundreds of containers on a cluster. This creates an almost impossible to defend attack surface, unless you know exactly what's in it and how it is supposed to behave.

Second, we're seeing a significant adaptation of attack tactics to this new reality. Research that now spans more than two years, performed by Aqua's cyber research team, Nautilus, is showing that highly organized groups are deliberately targeting Kubernetes and container infrastructure, with a constantly improving level of sophistication and scale. It now takes less than one hour for an unprotected cloud-based instance running containers to be attacked. The attacks utilize a variety of methods and evasion techniques to achieve their objectives, be it cryptocurrency mining, data theft, or credential theft. In order to counter these attacks, organizations have to adopt zero-trust approaches to limit the attackers' ability to cause damage. This means defining, during the application build phase, what the application is allowed to do, then using runtime security controls to enforce that.

Finally, I've seen a lot of confusion around the idea of the "shared responsibility model" in the cloud. Virtually all cloud service providers have adopted this, and all have pages on their websites and documents explaining it. Grosso modo, the shared responsibility model stipulates that the cloud providers will take care of securing their infrastructure ("security of the cloud"), while the customers will need to secure what they're running in the cloud ("security in the cloud"). However, this is very simplistic and not representative of the reality. Due to the many options in configuring cloud services, there's no simply answer, for example, to "who's responsible for securing this Kubernetes application?" - it depends on what kind of Kubernetes it is, what OS is running on the nodes, how access is configured, how networking is configured, and so on. Gartner has predicted that 99% of cloud security incidents will be the customers' fault through 2025. Well, if the responsibility is "shared", but one party will bear 99% of the responsibility, that's a very specific definition of sharing. The reality is that organizations don't need to do less in terms of security when moving to the cloud - the scope hasn't changed much, but the nature of what they need to address has. This why capabilities such as CSPM (cloud security posture management) and securing infrastructure-as-code are essential. Any change in a Terraform template might break something in your security posture, and this will not necessarily be as obvious as leaving an S3 bucket exposed or ports open.

So how does one handle all those significant shifts? The combination of much faster delivery methods, the ability to change infrastructure "as code", the more ephemeral workloads and shear number of microservices components to track and understand - it all requires a much more holistic approach to security that looks at the entire stack and the entire application lifecycle, and tries to identify, remediate, and mitigate issues as they happen, and with close cooperation between engineering teams, operations or DevOps teams, and security teams. Imagine a suspected security incident in a running Kubernetes application - how long would it take security teams to identify there's an issue in the first place? How long will it then take them to understand its root cause, or how to fix it? Would they know how long it's been there? Could they have prevented it from happening in the first place?

The mentality of security teams that only look at production environments with zero anticipation of what's coming down the pipeline is not a sustainable one. Because just as cloud native applications are developed and deployed faster, attacks in cloud native environments are also becoming faster. Without significantly reducing the attack surface, without having a-priori knowledge and context of what constitutes suspicious activity, and without large-scale automation of prevention, detection, and response capabilities, security teams are simply flying blind into a storm.

Organizations should overcome the resistance to change and adopt a holistic approach to security of cloud native applications and infrastructure, employing DevSecOps methods and processes. Not doing so is shortsighted and risky. The tools and methods for implementing DevSecOps are varied and available, and have significantly accelerated time-to-market and business agility for those who adopt them, while also improving (not just maintaining) their security posture and compliance.

##

To hear more about cloud native topics, join the Cloud Native Computing Foundation and cloud native community at KubeCon+CloudNativeCon North America 2021 - October 11-15, 2021    

ABOUT THE AUTHOR

Rani Osnat, VP Strategy, Aqua Security

Rani Osnat 

Rani Osnat has more than 20 years of enterprise software industry experience, in project management, product management and marketing, including a decade as VP of marketing for innovative tech startups in the IT security and cloud arenas. Previously Rani was a management consultant in the London office of Booz & Co. He holds an MBA from INSEAD in Fontainebleau, France. Rani is an avid wine geek, and a slightly less avid painter. 

Published Friday, September 17, 2021 7:32 AM by David Marshall
Filed under: ,
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<September 2021>
SuMoTuWeThFrSa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789