App-centric vs. address-centric security controls

Since the dawn of the firewall, the primary way of deciding whether network communication should be allowed or denied has been by looking at IP addresses and ports. This approach is problematic for two main reasons:

  1. It relies on naive assumptions. By relying on an IP address and port, we’re basically saying that if you’re using an authorized port, then both you and the thing you’re talking to must necessarily be authorized. But that’s not automatically the case.

    Once any system is compromised—and as recent news reaffirms, this happens regularly—attackers use the authorized network access of that system to move effortlessly through the network. Whether it is to propagate and infect, like the NotPetya strain of ransomware, or to connect to and exfiltrate entire databases, like the recent Equifax debacle, address-centric network security controls barely represent a speed bump for attackers. Once one address is compromised, the dominos fall in short order.

    Moreover, an IP address is an unreliable way of identifying authorized applications (click to tweet). Addresses can be, and are, spoofed. As an analogy, consider your phone. Call blocking based on a telephone number or caller ID may stop that annoying telemarketer who happens to play by the rules, but attackers rarely play by the rules. We’ve all received phone calls purporting to come from our own telephone number. Just as caller ID spoofing is both easy and common, so is IP address spoofing.

  2. It relies on outdated architecture. In today’s more dynamic IT environments, IP addresses don’t mean what they once did. Continuing the earlier analogy, telephone numbers once meant something interesting and persistent. Most people my age can remember their childhood phone number because it was the one any only way to reach home. Now, with mobile numbers, Skype (or Viber, or WhatsApp, or Tango), Google Voice, and more, a person’s telephone number is about as interesting, and nearly as volatile, as the color of their shirt. How many of you know the actual phone numbers of your family members?

    Not long ago, IP addresses seldom changed, and to stand up a new server meant a lengthy procurement and installation process. In today’s virtual, elastic environments, new servers spin up, spin down, and move locations with unprecedented speed. Having controls that rely on these quickly changing requirements becomes a policy management nightmare. This means that most environments deploy overly permissive policy sets on their firewalls so that they don’t impact business agility.

    The goal of network security is to ensure that only authorized software communicates over approved network paths. Trying to achieve this goal using only their declared addresses and ports is a losing proposition. Even using deep packet inspection to look inside the communication suffers the same problems—conversation patterns can be spoofed, and modern computing environments use more dynamic patterns than ever before.

There are three steps required to achieve better network security:

  • Step one: You need to be able to identify and validate the applications communicating in your environment (click to tweet this)—on both sides of the conversation.
  • Step two: You need to be able to define your security policies in terms of these applications, independent of their IP addresses or ports.
  • Step three: You need to be able to deploy these policies in a dynamic environment, independent of the infrastructure, so they can automatically adapt to rapid change—whether it be in a private or public cloud, a containerized or micro-services environment, a staging or production arena.

That’s why Edgewise developed its Trusted Application Networking product. Edgewise:

  • Automatically identifies applications and models your environment. Edgewise’s machine learning engine automatically models the optimal communication pathways in your environment and selects application attributes that uniquely and securely identify your applications.
  • Uses application-level language to define and enforce security policies. Controls are based on the actual identify of applications and their legitimate communications needs, rather than IP addresses, protocols and other network elements. This means that your application developers, who know the application better than anyone else, can develop policies without relying on server or network engineers.
  • Deploys anywhereon-premises, or in a public or hybrid cloud. As you migrate or scale your critical business infrastructure, Edgewise automatically adapts with the application. This enables the agility needed to meet your business demands without having to sacrifice security or continually rewrite your network policies.

Perhaps the telephone carriers or manufacturers will follow suit, as using caller ID is about as effective for stopping unwanted and malicious calls as address-centric controls are in network security. One can hope.

Harry Sverdlove, Founder and CTO

Written by Harry Sverdlove, Founder and CTO

Harry Sverdlove, Edgewise’s Chief Technology Officer, was previously CTO of Carbon Black, where he was the key driving force behind their industry-leading endpoint security platform. Earlier in his career, Harry was principal research scientist for McAfee, Inc., where he supervised the architecture of crawlers, spam detectors and link analyzers. Prior to that, Harry was director of engineering at Compuware Corporation (formerly NuMega), and principal architect for Rational Software, where he designed the core automation engine for Rational Robot.