Why the Security Industry Has Workload Protection All Wrong

[Shay_Levin]

By @tj Gonen - Head Of Cloud Security | Check Point

With cloud-based services dramatically speeding up the deployment and continual upgrading of applications, IT security has gotten massively more complicated over the past decade. But if the cloud makes everything a hundred times faster, it also multiplies threats to those applications at the same pace because of the speed and complexity. Organizations report that the size of their security teams have ballooned in an effort to keep up — but this is more often the result of an “old world” approach to protecting application workloads in the cloud, which is often based on a misapprehension of what workload protection actually is.

The concept of workload protection was first popularized a few years ago by analysts, who made it apparent that deploying applications via the cloud required new elements — such as containers — in order to function. Further, these applications could effectively become serverless, existing at any point across the cloud infrastructure — depending on when they were needed. These elements, along with the app itself, became known as “workloads”. As a result, “workload protection” became specifically connected with solutions that addressed container and serverless security.

The problem is that many security teams have run with this definition (and continue to do so), believing that workload protection is just about having a good container and serverless security solution. They often disregard the need to protect the application itself — or indeed any of the other elements that make up a cloud-deployed workload.

Yet what the business cares about, above all else, is the quality and functionality of the application. Whether it’s a customer-facing web service or backend software, it doesn’t care about containers or how the app is distributed across the cloud’s server infrastructure. But when the security team tells them that the workload is protected, more often than not they’re talking about something other than the app itself.

Even though a more accurate and holistic definition of workload protection is now available — for example, Gartner now uses the term “Cloud Native Application Protection” — the old definition continues to create dissonance and confusion within the market. This is also partly due to the security industry itself; and the way in which it compartmentalizes the products it promotes and sells to its customers, which in turn perpetuates an on-premises mindset stretching back 20-30 years.

When organizations first opened themselves up to the online world, they quickly faced a series of novel threats to their data and infrastructure. Accordingly, security companies sprang up to address these problems — first selling them firewalls, then antivirus solutions, and eventually an entire armory of discrete vulnerability management and threat prevention products. As the type of attacks multiplied, so too did the variety of defenses. However, at some point, this proliferation of solutions became untenable to manage and a process of consolidation began to take place, leading to a more holistic approach to security.

However, this point solution mentality has persisted in addressing cloud-based security threats, with each new element — container, serverless, etc. — treated as an individual attack vector to be protected, with individual teams assigned to each solution. All of which led to bloat in the security department. Given the rapid development of the web services space, this is entirely understandable — but it risks repeating the mistakes previously made with on-premises.

Even those organizations who understand that workload protection means more than just container and serverless security, have ended up deploying point solutions to address additional elements — such as configuration policy and posture management — and indeed application security itself. But while this piecemeal approach is theoretically doable in the short term, it’s neither efficient nor scalable — no matter how big the security team grows. Just as in the on-premises world, consolidation is the only sensible way forward.

Ultimately, it’s impossible to properly manage workload security in the cloud using point solutions, because (as I’ve already noted) the cloud moves much too fast for that. It might take months to deploy and secure a data center in the physical world, but it takes just a millisecond to launch one in the cloud — and if just a tiny part of the configuration is wrong, it doesn’t take long for that potential vulnerability to spread far and wide. Trying to manually fix issues as they occur in this environment just doesn’t work. The speed and complexity of the cloud require a solution that is both holistic and automated.

Application development has been driven by automation for some time now, enabling DevOps teams to roll out code almost continuously into a cloud infrastructure that is also automated. For security to be truly effective in this environment — and to work as a holistic solution — it needs to be present in the development pipeline from the start, with configuration policies baked into the application as it is coded. The only way to achieve this is through automation that guides the developer to always produce secure and compliant code that recognizes what’s normal and what’s anomalous and automatically reacts to changes and potential threats without human intervention.

In the cloud, a holistic workload protection solution is an automated solution — there is simply no other way of realistically doing it. If it can’t be automated, it isn’t a solution. And if security teams aren’t to become completely swamped by the task of managing their organizations’ web apps, they need to work alongside their DevOps teams to implement solutions that protect the entirety of the application workload — not just cloud-specific functionality.

[WendyRomero]

Interesting thanks @sh