Security in the Cloud: The Business Perimeter

When Leonidas of the Spartans found himself faced with the prospect of defending Sparta against the totally much bigger and meaner Persian army, he specifically chose the narrow pass at Thermopylae to do so. In the Battle of Stirling Bridge, William Wallace and his Scottish forces used to their advantage the narrow crossing of the bridge to defeat the English. When you’re stuck in a dungeon crawl, you stand in the door, reducing the effective capabilities of those hundred zombies to just two or three at a time.     

The strategy of forcing an attacker to traverse a single, restrictive point of control is an ancient one. It essentially reduces the advantage of having a significantly higher number of attackers than defenders.

We’ve been using this strategy for years in technology. It’s called the firewall. It’s a strategic point of control and it’s generally “the gateway” to the objective (apps and data). And that worked really well, as long as everything was behind the firewall and it was the only point through which an attacker could gain access to their objective.

With the prevalence of cloud today, however, attackers have many more points through which they can gain access to their objectives. Each app requires its own protective perimeter. They need their own DDoS protection and their own personal, private web application security policies. They need basically the same protections they’ve always had, but now they need it somewhere else. Architecture, not appliances, are as important to protecting your business forces (those are your apps) arrayed across the vast battlefield that is the Internet.

There are several options available. For example, you can deploy per-app protection as part of the larger “application architecture package” wherever it’s deployed. That might be on-premise, in a cloud-inspired environment, or it might be in the public cloud. Wherever it is, there you go – and that’s where you deploy your protections, with the application to form a per-app perimeter that is specific to the app and provides the same strategic control that the pass at Thermopylae provided.  The advantage here is that app security is packaged up with the app, necessarily. It’s taking Zero Trust to the cloud. 

Another strategy is based on principles found in that of serverless architectures; a cloud-first approach to centralizing security (still high in demand on many a security professionals’ wish list) without sacrificing the benefits of a simplified, cloud-based solution. That is to adapt the traditional strategic control offered by a firewall and move it into the cloud; into an “as a service” model. Such an approach affords organizations the ability to centralize app security while avoiding a likely costly model in which the data center continues to host the “primary” security services and all traffic must flow through it. This inefficiency is best addressed by migrating security like DDoS protection and app firewalls to the cloud, where both bandwidth, capacity, and access are broadly available. The advantage of centralization and the elimination of device management is significant. 

Regardless of which approach you might have chosen (or plan to choose), one stark reality stands out: the corporate perimeter is no longer the business perimeter. With increasing numbers of apps in various clouds and the steady but certain growth of the Internet of Things, security strategies must not only start considering how to protect apps in the cloud, but how to use the cloud to protect apps everywhere.