Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Image

Computer Incident Response and Product Security 30

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 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. 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
Be 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 from CERT 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 Cisco Product 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.

Ben Rothke is an information security professional and the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase Computer Incident Response and Product Security from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

*

This discussion has been archived. No new comments can be posted.

Computer Incident Response and Product Security

Comments Filter:
  • Potential life-threatening emergencies are handled differently than potential data loss... who would have thought?
  • Not the same thing (Score:4, Interesting)

    by Yvan256 ( 722131 ) on Monday January 24, 2011 @02:45PM (#34985188) Homepage Journal

    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.

    • I agree. This analogy is so flawed I don't even want to read the remainder of the post.

    • 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.

    ...

    • I don't get that from the review. Remember, it's about response team, not the insecurities themselves.

  • then their problem would seem to be a lack of giving a shit about it rather than a lack of ability to master the technological challenges the issue presented.
  • "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.

    Rajnovic's book seems to be an honest attempt to help IT securi

  • "I've been shot" tells the 911 operator a lot more then "the computers not working" tells the support department.
    • "I've been shot" tells the 911 operator a lot more then "the computers not working" tells the support department.

      Yes exactly, "My computer's been shot" is much more useful information that should be provided to the support department.

      • "911. What is your emergency?"
        "I've just been shot, and some shrapnel damaged my monitor. How long would it take to get a replacement?"
  • by Etcetera ( 14711 ) on Monday January 24, 2011 @03:06PM (#34985506) Homepage

    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.

  • by Fuseboy ( 414663 ) on Monday January 24, 2011 @03:07PM (#34985528) Homepage

    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)

  • This book is more about forming an incident response team than actually DOING incident response or forensic analysis. Since most slashdotters are going to lean towards wanting to know how to do things, I'd recommend Incident Response & Computer Forensics [amazon.com] by Kevin Mandia as Real Digital Forensics: Computer Security and Incident Response [amazon.com], both of which are quite good.

Garbage In -- Gospel Out.

Working...