Failing to map out a plan of action can have dire consequences in both our personal and professional lives. Professionally-speaking, have you thought about what you would do in the event of a security incident? No, I’m not talking about a physical security issue but rather a computer security issue — there’s a big difference.
Incident response in the IT realm is often overlooked. People will claim that they have a business continuity or disaster recovery plan, but that’s not what “incident response” is about. The essence of incident response is to provide clear and succinct instructions for countering hack attacks, malware outbreaks, employee computer abuse, loss or theft of mobile devices and the like. The overall goals are to protect sensitive electronic records, maintain uptime and properly preserve evidence to assist with any formal investigations and subsequent prosecution. It could be argued that incident response is part of the business continuity process, but technically there’s a difference, and it needs to be treated as such.
Incident response is advance preparation for a situation where you will not have time to learn as you go along. In terms of IT, the incident response process consists of:
• Implementing the proper tools and processes to help with visibility into the network;
• Proactively monitoring for incidents;
• Quickly containing known incidents;
• Cleaning up the situation; and
• Learning from each incident and the response process and moving forward.
A key part of incident response is the assumption that not all incidents are going to be highly visible. Many things that can get your business in a bind aren’t going to be immediately obvious such as:
• A trusted employee exploiting intellectual property or sensitive client data by e-mailing it to his personal e-mail address or copying it to the storage card on his trusted smart phone.
• A visitor to your building using your guest wireless network for illicit purposes.
• A hacker who has captured login credentials from an unsecured wireless connection or from a lost or stolen laptop who is masquerading as a legitimate user of your ERP system.
• A rogue employee using the default user ID and password to log into the Web interface of your CCTV surveillance system and deleting all the logs and digital video recordings.
• A phishing attack that leads to workstations on your network becoming part of a botnet.
• A malicious contractor using a vulnerability scanner and an exploit tool to gain unfettered admin-level access to your Windows-based servers that are not up-to-date on patches.
Even the best of traditional computer security controls will not detect or prevent these threats. Arguably, much of this could occur on networks that are “completely locked down” in the eyes of management.
The biggest mistake regarding incident response is not having a plan. A solid incident response should consist of:
1. An introduction outlining what the plan is about and what it covers.
2. Incident preparation steps you have taken.
3. Incident detection and containment process.
4. Incident eradication and recovery process.
5. Incident follow up to minimize re-occurrence.
6. Appendices such as a calling tree listing key employee and vendor contact information, testing logs and document revisions.
That’s all there is to an incident response plan. Of course, like policies or other living documents, your plan needs to be continually updated in order to remain effective.
The second biggest pitfall is not learning from your mistakes when an incident occurs. If you value something and understand the risks, you will do what it takes to put together a reasonable plan to minimize your losses. Be it in your personal life or in your business, mapping out a response plan is essential if you want to minimize the impact of the situation.
As U.S. Airways Captain Chesley Sullenberger said about landing his plane in the Hudson River, “I didn’t have time to learn what I needed to know...I had to have done hard work for decades for tens of thousands of hours to prepare for that moment.”