Incident Plan vs Incident Planning?
Original URL: http://blogs.gartner.com/anton-chuvakin/2013/07/23/incident-plan-vs-incident-planning/ | Archive.org Snapshot
“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