Recently, I had the great opportunity to discuss network security over dinner with one of the world\u2019s 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.\nLook for network uses that are abnormal, unusual, or different in some way from the norm. Techniques for doing this \u201chunting\u201d are expensive to implement and hard to interpret with frequent false positives but are a necessary evil.\nThe 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.\nExfiltration 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.\nUnderstanding normal and anomalous network behavior\nAt the center of mastering both securing and stealing data is the understanding of anomalous network behavior. The definition of anomaly is \u201csomething that deviates from what is standard, normal, or expected.\u201d 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?\nUsing 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.\nThis 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. \u00a0There 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.\nMaybe 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.\u00a0 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.\nZoom 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.\nGet baked (security)\nThe 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:\n\nAn understanding of services and their building blocks\nAn understanding of the protocols used\nAn understanding of the directionality of sessions (who is the client, and who is the server)\nAbility to provide detailed analytics and extraction of certificates\n\nSoftware 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\u2019s hardware-centric networks but are unable to cope with today\u2019s sophisticated security risks.\nIf today\u2019s packet-oriented networks became service oriented, they could then easily apply fixed rules to control network behavior. \u00a0For example, consider a typical web service:\n Patrick MeLampy\/128 Technology\nIn 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.\nBut 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 \u201cflows\u201d. 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.\nThe 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.\nThe service-oriented approach provided by SDN is a good option for today\u2019s 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.