Top incident response steps: Incident response team responsibilities

Information security breaches are a sad fact of life for businesses of all sizes; just ask Sony or Epsilon.

Driven by increasingly sophisticated exploits and a highly determined cybercriminal underground, these breaches can cost a business more than just sensitive data: The reputational loss can be far more damaging to a bottom line.

Formalising how to deal with a data security breach not only prepares the organisation for the worst, but can actually decrease the likelihood of the company becoming yet another attack statistic in the first place.

This two-part guide to incident response looks at the top incident response steps organisations should take if and when security breaks down and a breach occurs, starting with risk analysis, incident response plan creation and testing, breach detection and threat neutralisation.

1. Know your data and identify what is at risk.
The first step toward dealing with a data breach should be to ensure the company actually knows what data it has, and what data is most at risk of compromise. Use existing business impact analysis and disaster recovery reports as a baseline for data classification and location efforts.

However, there is more to risk analysis than just knowing what data needs to be protected and where it is located; there are also people and processes to consider. Think of risk analysis in a holistic fashion, and perform a high-level risk assessment to identify where any weakness in security may be found. This kind of threat assessment is best handled by an external third-party consultancy so internal politics do not cloud the real issues.

2. Create an incident response plan.
Once you know what data needs to be protected, create an incident response plan that will enable your organisation to best deal with any breach that should occur.

Having a structured methodology to respond to an attack not only ensures less panic and a better application of available resources during a time of great organisational stress, but can also help reduce reputational damage. The plan should be updated annually and should enable the business to identify, investigate, neutralise and notify in a managed way, be it concerning a denial-of-service attack, website defacement or a full-on, large-scale data theft incident. Every incident response plan will be different, dependant upon the data the company handles and the business sector it operates in, however, some basics are common to all:

• Create a multi-faceted response team, comprising named individuals with the power both to make immediate managerial decisions and the technological skill to deal with the threat on the front line. The plan should include emergency contact details for all team members, as the bad guys do not necessarily work office hours.
• Define how to handle emerging threats: Who should be notified and in what order for different levels of a potential breach?
• Develop a protocol for forensic collection and preservation of evidence during and after a breach, otherwise prosecution of perpetrators will be impossible. Also, consult the legal department in order to ensure evidence is collected properly, so as to be admissible in court; more on this to come later.
• Develop a protocol for disclosure to customers and media, and prepare notification templates.
• Prepare a disclosure timetable for other interested parties, such as law enforcement, business partners and banks.

3. Put your incident response plan to the test.
Having an incident response plan is pointless unless you know it is going to work. Using it for the first time during an actual breach is not a good idea; without testing it beforehand, it is impossible to know if the plan is practical or whether key steps are missing. Thus, make sure the organisation implements a testing schedule that will allow it to identify problem areas and remedy them quickly.

The plan should clearly indicate incident response team responsibilities, and members should not only practise plan implementation across various scenarios, but also these should always be time-limited to simulate the stress conditions they will face during a real incident. Ensure contact details for team members go beyond office and home numbers: Think in terms of email, conference call details, bridge lines, mobile numbers and so on. If your response team cannot be contacted, your plan cannot be implemented.

In addition, do not forget about documenting the need to document! Spell out what will need to be documented -- such as how the incident was discovered, by whom, the type of incident, attacker information, how the response plan was implemented, whether it was effective and, if not, what was done post-breach to correct those failings.

As well as instilling the confidence that comes with knowing the plan will work, such testing helps satisfy regulators that the organisation has met any data security compliance requirements by having an incident response policy that is properly implemented and properly written.

4. Be properly prepared for breach detection.
The biggest problems occur when a data security breach goes unnoticed for days or even weeks, providing the hackers with multiple opportunities to return and wreak even more havoc.

Do not rely solely upon technologies to detect a breach. Ensure the staff is trained to spot a potential breach, which could be as simple as reports of files that cannot be accessed or servers running more slowly than usual. A procedure to report these symptoms to the systems security team should be put in place, as well as further protocol regarding when to contact the incident response team if the symptoms warrant it.

5. Neutralise the threat quickly.
At the risk of stating the obvious, it is key to neutralise the breach threat as quickly as possible. Unfortunately, unless the incident response team has been authorised to do so, it's likely this will not happen.

All too often, the best-laid incident response plans fall apart while waiting for managerial approval regarding what action should be taken. The company has selected a response team for a reason: to respond to and deal with a breach. So ensure it has the authority to quickly implement the actions it deems necessary. Getting management to relinquish any responsibility will always be difficult, but it's often effective to speak in terms of the business, and money, that could be lost by delaying response to an incident in order to get approval from every possible stakeholder. Perhaps the easiest option, though, is to create a truly multi-departmental team consisting of at least one senior manager or director as well as technical experts.

Follow us on Twitter and we'll let you know when part two debuts.

About the author:
Davey Winder has worked as a freelance technology journalist for nearly 20 years. He is based in South Yorkshire.