Elasticity and autoscaling in the cloud
Communication on a cloud network doesn’t work the same way it does in a bare metal, on-premises data center. Things change too frequently, necessitating ongoing rule changes and exception handling which distracts network and security teams from the higher-level work of actual security. Modern cloud architectures are elastic and require security tools that can scale; legacy tooling just can’t handle today’s dynamism. As a result, network constructs—IP addresses, ports, and protocols—are only nominally effective at preventing “bad” on the network. Next-generation firewalls are quite good at moderating north-south traffic: keeping potentially malicious actors outside the perimeter. But where exactly is the perimeter today? Is it the device? Is it the user? Did the user change location, or devices for that matter? Is network segmentation configured properly or even at all? Can boundaries be traversed easily by threat actors who’ve abused overly-permissive controls (since address-based policies are complex to manage)?
Then there are cloud-native applications and services to consider—things that never cross a traditional perimeter and therefore aren’t subject to packet inspection by a firewall—yet they have to communicate across network paths to function properly. If a threat actor has made their way inside the network using stolen credentials or exploiting a software vulnerability, it’s easy to hide inside permitted network traffic and access system resources then exfiltrate large amounts of data to sell on the dark web.
Why? Because traditional or legacy network security technologies haven’t adapted to how employees and the resources they rely on operate today.
The network doesn’t matter. It is a vehicle for software, applications, and processes to communicate. Much like highways were built to handle automobile traffic. Yes, highway departments can erect guardrails and law enforcement can set and enforce speed limits, but the bulk of vehicle safety today is built into automobiles themselves. Because what is traveling down the highway is riskier than the highway itself. Organizations need to stop putting so much emphasis on the “highway” where applications and services “travel” and start attaching security control directly to applications and services. Traffic routes on today’s networks change too frequently for policies that depend on them to be reliable or manageable. Of course security and network teams can build guardrails—and cloud providers are getting very good at baking security into their environments—but the main goal of security today should be to protect applications and services and the data that reside inside them.
Application identity as the new control plane
The best and most valid way for accomplishing application-centric security is to abstract policies away from network topology and tie them directly to communicating network resources. In doing so, you ensure the “safety features”—the theoretical airbags, traction control, and anti-lock brakes—are focused on what’s important rather than its environment. Application identity-based control means that applications/services can communicate on whatever network they need to, or even across environments, and protection remains. It means that organizations can continue using cloud, containers, and virtualization (and whatever comes next) without the security team fretting about how to manage security.
Networking in today’s world is complex. Trying to secure all environments by focusing on networks constructs is just not realistic—and the reason security teams have to consider breaches in terms of “not if, but when.” Rather than continuing down the same network security path, organizations must shift gears and look to application identity as the new control plane. There will be plenty of networking issues to tackle in the future, to be sure, but securing your applications and services shouldn’t be one.