Fugue CEO Josh Stella Explains Why You Need To Think Like a Hacker To Beat a Hacker
In a brief video explainer and commentary, Josh Stella, co-founder and CEO of Fugue, the cloud security and compliance SaaS company, talks to business and security leaders about what hackers are searching for when they target cloud computing infrastructures and how to thwart them.
The ancient Chinese general Sun Tzu famously wrote: “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” That advice is just as relevant today as companies face a constant, never-ending war against hackers attacking their cloud computing infrastructures. Ninety percent of hacking is discovery, and 90% of defending is knowledge. Before you implement any security products or adopt new processes, you must first understand your cloud environment, and the unique threats against it.
A New Threat Landscape
The cloud infrastructure is very different from the data center. Developers and engineers build their own cloud infrastructure when they need to and have the ability to make (and change) their own infrastructure decisions, including security-critical configurations. This is significant because each change creates the risk of a misconfiguration left open to attack. And make no mistake about it — the bad guys will find it.
Read More: Ermetic Appoints Eduard Meelhuysen VP Sales For EMEA
What Is a Cloud Misconfiguration?
A misconfiguration is anything that proves ineffective at stopping a hacker. These vary from individual misconfigurations like leaving a dangerous port open or not patching a server to significant architectural problems that are easier for security teams to overlook. I guarantee that your organization has both kinds of misconfigurations in your cloud environments.
The primary driver of cloud computing is application programming interfaces (APIs) — the software “middlemen” that allow different applications to interact with each other. This eliminates a fixed IT architecture requirement in a centralized data center. It also means the traditional security model for securing data centers you may be familiar with — erecting an outward-facing barrier around the network perimeter to block incoming attacks — is not applicable in the cloud.
The control plane is the API surface that configures and operates the cloud. For example, you can use the control plane to build a container, modify a network route, and gain access to data in databases or snapshots of databases (which are more prevalent among hackers than breaking into live production databases). Put simply, the API control plane is the collection of APIs used to configure and operate the cloud.
Hackers are focused on finding and exploiting misconfigurations to get to the control plane APIs. Therefore, cloud security is a function of design and architecture, not monitoring and intrusion detection. By the time you’ve detected something, the damage has already been done.
Unfortunately, the security industry remains a step behind the hackers because many vendors do not protect their customers against attacks that target the cloud control plane. Frankly, most of them are meeting checkboxes to make senior executives and security teams feel better — until they’re hacked. It’s a security theater, and it remains all too prevalent in our business.
The Alphabet Soup of Cloud Security Categories
As a result, executives and security professionals are constantly bombarded by various security solution product categories and acronyms like CWPP, CNAPP and CSPM. But the hackers aren’t thinking about subverting vendors’ and analysts’ naming categories. They are thinking about how to get into your environment to do damage; that is all that matters to them.
You need to cut through the noise, clutter and confusion to understand where you should focus your attention. Don’t think about security in terms of individual product categories; they’re meaningless.
Read More: SalesTechStar Interview With André Ferraz, Founder And CEO Of Incognia
Lesson Learned From Real Cloud Breaches
Consider the 2019 Capital One data breach, which remains one of the largest ever to hit a big financial institution. The attacker broke through a misconfigured firewall (facilitated by permissions Capital One set that were likely broader than intended) to access a server and ultimately steal more than 100 million consumer credit applications.
The hacker didn’t care about getting into the server, except that doing so enabled them to surf the identity and access management (IAM) “network” using API keys to find and steal the data. Identifying that attack vector was the key to thwarting the attack, not whether Capital One had checked off that they had installed their vendors’ security products.
Hackers don’t live within the constraints of an organization’s security tools. Effective cloud security solutions ignore those product categories and focus instead on preventing what hackers do by analyzing all configurations and scenarios as a whole — because that’s what the hackers are doing.
A typical hack on the cloud spans identity, configuration (not just configuration of resources, but policy configuration of identity), the accessibility of resources, and the particular mechanisms you may use for encryption. The gaps that we see in most vendors’ security approaches are grounded in a false sense of security because they think they have satisfied all the items on a checklist.
The result is that a company feels confident in saying, “We have encryption turned on at rest,” but it doesn’t bother to examine whether it has an exposed identity, which contains credentials both to the data source and the keys for encryption, that’s long-lived and resident on a device in their cloud infrastructure.
Rest assured, that’s what the hackers are looking for because they don’t care about the categorization or the list of things that as security practitioners we do to make ourselves feel better. Creating an effective cloud security system requires that you first understand these threats. The most effective approach is to use Policy as Code.
Policy as Code
When developers build applications in the cloud, they’re also building the infrastructure for the applications instead of buying a pile of infrastructure and adding apps into it. That is a coding process using Infrastructure as Code, and developers own that process. Therefore, the security team’s role becomes that of the domain expert who imparts knowledge to the developers to ensure they work in a secure environment. The way you can do that is with Policy as Code, which enables your team to express security and compliance rules in a programming language that an application can use to check the correctness of configurations.
Policy as Code is designed to check other code and running environments for unwanted conditions. It empowers all cloud stakeholders to operate securely without ambiguity or disagreement on the rules and how to apply them at both ends of the software development life cycle (SDLC).
Leverage Automation Technology
Policy as Code also enables you to automate the continuous search for misconfigurations and, in some cases, their remediation. This relieves your security and infrastructure teams of the responsibility of spending the bulk of their time every day doing so via time-consuming, error-prone manual processes. A holistic response requires you to implement Policy as Code at the development phase, in the runtime, and the continuous integration/continuous delivery (CI/CD) pipeline. As you gain maturity, these things can then be institutionalized and built into your processes so that it’s all automated.
Protecting your cloud infrastructure begins with understanding how attackers think and operate and, critically, just how different their methodologies are compared to hackers targeting systems in the on-premises data center. You’ll likely discover your security team has implemented a grab bag of point solutions, perhaps all acquired from one vendor with one product name, that is insufficient in solving the little pieces of what Policy as Code can solve, fundamentally and strategically.