Q&A with the Author of Computer Incident Response and Product Security
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Please introduce yourself and tell us what you do professionally.
I am Damir Rajnovic but I usually go under my nickname Gaus. I am a member of Cisco PSIRT team. My main duties are to handle security vulnerabilities in Cisco products. This includes understanding the problem, finding all affected products across the whole Cisco range and driving the issue to the closure which means fixing the vulnerability. The visible result of our work is Cisco Security Advisory.
I started my career in computer security by handling computer incidents. The first one that I can recall was in 1995, when someone created a repository of pirated software on our FTP server. The next step for me was incident coordination during my tenure in EuroCERT. After that I moved to Cisco where I started working on product (in)security, which still occupies bulk of my time.
Apart from that I am active in FIRST—Forum of Incident Response and Security Teams. My current focus in FIRST is participation in standardization efforts. In particular that is coordinating FIRST efforts in ITU and ISO organizations.
Tell us about your new release. Who is it for and what is it about?
First of all these are actually two books within one. The first part is about creating and operating an incident response team and the second part is about handling product security vulnerabilities. As it happens these two topics are complementary. In good part computer incidents are happening because of vulnerabilities in products. Once a vulnerability becomes known, it must be fixed. So actually, we are talking about two faces of a same coin.
The book is meant for everyone who is interested learning why organizations should have an incident response team and how to operate it. Similarly, it is targeted to vendors who would like to improve their handling of product vulnerabilities, and especially those who do not have any product security teams. But the book should also help security researchers and the general public to understand why certain things are being done and implications of not doing them.
Why did you decide to write a book on this topic?
There are multiple titles that have “incident response” in their titles, but they usually move to intricacies of forensics around chapter two, if not sooner. A handful of books dealing with incident response were published some time ago. My book offers up-to-date information and is focused only on incidence response, rather than forensics. Additionally, my book is not talking about mechanics of dealing with incidents—such as how to create a filter and apply it on a router. It talks about how to create and operate a successful incident response team which is challenge unto itself.
The second part of the book is about handling product security vulnerabilities. Again, the emphasis is to give readers understanding what handling product vulnerabilities is about, why vendors make certain decisions, and what influence these decisions. This is not rehashing an old and tired argument about full disclosure versus no-disclosure or what represent sufficient time for a vendor to fix a vulnerability. There are plethora of places where you can find all possible arguments on each of these topics, and most probably, each of us has already has a position on them. Instead, I approach vulnerability by providing a framework within which vendors operate.
What makes your book/product unique?
It is the way it covers incident response. All existing books are focused on the technical side of incidents, such as how to apply countermeasures, how to filter packets, what exploits are around, and how they look. That and forensics. A lot of forensics. Very little is being said about establishing and operating incident handling teams, and it is certain that we need more of them.
As far as product vulnerability handling is concerned, to my knowledge, this is the first text that addresses this issue in this manner. Again, there are multiple books that will tell you what are most common programming errors, how to use a programming language in a safe manner, and what are the consequences when a vendor does not design a product correctly from security perspective (not to mention numerous papers and presentation about specific vulnerabilities in a specific products). What I tried to capture is framework within which vendors operate and make their decisions. This is different from anything currently out on the market.
What is the most beneficial thing people should know about your book/product?
Most beneficial is understanding why things are done the way they are done. I am not expecting that people will agree with everything said in the book, but I firmly believe that the only way to find a common ground for discussion is to understanding position of the other side, what are their goals, and to know decision process that led to certain conclusions.
What is not covered in the book and why?
There are several areas that were not covered in the book; one of the biggest is the legal side of incident response and product vulnerability. One of the early drafts contained one chapter that was focused on the legal issues, but that would not do justice to the subject. There are so many new and exciting developments in legal aspects of incident handling and vulnerability handling that these aspects probably deserve a book on its own. People tend to equate legal aspects with boring, but they are very important for our jobs. It is always helpful to have at least a basic understanding of legal aspects as it helps in making the right decisions in our daily jobs.