How to Develop An Incident Response Checklist for Your SaaS Business

Earlier this week, we published a post that explains how to develop an Incident Response Plan (IRP) to prepare for when an incident inevitably impacts your SaaS business. In addition to having an Incident Response Plan that identifies your critical systems, data, risk profile, stakeholders, and so on, it’s vital to have an Incident Checklist that lays out the main action steps to take when an incident actually occurs — thereby ensuring that you’re able to respond, stay on track, and address priorities in a thorough and logical fashion.

With that in mind, this post tells you what to include in an Incident Response Checklist by outlining the main steps and action items you should take from the time you first become aware that an incident might be occurring, through the subsequent investigation and remediation stages, and on to the post-incident phase where you focus on making improvements that will help you handle future incidents more effectively.

As you continue reading, you’ll see that this five-part checklist is by no means complete. Rather, it’s a starting point that you can build on to create a checklist that’s specifically suited to the unique nature of your organization’s culture and environment.

1. Investigate and Gather Intelligence

Purpose: To gather information that will help you understand the incident and devise a plan for immediate containment.

1. Record the date and time when the first signs of a problem appeared or the time the breach was discovered.
2. Check old support tickets around random outages or system performance issues, which can be signs of a problem.
3. Check your security systems for any alerts that are linked to suspicious behavior.
4. Interview anyone who has critical knowledge of the potential breach or witnessed any issues related to it.
5. If necessary, bring in a forensics investigator to help your core team with the investigation.

2. Contain the Incident

Purpose: To bring about immediate containment of the incident and also determine immediate follow-on steps.

1. Establish a security perimeter around any systems believed to be part of a breach (for example, take a cloud instance offline or remove it altogether, or change the VPC) to avoid potential exposure and possible spread.
2. Get forensics personnel or your Operations team to make a secure copy or snapshot of the affected systems so they can be replaced without compromising the manner of the breach.
3. Discuss additional action items that must be undertaken in the immediate future to contain the incident.

3. Engage Stakeholders

Purpose: To provide technical, business, and other stakeholders with the information they need to understand the incident and/or take appropriate action.

1. Notify key incident response stakeholders or executives that an investigation is underway.
2. When additional facts are obtained, brief key stakeholders (for example, executives, HR, legal, compliance, public relations) on what you know and don’t know.
3. In consultation with the stakeholders, determine the next steps to take. Note: If you suspect that a system has been hacked, do not make public statements until forensics can determine that an unauthorized incursion has occurred. A false alarm will likely damage your business’ reputation as well as the confidence of your customers.

4. Communicate and Resolve

Purpose: To meet compliance requirements, notify affected parties, and implement long-term, comprehensive corrective action.

1. If a breach is confirmed, follow compliance protocols to notify appropriate parties within the required timelines (for example, 72 hours for GDPR), including customers, partners, law enforcement authorities, or the media.
2. Communicate the nature of the breach to any affected internal and external parties, and make credential or system changes that are needed to remediate the problem.
3. After the incident is resolved, place affected systems back into production, monitoring them carefully for any follow-up incidents. Continuously validate that these systems and their dependencies are operating normally.

5. Review, Revise, and Improve

Purpose: To make ongoing improvements to your Incident Response Plan and Checklist.

1. After an incident, conduct a postmortem with your key stakeholders to review your end-to-end response process and to identify what worked and what could be improved in order to more effectively manage future incidents.
2. Any time you make significant changes to policy, technology, and/or operations, make appropriate changes to your response plan and checklist.
3. Conduct regular, periodic reviews and tests of your response plan and checklist, make modifications as necessary, and refine your best practices.

Final Words . . .

Preparing for the inevitability of a security incident is a requirement in today’s cybersecurity landscape. However, you can ease the burden this presents by incorporating security early into your processes to ensure that systems are configured properly, that applications are developed securely, and that your environments are being managed and monitored proactively.

To find out where your organization stands in terms of security maturity, and how Threat Stack’s Cloud SecOps Program can help, take our assessment today.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Christian Lappin. Read the original post at: https://www.threatstack.com/blog/how-to-develop-an-incident-response-checklist-for-your-saas-business