Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Computer Incident Response and Product Security

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

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

Sorry! There are no comments related to the filter you selected.

Gee (1)

Locke2005 (849178) | more than 2 years ago | (#34985146)

Potential life-threatening emergencies are handled differently than potential data loss... who would have thought?

Re:Gee (0)

Anonymous Coward | more than 2 years ago | (#34987310)

First comment, like all the comments, focus not on the book or the review. Who would have thought?

Re:Gee (1)

Locke2005 (849178) | more than 2 years ago | (#34987594)

Duh... if you take the time to actually RTFA, how can you possibly get first post???

Not the same thing (3, Interesting)

Yvan256 (722131) | more than 2 years ago | (#34985188)

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.

Re:Not the same thing (0)

Anonymous Coward | more than 2 years ago | (#34987002)

get a grip, it is just an intro...and your thoughts on the CONTENT!!!!

Re:Not the same thing (1)

mschaffer (97223) | more than 2 years ago | (#34987460)

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

Re:Not the same thing (0)

Anonymous Coward | more than 2 years ago | (#34987658)

and your point is??????????

Re:Not the same thing (1)

noidentity (188756) | more than 2 years ago | (#34987854)

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.

Re:Not the same thing (0)

Anonymous Coward | more than 3 years ago | (#34991432)

If you put an AXE in a vital server. I'm sure it will be replaced fast. If you point out that the server is swapping|paging then nothing will happen. I heard it myself from a boss "Its not a problem". And I was like what you need me here for then?

Wow (0)

Anonymous Coward | more than 2 years ago | (#34985190)

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.

So we actually got our priorities right for once. Pretty exciting news.

this book seems to be too generic (1)

JonySuede (1908576) | more than 2 years ago | (#34985194)

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.

...

Re:this book seems to be too generic (2)

I8TheWorm (645702) | more than 2 years ago | (#34985290)

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

Re:this book seems to be too generic (0)

Anonymous Coward | more than 2 years ago | (#34987156)

reviewer says this is an intro, not the definitive text on the topic.... what more do u want?

Re:this book seems to be too generic (1)

Omniscientist (806841) | more than 3 years ago | (#34991096)

... what more do u want?

The definitive text on the topic, I'd say. Google is great for introductions on things.

If the summary about TJX is true (1)

bugs2squash (1132591) | more than 2 years ago | (#34985274)

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.

Re:If the summary about TJX is true (0)

Anonymous Coward | more than 3 years ago | (#34993468)

true. but that is one small part of the overall much larger security problem.

insecurity pinpointed and secured? (1)

doperative (1958782) | more than 2 years ago | (#34985304)

"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 all began with an antenna [colombiaunderground.org] and a laptop computer.

911 Calls re: Cat in Tree (1)

QuincyDurant (943157) | more than 2 years ago | (#34985336)

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 security get up to well-established standards.

People call 911 with actual information. (1)

Kenja (541830) | more than 2 years ago | (#34985354)

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

Re:People call 911 with actual information. (2)

Java Pimp (98454) | more than 2 years ago | (#34985594)

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

Re:People call 911 with actual information. (1)

gnapster (1401889) | more than 2 years ago | (#34987802)

"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?"

NIMS/ICS? (2)

Etcetera (14711) | more than 2 years ago | (#34985506)

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.

Core Competency (2)

Fuseboy (414663) | more than 2 years ago | (#34985528)

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)

security was handled by Heartland Payment Systems (1)

doperative (1958782) | more than 2 years ago | (#34985748)

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

Except the transactions [securecomputing.net.au] were handled [informationweek.com] by Heartland Payment Systems [washingtonpost.com] , an organization supposedly charged with securing credit card transactions.

Re:Core Competency (0)

Anonymous Coward | more than 2 years ago | (#34986256)

"Thank you for Dialing 911! Your call is important to us. Please stay on the line for the next Customer Service Representative.

We are currently experiencing a higher customer call volume.
If you are a Gold Service memeber, press 4,
If you have a Platinum Partner Pass, Scream 6,
otherwise, please stay on the line."

I worked the TJX breach (0)

Anonymous Coward | more than 2 years ago | (#34985864)

The problems with TJX weren't just that they were hacked. They had systemic architecture issues and a lack of expertise to identify and resolve them. Based on their 10K filing, the attacker had access to the information compromised for at least 3 years. There's a flawed assumption that an organization that allowed that can recover quickly from a compromise of that nature. ^TJX's issue was that they never spent any money on security that they didn't absolutely have to. Their pre-breach IA team was significantly understaffed and under experienced for a Fortune 500 company, they had almost no network visibility and no vulnerability management at all. An organization like that has more problems than an inadequate IRT.

Re:I worked the TJX breach (1)

rjstanford (69735) | more than 2 years ago | (#34987180)

^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 first place.

Other books (1)

bsDaemon (87307) | more than 2 years ago | (#34987030)

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.

Re:Other books (0)

Anonymous Coward | more than 3 years ago | (#34992482)

thankx, but both those books r over 8 yrs old....

Anecdote. (0)

Anonymous Coward | more than 3 years ago | (#34989190)

This book is recommended reading (but not required) for a few units in my IT Security Degree and frankly I know why. It's the same airy-fairy bullshit that most Cisco books are like, there are much better books then this if you're looking to form IRT which take into consideration many viewpoints and analysing the benefits and flaws of different models rather than the Cisco(TM)(R)(OMG) Method(TM)(R)!
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?