A security incident as defined in
NIST SP800-61 rev 1 is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. That being the case then triggered web filters, IDS/
IPS alerts, AV alerts, failed
login attempts etc all combined can easily add up to hundreds if not thousands, possibly millions of "incidents" a day within an organization.
Thinking that any and all incidents require implementation of an organization's Incident Response Team is impractical. So when does one call in the posse? Unfortunately the answer is not black and white because it varies from organization to organization. However below are what I believe to be very good guidelines on when to make that call.
I asked
Lenny Zelster via
twitter if he had an answer and he was kind enough to provide very good info on
his blog. By the time Lenny
Zelster posted I had already performed further research on my own and fell upon one of the same sources as he did,
NIST SP800-61. I will be using it as reference below; but I want to expound a little further on what
NIST provided as well what US-CERT.gov and CERT.org have to say.
Down to it. It is up to an organization to determine the best use of their resources and with that determine when an incident warrants implementing a formal incident response. In the private sector one may be thinking more in the terms of what QUANTIFIES ($$$$) a formal incident response over what QUALIFIES as needing a formal incident response; and that is fine as this may very well be step one in the categorization process.
Looking at what the US Government Does
Even a government entity understands that priorities must be set on when to call in the posse.
NIST itself suggests that minor incidents should be handled by basic staff instead of a formal response team.
I am a fan of ratings and categories because they provide fairly firm boundaries. I say firm because in the real world there is much gray. Ratings and categories help one determine what is not so important, what is important, and what is very freaking important!
First categories to create are IMPACT or EFFECT ratings. Many groups I have worked with in the past use Low Medium High.
NIST breaks it down a bit more as shown in the table below taken from their SP800-61 guide page 3-15.
Once EFFECT ratings have been established an organization should assign
CRITICALITY ratings which are typically based on system or processes affected. For example if
malware hits one system, is not spreading, and has been
quarantined by the AV program this may not warrant a formal incident response, if it is on a user's workstation; however, if it is on a payroll server then formalizing incident response may very well be implemented. This
NIST pub provides another nice table as an example on page 3-16.
NIST goes even further and utilizes the values it provides to determine an overall severity score
Overall Severity/Effect Score = Round ((Current Effect Rating * 2.5) + (Projected Effect Rating * 2.5) + (System Criticality Rating * 5))
The rating can then be compared to an incident impact rating chart also found on page 3-16
So based on the final score one will hopefully have the an idea of whether or not to call in the posse!
A little more from the US Government:
This does not directly pertain the
implementation of the Incident Response Team but I think it does add even more value to the fact that not all incidents are equal and thus the need for incident prioritization. The Federal Incident Reporting Guidelines from
US-Cert provides the table below for federal reporting time frames. Notice that some of incidents are reported on only a monthly basis.
So I hope this helps somebody out there get a grasp on incident response and prioritization,
else as Lenny
Zelster mentions in his blog "start panicking about every IDS or anti-virus alert, and you’ll not only develop hypertension, but will also waste the time of your staff."
Many thanks to
Lenny Zelster,
NIST, and
CERT.
.
