And Another Thing... More NSM Thoughts

My Hawke vs the Machine post elicited many comments, all of which I appreciate. I'd like to single out one set of comments for a formal reply here. These are by "DJB," which I highly doubt is Daniel J. Bernstein since the comment ends with "See you at the next ISSA meeting." (DJB lives in Illinois and I live in Virginia.)

DJB writes:

The topic is not alert-centric vs. NSM, or even passive vs. reactive. The real issue here is Return on Investment for security and Due Care. The cost and lack of common expertise of NSM is why it has not been fully adopted. Every SOC/NOC I’ve ever been in (over 100) suffers the plight you have identified. Furthermore, I could hire a hundred people with your level of expertise or the same number of Gulas, Ranums and Roeschs to perform NSM. The only problem is that the problem would not go away and I would be out a significant amount of money, even if you have “the right forms of data available.” The volume of traffic that we are talking about would require far too many experts.

Let me address these points in turn.

• There is no ROSI (return on security investment). There is simply cost avoidance. Due care is a concept I am more likely to embrace.


• NSM requires almost no cost at all. All of the software I use is open source. Most of the hardware I use is old junk. (This is one beauty of Unix.) When necessary I do buy hardware, and certainly one can spend lots of money on specialized gear. However, for the average company using an OC-3 or lower, you can get an acceptable amount of NSM data without breaking the $3000 barrier for a very fast, big-hard-drive 1U box and network tap.


• What takes more expertise: interpreting cryptic output from a series of alerts (through alert-centric processes) or inspecting all of the traffic associated with an event of interest (NSM processes)? Making sense of the alerts from any leading commercial IDS/IPS can be an exercise in astrological prognostication and intestine reading. Looking at session patterns or -- unbelievably! - what commands the intruder tried to execute on the Web server and what responses came back takes very little skill. (Darn, I think I just called myself an idiot.) Furthermore, from whence does skill derive? Looking at alerts, or inspecting traffic? Q.E.D.


• If every SOC/NOC (100) you've visited suffers the same problem, they need help! Contact me: I provide assessment and remediation services for exactly those sorts of broken organizations.


• With NSM you don't need to hire a hundred Gulas, Ranums, and Roesches. First, they don't exist. Second, the data helps make the expert, not the other way around.


• With or without NSM, security problems never go away. This is important: There is no security end game. All you do is achieve an acceptable level of perceived risk. That's my definition of security. With NSM, however, you know what is happening and can try to improve.

I think the other points have already been addressed.

One closing thought: I have never met an analyst -- a person who is actually trying to figure out what security events are ocurring on a network -- who rejects NSM once exposed to its tools and techniques. In fact, when I taught at SANS CDI East last month one of my students offered one of best comments I've ever read:

Wow, practical information for network and security engineers... why isn't anyone else teaching something this useful? (Comment from student, 15 Dec 06)

Many people who are tangentially related to network security or sell products or do other services reject my ideas all the time. (Some do, not all do.) The people in the trenches see the value, and really that's all I care about. The possible exception is convincing their bosses, so the analysts get the equipment and training they need.