Networking anomalies

Recently, I had the great opportunity to discuss network security over dinner with one of the world’s best security practitioners. I learned that keeping bad actors from eventually getting inside a network is nearly impossible. While we maintain our vigilance at our borders over time we should assume our network would be penetrated, so the key to preventing exfiltration (which generally follows) is to look for networking anomalies.

Look for network uses that are abnormal, unusual, or different in some way from the norm. Techniques for doing this “hunting” are expensive to implement and hard to interpret with frequent false positives but are a necessary evil.

The amount of data, and the detection of anomalies is a candidate for an artificially intelligent big data process. Through analysis of mountains of data, one hunts for network uses that may be anomalous. Successful exfiltration has become a game of cat and mouse, stealing without being noticed.

Exfiltration without looking like an anomaly is a science. The bad guys nearly always proxy all exfiltrated data through public clouds or universities to avoid detection. They also quite often move data inside of existing protocols to avoid detection. And finally, they always encrypt their packets to avoid detection. Often the data is moved so slowly that the packet flows are not noticed.

Understanding normal and anomalous network behavior

At the center of mastering both securing and stealing data is the understanding of anomalous network behavior. The definition of anomaly is “something that deviates from what is standard, normal, or expected.” Network owners need to have a concept of normal or expected behavior to identify an anomaly. What is normal for your network? Do you know?

Using Little Snitch, I decided to analyze my own computer for one hour. I used the internet for Gmail, Facebook, CNBC and CNN. What surprised me was that there were over 600 different networking destinations for just the one-hour. These destinations covered the entire world, including at least ten different countries on three continents. Advertisers, ad trackers, software updaters, authentication sites, cache sites, backup services, security software, storage were intermingled with content sites, redirections, and simply unknown or mysterious destinations. Since I only visited four web sites, I was surprised at how many different real destinations were contacted.

This striking difference between the application view, and the true network view is astonishingly hard to reconcile. Defining anomalous behavior is simply anything different after a baseline, but everything we do constantly evolves generating anomalies routinely.  There is also a lot of noise from consumer grade applications that we all use mixed in with our secured corporate assets that have very defined behaviors.

Maybe our aim should be to focus instead on understanding and defining our normal behavior with enforcement. Corporations often break their data networks into security zones, where the definition of what is normal or expected is well defined.  Zones that contain sensitive customer data may not have direct access to the internet and may only be reachable through access control lists. Zones that contain general employee populations may have much greater access. The big challenge for most companies is that communications must go between zones. The web server must interact with the application server that in turn must query the customer sensitive data. What is striking is that most useful applications require crossing zones.

Zoom forward to the current time when everything is moving to public and private clouds. Now the zone concepts are giving way to security that is painted on by chaining software pieces together. The physical zones of the past are now simply logical zones running virtually in public clouds.

Get baked (security)

The question is, can security be baked so deeply into the network that our definition of normal when enforced provides markedly better security? Attributes a network with baked in security needs are:

1. An understanding of services and their building blocks
2. An understanding of the protocols used
3. An understanding of the directionality of sessions (who is the client, and who is the server)
4. Ability to provide detailed analytics and extraction of certificates

Software Defined Networking (SDN) can address this need. The hardware-centric networking model is being replaced by a service-centric fabric running entirely on commodity hardware, or in a virtual machine (VM) on site, or in a cloud. The old model has led to perimeter-based security architectures that are suited for yesterday’s hardware-centric networks but are unable to cope with today’s sophisticated security risks.

If today’s packet-oriented networks became service oriented, they could then easily apply fixed rules to control network behavior.  For example, consider a typical web service:

Patrick MeLampy/128 Technology

In this scenario, the arrows show the direction of the client/server connections. We could be more specific and define the protocols in use at each arrow. If the network knew that these were the only pathways and directions for these specific protocols and servers, then anything else would be anomalous.

But our networks today do not have directionality. They do not understand protocols. They route packets one-by-one in a single direction and call them “flows”. We need instead to chain in firewalls between each server to apply directionality and access controls. We also may need to insert load balancers to get proper scale. And we need to be ever vigilant that the customer database may be accessed by anybody at any time who has broken into the network zone.

The future is not about looking for something anomalous after establishing a baseline. Instead we need to start with a deny all by default model for secure services. In the above example, only the application server should access the customer data, and only with Hadoop transactions over TLS. Nothing else should be permitted. No other protocols, no other packets, no other clients, no other servers.

The service-oriented approach provided by SDN is a good option for today’s security needs, but not every service needs to be secure. For the services that need to be 100 percent secured, we need to completely define what is the normal behavior, and then we need to have networks with baked in capabilities to automatically enforce the policies. When the policies are properly enforced, there can be no anomalies by definition.