Software Development
Cybersecurity / Data / Digital access / Guest posts / Internet

An optimistic outlook for 2022: Cloud security vulnerabilities are 100% preventable

Cloud security SaaS executive Josh Stella details the new security paradigm that cloud computing has created and debunks the long-standing myths that compel organizations to rely on outdated, ineffective security measures.

Cybersecurity. By frederickmaheux
This is a guest post by Josh Stella, cofounder and CEO of cloud security SaaS company Fugue, based in Frederick, Maryland.

Predicting that more enterprises will suffer a cloud data breach in 2022 is not exactly going out on a limb. Migrating IT systems and applications out of the data center to cloud computing platforms is a tenet of an effective digital transformation strategy. But in their rush to the cloud, too many organizations fail to identify the security risks that are unique to cloud computing, primarily misconfigurations.

In the past year, 36% of companies suffered a serious cloud security leak or breach due to cloud misconfiguration, according to Fugue’s State of Cloud Security 2021 Report. And Gartner expects that through 2023, at least 99% of cloud security failures will be the customer’s fault, mainly in the form of cloud resource misconfiguration.

However, there’s reason for optimism in the new year: These vulnerabilities are 100% preventable. Mounting an effective defense against hackers constantly on the hunt for cloud misconfigurations requires security professionals to go beyond the traditional tools and methodologies they have long relied on to secure data centers.

Cloud Security Myth No. 1: The cloud is a data center in the sky

First, it’s critical to understand just how different the cloud infrastructure is from the data center infrastructure. Developers and engineers can now build their own infrastructure as needed, instead of waiting for the data center team to do it for them. That means they can make their own infrastructure decisions — including security-critical configurations — and then change them constantly. And every time they do, they create the risk of a misconfiguration left open to attack.

Cloud computing is driven by application programming interfaces (APIs) — the software “middlemen” that allow different applications to interact with each other. This eliminates the requirement for constructing and maintaining a fixed IT architecture in a centralized data center. It also means that you cannot apply the data center security model of erecting an outward-facing barrier around the network perimeter to block incoming attacks.

Security in the cloud is a function of design and architecture, not just monitoring and intrusion detection. One hundred percent of the time, hackers are trying to get to the control plane APIs. The traditional data center risks of network penetration and the slow exfiltration of data have become irrelevant to cloud security because, by the time you’ve detected suspicious activity, the damage has likely been done. You must turn your attention to the control plane to prevent hackers from acquiring your API keys.

Cloud Security Myth No. 2: The security team alone can fix it

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. That process 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. 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 for 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.

Cloud Security Myth No. 3: Cloud security needs a human touch

At the same time, Policy as Code 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 service offerings keeps increasing as does the number of deployments you have and the amount of resources you need to secure. And so 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, such as the latest big data breach that makes news headlines.

To have a holistic response, one that actually works and isn’t merely security theater, you need to use Policy as Code enforced at the development phase, in the continuous integration/continuous delivery pipeline, and in the runtime. And as you gain maturity, these things can then be institutionalized and built into your processes so that it’s all automated.

What success looks like

Organizations that have implemented effective cloud security programs share some characteristics that any enterprise can emulate to harden their cloud security postures:

  • Know the environment — Gain constant situational awareness about what is happening in the cloud. That means doing more than conducting a weekly or quarterly audit. The hackers are also deploying automated tools to search for and exploit misconfigurations as soon as they appear. So knowing the environment is critical to securing cloud infrastructure.
  • Focus on prevention — Shift your security mentality away from trying to detect intrusions in real time. You’re not going to be able to, and by the time you do, the hackers will have taken everything they want anyway. Prevention is your only hope in cloud security because the hacks are too fast and too difficult to notice as they’re occurring.
  • Empower developers — Enlist the developers in the process by empowering them with tools. After all, since you’re now focusing on prevention, who is better positioned to prevent misconfigurations than the developers and engineers who are building these applications and systems? The way you do that is by giving them the right tools, specifically, Policy as Code.
  • Measure and repeat — Successful organizations quantify how successful they’re being at preventing hacks that could potentially happen and using that data to improve their processes.

Knowledge is power

Executives need to be more aware of the unique risks the cloud presents to their organizations, not simply believe they’re secure because somebody on their team following a vendor’s checklist says they are. Unfortunately, we see this a lot in the cloud security marketplace.

Many vendors are not really doing much to protect you against real hacks, they’re more concerned with helping security professionals present checked boxes to executives to make them feel better. That works until a hacker inevitably discovers a cloud misconfiguration and causes a devastating data breach.

To create a holistic response that actually works and isn’t security theater, think of the vulnerabilities that are manifest in your cloud environment as a virtual hole you’ve dug as your cloud infrastructure has expanded. The first thing you need to do to fill that hole is to gain a full understanding of its dimensions and depth. At the same time, you need to stop the DevOps teams from digging the hole again. The right way to do this is with Policy as Code.

Cloud breaches are due to design failures

In the short video below, I explain that every major cloud breach involves hackers exploiting flaws in the design of the system. I describe cloud security as a function of design and architecture, not monitoring and intrusion detection, because by the time you’ve detected something, the damage has already been done.

Companies: Fugue
Engagement

Join the conversation!

Find news, events, jobs and people who share your interests on Technical.ly's open community Slack

Trending

Where to watch the April 8 solar eclipse in Pittsburgh

How venture capital is changing, and why it matters

What company leaders need to know about the CTA and required reporting

The ‘Amazon of science stores’ and 30 other vendors strut their stuff for Philly biotech

Technically Media