How To Identify What Applications Are On Your Network
I have no idea what applications are on my network. Sound familiar?
Deep packet inspection devices read the payload of packets within network traffic flows. And many can decode the application that sent it and show you what applications are on your network. These devices require special chipsets to process packets at the speed of network traffic flows, which makes them expensive. But, is it possible to identify the application that sent a packet without using a deep packet inspection device? The short answer is yes, and this Application Intelligence Infographic describes how, but let’s take a deeper look into why you would want to and where this capability would help.
The Search for Efficiency
The cost of a deep packet inspection device is probably six figures for the average enterprise customer. There are many factors affecting how much an organization would spend, but the cost is usually based on the speed and capacity of the device. For instance, 10Gb devices would cost more than 1Gb devices. The cost of capacity and speed creates a problem for companies because traffic volumes are not going down. Higher traffic volumes translate to more devices. But, if you could limit the traffic they inspect, you could free up some device cycles (and maybe some cash). That was part of the motivation behind bringing application intelligence into the visibility layer. The idea was to figure out a way to identify the application that sent the traffic without having to use deep packet inspection.
The Cost of Data Ingestion
Identify the application that sent the traffic before it reaches your tools and you can filter traffic to target only specific tools. Got an email scanning tool? Send it only email traffic. If you can direct traffic to specific tools, then you can do the opposite and filter out traffic too. Imagine being able to filter out streaming media traffic like Hulu and NetFlix rather than sending it to the intrusion detection system (IDS). Companies could decide to accept a certain level of risk and deem some traffic safe without inspecting it. YouTube traffic might be a good candidate, for instance. This small increase in risk might be worth the cost savings and each company could decide that. Additionally, cost savings might actually go beyond eliminating tool cycles. Some tools structure their license based on the amount of data they ingest. For instance, Splunk Enterprise licenses specify how much data can be indexed per calendar day. It all boils down to this. Identify the application before it gets to your tools and you have greater control and flexibility over your environment, and maybe even your spending.
Designed for Passive Monitoring Only
The idea of identifying the application source of a packet and filtering it to target or skip a tool is meant only for out-of-band tools (passive monitoring). Inline (or In-band) tools like next-generation firewalls (NGFW) are active, real-time security inspection tools designed to protect the perimeter. I have not seen a use case where you would want to filter traffic by application type and bypass an all-purpose perimeter security tool. But, once you are passively monitoring network traffic (performing analysis or detection using network packet copies), filtering in or filtering out traffic by application makes a lot of sense.
How to Get Started
First, you need a visibility layer. Something to avoid directly connecting tools to SPAN ports. Ixia’s Security Fabric sits between your network and your tools, creating a tool distribution network (a visibility layer). It essentially provides all tools with access to all data no matter where it is on your network. Once inside the Security Fabric, filter rules can be created and network traffic distributed to the tool you want to have it. And, it also provides the opportunity to perform advanced packet processing such as masking or eliminating sensitive data so you remain in compliance.
How Application Intelligence Works
Packets are processed by Security Fabric’s Context-Aware Data Processing Engine. The process of identifying the application starts with analyzing the packet’s 5-tuples. 5-tuples is just jargon for protocol; source IP address and port number; and destination IP address and port number. It checks these 5 tuples against its database of sessions and if it finds a session, then it knows the application. How does it know? If a session exists, then it has already processed a packet with the same 5 tuples and identified the application. Sessions are created to keep the Fabric from having to do the heaving lifting again. The session is then stored for fast and accurate application identification when future packets arrive with the same 5 tuples.
If the 5-tuples data does not correlate to a session in the database, then it looks to match other clear-text data in the packet with its database of signatures. If there’s a match, the application is identified. Security Fabric comes with hundreds and hundreds of built-in application signatures (a complete list is provided in Appendix B of this white paper) so you don’t have to create your own for a majority of the applications on your network.
If the application is not in the database, the Context-Aware Data Processing Engine starts building an application signature based on certain characteristics of the traffic. For example, it may use port numbers, protocol details, and SSL certificate information. Finally, it names the application and stores it in its database. But it also keeps learning and modifying the signature when more traffic of the same type is spotted.
A Dashboard to See the Applications
Network admins and security analysts simply launch the Context-Aware Data Processing Dashboard to see the applications on their network. The dashboard is live and continuously updated with the bandwidth each application has used along with other helpful metrics. It’s also actionable, so you can point-click and filter traffic to a specific tool.