Living in a zero-trust world: moving past identifiers as verifiers

For a very long time, computer networking has relied on “unique” identifiers to verify that a user/system/traffic/application is what it says it is. In other words, “my identity is my identity, therefore I am who I say I am.” This setup, though, is very simplistic and assumes that no two entities can have the same ID, or that no user/system/traffic/application can spoof another’s identity. In today’s not-so-simplistic world of networking, most technologies haven’t moved past this notion of an ID as a verifier, and we’ve seen the consequences in the form of cyber intrusions and compromises. This problem is the origin of zero trust network principles, and Edgewise solves that problem with Trusted Application Networking.

We can see that there are better ways to verify identity by taking a lesson out of the playbooks of newer technologies. Consider, for example, the recent uptick in caller ID spoofing. Odds are you’ve gotten dozens of phone calls on your personal cell phone that appear to be coming from not just your area code, but also an identical prefix as your own number. The idea that spoofers have in mind is that you’re more likely to pick up a call that appears to come from a neighbor, and those who have phone numbers very similar to yours are more likely to be your neighbors.

But as we all know, those calls aren’t actually coming from your telephone number neighbors, they’re being faked to get you to pick up when it rings.

In contrast, think of the messaging service WhatsApp. WhatsApp communications are encrypted end-to-end, and that encryption is not optional. You can be confident that if you’ve followed the proper steps to set up a conversation through WhatsApp that the person you’re speaking with is the person you’re trying to speak with and that the conversation isn’t being intercepted.

Lost in translation

With respect to business applications and software built for enterprise use, security and networking teams continue to try to force outdated constructs onto development teams’ workflow (click to tweet this). Developers are, to put it bluntly, not thinking about IP addresses and firewall rules. Security teams swoop into the development process to discuss why developers must write software that conforms to this firewall rule or that.

Security is speaking a different language, and it’s one that is likely to be forgotten as soon as the security person walks out the door and the developer looks at the production schedule.

The fact is, though, that applications as they are written today pose serious threats to enterprises. And the technologies we are using to try to mitigate those threats simply aren’t adequate. Firewalls—one of the main technologies implemented to deal with identifying and verifying traffic—rely mainly on IP addresses, ports, and some aspects of the application protocol to detect those threats. It’s impossible for firewalls to define policies with true application concepts at the center. At the end of the day, the goal is stop bad intentioned actions. Inferring intent from a couple numbers in a network packet is next to impossible; adding detailed insight regarding each of the communicating applications makes the job not only possible, but feasible.

East, west, north, and south

All of this describes communications within a network. What happens, then, when this traffic occurs in an external environment? In these cases, defining “good” vs. “bad”/”allow” vs. “deny” in terms of network elements is nearly impossible, unless you want to entirely reconfigure your network to utilize secure tunneling protocols and finely granular firewall rules (an extremely resource-intensive prospect). What’s more, you can’t take advantage of cloud-native capabilities like auto-scaling without impacting the application. Some tools, like microsegmentation products, try to abstract identifying information but at the end of the day, these technologies are still constrained by the underlying address-based enforcement technology.

The limitation of entrenched technology constrain security teams and developers alike, leaving them hamstrung by cumbersome tools and outmoded techniques that do little to prevent lateral movement of attackers. While application developers are readily moving forward, security has, for a very long time, been stuck in the past – relying on technologies and processes that are as outdated as the telephone number. Though this concept worked well 20 years ago, it’s time for security to move forward by embracing zero trust concepts. Just as you fully expect your cell number to migrate with you between carriers, so too should you expect your database container’s security policies to migrate with it through the network (click to tweet this).

Edgewise has developed Trusted Application Networking for this reason. It’s focused on application characteristics, not the environment in which the app is running. Trusted Application Networking works anywhere: on premises or in the cloud. With Edgewise you are able to protect your application with the right controls, without negatively impacting business agility.

To learn more about Trusted Application Networking, contact us today for a demo on how Trusted Application Networking:

  • Uses application-level language to define and enforce policies.
  • Enforces policy based on the applications communicating.
  • Deploys anywhere with portable policies on-premises or in a public or hybrid cloud.

When it comes to security, thank you, IP addresses and ports. You’ve had a good run, but it’s time for an upgrade.

Tom Keiser, Edgewise Engineering

Written by Tom Keiser, Edgewise Engineering

Tom Keiser is a principal kernel developer at Edgewise. Previously, he specialized in distributed file systems and distributed instrumentation. Outside of work, he enjoys large format photography, macroeconomics, and reading about history.