How to Prevent Capturing Data for Security Reasons

Security should be top of mind these days. I wrote an article years ago about three lessons you can learn from doing a network security analysis. Taking the appropriate steps is even more crucial now than then.

But how do you protect your organization when you need to help troubleshoot an application problem and need to capture packets? In this post, let’s talk about how you can go about doing that.

Security Compliance

When doing a packet capture, one of the things we must always be concerned about, especially nowadays is capturing too much data. As a general rule, you want to capture as much data needed to solve a particular troubleshooting problem. But you don’t want to capture so much that it worries security engineers.

There’s a lot of security compliance to follow. These compliance standards help give your organization a chance at avoiding getting hacked.

You have the Health Insurance Portability and Accountability Act (HIPAA) in healthcare. HIPAA ensures that healthcare organizations are doing all they can to protect patient data. The US Department of Health & Human Services (HHS) tracks the number of breaches that affect 500 or more individuals. According to their Breach Report, a healthcare organization breach affected over 22 million Americans in 2020. That’s over 6% of the US population, just from healthcare!

There’s General Data Protection Regulation (GDPR) in Europe. GDPR requires organizations to protect user personal data and privacy. IAPP, the global information privacy community, tracks GDPR compliance. In its 2019 IAPP-EY Annual Governance Report, they found that among the organizations who have to comply with GDPR, 38% reported having a breach that year.

These are just two of many other security compliance standards organizations should follow. And many reasons to make sure breaches are minimized.

So when you’re capturing data to help solve a problem, you don’t want to inadvertently capture user data. This is especially important if, for whatever reason, that data is not encrypted with TLS, IPsec, or any other encryption protocol.

How do you avoid doing that? You capture only the headers. That’s how!

Packet Header Security

Each packet on your network has packet headers that are used to help get data from one end of a network to another end. This helps route the packet through the network from an application’s clients to its server instances.

But these headers can also help you analyze data when you need to troubleshoot.

A typical frame seen on the network with packet capture tools shows a size of 1514 bytes. You get more bytes if the protocols that make up this frame have additional options or are what’s known as a jumbo frame. For example, with a jumbo frame, over 9000 bytes.

On an IP network, there are usually three main types of headers – Ethernet, IP, and TCP, and application layer.

The Ethernet header is usually about 14 bytes, with information such as the 6-byte source and destination MAC addresses. The IP header is 20 bytes, with information such as the 4-byte source and destination IP addresses. The TCP header is another 20 bytes, with information such as the 2-byte source and destination ports.

This usually leaves about 1460 bytes for the application data, but other implementation protocols can reduce this as well. For example, if your data is encrypted with TLS, you lose about 5 bytes to the TLS header. Or, if you’re using the Cisco WAN acceleration protocol, WCCP, you lose about 200 bytes due to its maximum segment size (MSS).

But on a typical packet, more often than not, an application is likely to have about 1460 bytes of data it can send.

In a packet capture scenario, the application data is what you want to protect and not see. So how do you do that?

Packet Capturing

When doing a packet capture, regardless of the tool you’re using – tcpdump, Wireshark, etc – you usually can limit how much data you capture in bytes. Since these headers do not contain any specific information about what the application is sending, you can capture just the headers of the Ethernet, IP, and TCP protocols.

All three protocols together have a typical header size of 54 bytes. So when you run your packet capture, you can specify that you only want the first 54 bytes of a network packet.

If you’re using tcpdump, you do this by using the -s option. So to capture only 54 bytes of data, you specify a snapshot length of 54.

tcpdump -i <device interface> -s 54

If you’re using Wireshark in the command line, you can use the same -s option.

tshark -i <device interface> -s 54

If you’re using Wireshark UI, you can go to Capture -> Options menu and change the Snaplen to 54.

I recommend that 54 bytes be your minimum for the snapshot length but try for something larger, if possible. Unless you know exactly what’s running on your network, which is often not the case, you want to capture a little more data. For example, if options are enabled in the TCP header, you’ll have up to 20 more bytes to capture.

So when you limit your packet captures, you should try to go as high as 100 bytes, but not more than that. Depending on the application layer protocol, you may be able to see just enough data that gives you a little more clue into what the application is doing. However, if you capture much more than 100 bytes, you might capture actual personally identifiable information (PII). You want to avoid capturing PII data.

Go Limit Captures

You can see why it’s important to limit the amount of user data when doing packet captures. Not only do you have to worry about being compliant with the various standards out there, but you also want to limit the data in case a possible attacker gets to this data.

Capturing only headers is a great way to get the data you need to help with troubleshooting an application or network issue. But it may not help in certain situations when you need a little bit more information about the application. So always seek to capture at least 54 bytes, but not more than 100 bytes of packet data.