|
The short answers to your questions are "Yes," "Not too much detail," and "Yes." Let me explain.
The typical incident handling team gets reports of all kinds of anomalies, ranging from missing files all the way up to complete compromise of vital servers. Additionally, based on these initial reports, the team may investigate and formally declare incidents for some of them, while determining that others are mere user mistakes with no actual attack underway. To help sort out all of these reports and incidents, a team should have an incident severity rating that will help guide the organization on the time sensitivity, priority and management attention needed for various issues. We simply cannot treat every incident with the same level of urgency and attention, because doing so is a waste of resources. Even if an organization doesn't have a formal priority scheme, employees will likely work from gut instinct, informally determining which issues are the most important. The problem with working from the gut is that management and others on the incident handling team may have different perceptions and expectations regarding priorities, which could lead to confusion and people dropping the ball. Thus, I heartily recommend that companies formalize an incident severity rating system.
However, I don't think such a system should be too detailed or have too many fine-grained levels. I find that three or four levels make the most sense, and have seen such systems work very well in many enterprises. The bottom level could be an isolated infection, such as a malware alert from an anti-virus tool, which was cleaned up by the AV tool itself, reported on a weekly basis. Then, employees could get to a moderate attack that exploits two or three systems, but can be quickly and easily cleaned up by manual uninstall or related activity, perhaps reported daily. Important attacks might be associated with an attacker who has gotten control of several machines, interacting with them in a real-time basis. Because of the risk of further compromise and embarrassment, employees should respond to such incidents very quickly, perhaps within an hour or two. And, at the top of the chain, would be critical incidents, which require immediate attention because of their severe financial impact, reputation damage or regulatory implications. Thus, organizations define at a moderate level the impact associated with each level, as well as the timeframe for notification and response.
Note that the severity initially assigned to an incident may change as it is investigated. Its severity may be increased or decreased depending on the facts. Such changes shouldn't be discouraged, as they are a reality of how our investigations proceed. A change in severity is an important signal to management about the status of the given incident.
To help sort this out, Richard Bejtlich, a brilliant security practitioner and researcher posted a framework with eleven questions to help incident handlers discern the severity of an incident on his blog in December 2007. I recommend reviewing his questions, tweaking them to support your organization's specific needs, and then define three or four categories as I've indicated above based on the answers to Mr. Bejtlich's questions.
More information:
|
