“You MUST have an incident response plan!!!” Thus screamed plenty of security incident response guidance, including some of my own.
However, whatever happened to “no plan survives contact with the enemy” (a classic version of a quote from Helmuth von Moltke)? Aren’t plans useless because of that?
Still, if you think Sun Tzu trumps von Moltke any day of the week, then how about “the general who wins a battle makes many calculations in his temple before the battle is fought “ (quote from Sun Tzu, who also said that “the enlightened ruler lays his plans well ahead”)
The enlightened reader should be reaching this “Aha!” moment right about now: PLANS can be useless, but PLANNING is golden! A process for “laying plans” and “making calculations” is a secret of winning (well, not losing), and having a printout of your plan in hand won’t do the trick.
Security incident response planning is an activity, a process, a verb (if you must). On the other hand, a plan is a piece of paper, as useless as …eh… a security policy that is not tied to monitoring and enforcement.
Even PCI DSS, occasionally a source of useful security wisdom, has this to say about security incident response planning (Requirement 12.5.3, 12.9 and others):
“12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.”
“12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.”
(it does NOT say “download a stupid IR plan template from some shady site and then go to sleep until CNN announces a breach at your site”, in case you are wondering!)
On top of this, QSAs are told to “review documentation from a previously reported incident or alert to verify that the documented incident response plan and procedures were followed.”
By the way, PCI DSS also states that an organization must “test the plan at least annually” (Requirement 12.9.2). Even if life tests your plans more often than that (which is extremely likely nowadays), a dedicated test of response workflows and activities, especially for the types of incidents common in your industry, but not yet incurred on your organization, is an extremely worthwhile endeavor…
Finally, incident response planning is something even ostriches with their heads in the sand must do: if you make a concerted effort to avoid security monitoring (in order to avoid detecting an incident and thus incurring extra work), an incident will likely come your way anyway! After all, doesn’t Verizon breach report say that most incidents are detected by 3rd parties? Therefore, you need to plan on how you will respond to an incident that happened a year ago…
Posts related to the same research project:
- On Importance of Incident Response
- Is That An Incident In Your Pocket – Or Are You Just Happy to See Me?
- Time-tested Incident Response Wisdom?
- Incident Response: The Death of a Straight Line
- Alert-driven vs Exploration-driven Security Analysis
- My Next Research Area: Incident Response
- All posts tagged security incident response
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
5 Comments
Hi,
Thank you for making the point about value of plans verses planning.
A couple of observations:
1. Large (hierarchical) organisations often place all the value on the plan. The bigger more detailed the plan, the more valuable it is to the organisation.
2. These organisations often view planning activity as the cost of producing a plan. Costs are minimized as much as possible.
3. Small adaptive organisation often realise that there is little value in the plan itself.
4. Unfortunately, these adaptive organisations often “throw the baby out with bath water”. If the plan is not useful, then the process to produce the plan is waste of time an effort.
The value placed on plans and planning can be informitive about the organisations overall.
Some militaries use the term “appreciation” to refer the process of assessing and understanding the possible options.
Kind Regards,
Alex
Alex, thanks for your really insightful comments. Indeed, plenty of orgs under-do planning while others over-do the plan creation.
Incident Plan? Incident Planning?
why to oppose? I’d combine both 😉
As we all know, the key idea is 1) to think *before* and then 2) prepare as possible – 2 parts, 2 steps.
therefore implement results [of thinking] as a response + workflow for your DLP / Incident Mgmt engine to support the what’s required right after is extremely demanded:
1) immediate / automatic response [might be [sub] workflow as well, though]
2) workflow to support whole investigation process as required, with 1) as a trigger for 2), if you wish [might take month(s)]
I mean, we found very promising idea that *whole* chain
Incident – Investigation – Measures – [measures] Execution Control*
must be covered and supported by the *one* tool [chain]
* KPI is a bonus
PS here is short video at http://www.youtube.com/watch?v=pnqhAr2uUIM to illustrate Incident Management and Response/Workflow using Data Luxury Protection on the endpoints, end users view.
@valery Thanks a lot for the comment. Indeed, the “opposition” was a bit false and artificial. You do need A PLAN and you do need TO PLAN.
BTW, thanks for the video link – will look at it.