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 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.