An incident response policy is a documented step-by-step plan for the role of personnel and technologies in the aftermath of a cybersecurity incident. The policies should be specific, tailored to the types of assets your organization has, and crafted according to best practices as laid out by entities like NIST.
Ever received a lengthy security questionnaire from a potential customer?
Your organization’s incident response policy is one area that security questionnaires may focus on. Here are several questions you may find on a security questionnaire on this topic:
- Does your organization have documented incident response plans and processes?
- How quickly do you aim to respond to security incidents, and what factors influence your response time?
- What roles and responsibilities are defined within your incident response team?
- Can you outline your process for containing and mitigating security incidents?
These are just some of the questions you may see on a lengthy security questionnaire. Additionally, under SOC 2, Incident Response & Business Continuity/Disaster Recovery appear throughout the criteria all organizations must meet (the Common Criteria) regardless of the selected Trust Services Criteria.
This article will give you the tools to develop a robust incident response policy or to assess the strength of your existing policies and ensure they will hold up under scrutiny from potential customers, partners, and other stakeholders.
What Is The Role of An Incident Response Policy?
There is an asymmetry between attackers and defenders.
Even organizations that spend tens or hundreds of millions of dollars on cybersecurity can be breached. Building a cybersecurity program based on the warfare principle of defense in depth is absolutely critical, and so is planning for when it fails.
A robust incident response policy and planning exercises should equip your team, your executives, and your board to deal with a range of potential incidents and scenarios if the worst happens. An incident response policy provides a plan to carry out a set of concrete and specific actions that your organization will take to manage the aftermath of a major security incident.
Security incidents can come in many shapes and sizes. An employee losing a laptop in an airport with customer data is a security incident, and so is a ransomware group exfiltrating ten terabytes of data. The difference is in scale. Your incident response plan should serve as a business enabler that allows you to react quickly in the event of both small and large security incidents.
Big Picture Elements of Your Incident Response Policy
An incident response plan should be comprised of a set of policies and procedures that provide a clear game plan for:
1. Understanding the scope of the incident: The first and most important question to answer during an incident response process is to get a handle on the scope. Is customer data affected? Is employee data compromised? What IT systems or infrastructure is affected? What else could be affected? What core business processes do the IT systems enable? These are just some of the myriad of questions that need to be answered early.
2. Containing the incident: Your incident response plan should also spell out specific policies that will guide how you contain the incident. Critical systems may need to be shut off – who is responsible for making the decision? What is the backup plan if, for example, your company’s CRM is unavailable for an extended period of time? These types of questions around incident response planning need a robust and coherent answer.
3. Notification: All 50 U.S. states have data breach notification laws, requiring companies to notify consumers when their data has been stolen. In addition, organizations such as the U.S. Securities and Exchange Commission have regularly implemented new rules requiring financial institutions to notify them of a breach within 24 hours.
4. PR and Communication: For a severe enough event, particularly one that falls under notification requirements, it is likely that you will need to issue a formal statement. We recommend being clear, concise, and not attempting to hide or obfuscate information. It is a good practice to explain which systems were affected, which types of data may have been compromised – and which types were not compromised – in addition to any recommended actions for customers or others who may have had sensitive data exposed.
5. Lessons Learned: After an incident is resolved, you should perform lessons learned. Ask questions like: How did the plan work? Were there any failures or portions that weren’t adequately carried out? Was it clear who was responsible for each piece of the incident response process?
Putting Your Incident Response Plan Into Practice
Incident response plans are only as valuable as the amount of damage they mitigate in a real-life incident. At Rhymetec, we recommend doing tabletop exercises. Schedule time every year to practice going through an imagined incident in order to understand how well your plan works in practice. This gives your team hands-on practice in reacting to real-life incidents, quickly getting a grasp on what has been compromised, and examining which systems and core business functions will be compromised.
During incident response planning exercises, it’s also important to involve different stakeholders across the organization that may be impacted by sudden outages or other problems. Test out different scenarios to better understand which systems are essential for the business to continue to operate with and which controls might fail in the event of a real incident.
Let’s go over the phases of an incident response plan. Here’s what you should do before an incident, during an incident, and after an incident:
Before An Incident: Pre-Conditions For Effective Recovery
Not all incident response teams are equally effective. NIST regularly publishes general guidance on cybersecurity event recovery. NIST’s special publications serve as a great resource for in-depth incident response steps for malware incident handling and ransomware protection and response.
Here are a few best practices for pre-conditions to enable effective recovery. These are things you should already have in place before an incident occurs and should be continuously updated:
- Recovery Playbook: Create a formal plan with security policies specific to ransomware or malware attacks (note that security policies for small businesses are just as important as they are for larger companies). A clear plan should be set forth for communication with backup and recovery teams, company management, law enforcement, other stakeholders, and PR. Maintain a list of all personnel and technology to be involved in the recovery process.
- Regular Training: Conduct regular drills for team members to ensure everyone is ready to react in the event of an incident and to refine the recovery process.
- Critical Asset Mapping: Maintain up-to-date inventories of all hardware, software, and data assets. This involves maintaining security dependency maps that prioritize restoration. Keep an ongoing, updated list of resources ranked by priority that are required to keep things running across the organization.
- Preventative Security Measures: Use network monitoring tools to detect suspicious activity and employ endpoint detection and response solutions to notify of potential malware.
- Additional Defensive Security Measures: Use antivirus software, intrusion detection systems, and firewalls. Implement MFA policies and conduct phishing training for employees.
During & After The Incident
Here are a few best practices, again based on the guidelines set forth by NIST, that you can use to make sure you are maximally efficient when responding to a serious IT infrastructure or security incident:
- Determine The Scope: The first step is to confirm the scope of infected systems. Set specific recovery goals for your team in 12-hour increments.
- Containment: Next, isolate infected systems from the network to stop further distribution in the case of malware. Identify and disable any accounts that have been compromised.
- Eradication: Use antivirus or anti-malware tools to remove the malware from infected systems. Patch any known exploited vulnerabilities to protect against future events, and conduct a forensic analysis to understand the scope of the compromise and find any remaining backdoors.
- Recovery: Restore impacted systems and data from backups (after ensuring the backups are not infected with malware), and continuously monitor restored systems for any signs of reinfection. Provide impacted users with access to alternative systems as needed.
- Post-Incident Analysis: Document lessons learned, update the incident response policy based on the experience, and maintain open communication with senior management, IT staff, and legal counsel.
In Conclusion: The Importance of Having A Documented Incident Response Policy
According to IBM, it takes companies nearly 70 days to contain a security incident on average, and only 45% of companies have an incident response plan in place. Going forward, it is important to get that number up across the board, especially for smaller organizations that often lack the same in-house security resources large companies have.
Cybersecurity for startups and SMBs is just as critical as it is for large companies. Organizations are increasingly using similar services and infrastructure, which means companies’ attack surface looks more and more similar regardless of size.
Having a plan in place enables organizations to respond swiftly and effectively in the event of a security incident. At Rhymetec, we work closely with our clients to respond effectively to incidents, document the recovery process, and create detailed post-mortem reports based on lessons learned.
About Rhymetec
Our experts have been disrupting the cybersecurity, compliance, and data privacy space since 2015. We make security simple and accessible so you can put more time and energy into other critical areas of your business. What makes us unique is that we act as an extension of your team. We consult on developing stronger information security programs within your environment and provide the services to meet these standards. Most organizations offer one or the other.
From compliance readiness (SOC 2, ISO/IEC 27001, HIPAA, GDPR, and more) to Penetration Testing (Web Application Pentest, API Pentest, External Network Pentest, and Mobile Application Pentest) and ISO Internal Audits/ISO Compliance, we offer a wide range of consulting, security, vendor management, and compliance management services that can be tailored to your business environment.
If you’re ready to learn about how Rhymetec can help you, contact us today to meet with our team.
About The Author: Metin Kortak, CISO
Metin Kortak is the Chief Information Security Officer at Rhymetec. Metin began his career working in IT security and gained extensive knowledge of compliance and data privacy frameworks such as SOC 2, ISO 27001, PCI, FedRAMP, NIST 800-53, GDPR, CCPA, HITRUST and HIPAA. He joined Rhymetec to build data privacy and compliance as a service offering. Under Metin’s leadership, these offerings have grown to more than 200 customers, positioning the company as a leading SaaS security service provider in the industry.
Interested in reading more? Check out our other blogs:
- Maximize Your Use of Compliance Automation Platforms
- Understanding ISO 42001 Controls: Implementing and Managing Artificial Intelligence Responsibly
- Phishing Training For Employees: 5 Steps To Success