Review of Security Monitoring Posted
Amazon.com just posted my four star review of Security Monitoring by Chris Fry and Martin Nystrom. From the review:I must start this review by noting that the authors of Security Monitoring (SM) cite my blog and books several times, which is appreciated. I must also mention that their boss Gavin Reid, who posted a review below, has offered to sponsor my company's application to the Forum of Incident Response and Security Teams (FIRST). O'Reilly kindly provided a review copy of SM.
I think SM should be positioned as an Introduction to Basic Security Monitoring. At just over 200 pages, it's not written to be much more than that. I'm not sure I will change the mind of the reviewer who considers my first book to be "introductory," but it might help to remember that my first book is just shy of 800 pages and covers every aspect of Network Security Monitoring.
SM is technically correct, but its approach to incident detection will fall far short of what is needed in the real world. SM concentrates on a paradigm it calls "policy-based monitoring," (abbreviated PBM here) with this goal: "to compare events discovered on the network to ensure that they are approved and acceptable... PBM is practical where acceptable conditions can be documented as policies... [Y]ou must codify acceptable behavior as policies, providing a reference point against which to survey" (pp 16-17) This sounds great, but it has several real flaws...
Please read the rest of the review for the whole story.
Richard Bejtlich is teaching new classes in Las Vegas in 2009. Late Las Vegas registration ends 22 July.
Comments
RB- "I'm not sure I will change the mind of the reviewer who considers my first book to be "introductory," but it might help to remember that my first book is just shy of 800 pages and covers every aspect of Network Security Monitoring"
CF- Our preface said that the book is not an intro to sysadmin, network admin, etc and that advanced technical topics can be found in other books. Sounds like you're more pissed about the amazon.com dude's review calling your book introductory and our book advanced. I don't really agree with his assessment and can understand the frustration. As for the SSN example, it's just that...a *simple* example of how you can customize your toolset to watch for violations that may be unique to your environment. It's not supposed to catch advanced adversaries, it's for the $7/hour data entry clerk looking to make a quick buck. If you actually read the whole section you would see that there are 7 other methods of monitoring based on their security policy, including watching for outbound connections from the hosts (see page 31).
RB- "Second, SM buys into the digital situational awareness paradigm that I call "sufficient knowledge." In other words, if a product fires an alert for "BitTorrent protocol" (example p 95), the analyst is supposed to accept it as truth and be happy with what he or she gets from the security product."
CF- Interesting observation but I don't recall us advocating complete reliance on IDS alerts as your sole source of incident data. We also discuss the use of netflow, syslog and other event data which would be checked when the IDS alert was seen.
RB- "The fact is that real security analysts will want every scrap of network traffic associated with an alert, including knowing exactly how the detection mechanism decided to notify the analyst"
CF- The context in this case is a datacenter environment. Keeping anything beyond a short timeframe is not going to be cost-effective. You can deploy something like an Infinistream or Niksun etc device and be able to go back perhaps a few days, but the idea that you could keep all packets in anything but the smallest datacenter environments is not based on reality (unless you have unlimited budget). Just 2Gbps of sustained traffic at your capture point will leave you requesting ~ 20 Terabytes of disk storage per day This method is more effective at the perimiter where bandwidths are not typicaly so high.
RB- "Third, some parts of the book indicate to me that the authors are fairly new to enterprise monitoring. On pp 112-114 they discuss relying on SPAN ports and say "we wouldn't dare implement this inline at the data center gateways (or distribution layer), due to the high bandwidth requirements and asymmetric paths.""
CF- Everyone has different requirements and tolerances for risk. We've tried to provide a way to look at these decisions from a few different perspectives. I'm thinking of what happens when your TAP goes into "automatic failover" in *only* 2-3 seconds (spanning-tree convergence, routing convergence, all things you don't want for FCoE, VOIP, video, etc). The point is that you need to understand the failover scenarios very well. And sure, you can design your way around all of this, but it all depends on how much complexity you want to add to your network (again back to requirements/tolerances). The network engineer stealing your SPAN example is more to plant the idea that you'll want to make sure that your data sources don't disappear, which we discuss.
RB- "The caveat is that you should recognize the book is an introduction to the basics."
CF- It's really about getting the most out of and improving on what you have already. Our intention in writing the book was to share some experiences and best practices for the benefit of peers. There are a lot of very powerful tips, methods, and tools presented in a practical way. Thanks again and I hope we can discuss/collaborate/share more via FIRST.
Chris
http://www.oreillynet.com/pub/e/1370
Wednesday, July 15th, 2009 10AM PST
The obvious choice is the Tao of NSM, which I've been considering picking up, but are there any other books you'd recommend reading first?
http://www.bejtlich.net/reading.html
has my recommendations plus what I'm reading, which may or may not be relevant.