About the author: Josh Stella, Co-Founder and CEO of Fugue
Cloud infrastructure is quite different from data center infrastructure. When developers and engineers require it, they may design their own cloud infrastructure and make (and alter) their own infrastructure decisions, including security-critical configurations. This is critical since each modification increases the likelihood of a misconfiguration leaving the system vulnerable to attack. And make no mistake: the evil guys will discover it.
Listen to the full Expert Blog
What Is a Cloud Misconfiguration?
Anything that fails to stop a hacker is referred to as a misconfiguration. Individual misconfigurations, such as leaving a risky port open or failing to patch a server, to major architectural issues that are easier for security teams to miss, are among them. Both types of misconfigurations are almost certainly present in your cloud setups.
Application programming interfaces (APIs) are the software ‘middlemen’ that allow various programs to connect with one another, and they are the main driver of cloud computing. In a centralized data center, this reduces the need for a set IT architecture. It also implies that the standard data center security paradigm, which involves creating an outward-facing barrier around the network perimeter to thwart incoming attacks, isn’t relevant in the cloud.
The API interface that configures and runs the cloud is known as the control plane. You may use the control plane to construct a container, change a network path, and access data in databases or database snapshots, for example (which are more prevalent among hackers than breaking into live production databases). Simply said, the API control plane is a set of APIs that are used to configure and manage the cloud.
To get access to the control plane APIs, hackers are looking for and exploiting misconfigurations. As a result, cloud security relies on design and architecture rather than monitoring and intrusion detection. The harm has already been done by the time you notice something.
Unfortunately, the security sector is still lagging behind hackers, as many providers fail to defend their clients from assaults on the cloud control plane. To be honest, most of them are just checking boxes to make top executives and security teams happy – until they’re hacked. It’s a security show, and it’s still all too common in our industry.
The Alphabet Soup of Cloud Security Categories
As a result, executives and security experts are continuously assaulted with acronyms like CWPP, CNAPP, and CSPM for numerous security solution product categories. The hackers, on the other hand, aren’t considering undermining the naming categories used by suppliers and researchers. They are just concerned with gaining access to your surroundings in order to cause harm; this is all that matters to them.
To understand where you should focus your attention, you must cut through the noise, clutter, and confusion. Don’t think about security in terms of product categories; they’re irrelevant.
Lesson Learned from Real Cloud Breaches
Consider the 2019 Capital One data breach, which is still one of the biggest to affect a major financial organization. The attacker gained access to a server through a misconfigured firewall (aided by permissions provided by Capital One that were likely broader than intended) and stole more than 100 million consumer credit applications.
The hackers didn’t care about getting into the server as long as it allowed them to use API keys to search the identity and access management (IAM) ‘network’ for data to steal. The key to preventing the attack was identifying the attack vector, not whether Capital One had checked off that their suppliers’ security systems had been deployed.
Hackers aren’t bound by the limitations of a company’s security systems. Effective cloud security solutions disregard those product categories and instead focus on preventing what hackers do by assessing all configurations and situations in their entirety – since that’s exactly what hackers do.
A typical cloud hack involves identification, configuration (not just resource configuration, but policy configuration of identity), resource accessibility, and the encryption techniques you may utilize. The flaws we observe in most vendors’ security techniques are based on a false feeling of security, as they believe they’ve checked off all the boxes on a checklist.
As a consequence, a company can confidently state, “We have encryption switched on at rest,” but it won’t bother to look into whether it has an exposed identity, which comprises both data source credentials and encryption keys, and is long-lived and stored on a device in their cloud architecture.
That’s exactly what the hackers are searching for, since they don’t care about the classification or the list of things we do to make ourselves feel better as security professionals. To build a successful cloud security solution, you must first comprehend the dangers. Using ‘Policy as Code’ is the most efficient method.
Policy as Code
When developers create cloud applications, they’re also creating the infrastructure for the apps, rather than purchasing infrastructure and then adding apps to it. That is an Infrastructure as Code coding method, and developers are in charge of it. As a result, the security team’s duty shifts to that of a domain expert, imparting information to developers so that they may operate in a safe environment. You may do so using Policy as Code, which allows your team to define security and compliance requirements in a programming language that an application can use to verify configurations are proper.
Policy as Code is a tool for detecting undesired circumstances in other code and operating environments. At both ends of the software development life cycle, it enables all cloud stakeholders to work safely without ambiguity or dispute on the rules and how to apply them (SDLC).
Leverage Automation Technology
You may also use Policy as Code to automate the continuous search for misconfigurations and, in some situations, the repair of those misconfigurations. This frees up your security and infrastructure teams from having to spend the majority of their days doing so manually, which is time-consuming and error-prone. Implementing Policy as Code in the development phase, runtime, and the continuous integration/continuous delivery (CI/CD) pipeline is required for a holistic response. These items may then be institutionalized and implemented into your procedures as you achieve maturity, making everything automatic.
Understanding how attackers think and work, as well as how different their tactics are from those used by hackers targeting on-premises data centers, is the first step in securing your cloud infrastructure. You’ll probably find that your security team has adopted a patchwork of point solutions, maybe all from the same vendor with the same product name, that are insufficient to handle the little portions of what Policy as Code can fundamentally and strategically solve.