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 help organize a small infosec meetup in baltimore called charmsec. If you are looking for charmsec details you probably want to go here.
RSS
Posted May 26, 11:59 AM by ben
This is a draft post I just ran across. I’m publishing it “as is” in case it may be useful to someone; sorry for the fragmented post.
Over the last year and a half (and arguably three) years I have been wrapping my head around tracking and reporting of incidents. This is an account of some the rules I have used up to this point. Some issues are easy, some are hard.
use a platform
KISS- stay away from complexity
treat it like an object:
enumerate attributes of incident
enumerate methods applied to incident
enumerate methods applied to a range of incidents
maintain confidentiality when possible; but don’t sacrifice usability if the risk to confidentiality is low.
understanding severities
I loosely based how I classify severities as to the F-scale tornado classification. The F-Scale is based on describing the damage done as opposed to describing the actual event. I feel this is an important distinction as you can’t realistically enumerate every incident/attack and doing so is futile. So don’t try. instead create attributes or characteristics that are important to you. Good examples of attributes: scope, activity, impact, loss. Based on the attribute, a qualitative decision is made as to the severity. There are also times when a certain severity is mandated. This is typically based on legality requirements. For example a loss of PII, or health records should be a threshold event that immediately creates a higher severity level.
create rules of engagement based on severity levels.
if you don’t know how many incidents were opened last week then you’re not yet successful.
utilize new stuff. Like tagging.
Do not reinvent the wheel. Utilize NIST 800-61 when possible.
Do not reinvent the wheel. Use existing platforms.
| tags (brainstorming, incident-handling)
This work by http://electricfork.com is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.