electricfork

Defining incidents

Posted Dec 13, 12:02 PM by ben

Richard’s post inspired me to rant about how I’m approaching the same problem. Previously I’ve seen systems and processes so overly complicated and detailed that they simply were not used or acknowledged. I sat on this for a while; not liking what was out there. I’ve began throwing ideas around based on the Tornado Fujita Scale. While the Fscale itself has specific measures (wind speeds) it also has outcomes and descriptive phrases (An F6 tornado is “Inconcievable”, how cool is that?). Currently I have it down to:

Level Distinction
0 Disruption
1 Loss of Information
2 Loss of Positive Control
3 Impact to Business
4 Black Swan

I then matrix each of these with Types of Incidents: policy violation, malicious code, DoS, unauthorized access, other. Each of these give a basic guideline (not a rule or requirement) for each level of distinction. In the case of Malicious Software, for instance:

level Distinction Example
0 Disruption Spyware, one-off infection, phishing attempt
...
2 Loss of Positive Control Active Command & Control channel
...
4 Black Swan A TJX scale of infection that I can’t or wont dream up

Each of these levels will eventually have their own expectations on response and rules of engagement. I don’t foresee a Level 0 (disruption) as necessarily being court admissible. This rules out chain of custody, forensics etc while a level 3 (impact to business) may very will have such expectations.

I like the guidelines approach, as the usage builds over time then I expect organic growth of the system to begin diving into specifics. But any initial scheme will go through maturation and not trying to create a complex framework will lead to a slower adaptation.


// :: /

Comment

Commenting is closed for this article.

Creative Commons License
This work by http://electricfork.com is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

archive

about

charmsec

I lead an information security ops and response team. This site is a collection of interesting notes and brainstorms on the protecting from, detecting of, and responding to badness. You can read more about me or my site here.

You can subscribe to my blog via rss , or if you're looking for older items check out my archive of previous posts.

I organize a small infosec meetup in baltimore called charmsec. If you are looking for charmsec details you probably want to go here.

 

RSS

:: © 2002-2008