Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

brothke writes "When someone calls 911 in a panic to report an emergency, within seconds the dispatcher knows where the call is coming from, and help is often only moments away. When it comes to computer security incidents, often companies are not as resilient in their ability to quickly respond. Take for instance theTJX Cos. data breach, where insecure wireless networks were compromised for months, revealing millions of personal records, before they were pinpointed and finally secured. Once made aware of the issue, it took TJX an additional few months until the situation was completely in control and secured. In Computer Incident Response and Product Security, author Damir Rajnovic provides the reader with an excellent and practical guide to the fundamentals of building and running a security incident response team. The book is focused on getting the reader up to speed as quick as possible and is packed with valuable real-world and firsthand guidance." Read on for the rest of Ben's review.

Computer Incident Response and Product Security

author

Damir Rajnovic

pages

256

publisher

Cisco Press

rating

8/10

reviewer

Ben Rothke

ISBN

1587052644

summary

Provides a good overview of the topic of computer incident response and product security

tester dataBe it a IRT (Incident Response Team), CIRT (Computer Incident Response Team), CERT (Computer Emergency Response Team), or CSIRT (Computer Security Incident Response Team); whatever the term used, companies desperately need a process and team to formally respond to computer security incidents. The simple equation is that to the degree the incident is quickly identified, handled and ameliorated; is to the extent that the damage is contained and limited.

At just over 200 pages, the books 13 chapters provides an excellent foundation on which to start a CIRT. The book is divided into two parts. Chapters 1-6 form part 1, Computer Security Incidents, with part 2 being on Product Security.

Chapter 1 provides a basic introduction to the topic on why an organization should care about computer security incident response. This brief chapter touches upon the various business impacts, in addition to the legal and other reasons necessary for establishing a CIRT.

Chapter 2 lays down the 6 steps in which to establish an IRT, which are: defining the constituency, ensuring upper-management support, obtaining funding, hierarchy, team structure and policies and procedures. Each of these steps is crucial, and a mistake too many organizations make is to leave one or more out. Only later when an incident occurs, which often takes an inordinate amount of time to fix, do these companies realize that their IRT was incomplete and inadequate in the first place.

The chapter includes an interesting look at the various types of IRT teams that can be created; namely central, distributed or virtual. The book notes that if you don't have sufficiently strong support from senior organizational executives to form a real IRT (which should be a huge red flag right there), a virtual team is a good option. Virtual teams can be easier to set up as they are less formal with fewer bureaucratic hurdles. While there are benefits to a virtual IRT, companies that are truly serious about computer security will ensure that they have a formal and dedicated IRT in place.

In chapter 3, Operating an IRT, the author details the items needed to successfully operate an IRT. One of the soft skills the author discusses is effective interpersonal skills. The author writes that one situation that can arise when handling an active incident is that the person reporting the incident may say offensive things or become abusive to the IRT analyst. This behavior is generally the consequence of the attack, indicating its urgency. When dealing with such a person, it is imperative that IRT analyst not get caught up in the user's behavior. Rather they must focus on determining the appropriate method to fix the problem.

While part 1 is around the computer security incident itself, part 2 deals with product security. Most organizations create their IRT around computer security incidents. In chapter 8, the author writes about the need to create a product security team (PST) to deal with security issues related to vendor products.

Every software and hardware product has security flaws, be it Cisco, Juniper, Check Point and others. By understanding this and having a PST to deal with vendor security issues, a company will be adequately protected. In truth, only large companies will have the budget to support an independent PST in addition to an IRT.

In many ways, the PST is simply a specialized section of the IRT, with specific expertise around a specific product set. Many firms already have some sort of PST in place to deal with Patch Tuesday, which is the second Tuesday of each month when Microsoft releases security patches.

Overall, Computer Incident Response and Product Security provides a good overview of the topic. At 215 pages, the book should be seen as an introduction to the topic, not a comprehensive reference. The reason is that a topic such as security incident response requires much broader coverage given the extent of the requirements encompassed. In some ways though, its conciseness is its advantage, as a 750 page tome, while adequate for the subject, may overwhelm many, if not most readers. Also, the author has the ability to adequately discuss topics in a manner while brief, does cover the topic issues.

At $49-, the book is moderately priced, given the value of the content. For those on a limited budget, the Handbook for Computer Security Incident Response Teams fromCERT provides a good overview of the topic. While the handbook was last revised in 2003, much of the core concepts around incident response are immutable.

As this title is from Cisco Press and the author an employee of the CiscoProduct Security Incident Response Team (PSIRT), the book has a definite Cisco slant. While Cisco products are often referenced, this though is not a book from Cisco marketing. More importantly, as part of the Cisco PSIRT, the author has first-hand knowledge of one of the world's premier IRT.

For those serious about computer security and incident response, Computer Incident Response and Product Security should be one of the required books for every member of the team.

Usually, when someone calls 911, it's because that person is in trouble and needs to be removed from a location or a situation.

Computer incidents are more like someone calling 911 because the building is unstable but has to stay inside it anyway. You can't fix a building within a few minutes. The architect needs to review the blueprints, the construction workers need to make the required modifications, go back to the architect because his solution forgot to take something into account, etc. It's not a quick fix situation.

Or like when something toxic is leaking or a person is injured, but nobody is around to notice it and call 911. Summary's comparison with a 911 call is just dumb. It seems the goal was to just make computer security look bad, as if breaches of security could be somehow detected in all cases and reported and dealt with immediately.

this review is too long and this book seems to be too generic; examples:

Every software and hardware product has security flaws, be it Cisco, Juniper, Check Point and others.

Chapter 2 lays down the 6 steps in which to establish an IRT, which are: defining the constituency, ensuring upper-management support, obtaining funding, hierarchy, team structure and policies and procedures.

"Take for instance the TJX Cos. data breach, where insecure wireless networks were compromised for months, revealing millions of personal records, before they were pinpointed and finally secured. Once made aware of the issue, it took TJX an additional few months until the situation was completely in control and secured"

Don't you mean the data breach that went unnoticed for over eighteen months [itpro.co.uk] (or possible up to two years [zdnet.co.uk]) until their bank informed them of the huge number of fraudulent transactions. Which a

Not all 911 calls are about life-threatening emergencies. And that homicides are more serious than armed robberies is not offered as an excuse for failing to investigate both expeditiously. It would be nice if the computer industry would stop excusing itself on the grounds of terminal uniqueness. There are a great many laws and procedures in the "real" world that can and should be adopted by the computer world without rethinking or reinvention.

I'd much rather read something focusing more closely on computer incident (and NOC operational) response and its similarities to ICS principles. I'm sure there are places that run coordinated responses to events (especially cross-departmental events) along the lines of an Incident Command System [wikipedia.org], and I'd be curious what their experiences are and how other groups can transition to something similar.

I have to imagine that any cyber-response being handled at the national level is going to follow NIMS [fema.gov] to some extent as well.

This shouldn't be surprising - an organization's purpose is to do what it does, to quote somebody or other. TJX is making money off transactions; security is only incidental, and responding to unusual events runs counter to the grain of an optimized organization. The 911 call center, on the other hand, is helping people as a matter of course. (Just see how well they do when they start trying to make money off the transactions! j/k)

^TJX's issue was that they never spent any money on security that they didn't absolutely have to.

That's actually not a bad thing. I'd restate that to say, "They didn't realize that they absolutely had to spend money on security until it was too late." Not spending money on things that you don't need to spend money on is good business - there are a myriad of things that might be needed, but probably won't be, and covering all of your bases will quite literally put you out of business. They chose poorly, and should be criticized for that, but they shouldn't be criticized for making the choice in the f