What's in an Incident Response Plan?

Another data breach case caught up in the daily news. Uber has made a name for itself with its loss of 57 million user (including driver) records. Not surprising. This is a vicious cycle. Users demand faster and easier access to more online services on the move. Providers have to catch up to deliver and push for more of their brick-and-mortar service into online service to meet the demand. That makes them susceptible to cyber attack when no proper security measures are put in place. 

Face the Hard Truth

That said, we have to accept the reality and face it.

1. There is no silver bullet in this cyber world. When an incident happens, will you be prepared? In Uber's case, they knew about the incident but had not reported it and even paid the hackers to delete the data leak and be silent on it. This is a bad practice. 
2. You do not have the luxury of time. When incidents happen, how effective and systematic is your response? Incident management has a gamut of things that need to be done -- before, during, and after things have happened. It cannot be left to assumption. It is a "when" and not "if" mindset to better manage incident and response promptly. 
3. It is becoming more difficult to prevent incidents from happening. When incidents happen, do you have a playbook to manage the attacks? You need to be vigilant about the security events and identify the "culprit(s)". This may include an insufficiently resourced online service under denial of service attack to a phishing email that spoofs and tricks user to siphon off credentials and sensitive data. 

There is a need for a systematic incident handling framework to contain and reduce the impact and eventually restore normalcy from the damage loss with effective controls in place. More importantly, get yourself familiarized with the incident management lifecycle -- it is self explanatory. 

Do the First Thing Right 

Coming up with an incident framework is no easy feat and effort to develop this "bible" will be non-trivial if there is no starting template or guidelines for the organizations to reference when trying to implement the right incident management process for their environment.

ITIL has a good incident management framework worthy of consideration, especially for those who like to have a preview of what needs to be done to be ready when an incident happens. This wiki site has a good run-through and checklist templates that will come in handy. 

Even with the right framework in place as a governance, you still need to make sure an execution plan is in place. You will need to follow the plan diligently in the event of an incident, as it covers the key incident response procedures. Here is the suggested baseline for your plan:

1. Objective & Scope of the response plan (targeted audience, type of incident covered)
2. Role & Responsibility of the actors (incident team, system owner, management committee, authority)
3. Reporting & Escalation Workflow (entity involved, triage activities, severity of incident, timeline for activities)
4. Playbook Guidance (step through on various common incidents and action taken)
5. Media Handling (public communication, prepared statement in event of leakage or further damages)
6. After Action Review (processes to identify learning and review the plan and policy, conduct of user awareness)
7. Annexes (contact list, security policy and standard, Reference to IETF like  2350 Expectations for Computer Security Incident Response, PGP keys for information exchanges, Cue card version of playbook)

Build the plan details with the actual procedure that will be executed by your staff and peers. In the annex, you can find a high-level sample "plan skeleton" that covers a compilation of the scope to be covered under each section. As mentioned earlier, try to leverage the template in the wiki site.

How to Bring This Forward

Start to impress your management board and stakeholders on the work you are doing to build the organization incident framework and plan. Also include the governance process that you should introduce. It is not a once-off planning session. For example, with any update to the framework or plan, the approval process will kick in to maintain the required management oversight. A regular update session regime and change process need to be in place. With a proper set of procedures in place, you can assure the stakeholders that if the business gets hacked one day, the efforts in developing these sets of procedures will pay off. 

Lastly, as organizations expand and people's roles change, it's essential that documentation related to who is involved in incident response activities is updated to reflect these changes. You also need to set aside time to recommend and build the incident response team. Without a dedicated team, all the discussed strategy will just be "paper talk". If there is no capability for an in-house team, get external incident response support from other providers.

Good luck in the planning! 

============================================================

Annex - Sample format of incident Response plan

============================================================

Objective

This section should be short stating the plans requirement to align all incident handling procedures within the organization for timely response and containment. In addition, the plan also serves to inform the audience of the reporting and escalation requirement based on the severity of the incident.  

Role & Responsibility

This section covers mainly the External and Internal parties

• External - Security authority in your organization and Internal Computer Emergency Incident Response Team (CERT from FIRST)
• Internal - Security Response Officer and Manager, Chief Information Security Officer (CISO) and Security Operation Team

Define their responsibilities in terms of the areas they are in charge of and what to act on during the incident, like CISO will oversee and update senior management on the organization incident reported, supported by the incident manager's update. Keep it concise. 

Reporting Structure

This section covers the following escalation levels and SLA for response, based on severity 

• Workflow of the incident handling by the manager and the activated team for remediation
• Business impact of the confirmed incident 
• Classification of the system and asset affected
• Severity of the incident and stipulated SLA for onset report, daily sitrep till gap is addressed for case closure 

Playbook (handling of various cases)

This section covers the steps through the incident's onset, containment, and remediation phases as well as the eventual recovery stage to return to original state before the incident. Below are common cyber incidents which the plan should cover at a minimum.

• Ransomware
• Malware Infection
• DDoS attack 
• Loss of Equipment 
• Website defacement 
• Fake or Phishing Website 
• Phishing email and scam

Media handling

This section will cover the necessary public statement to be prepared by the corporate comms team in the organization. 

• In the event of Personal Data leaks due to compromised assets or abuse by internal or external personal 
• In the event of a faked website that masquerades as a scam and phished site 
• In the event of outage or unavailability of the main corporate website 
• In the event of monetary loss by affected customer due to use of compromised e-Service 

After Action Review

This section mandates the necessary activities to identify the learning points and review the plan to improve the handling procedures. It is important that the effectiveness of the response procedure is regularly reviewed from each incident closure reporting. 

• Conduct regular incident exercises to assess the procedure's robustness as injects are introduced. 
• Carry out ‘post-mortem' reviews where the response team can identify and build upon the response activities that worked well.  It can also spot and remediate any processes in need of improvement.

Annex

This contains an Incident Report Template with the following fields:

• Incident ID (e.g. unique to incident which can be based on DDMMYYYY-<Incident type#>-<Incident Count#>
• Reporting Party (e.g. Who is reporting and When the incident is detected)
• Incident Type (e.g. selection from the list in the playbook)
• Affected Party (e.g. asset/type, personal and dependencies implicated)
• Incident Severity (e.g. category level High (1), Medium (2) and Low (3) business impact)
• Incident details (e.g. root cause, timeline of event and activities covering before the incident is detected until it is reported to authorities)
• Action Taken (e.g. Containment measures and mitigation steps take to reduce the exposure, include timeline if available)
• Signed off (e.g. Acknowledgement can be via email receipt)

And also contains Situation Report Templates: 

• Incident ID
• Reporting Party (e.g. Who is reporting and When the incident is detected)
• Current state of affected party (e.g. any further damages or losses)
• Follow up action (e.g. status of the containment, brief analysis summary of the root cause and outstanding actions)
• Signed off (e.g. Acknowledgement can be via email receipt)

=======================