Friday, June 05, 2009

Information Security Incident Classification


Thank you to those who commented on my previous post on this subject. I've had a few people ask to use this chart, but I wanted to clarify a few items now that there has been some good public and private discussion about it.

My intention with this chart is to help classify an incident involving compromise of an individual system. There are plenty of other sorts of information security incidents, but at the moment this is the biggest problem I deal with on a daily basis. I need a way to talk about the state of an individual compromised asset. I found the traditional DoD Category system wasn't sufficient, especially in the post-Cat 1 world. I still like those Categories but I needed to go further (post-exploitation) and for one of my constituents, backwards (to when a system is just vulnerable, but no one is yet interested in it -- as far as we can tell).

I decided to call this updated chart a "classification" rather than a "rating," and to remove the label "impact." The words rating and impact imply "risk" and asset value to some degree, and I'm not talking about either here. This is a little bit like assigning a CVE number; it says nothing about the seriousness of the vulnerability, but at least we can all reference the same vulnerability. With my chart I can now build service expectation timelines around the incident type. I can also quickly understand where we are with any incident when one of our team says "we have a Cat 1, but our perimeter defenses appear to have contained the incident so it has not reached Breach 3 status."

I think it is important to keep in mind that having anything remotely approaching a valid understanding of "risk" requires a great deal of understanding about the assets in question. Not only must you understand the nature of the compromised asset (its function, normal usage patterns, its inputs, its processes, its outputs), but you must understand the means by which the asset interacts with the network, any trust relationships, and many other factors. In most cases the only way to gain a real appreciation of these real-world conditions is to either 1) observe the intruder in action, seeing what he can do or get, or 2) red-team the system yourself to see what you can do or get. Modern systems and enterprises are far too complex for anyone to sit back like Mycroft Holmes and truly understand the "risk" of a compromise.

I should also say that I would never expect to tell a manager that we have discovered a Breach 2 and then walk away. The natural next question involves the issues of the previous paragraph, and answering them takes far longer than the process of detecting and validating the incident. If you doubt me, try talking to the office in the DoD that does nothing but computer incident damage assessment all day long.

Incidentally, please feel free to use this diagram, providing you cite the source. I am encouraged when others seek to adopt this sort of language for their own programs, because it moves us closer to having common ways to discuss operational problems. Thank you.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

No comments: