Computer Incident Response and Product Security

Posted on by Ben Rothke

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

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

Senior Information Security Manager, Tapad

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community