Secure Network Analytics (Stealthwatch): Then, Now, and Beyond
Part 1: In the Beginning
(2001-2011)
Secure Network Analytics (formerly Stealthwatch) was recently recognized as the industry leader in Network Detection and Response (NDR). This product journey began in 2001, and through the years, we have had to innovate to remain a leader. Yes, I said 2001. A time when we were still imaging machines from optical drives, Windows XP had just shipped, before the social media boom and maybe even before some of you readers were born. In so many ways, things are different today than they were back then but the product’s primary objective has never changed; “To analyze network behavior in order to identify threats and malicious activity and direct it to the most effective response.”
It all began in 2000 where a Georgia Institute of Technology professor, Dr. John Copeland founded a company called Lancope. It was his vision that would inspire others and ultimately lead to where we are today. Along the way, there were some significant battles we had to fight and hold our ground. Some of these were strategic bets that would later pay off.
Dr. Copeland founded Lancope upon the discovery of “probing” on his home computer through odd bursts of data in the fall of 1999. Recognizing that these data bursts had malicious intent and could traverse a firewall, Dr. Copeland invented “Flow-based Analysis” to derive the probability that a conversation between two hosts was malicious. The clever thing about Flow-based analysis is that it involves the statistical analysis of counts built from packet headers alone. At the time, this meant the solution could operate at higher packet rates that IDP/IPS alternatives of the day.
Using Flow-based analysis was a natural fit for NetFlow, and it allowed us to scale across the entire network to provided unprecedented breadth of security visibility. However, one argument we needed to address was “Why are we using NetFlow? NetFlow was not meant to be used for security!” NetFlow was introduced by Cisco in 1996 and was superseded by Internet Protocol Flow Information eXport (IPFIX) in 2008 (rfc5101/rfc5102). We trained our analytics on it because we knew that if we were right, instead of having visibility where we could deploy sensors, the network itself would become our sensor!
The next argument we needed to overcome was “You can’t do real network security detection without Deep Packet Inspection!” Because we did not depend on Deep Packet Inspection, industry experts would argue that we cannot detect threats with NetFlow/IPFIX alone. To understand the validity of this argument, you needed to go back to a time where network encryption was used sparingly. Most of the network was largely operating in the clear – I know it sounds insane, but these were simpler times. The use of SSL and TLS was not widespread and setting up a site-to-site VPN took a network genius. We knew that it would be only a matter of time before Deep Packet Inspection would become a thing of the past. Today, even if you were to capture all the packets, well over 90% of it would be encrypted and opaque to direct inspection. Let me be clear, if DPI was available, we would use it, but we did not depend on it for our security analytical outcomes. This put us in a very strong position because our machine learning algorithms would not be affected by the pervasive use of network encryption. So once again, we made a very important strategic bet for the reality of today.
As Lancope became more and more successful within the larger global 2000 enterprises, we quickly learned that we needed to add integrations that would allow us to perform analytics from multiple centricities. We felt that there might be cases where customers want to view the results by device, or by application, or by user. A device-centric question would be “What has this device communicated with in the past 30 days?” A user-centric question would be “What has the user alice01 done on my network in the past 30 days?” To add in this user-centricity, we needed to integrate with an authoritative source for that data. At the time, Cisco offered the “Identity Services Engine” or ISE for short. Integrating Secure Network Analytics with ISE meant that we could now offer device and user-centric analytics when it came to the behavior we observed across a customer’s network. ISE would also lay the groundwork for safe and secure automated responses. If a threat actor was active on a part of the network, Secure Network Analytics could signal to ISE to isolate that device or user. All of this functionality back 10+ years ago would begin to define what is now the extended detection and response (XDR) market today.
With 10 years in market with Secure Network Analytics, Lancope and Cisco established a strong partnership. The two companies were a match made in heaven due to the fact that Secure Network Analytics did network behavioral analysis and the network is where computers behave. Secure Network Analytics is now an essential part of the “Network as a Sensor” concept and customers consider it a pivotal part of their security program. Up until 2011, threat actors were breaking into your networks and thus the appropriate detection was in place, but something was changing. Attackers weren’t breaking in anymore, they were simply logging in and operating in your network as someone you trusted! Those traditional detection methods were no longer effective because no alarm bells would be triggered. It was now all about detecting when an application, device, or user started to behave in a way that was suspect and Secure Network Analytics was in the right place at the right time.
In the next part to the series, we will take a look at how things changed after being acquired by Cisco in December of 2015. After that, we will look into the future and talk about what’s to come!
Share:
