NEW VIDEO: Security Weekly - How to protect AWS metadata services (used in Capital One breach). Watch now!
 
 

Got 99 Problems but Your Network Ain’t One

Data, applications, and services all need a home, a place users and processes can interact with organizational resources. Every business, be it a small mom-and-pop pizza shop or a Fortune 50, runs on data and applications. Owners and employees need access to databases, payment systems, collaboration technologies, custom-built applications, and more to perform everyday work, and all of these resources reside on some network somewhere. Or multiple networks. And those networks may be distributed and owned by someone else. Some are on-premises, some are cloud-based. Some have one tenant and others have dozens. All the while, every piece of software, every process communicating on those networks needs to be secured so that unauthorized users can’t tamper with, delete, or illicitly access systems or data. As a consequence, security and networking teams spend a lot of time worrying about the network: What kind of network is it? What is on the network? How much risk exposure does that create? Where do my security responsibilities start and end with SaaS/PaaS/IaaS? How do I gain real-time visibility into what’s happening on my networks and then correlate that across all my environments?

The questions are endless yet all center around the network. However, remote workers, mobile devices, highly interconnected supply chains, IoT, rapid and continuous application development and deployment, containers, and more all make the concept of a secure network incredibly complex, costly, and (frankly) unlikely. As the saying goes, “organizations that haven’t been breached just don’t know it yet.” Social engineering and software vulnerabilities make it too easy for an attacker to exploit a common weakness and enter networks undetected. Once inside, very few organizations have adequate controls to prevent attackers from exploiting generous permissions and accessing resources they have no business accessing.

With all of that being said, companies continue to try to prevent cyber attacks with technologies that depend on network constructs: firewalls, IDS/IPS, DLP, anti-virus. Endpoint and user authentication and authorization controls are layered on for added protection, as are other technologies like encryption, network monitoring, mobile device management, and network access controls. Still, the fact remains that many of these tools use network and location-based information as the basis for their permit/deny/quarantine decisions.

Yet we know networks have changed.


Stay on the cutting edge. Subscribe to our blog.


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.

 

Katherine Teitler, Director of Content

Written by Katherine Teitler, Director of Content

Katherine Teitler leads content strategy and development for Edgewise Networks. In her role as Director of Content she is a storyteller; a translator; and liaison between sales, marketing, and the customer. Prior to Edgewise, Katherine was the Director of Content for MISTI, a global training and events company, where she was in charge of digital content strategy and programming for the company's cybersecurity events, and the Director of Content at IANS, where she built, managed, and contributed to the company's research portal.