A conversation with application security and public cloud veterans John Steven and J Ram.

Cloud computing has become the engine powering a new remote workforce, creating immersive customer experiences, and accelerating time to market. It’s giving businesses a more resilient foundation on which to run. It’s also happening fast, with Infrastructure as a Service (IaaS) reaching $80 billion and 17.1% compounded annual growth by 2022, according to analyst firm Gartner.

When major changes come that quickly, increased risk is inevitable. But it doesn’t have to be unmanageable if you have the necessary tools.

Rapid cloud growth and the use of infrastructure as code (IaC) have certainly created a world of new security risks that neither developers nor security teams fully understand. And until recently, lacked the tools to even see, much less resolve. Fortunately, the tools for comprehensive automated scanning of infrastructure-as-code security are finally available. This is a radical advance for security and risk teams struggling to quantify their cloud risk and close the widening gap between that risk and their ability to effectively govern it.

This blog transcribes a conversation on how that gap can be closed, with perspectives from J Ram, an expert in cloud, and John Steven, well-known authority in application security. They discuss steps that cloud security and compliance owners can immediately take to minimize their exposure.

Tony: This widening gap between software delivery and security governance, what’s driving it?

John: At its core, the gap is caused by the now dominant time-to-market imperative. Organizations are aggressively enabling “self-service” in every aspect of delivery: IT through Cloud Service Providers (CSPs), Software through Open Source Software (OSS), and now most importantly, delivery and deployment through Infrastructure-as-Code (IaC). Through IaC, engineers compose and configure their applications from a multitude of available OSS, containers, and cloud services. With that range of capabilities, IaC dramatically increases an engineer’s ability to construct and deploy applications on their own, but also gives them a disproportionate amount of influence on the security posture of its cloud resources.

J Ram: That’s right. While IaC is making cloud deployments more consistent and reliable, several recent industry studies point to the fact that it’s also having an unintended negative affect on security and compliance. Reported breaches continue to escalate, and the range of root causes continues to vary. Causes can be anything from over-privileged roles and disabled MFA, to misconfiguration of data stores and stolen credentials.

The variety of breach vectors are not at all surprising, considering that IaC defines provisioning, network, dependencies, identity and access, services, and more.

But there is good news! Many common flaws, including hard-coded credentials, excessive rights and permissions, unencrypted traffic or storage, unrestricted network access, and many other problems can all be identified by comprehensively scanning IaC.

Tony: John, are CISO’s concerned about this?

John: Some savvy ones are. But I believe this is a legitimate “awareness gap” in the security space at the moment. Organizations often have robust source code review capabilities but don’t’ realize that over 10% of their code base is likely IaC. There are twin gaps in most security initiatives. First, subject matter expertise about IaC toolchains and what “security blueprints” should apply to them. And second, possession of an automated scanning capability that allows them to check engineers’ code against their requirements and best practices.

Most organizations lack visibility into IaC security. Infrastructure code is not inventoried, nor is it scanned for misconfiguration, security defects, policy violations, or adherence to best practices. Where CTO offices have defined security blueprints, their organizations do not have a means of ensuring they are followed. As a result, organizations face a serious visibility and governance gap: they’re operating their business without knowing what they’re responsible for, what their cloud exposure and resulting risks are, or where existing organizational controls may be applied to mitigate risks.

Tony: Can you explain why it is so difficult for organizations to manage these risks?

J Ram: My perspective is that it’s both a cultural divide and a tooling problem. Cloud teams use automation to go fast, while security is relegated to manual reviews. This creates enormous friction and often pushes security checks to after deployment.

In addition, while security teams know what can go wrong from a security perspective, and cloud teams have a good grasp on IaC toolchains and CSP services, neither team can translate between each other’s native languages.

Finally, there were no comprehensive tools available for scanning IaC, or the configurations of the many CSP services in order to validate proper usage of technical security controls.

John: Agreed. CISOs and their reports consistently ask me two questions:

  1. What can I use to continually discover cloud-based assets I need to protect and their associated IaC; and
  2. Are there tools I can use to scan the configuration of those assets, or the orchestration used to deploy and operate them?

This is top of mind for most security executives. Those instances where it’s not a high priority can be attributed to a lack awareness of or confidence in a viable solution that wouldn’t require them to hire an army of cloud-native experts that they can neither find nor afford.

Tony: What should organizations be doing today?

John: With the current amount of IaC in organizations’ code bases, and the emphasis on more automation via IaC, it’s no longer acceptable, in my opinion, to not apply security controls here. Organizations must:

  1. Scan CSP configuration and IaC to continually update their view of cloud-based assets for which they’re responsible; and
  2. Apply at least a baseline set of security checks across the security domains Ram mentioned, such as data protection, IAM, networking/trust, and configuration hygiene.

J Ram: This is exactly where Concourse Labs can help. We provide a comprehensive set of integrated IaC scanning capabilities that enable organizations to gain a complete and granular view of their IaC risks. We start by shifting cloud security left, helping them prevent IaC vulnerabilities from entering the cloud pipeline. But since cloud services are highly dynamic, and drift happens, we also ensure “full stack” compliance by continually assessing cloud configurations and modeling IaC behavior at runtime.

This dramatically reduces IaC risk by giving security and risk teams the visibility and control they need, while freeing developers to innovate at the speed and scale of the public cloud.

Tony: John, Ram, this has been very insightful. Thank you for sharing your thoughts today.

Concerned about IaC vulnerabilities? Learn more about how Concourse Labs can help you mitigate IaC risk by downloading our latest solutions brief: Eliminate Infrastructure as Code Vulnerabilities at the Source.

####

About John

John is the Principal at security consulting firm Aedify, where he uses his deep expertise to regularly advise security executives and help foster industry-wide initiatives. A co-author of the BSIMM study and co-editor of the Building Security In department of IEEE Security & Privacy magazine, John is regularly invited to keynote and speak at industry events.

About J Ram

J Ram is co-founder of Concourse Labs and an accomplished technology leader with deep expertise in distributed computing and infrastructure. He has pioneered multiple technology strategies in large-scale enterprises, including Goldman Sachs, where he held positions as CTO of Global Services and Global Head of Cloud Platforms.