Concourse Labs is pushing the narrative around the importance of
automating cloud security and compliance. Central to this is the concept of
security-as-code, which provides the framework to accomplish this.
And while they aren't the first, nor will they be the last, the
company's CEO, Scott Crenshaw, took some time out to chat with VMblog to share
why he thinks automating security and compliance at every stage of the cloud
application lifecycle is critical to changing the security paradigm and
ensuring safe and unrestricted usage of public cloud infrastructure.
VMblog: What important
cloud-related trends are driving the need for security as code?
Scott Crenshaw: The
recent Cloud Configuration Security Practices survey conducted by Cyber
Security Hub (CSH) found that 68% of organizations use infrastructure as code or similar software-defined tools to provision their cloud
infrastructure services. And while infrastructure as code enables companies to deploy cloud applications at scale, it can also
rapidly promulgate vulnerabilities if not implemented correctly.
Unfortunately, the survey also found that only
about 1 in 4 companies have adopted widespread use of infrastructure as code security tools, leaving the large majority of organizations highly
vulnerable to data breaches and disruption in the cloud. Automation replicates
non-compliant infrastructure as code at scale, and once a vulnerability is
introduced, it only takes minutes for bad actors to find and exploit
misconfigured cloud services and exfiltrate sensitive data or gain access to
critical systems and controls.
Time and time again cloud misconfigurations are
identified as the root cause behind cloud data breaches. Just a couple of
months ago a leading Turkish airline inadvertently exposed 23 million files
containing sensitive passenger, staff, and flight data, by way of an
unprotected S3 bucket.
The CSH report further unveiled that financial
services, healthcare, and communications organizations will increase their
number of applications deployed in the cloud by 395% within the next 12-months
to an average 145 applications. However, the data has also revealed that most
security teams can only effectively review three applications per week.
Clearly, a new approach is needed to protect companies from the risks of
dangerous mistakes within their infrastructure as code. This bad situation will
only get dramatically worse if organizations do not change the way they protect
against cloud misconfiguration and begin automating security and compliance
reviews everywhere that code exists.
VMblog: What are
some of the current challenges that CIOs, CISOs, and CROs need to contend with
when it comes to cloud security and compliance?
Crenshaw: Clouds
are relatively new to most security and governance teams and thus introduce
significant complexity and risk, which only exacerbates the well-publicized
shortage of cloud development and cloud security talent. This is compounded by
the fact that each of the three hyperscale cloud service providers (AWS, Azure
& GCP) must be configured and protected differently.
Unsurprisingly, despite pervasive automation of
cloud infrastructure, many companies still have security and compliance
processes that are manual in nature or are comprised of fragmented tools and
processes. However, this cannot scale to keep pace with the velocity and volume
at which cloud applications are being deployed, nor the rate at which new risks
are being exposed. In fact, 62% of survey respondents say they concurrently
manage hundreds or more tickets specific to cloud misconfiguration, with almost
one-third managing thousands to tens of thousands of tickets. This places a
huge burden on security teams; without a paradigm shift, they cannot possibly
keep up.
DevOps teams struggle to hire and retain enough
experienced cloud engineers to meet their business needs. Developers are driven
by fast time to market, not security nor compliance. Slowing them down with
onerous security reviews and evidence gathering slows the business and
increases the risk of losing talented developers. Only with a security-as-code
approach can developers deliver at the pace of cloud while delivering secure
and compliant code.
Finally, risk and compliance teams are
challenged by a lack of visibility of actual cloud usage and reliable evidence
of their cloud compliance. Most internal cloud audits are performed through
manual attestation, which simply doesn't work given the ephemeral nature of
cloud, where servers, data stores, and networks are created and destroyed in
milliseconds. It is at best a guess, one which is guaranteed to be inaccurate,
exposing the company to the risk of data leakage and regulatory sanction.
Instead, risk and compliance teams need an independent, reliable, and
always-accurate record of cloud compliance.
Security as code addresses all these concerns by
enabling security teams to quickly see and focus on the most critical cloud
risks, equipping cloud developers to deliver secure applications without
impacting their work nor delivery speed, and providing risk and compliance
teams with always up-to-date auditable reports and evidence of their cloud
compliance posture.
VMblog: Security
as code sounds like it can potentially be a game-changer in cloud security. How
is it different from what is already being done, and how can it inject a level
of automation that has often been found lacking?
Crenshaw: Security
as code is predicated on the notion that security should be viewed as an
integral part of the entire software development lifecycle (SDLC) and treated
like a first-class citizen. Core to this is the ability to automatically
enforce the same controls and guardrails in development and at runtime, using a
single unified policy architecture, thus providing consistency with how
security is applied and a comprehensive view of cloud risk.
However, shifting security left has faced
significant challenges: First, every company of scale has a variety of
development tools and standards; finding a way to secure all of them has been
hard. Second, the shift-left experience
has been invasive, disrupting developers' workflows and making for an
inefficient and disruptive experience.
Security as code solves these challenges by
defining enterprise standards as automatable policy, which can easily be
applied uniformly across every DevOps toolchain. This lets guardrails be
automatically injected to publish and enforce policy directly within diverse
IDE, SCM, CI/CD, and production environments. Guardrails are integrated via
simple API calls to the tools developers already use, showing developers both
the policies they are expected to enforce and whether their code is compliant
or not, simply, clearly, and instantly.
VMblog: On a practical
level, how does security as code work?
Crenshaw: Companies
typically choose a set of applications to start with, and get a baseline
assessment of their compliance with industry standards and best practices
within 24- hours. Reports highlight the most critical risks so that teams can
prioritize remediation to what matters most.
Many companies choose to build on this baseline
by adding their own security and compliance policies. Policies can be authored
without having to write code or having a wealth of cloud expertise. And because
security as code treats policy as a first-class citizen, all policies are
automatically versioned, audited, and evidenced throughout their entire
lifecycle.
With out-of-the-box API integrations, policy
guardrails can be automatically applied at every stage of the cloud application
lifecycle. As developers commit code, they instantly confirm it meets policy,
and where it fails, they immediately get the guidance required to remediate
violations themselves and bring applications into compliance. Preventing
mistakes from turning into breaches; without deploying agents, disrupting
developers, or being slowed by manual security processes.
As new resources are deployed to the cloud,
security as code automatically inventories them and continuously evaluates
their configuration against all policies, to rapidly detect risks in production
that stem from drift, attack, or negligence.
VMblog: Ok, so
why should organizations care about a security as code approach, and what makes
it the technology that will redefine cloud security?
Crenshaw: As the
data shows, companies are rapidly moving applications and data to the cloud.
But it is hard to find a CISO, CIO, or GRC leader who truly believes she knows
- much less is in control of - her exposure in the cloud. Yet the pressure to
migrate continues unabated, with little tolerance for slowing innovation to get
control.
Security as code solves this cloud dilemma.
Developers meet their time-to-market goals, while also knowing their code meets
enterprise security and compliance standards. Security teams gain comprehensive
visibility and control of vulnerabilities rapidly, and the ability to
automatically apply standards consistently and correctly within development and
at runtime. Risk leaders can eliminate human error and compliance ambiguity
from manual attestation, with an authoritative record based on validating
evidence. Thus enabling companies to move to the cloud with confidence.
##