Network Security Monitoring Lives

Every once in a while I will post examples of why Network Security Monitoring works in a world where Webbed, Virtual, Fluffy Clouds abound and people who pay attention to network traffic are considered stupid network security geeks.

One of the best posts I've seen on the worm-of-the-week, Conficker, is Risk, Group Think and the Conficker Worm by the Verizon Security Blog. The post says:

With the exception of new customers who have engaged our Incident Response team specifically in response to a Conficker infection, Verizon Business customers have reported only isolated or anecdotal Conficker infections with little or no broad impact on operations. A very large proportion of systems we have studied, which were infected with Conficker in enterprises, were “unknown or unmanaged” devices. Infected systems were not part of those enterprise’s configuration, maintenance, or patch processes.

In one study a large proportion of infected machines were simply discarded because a current user of the machines did not exist. This corroborates data from our DBIR which showed that a significant majority of large impact data breaches also involved “unknown, unknown” network, systems, or data.

This my friends is the reality for anyone who defends a live network, rather than those who break them, dream up new applications for them, or simply talks about them. If a "very large proportion of systems" that are compromised are beyond the reach of the IT team to even know about them, what can be done? The answer is fairly straightforward: watch the network for them. How can you do that? Use NSM.

Generate and collect alert, statistical, session, and full content data. I've also started using the term transaction data to mean data which is application-specific but captured from the network, like DNS requests and replies, HTTP requests and replies, and so on. These five forms of data can tell you what systems live on the network and what they are doing. It is low-cost compared to the variety of alternatives (manual, physical asset control; network access control; scanning; etc.). Once a sensor is deployed in the proper place you can perform self-reliant (i.e., without the interference of other groups) NSM, on a persistent and consistent basis.

Where should you monitor? Watch at your trust boundaries. The best place to start is where you connect to the Internet. Make sure you can see the true source IP (e.g., a desktop's real IP address) and the true destination IP (e.g., a botnet C&C server). If that requires tapping two locations, do it. If you can approximate one or the other location using logs (proxy, NAT, firewall, whatever), consider that, but don't rely only on logs.

NSM lives, and it is working right now.

---

Richard Bejtlich is teaching new classes in Europe and Las Vegas in 2009. Online Europe registration ends by 1 Apr, and seats are filling. Early Las Vegas registration ends 1 May.