Incident response planning contains specific directions for specific attack scenarios, avoiding further damages, reducing recovery time and mitigating cybersecurity risk.
Incident response procedures focus on planning for security breaches and how organization's will recover from them.
Without a formal IR plan in place, organizations may not detect attacks or may not know what to do to contain, clean up and prevent attacks when detected.
Remember, techniques like IP attribution aren't always helpful and your organization may not be able to recover stolen data and needs to know what it will do in that event.
Why is Incident Response Planning Important?
Incident response planning is important because it outlines how to minimize the duration and damage of security incidents, identifies stakeholders, streamlines digital forensics, improves recovery time, reduces negative publicity and customer churn.
Incident response encompasses preparation for unknown and known cyber threats, reliably identifying root causes of security incidents and post-incident disaster recovery.
It allows organizations to establish best practices for incident handling and develop a communication plan that may involve notifying law enforcement, employees and staff.
Incident response is a crucial component of preventing future incidents and running an organization that processes sensitive data like personally identifiable information (PII), protected health information (PHI) or biometrics.
Every security event can have a short term and long term impact on your organization.
According to IBM and the Ponemon Institute the average cost of a data breach in 2019 was $3.92 million.
Beyond the cost, business continuity, customer loyalty and brand protection are massive concerns, especially as organizations increasingly rely on third-party vendors.
While it's impossible to remove all security issues, an effective incident response process can mitigate the largest cybersecurity risks.
Who is Responsible for Incident Response Planning?
Organizations should form a computer security incident response team (CSIRT) who is responsible for analyzing, categorizing and responding to security incidents.
Incident response teams can include:
- Incident response manager: oversees and prioritizes actions during detection, containment and recovery of an incident. They may also be required to convey high-severity incidents to the rest of the organization, customers, law enforcement, regulations and the public where applicable.
- Security analysts: support and work directly with affect resources, as well as implementing and maintaining technical and operational controls.
- Threat researchers: provide threat intelligence and context around security incidents. They may use third-party tools and the Internet to understand current and future threats. Organizations will often outsource this function if the expertise does not exist in-house. If this is your organization, look for tools or services that can automatically monitor for leak credentials, data leaks and third-party and fourth-party vendor security posture.
That said, effective incident response relies on cross-functional incident response team members from all parts of the organization.
Without stakeholders from senior leadership, legal, human resources, IT security and public relations, incident response teams can prove ineffective.
Senior leadership support is particularly necessary to gather necessary resources, funding, staff and time from different teams. This may be a Chief Information Security Officer (CISO) or Chief Information Officer (CIO) at a large organization or even the CEO or a board member at smaller organizations.
Legal counsel can help the organization understand which data breaches must be reported to regulators and customers, as well as advice around liability for third-party vendor data breaches.
Where an incident is from an insider threat, human resources can assist with removal of staff and access credentials.
Finally, public relations are essential to ensure an accurate, consistent and truthful message is communicated to the regulators, media, customers, shareholders and other stakeholders.
What are the Different Types of Security Incidents?
There are many types of security incidents and ways to classify them. This is largely an organizational decision, what is considered critical at one organization may be minor at another. That said, there are a range of common cyber incidents every organization should be aware of and plan for:
- Ransomware and other types of malware
- Man-in-the-middle attacks
- Social engineering like phishing and spear phishing
- Exploits of CVE-listed vulnerabilities
- Corporate espionage
- OPSEC failures
- Data breaches
- Data leaks
- Email spoofing
- Domain hijacking
- Denial of service (DoS)
Each of these security incidents is common enough to warrant a formal incident response process and recovery plan. Security analysts need to be aware that even small incidents can open up new attack vectors that lead to larger attacks. This is why real-time threat intelligence is so important.
Security teams need to understand the impact that vendors can have on their organization's security posture. Even if third-parties aren't conducting critical business activities, they still represent significant vendor risk.
This is because they may have access to sensitive data or property, and your organization may be accountable for their security failures.
Look for vendors with SOC 2 assurance, ask to see their information security policy and develop a vendor management policy that contains a third-party risk management framework that allows your organization to easily perform cybersecurity risk assessments on current and potential vendors.
What Tools are Available for Incident Response Teams?
There are tools and industry standards that can be helpful to incident response teams. Tools can be split into three categories:
For prevention, an organization may employ a security scanner and a data leak detection tool to prevent leaked credentials and other sensitive data being exposed due to poor S3 security or a lack of configuration management.
A common response tool is remediation workflows where incident response teams can request remediation, track and close third-party attack vectors.
What is the Industry Standard for Incident Response?
There are two frameworks that have become industry standard, the NIST Incident Response Process and the SANS Incident Response Process.
The NIST Incident Response Process is four steps:
- Detection and analysis
- Containment, eradication and recovery
- Post-incident activity
Whereas, the SANS Incident Response Process is six:
- Lessons learned
As you can see, both NIST and SANS have all the same components and flow with different verbiage and clustering.
Whether you follow NIST, SANS or another incident response plan template, your IR plan should:
- Provide an overview
- Identify and describe roles and responsibilities
- Be tailored to specific business risks and needs
- Outline the current state of information security, data security and network security
- Have clear detection and identification procedures
- Specify tools, technologies and resources needed for containment and eradication
- Outline recovery and follow-up tasks
- Have a communication plan
- Be well tested
- Have version control or a section to outline when and who made revisions
What are the Metrics Incident Response Teams Should be Measured Against?
Incident response is like any aspect of an organization, what gets measured gets managed. Ongoing management includes setting and measuring incident response goals, as well as periodically testing the incident response plan in tabletop exercises to ensure that all stakeholders are comfortable with their duties and responsibilities.
Common metrics include:
- Your security rating
- Competitor security ratings
- Number of vendors
- Average vendor security rating
- Distribution of vendor security ratings
- Lowest rated vendors
- Least improved vendors
- Highest rated vendors
- Most improved vendors
- Number of security questionnaires sent
- Number of security questionnaires received
- Vendor risks remediated
- Number of incidents detected
- Number of incidents missed
- Number of incidents requiring actions
- Number of repeat incidents
- Number of known attack vectors
- Average remediation time
- Number of data breaches and data leaks
- Average vendor security posture
- Number of stakeholders present in incident response plan review meetings
- Number of stakeholders present in incident response plan tabletop exercises
- Possible procurement of cybersecurity software, e.g. software to automate vendor risk management
- Other security initiatives, e.g. cybersecurity awareness training, website risks, email security, network security, malware and brand protection
What is the Difference between an Incident Response Plan and Business Continuity Plan?
While an incident response plan and business continuity plan have a similar goals – minimize the impact of unforeseen events and keep the business running – incident response planning generally has a higher level of visibility.
Incident response plans are concerned with security incidents and breaches that impact information security, network security and data security.
Business continuity plans focus on creating a system to prevent and recover from potential threats to a company, whether that be personnel, assets or natural disasters.
This is why most organizations have two seperate documents for incident response and business continuity, which often reference each other.
How UpGuard Scale Your Organization's Incident Response Team by Detecting Data Leaks and Preventing Third-Party Breaches
UpGuard BreachSight can help monitor for DMARC, combat typosquatting, prevent data breaches and data leaks, avoiding regulatory fines and protecting your customer's trust through cyber security ratings and continuous exposure detection.
UpGuard Vendor Risk can minimize the amount of time your organization spends managing third-party relationships by automating vendor questionnaires and continuously monitoring your vendors' security posture over time while benchmarking them against their industry.