Network Protocol and Contextual Analysis: Picking the Right Tools for the Job
by Eric ReevesI work on the team behind the Application and Threat Intelligence (ATI) program, which provides everything needed to maintain your BreakingPoint Storm CTM. This includes new application protocols, security attacks, performance enhancements, and more. I thought that I would write two blog posts, the first providing a brief education on what analysis tools we use and why. The second post will provide an example of how this all works, looking at the BreakingPoint Storm CTM simulating a SIP/RTP call. Let’s start with the protocol analyzers.
The purpose for using these analyzers is twofold. On one hand, these analyzers are invaluable resources when researching new protocols, understanding new features of an existing protocol, or grasping the concept behind an enhancement request. Conversely, we also use these tools to validate the traffic that our own BreakingPoint Storm CTM produces. This is an unyielding requirement within our development cycle.
Generally speaking, we use a combination of commercial and open source products when analyzing application protocols. There are many advantages to using both, including the ability to compare interpretations of the protocol specification between the open source community and commercial entities. Some protocol implementations do not necessarily adhere to the specification, and naturally nor does the analysis tool. In using an open source product we're able to review the source code, reach out to the community, and even change the product ourselves. Conversely, commercial protocol analyzers may offer the same benefits but usually offer different features as well as the support resources you would expect from a commercial entity. Additionally, the participation of both entities provides a “checks and balances” system with respect to protocol correctness vs. real-world implementation.
Another advantage is that many of our customers use both types of these products. By verifying protocol data with the same products our customers use on a daily basis, we maintain customer confidence across ATI updates and software releases. Lastly, we are not obliged to rely on just one analyzer; if one analyzer doesn't support a particular protocol or feature, or doesn't provide the required level of detail, then we may use a different analyzer to obtain the information that we need.
Here are the protocol analyzers we use most often, grouped into two main categories, which we will discuss in order below:
- Protocol Analysis
- Wireshark
- NetScout
- InfiniStream Console
- Sniffer Intelligence
- Contextual Analysis
- NetWitness
- Investigator
- Decoder / Concentrator
- DejaVu TrafficScape
- NetWitness
Please note, from time to time we may use another tool; however, we do so only to cross-reference our results against those in the list above.
Protocol Analysis
The purpose of this category is self-explanatory. In order to ensure the desired level of realism and correctness for our application simulations, BreakingPoint engineers must inspect packets up to the most granular level. By providing packet data at layers 1 through 7, we can ensure protocol correctness with respect to encoding, syntax, and even state.
Each of the analyzers in this category provides essential features. The most useful feature is the ability to view not only the hex/binary representation of data, but also the interpretation of the data. Every analyzer has a concept behind its packet inspection mechanism including dissector, decoder, parser, inspector, and others. While the method by which the data is inspected may differ, for our purpose the result is the roughly the same. We need the ability to parse protocol data into easily readable and searchable fields.
These analyzers also perform encoding and decoding operations. In other words, they translate binary-encoded data into a format readable by humans. As someone who has spent many hours staring at H.323, H.248, and S1AP captures, I cannot stress enough the convenience that this feature provides.
Speaking of convenience, we also need the ability to create custom filters. Custom filters provide the ability to quickly target data of interest, whether we're looking for all data within a particular protocol or specific sets of protocol data. A great example of this feature is using Wireshark's filter to display only HTTP requests, Filter:http.request. Another useful Wireshark filter is Filter:malformed, which shows only packets that Wireshark's protocol dissector has regarded as malformed. NetScout, NetWitness, and DejaVu all have similar capabilities.
Finally, each tool supports the import of packet captures. While this is advantageous when dealing with smaller trace files, the BreakingPoint Storm CTM captures an immense amount of data, often too much to take advantage of this feature. Hence, an added benefit of the NetWitness and NetScout solutions is an impressive collection of hardware that reads data directly from the wire at very high data rates. We use this by placing a tap on a loopback connection while running a validation using the BreakingPoint Storm CTM. This allows us to inspect the data in real time. The ability to capture this data directly off the wire is an invaluable resource during long simulations or those that require data that is too large for export/import. We can capture several hours' worth of data, drill directly into a particular window, then export that specific data to other analyzers.
Contextual Analysis
Contextual analysis is not only the analysis of data, but also analysis of the environment in which it occurs. In contextual analysis, not only is a specific data set subject to inspection, but also its relationship to other data in the same environment. Doing this allows us to assign a greater context or significance to certain data.
This becomes particularly important for lawful intercept or network forensics systems. These two examples require complex scenarios, which we want to be able to analyze during our own development. Merely producing data that “looks correct” is not enough to validate that a lawful intercept device is working properly. While our use of these analysis tools occurs later in the development process, they represent an equally critical set of requirements.
Both NetWitness Investigator and DejaVu TrafficScape provide the ability to search against relationships between data, e.g. e-mail conversations between two specific users, VoIP calls from a particular location, or instant message sessions among a group of users. We use this functionality to assess how well the flow and action settings translate data from the BreakingPoint Storm CTM into a format that challenges and satisfies the customer. Both tools allow users to drill into specific sets of data, only to reveal even more data to explore.
BreakingPoint provides our customers with the most realistic application protocol traffic in order for them to validate the resiliency of their networks. These analyzers allow us to be sure that our applications are working properly, at every level, during simulation. In Part Two of this series I'm going to show you a direct example by exploring a SIP/RTP call.
