The Importance of Lossless Visibility!
Does lossless visibility really matter for monitoring tools?
They’re supposed to be able to handle lost packets, corrupt packets, data gaps, etc., right?
Well, the answer is kinda, sorta, absolutely NO!
Security and monitoring tools are only as good as the data they see, or don’t see. Some tools have capabilities to help them “tolerate” missing data but that is a flawed theory and here’s why.
Missing data can lead to missed or false positive security threats, longer and more costly troubleshooting efforts, and lower customer satisfaction ratings. According to the 2016 Verizon Data Breach Investigation Report, most victimized companies don’t discover security breaches themselves. Approximately 75% have to be informed by law enforcement and 3rd parties (customers, supplier, business partners, etc.) that they have been breached—they had no idea the breach had happened. It’s hard enough to defeat modern network security threats, you don’t want to start off with limited network visibility. But that’s exactly what happens if your monitoring solution (which includes your taps, SPANs, and network packet brokers) does not feed your security and monitoring tools the correct data. For instance, check out this report from the Tolly Group about how one network packet broker drops packets and doesn’t even report it.
Other than missing your target reason for network visibility!
The following list shows some examples of why lossless visibility is important:
- Many security tools need “session stickiness”
- Loss of data can actually help hackers hide themselves
- SPAN ports already contain summarized data, missing data gives exploits more chances to hide
- Missing data can result in false positives for security and troubleshooting conclusions
- False positives mean duplicate efforts and longer resolution times
- At around 50% packet loss, performance analysis tools will start to fail
Many security tools need “session stickiness.” This allows them to correlate all components of a session to evaluate the risk and analyze the data for security threats. What happens when data is missing? One outcome is that the device, maybe it’s an intrusion prevention system (IPS) or some other inline tool, does not detect that the session has closed. If too many sessions remain open, the tool’s memory can’t track anymore sessions. This can either lead to data not being inspected or the tool might place itself in an alarm state and take itself out of normal service.
In another example, the loss of data can actually help hackers hide themselves. For instance, the hacker would start off with a DDoS attack. As the targeted network equipment gets loaded down, security tools and monitoring equipment would get loaded down as well. If the NPB starts dropping packets to the security tools, then the loss of packets can provide a type of smoke screen cover for the hacker who’s using the DDOS attack as a distraction while he tries to infiltrate the target network.
A third example could be an out-of-band intrusion detection system (IDS) that is monitoring data from a SPAN port. SPAN ports are a well-known entity that forwards summarized data, not a complete copy of all data. Bad and missing data is dropped by the SPAN port. This allows an attacker can hide threats, like embedded malware within the payload, within unmonitored gaps from the SPAN port.
In another example, missing data will look identical to packets dropped over the network. This can quite often generate a “false positive” kind of result where an IT admin or a Network Operations Center (NOC) may end up going through a troubleshooting workflow to solve some underlying problem and immediately conclude that the network is dropping packets as the cause. This is problematic for two reasons. First, they may declare “success”, without actually having identified anything going wrong over the actual network. Second, the organization may spend considerable time, effort, and money trying to “fix” the packet loss issue because they have assumed it is a network issue.
Missing data also makes it harder on monitoring tools to perform their job. For instance, using a performance analysis tool as an example, at a certain point, maybe around 50% packet loss, the tool will start to fail in its ability to monitor the data. This is because of the heavy drain on memory required to watch for conversations that never complete, since the “end session” data never came through. This means that the monitoring tool is not able to close the open sessions and allocate memory to a new session(s).
In a final example, all of the data may be there but it is so far out of order because buffers have reordered the data packets. This can lead to information loss as well. Even if the probe can make up for the lost/incorrectly ordered data, it puts a higher load on the tool and detracts from the tool’s core purpose of analyzing data. Tool CPU and memory resources are wasted trying to make corrections for errors that a poorly designed packet broker, or poorly designed visibility architecture, has introduced.
So, the right visibility solution is important, if not critical to your security and monitoring architectures. If you want more information on the importance of lossless visibility, read this whitepaper to get the full story. You can also get more information here.
Author:Keith Bromley is a product marketing manager for Ixia, Inc., with more than 20 years of industry experience in marketing and engineering. Keith is responsible for marketing activities for Ixia’s network monitoring switch solutions. As a spokesperson for the industry, Keith is a subject matter expert on network monitoring, management systems, unified communications, IP telephony, SIP, wireless and wireline infrastructure. Keith joined Ixia in 2013 and has written many industry whitepapers covering topics on network monitoring, network visibility, IP telephony drivers, SIP, unified communications, as well as discussions around ROI and TCO for IP solutions. Prior to Ixia, Keith worked for several national and international Hi-Tech companies including NEC, ShoreTel, DSC, Metro-Optix, Cisco Systems and Ericsson, for whom he was industry liaison to several technical standards bodies. He holds a Bachelor of Science in Electrical Engineering.
Also - There is an old paper on TAP versus SPAN...etc on www.LoveMyTool.com that has been downloaded over a million times and shared with hundreds of sites and schools. Even stolen by one company and they put their name on it, a bit lazy of them.