FREDERICK, Md.--(BUSINESS WIRE)--In a brief video explainer and commentary, Josh Stella, chief architect at Snyk and founding CEO of Fugue, a cloud security and compliance SaaS company, talks to business and security leaders about why they need to think bigger about cloud risk.
Ask security professionals to name the biggest threat to their organizations’ cloud environments, and most won’t hesitate to give a one-word answer: misconfigurations. Technically, they’re not incorrect, yet they’re defining “misconfiguration” much too narrowly. They’re likely thinking of an Amazon S3 bucket that’s left exposed or a misconfigured security group rule. While identifying and remediating misconfigurations must be a priority, it’s important to understand that misconfigurations are but one means to the ultimate end for attackers: control plane compromise, which has played a central role in every major cloud breach to date.
Considering the steady cadence of news headlines tying cloud breaches to misconfigurations over the last several years, it’s understandable that finding and fixing misconfigurations has been the primary focus of security professionals and their solutions vendors.
But these stories almost always bury the lede. All of these attacks began with an initial penetration event — either a single resource misconfiguration, an application vulnerability, or application programming interface (API) keys in source code — which attackers identify using automation tooling.
That’s just the beginning of the story. Once a hacker gains a foothold in an environment, it’s the API keys that permit them to operate against the cloud provider’s API control plane that they’re really after. These API keys enable them to discover knowledge about the environment, move laterally, and find and extract data while evading detection by security tools.
The cloud control plane is the collection of APIs that a cloud service provider like Amazon, Google or Microsoft provides to your developers so they can configure and control the cloud environments they’re working in every day. When developers build applications in the cloud, they’re also building the infrastructure for the applications as opposed to buying a pile of infrastructure and shoving apps into it. The process of building cloud infrastructure is done with code, which means developers own that process. They’re the ones using the APIs to make or destroy servers and make or access storage.
A New Threat Landscape
That’s why the control plane is the primary attack surface for hackers in the cloud and also why cloud breaches don’t resemble the “low and slow” exfiltration events we looked for in the data center. Cloud data breaches don’t typically traverse traditional TCP/IP networks, where traffic can be monitored and across which attackers had to operate carefully.
Control plane compromise attacks are more like “smash and grab” events. It takes just a few commands to sync the sensitive continents of an Amazon S3 bucket to a bucket in the attacker’s AWS account. Or copy a database snapshot, which they can unencrypt because they’ve found the keys.
Consider the cloud breach Twitch suffered last year after a hacker gained access to a trove of sensitive data, including information on users and source code for yet-to-be-released applications. The attack crossed over source code, business secrets, and user data — even to parent Amazon. And the cause was not simply a single “misconfigured server” as portrayed in the media because, obviously, all of that disparate data didn’t live on a single server. Rather, the design of the system architecture was deeply flawed, and the attacker exploited these flaws.
The important thing to understand here is that once the hacker gets in, whether via misconfiguration or an application vulnerability, that’s not the end of the breach — it’s just the beginning. They use that initial entry point to conduct discovery exploration and to try to branch out into the rest of the cloud infrastructure. They’re not doing that through your IP network configurations, they’re using identities.
The lesson for all business leaders and security professionals is that they must shift their strategic focus from traditional security approaches like intrusion detection and network security to prevention and secure cloud architecture design. Making this shift requires addressing five key fundamentals, beginning with knowing your environment and all of the ways that attackers might exploit it.
Resource misconfigurations will always slip past guardrails and into the runtime environment, that’s unavoidable. The challenge is finding and remediating them before attackers can find and exploit them. Knowing your environment is about more than understanding everything that’s running and making sure resources aren’t misconfigured (but that’s a requisite starting point). You need to think like a hacker in order to understand the ways your environment is vulnerable if a hacker gains initial penetration.
The vast majority of cloud exploits are due to imperfect design and architecture; cloud security is really a design problem, primarily, not a maintenance problem. It’s very different from data center security. Achieving the requisite knowledge of your environment in order to prevent security events from happening requires embracing the second cloud security fundamental: implementing secure designs.
Cloud Security Fundamental #2: Focus on Prevention and Secure Design
Cloud security is a design problem, not a maintenance problem — another way that cloud security is very different from data center security. Because you must know your environment in order to thwart attackers and prevent security events from occurring, you must implement secure designs that start not with the security team but with the people working in the cloud every day: developers.
Cloud Security Fundamental #3: Empower Developers
Because you’re focusing on prevention and secure design, who better to prevent misconfigurations and design flaws than the developers and engineers building these systems in the cloud? Give them the tooling that guides them in designing environments that are inherently secure against today’s control plane compromise attacks. The way you do that is via policy as code (PaC).
Cloud Security Fundamental #4: Adopt Policy as Code
When developers build applications in the cloud, they’re also building the infrastructure for the applications as opposed to buying a pile of infrastructure and shoving apps into it. The process of building cloud infrastructure is done with code, which means developers own that process, and this fundamentally changes the security team’s role.
In a completely software-defined world, security’s role is that of the domain expert who imparts knowledge to the people building stuff — the developers — to ensure they’re working in a secure environment. PaC enables your team to express security and compliance rules in a programming language that an application can use to check the correctness of configurations.
PaC is designed to check other code and running environments for unwanted conditions or things that should not be. It empowers all cloud stakeholders to operate securely without any ambiguity or disagreement on what the rules are and how they should be applied at both ends of the software development life cycle (SDLC).
At the same time, PaC automates the process of constantly searching for and remediating misconfigurations. There are no other approaches that in the long run are successful at this because the problem space keeps growing. The number of cloud services keeps growing, the number of deployments you have, and the amount of resources keeps growing. You must automate to relieve security professionals from having to spend their days manually monitoring for misconfigurations and enable developers to write code in a way that is flexible, that can be changed over time, and that can incorporate new knowledge.
To have a holistic cloud defense — one that actually works and isn’t merely security theater — you need to use policy as code at the development phase, in the continuous integration/continuous delivery (CI/CD) pipeline, and in the runtime. And as you gain maturity, these things can be institutionalized and built into your processes so that it’s all automated.
PaC provides developers with invaluable input and feedback on what mistakes they’re making from the security perspective they need to secure their cloud environments and, just as importantly, does so in an automated way. Equipping developers with tooling and automation ensures the creation of more secure designs and delivers the knowledge required to shift the focus to prevention.
Cloud Security Fundamental #5: Measure What Matters
Because your cloud environments are constantly changing, you must constantly measure the effectiveness and deficiencies of your cloud security strategy. Successful organizations quantify how effective they’re being at preventing hacks that could potentially happen and using that data to improve their processes. Because these are mutable resources, you want to prevent misconfigurations upfront and when new ones inevitably appear.
This measuring discipline will not just help you manage and reduce risk, it will help your organization realize the full potential of the cloud. Developers are under enormous pressure to build and ship applications quickly. Cloud security is too often the rate-limiting factor for how fast they can go in the cloud and, more broadly, how successful the organization’s digital transformation can be.
You don’t want developers waiting around for security approvals, and you don’t want your engineers to spend the bulk of their hours on manual cloud security tasks such as auditing environments, remediating vulnerabilities, or doing the rework that often results when teams wait until infrastructure is built to identify security issues. Measuring the impact your cloud security systems and policies have on these lines of business will help you identify and smash roadblocks that hurt productivity levels and create in-fighting.
While it’s good practice to log everything that’s happening in your cloud environment and analyze those logs for unwanted activity, the reality is that control plane compromise attacks happen so fast that the best you can count on is discovering that you were hacked shortly afterward. Most victims don’t discover they were breached until their data shows up on the dark web — or the hacker starts bragging about their exploits.
Don’t become yet another statistic that prompts a new wave of bad news headlines. Embracing the five fundamentals of cloud security will enable you to broaden your cloud security focus beyond the narrow view of the risk misconfigurations pose and focus on preventing control plane compromise.
About Josh Stella
Josh Stella is chief architect at Snyk and a technical authority on cloud security. Josh brings 25 years of IT and security expertise as founding chief executive officer at Fugue, principal solutions architect at Amazon Web Services, and advisor to the U.S. intelligence community. Josh’s personal mission is to help organizations understand how cloud configuration is the new attack surface and how companies need to move from a defensive to a preventive posture to secure their cloud infrastructure. He wrote the first book on “Immutable Infrastructure” (published by O’Reilly), holds numerous cloud security technology patents, and hosts an educational Cloud Security Masterclass series. Connect with Josh on LinkedIn and via Fugue at www.fugue.co.
About Fugue
Fugue (part of Snyk) is a cloud security and compliance SaaS company enabling regulated companies such as AT&T, Red Ventures, and SAP NS2 to ensure continuous cloud security and earn the confidence and trust of customers, business leaders, and regulators. Fugue empowers developer and security teams to automate cloud policy enforcement and move faster in the cloud than ever before. Since 2013, Fugue has pioneered the use of policy-based cloud security automation and earned the patent on policy as code for cloud infrastructure. For more information, connect with Fugue at www.fugue.co, GitHub, LinkedIn and Twitter.
All brand names and product names are trademarks or registered trademarks of their respective companies.
Tags: Fugue, Snyk, cloud security, SaaS, compliance, Josh Stella, policy as code, cybersecurity, cloud, cloud security automation, cloud control plane, network configuration, cloud configuration, cloud misconfiguration, data breach, hackers, application programming interface, API, cloud policy enforcement
