Tag Archives: Packet Analysis

Network Packets Matter to Security Professionals

Imagine that you investigate car accidents. When you arrive at a scene, you see the smashed cars, skid marks, bent post, and whatever else, and quickly determine that one car came into the path of the other one. This paint on the fender matches that dent in the other car, for example, and even the angles where the car ended up tell a story.

Now imagine that the insurance company asks you to investigate an accident that happened last month. You can still go to the scene, but this time, all you see are some skid marks, a still bent post, and a few other things. But no cars. Perhaps you can still figure out what happened, but it isn’t easy.

Being an accident investigator without being able to see the cars is the situation that security incident investigators find themselves in when they are investigating a breach and can’t see the packets that were the vehicle for the attack.

The problem is that most attacks aren’t discovered for months, and by that time, the packets are gone. It just isn’t practical to store weeks and months of network traffic; a network averaging only 3 Gbps requires 7.5 petabytes of storage in 229 (the median time between breach and discovery according to a recent study.) And since it is the median time, even with 7.5 petabytes, you’re missing half the security events. So let’s double it to be safe. And assume we’re buying relatively inexpensive storage. That is still over $5 million!

The answer is intelligently determining what to store, but that’s the subject of another blog post. Stay tuned!

Preventing Bandwidth Issues

First, a quiz: In the following scenario, do you think this is a network, device or application problem?

Users are continually experiencing garbled and choppy VoIP calls, Internet connections are slow, and you are receiving complaints of poor video quality.

If you answered network bandwidth issues, you are correct. With video becoming the primary data type on networks of all types, it’s a lot easier for networks to become strained and overused, and often not by mission critical traffic.

If you are consistently experiencing these problems, here are some helpful steps to take to prevent bandwidth issues.

Step 1: Create a baseline
It’s always important to know what your bandwidth needs are based on the number of users and the types of applications that are running on your network. Know who is using what, when, where, and why in regards to network segments. This will help you understand the overall demand on your network and allocate bandwidth appropriately. It will also allow you to quickly determine when network usage is exceeding norms.

If new applications, new users, or new devices are introduced be sure to reevaluate your baseline usage.

Step 2: Prioritize critical business applications and tie baseline protocols and usage to those applications
Each network segment may have different protocol priorities because of the specific applications that traverse those segments. Top applications need to be handled based on business importance for the segment they are individually on.

That said, even if you prioritize your business applications, any protocol that is not performing well could affect overall application performance. In order to determine what application might be causing problems, it is essential to have a network analyzer that can break down and show individual flows and their performance. The network analyzer can provide visibility into the weakest link as well as options to sort application flows with various criteria choices.

Step 3: Use packet shaping technologies
Packet shaping allows you to prioritize certain network traffic, like key applications or real-time data (like VoIP) over other, less critical traffic on your network. For example, if you run an online store that is the backbone of your business, HTTP traffic to and from your web servers is critical. Packet shaping technology can give this traffic priority over everything else, ensuring the best possible user experience for your online customers.

Step 4: Prune your protocols/traffic
Most corporate networks have unnecessary traffic which can consume precious network bandwidth needlessly. Check for protocols that may no longer be necessary on your network, or that could be network hogs, like SNMP, to determine if they still have a purpose or if they are being misused. If they are no longer mission critical, make sure your packet shaping technology treats this traffic with the lowest possible priority.

Along with continuously pruning your network, be sure to constantly monitor your network. The best monitoring solutions will allow you to archive packet data to disk, providing a complete recording of network activity. When your monitoring solution indicates problems, simply “rewind” your network to determine exactly what the issue is. Whether it’s a surge in web-based sales due to your latest promotion, or employees streaming the Stanley Cup playoffs, it’s up to you to know what your network can handle, and up to your network monitoring and analysis solution to let you know when bandwidth issues are about to occur.

Packet and Protocol Analysis Are the Same Thing, Right?

These two approaches in network analysis are often mentioned synonymously, but one is more thorough than the other. Do you know which one? If yes, then no enjoy this refresher blog post. If no, then let us explain.

Protocol analysis is a subset of packet analysis. Protocol analyzers interrogate packet headers to determine if the protocol is being used for communication, and what type, like HTTP. This form of analysis is strictly for the communication layer and is best served if you are trying to solve basic connectivity or configuration issues or simple timing issues.

On the other hand, packet analysis dives deeper into the packet for analysis. Packet analyzers address both the packet header as well as the payload, which contains critical information about applications and their operation on your network. Packet analyzers can answer the deeper, and often-asked question, “is it the network or the application?” The evidence is clear when you dive into a network flow for a user with a problem and see in the decode “Process ID 169 was deadlocked with another process and has been chosen as the deadlock victim. Re-run your command.”

Need a deeper explanation of troubleshooting end user experience with packet payloads? Check out this post on LoveMyTool.