The cloud disrupts IT and compute paradigms, and allows us to rethink everything about them. But more often than not, the move to the cloud means merely transfer of on-premise IT to cloud environment, almost unchanged.
Perimeter is one such example.
Like most other security means, perimeter (aka DMZ) was born out of necessity — set a secure buffer zone between the untrusted external network (Internet) and the trusted internal network (corporate LAN). Perimeter is the component of the network that is designed to “take the bullet” for the network it protects, to serve as the first (or last, depending on your point of view) line of defense.
What is perimeter?
“In computer security, a DMZ or demilitarized zone (sometimes referred to as aperimeter network) is a physical or logical subnetwork that contains and exposes an organization’s external-facing services to a larger and untrusted network, usually the Internet. The purpose of a DMZ is to add an additional layer of security to an organization’s local area network (LAN); an external network node only has direct access to equipment in the DMZ, rather than any other part of the network. The name is derived from the term “demilitarized zone”, an area between nation states in which military operation is not permitted.” — (source: Wikipedia)
The early perimeter was very simple: One or two firewalls and a VPN. Over the years, with the growing number of Internet-facing services and remote users, more security and network services were added to the perimeter (e.g. WAN Optimization, Server Load Balancing, Application Delivery Controllers, Web Application Firewalls, DDoS protection, IAM).
A simple perimeter:
In reality, perimeter did not — and cannot — provide the level of protection it is supposed to provide. The increasing number of security and data breaches we witness, and their severity, are evidence of that. In most of these breaches the attackers were able to penetrate the perimeter protection rather easily.
The problem with old world perimeter
Perimeter can be hacked and penetrated in many ways — it is merely a more secure and isolated network segment. But once attackers penetrate the perimeter (and they do…), they are effectively in the corporate network.
Why is perimeter part of the network? It has to do with the architecture of early corporate networks that were fixed and rigid.
Interestingly, with the move of corporate resources to the cloud, the same paradigms persist. Enterprises simply build corporate network segments in the cloud (e.g. VPC). The perimeter follows, and becomes a replica of the on-premise perimeter — attached to the corporate network in the cloud, and part of that network.
Now, the A-B-C of security begins with isolation and separation. The more isolated and separated the resource is, the more secure it is expected to be. So why not completely isolate and separate the perimeter from the corporate network?
If the cloud allows us to do things differently (and better…), why stick to the old practices when we know they fail?
Enter cloud perimeter
Consider a standalone cloud-based perimeter, delivered as a service: The separation and isolation from any network or cloud it protects are inherent. It’s physically and logically isolated from the application environment it protects.
Conceptual illustration of cloud-perimeter:
Such a cloud-based-perimeter comes with multiple additional benefits:
- Removes the attack surface from the corporate network edge: perimeter is the attack surface of the network it protects. If the perimeter is provided as a cloud service, the attack surface is removed for the corporate network.
- Hides the protected applications: When cloud applications are protected by a cloud perimeter, users who access them cannot even know what cloud they’re running on. Effectively, the cloud-perimeter hides cloud applications from the public Internet, yet makes them completely accessible to authorized users.
- Provides a single, unified, central perimeter for all corporate environments (public cloud, private cloud, on-premise etc.): Since a cloud service by its very nature can serve any number of connected environments, there’s no need to set-up or configure new perimeter with every new application that requires remote access, or with every new network location (e.g. new branch office). Think of it as a “perimeter hub”.
- Can be easily replicated to regions and zones: Another property of a cloud service — it is omnipresent (e.g. local and regional POPs).
- Has no scalability pains: Cloud service is inherently elastic and extensible. Additional services are automatically deployed and scaled up.
- Significantly reduces the “cloud lock-in” phenomenon: If perimeter (and other fundamental services) are provided by the host/public cloud platform, they are exclusive to the cloud platform, hence — “lock-in” the customer to that cloud platform.
- No upfront or ongoing integration and no maintenance costs: Cloud service is all about subscription, not upfront investment.
Veteran IT folks use to say that perimeter is “IT’s unwanted and unloved child”. It’s also one of IT’s budgetary black-holes. Cloud-based perimeter can change that.