Incident response success in five quick steps

It's amazing that monks can stay calm and "in the zone" at all times under any circumstance. But they don't get there overnight; it takes practice, years and years of dedicated practice. It also takes discipline, and that is what really separates the enlightened from the pretenders.

Of course, by now you're wondering, what does this have to do with security? The reality of being a security professional is that being compromised goes with the territory. Maybe not today, maybe not tomorrow, but at some point, a compromise will happen, be it the result of a flawed Web application or a malicious insider, and most practitioners will not be ready. Instead of relying on a pre-established, rock-solid incident response plan, the security manager will panic, bungle the response and eventually start looking for a new job, because it's almost impossible to recover one's reputation internally once a major incident occurs and isn't handled properly.

But it doesn't have to be this way. It is possible to be calm in the face of a towering inferno as long as the incident response plan is well-defined and ensures that organizational data remains safe, while containing any damage. There are a number of steps that any security manager can take today to ensure that their organizations are ready when that very bad day inevitably arrives.

Step 1: Write down the plan
A lot of practitioners have an incident response plan, but it resides in their heads. That is not good enough. Practicing the steps while on the treadmill? Not good enough either. The plan needs to be communicated more broadly than the family dinner table, and that means writing it down, sharing it with colleagues, r

To continue reading for free, register below or login

Requires Membership to View

To gain access to this and all member only content, please provide the following information (all fields required):

First Name:
Last Name:
Country: Select... Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Congo, Democratic Republic of Cook Islands Costa Rica Cote D'Ivoire Croatia Cuba Cyprus Czech Republic Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Gambia, The Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard and McDonald Islands Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Korea, North Korea, South Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macau Macedonia Madagascar Malawi Malaysia Maldives Mali Malta Man, Isle of Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia Moldova Monaco Mongolia Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island Northern Mariana Islands Norway Oman Pakistan Palau Palestine Panama Panama Canal Zone Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Romania Russia Rwanda Saint Helena Saint Kitts and Nevis Saint Lucia Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia and Montenegro Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and South Sandwich Islands Spain Sri Lanka Sudan Suriname Svalbard Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand Timor-Leste Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu U.S. Minor Outlying Islands Uganda Ukraine United Arab Emirates United Kingdom United States Uruguay Uzbekistan Vanuatu Vatican City Venezuela Vietnam Virgin Islands Wallis and Futuna Islands Western Sahara Yemen Zambia Zimbabwe
Email Address:

I would like to receive a FREE subscription to Information Security magazine online.
YesNo

Do you manage, evaluate, recommend, implement, support or purchase security products, software or services?
YesNo

Please estimate the yearly security budget for your entire organization including all security products and services.
Please select... Over $10 Million $5 Million-$10 Million $1 Million-$4.9 Million $500,000-$999,999 $100,000-$499,999 $50,000-$99,999 $25,000-$49,999 $10,000-$24,999 Less than $10,000 None

What is your role in purchasing IT related products and services? (Check all that apply)
Technical decision maker
Financial decision maker
Recommend/Specify
Evaluate products
Implement Products/Services
Determine Needs
Create Security Strategy
None

By joining SearchSecurity.com you agree to receive email updates from the TechTarget network of sites, including updates on new content, magazine or event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile or unsubscribing via email.

TechTarget cares about your privacy. Read our Privacy Policy

The document should lay out exactly what will happen in the event of an incident. It needs to specify accountabilities, escalations, and if/when to bring law enforcement into the picture. If it's not written down, it might as well not exist, because not only could something happen to prevent you from being in position to respond during an incident, but a good incident response plan is also one that all parties are familiar with long before an incident occurs.

Step 2: Get buy-in
Once the plan is written down, it needs to be circulated amongst the organization's internal IT power brokers to make sure that everyone understands the document the same way and knows their responsibilities. Of course, that includes the CIO, since an incident may involve taking systems and/or networks out of service. Appropriate response tactics need to be discussed and accepted before the incident, or be ready to suffer the consequences of mismanaged expectations.

Don't forget about other members of the senior team as well, especially human resources and the general counsel. In the event the incident results in a legal prosecution, both of those individuals will be able to determine exactly what data needs to be gathered and how the response and other personnel action need to play out.

Step 3: Understand escalation
I mentioned escalation above, but it's important to get a little more specific. The first thing to determine is the notification process. Who gets called and when? Under what circumstances is the CIO, CFO, CEO, etc. brought into the situation? When should they be awakened in the middle of the night, if ever? The time to find out that the CEO doesn't care isn't at 3 a.m. when she's chewing your ear off for disturbing her beauty sleep.

It's also important to make sure that the level of acceptable damage control is specified. If a key customer-facing application may be compromised, is an out-of-band investigation conducted, or is the application taken down? Who should be making that decision? Odds are it's not the security professional, but having someone accessible at all times to make those kinds of calls is absolutely critical.

Step 4: Practice, practice and then practice some more
When was the last time your enterprise conducted an incident simulation? Most organizations answer that question in years, if ever, and that's a problem. The fact is every organization has a dynamic workforce, set of trading partners, application base and lots of other things changing at all times. That means the incident response plan needs to be a truly living document. It needs to change when the business changes and those changes need to be reinforced though practice.

I know that it may be a challenge to get the troops motivated about incident response simulations when it's far from the real thing, but it's important. Major mistakes can be made or time lost when an enterprise fails to realize there's a gaping hole in the plan until an incident occurs. Remember, optimally a lot of the responses under duress are conditioned responses, and they only get that way through practice and repetition.

Step 5: Learn from mistakes
Even the best, most field-tested security professionals mess things up, especially in the middle of an incident. That's why besides containing the damage in real time, doing a detailed post-mortem is the most important aspect of the process. Everyone makes mistakes, but hopefully not the same mistakes more than once.

Unless a concerted effort is made to understand the nature of the incident, what went wrong and what will be changed moving forward to ensure it doesn't happen again, history will repeat.

So, swallow a bit of pride, dig deep into the incident and make whatever process changes are required to ensure the same incident doesn't happen again. This type of post-mortem is also invaluable during an audit, so show the auditor how the organization recovered from an incident and learned from it.

Remember, the difference between someone that is perceived to be a hero in a tough situation and a goat looking for his or her next job is all about how the incident is handled. Follow these five steps and security professionals can live to fight another day.

About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com's expert-in-residence on information security management. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at) securityincite (dot) com.

Rate this Tip To rate tips, you must be a member of SearchSecurity.com. Register now to start rating these tips. Log in if you are already a member. BROWSE BY TAG Compliance Counselor,   Network Intrusion Detection and Analysis,   Enterprise Network Security,   Information Security Incident Response,   Information Security Policies, Procedures and Guidelines,   Information Security Management,   VIEW ALL TAGS Digg This!     StumbleUpon     Del.icio.us    RELATED CONTENT Compliance Counselor Common PCI questions: Web application firewalls or source code review? PCI management: The case for Web application firewalls The basics of enterprise GRC project management PCI DSS: The structure of a standard How to choose between source code reviews or Web application firewalls HIPAA compliance: New regulations change the game Data security best practices for PCI DSS compliance Key elements of a HIPAA compliance checklist A preview of PCI virtualization specifications Strategies for email archiving and meeting compliance regulations Information Security Incident Response Tying log management and identity management shortens incident response Tabletop exercises sharpen security and business continuity Security book chapter: Applied Security Visualization The challenges of incident response plans and procedures CISOs, human resources cooperation vital to security After a data breach, are there legal implications of sharing details? Boosting morale of the information security staff after a data breach Recovering stolen laptops one step at a time IT security pros face challenge during economic crisis Spotlight article: Domain 9, Physical Security Information Security Incident Response Research Information Security Policies, Procedures and Guidelines Twitter risks, Facebook threats trouble security pros Cybersecurity czar candidate questions clout of new position Incident response planning The basics of enterprise GRC project management RSA council addresses growing security risks in the cloud How to write a risk methodology that blends business, security needs Risk management must include physical-logical security convergence DHS fills National Cybersecurity Center post New partnerships, creative thinking help security bust recession Experts optimistic of Obama cybersecurity plan RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary incident response  (SearchSecurity.com) RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.