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.

##