Contents
- 1. Introduction
- 2. Roles and Responsibilities
- 3. Incident Response Process
- 3.1 Incident Identification
- 3.2 Incident Classification
- 3.3 Initial Response Procedure
- 3.4 Investigation and Containment
- 3.5 Mitigate and Eradication
- 3.6 Recovery
- 3.7 Closing the Incident
- 3.8 Post-Incident Analysis
- 4. Communication Plan
- 4.1 Objective
- 4.2 Pre-Incident Communication
- 4.3. Incident Detection and Analysis
- 4.4. Internal Communication During Incident Response
- 4.5 External Communication During Incident Response
- 4.6 Post-Incident Communication
- 4.7 Review and Update Communication Plan
- 5. Legal Considerations
- 6. Plan Maintenance
- 7. Training and Awareness
- 8. Conclusion
Version | Date | Summary | Paragraph | Author |
0.1 | 09/2023 | - | - | Simeon Drage |
0.2 | 29/02/24 | Added Impact Assessment Table |
3.2.1.1 Identify Affected Assets - Table 1 |
Simeon Drage |
1. Introduction
This Incident Response Plan (IRP) outlines the processes to identify, respond, and recover from security incidents at IRIS Connect. The purpose of the plan is to establish a well-structured and effective approach to managing incidents, minimizing potential damages, and reducing recovery time and costs.
2. Roles and Responsibilities
- Incident Response Team (IRT): The IRT will be responsible for executing this IRP. The team is led by the Incident Response Manager and includes representatives from IT, Legal, HR, and Public Relations.
- Employees: All employees are required to report suspected incidents immediately through the predefined channels established by the IRT.
Each member of the IRT will have a specific role and set of responsibilities during a cybersecurity incident.
Role |
Responsibilities |
Person responsible |
Incident Response Manager |
|
Steve Clapp Matt Newell |
People |
well-being
|
Primary - Simeon Drage Deputy – Steve Clapp |
Record keeper |
|
Primary - Steve Clapp Deputy - Simeon Drage |
Communications |
|
Primary - Simeon Drage Deputy – Steve Clapp |
Marketing & Social Media liaison |
|
Primary - Rico Patzer |
Internal IT/ Support |
|
Primary – Kieron Etherington Deputy – Simeon Drage |
Development |
|
Matt Newell |
Facilities |
|
Primary - Simeon Drage Deputy – Steve Clapp |
3. Incident Response Process
3.1 Incident Identification
Employees and systems should report any potential security incidents to the IRT as soon as they are identified. The IRT will determine whether an event constitutes a security incident.
3.1.1 Criteria for Cybersecurity Incident Reporting
Objective: To establish a consistent, comprehensive, and effective process for reporting cybersecurity incidents at IRIS Connect. These criteria will ensure that all potential cybersecurity incidents are promptly identified, reported, and addressed.
3.1.2 Definition of a Cybersecurity Incident:
A cybersecurity incident is defined as any event that negatively impacts the confidentiality, integrity, or availability of IRIS Connect's information systems or data. This could include, but is not limited to:
- Unauthorized access or attempts to access IRIS Connect systems or data
- Detection of malware or other malicious software
- Loss or theft of devices containing sensitive company data
- Multiple failed login attempts or other suspicious user behavior
- Any unexpected system behavior or disruption that could indicate a cybersecurity issue
3.1.3 Incident Reporting Thresholds:
All potential cybersecurity incidents, regardless of perceived severity, should be reported. Even minor incidents can potentially be indicators of larger issues or part of a broader attack.
3.1.4 Reporting Procedure:
- Personnel should report any potential cybersecurity incidents as soon as possible (ideally within the same hour as becoming aware of the potential incident), to ensure a swift response.
- Incidents should be reported to the Incident Response Team (IRT), typically via a Slack, face to face, phone call or email.
- If the incident is discovered outside of normal working hours, personnel should follow the after-hours incident reporting procedure, which should include an emergency contact method for the IRT.
3.1.5. Information to Include in an Incident Report:
An incident report should include as much of the following information as possible:
- The date and time when the incident was discovered
- The person who discovered the incident
- The systems, services, or data affected
- A description of the incident, including any error messages, suspicious emails, or unusual system behavior
- Any immediate actions taken in response to the incident
3.1.6 Confidentiality and Non-Retaliation:
Reports of potential cybersecurity incidents will be kept confidential to the extent possible, and consistent with legal obligations and the need to investigate the incidents. IRIS Connect is committed to a non-retaliation policy, meaning employees will not be penalized for reporting incidents in good faith.
By adhering to these criteria, IRIS Connect can ensure that all cybersecurity incidents are reported promptly, accurately, and consistently, facilitating an effective incident response.
3.2 Incident Classification
The IRT will categorize the incident based on its potential impact and severity. This classification guides the urgency and scale of the response.
3.2.1 Impact Assessment
3.2.1.1 Identify Affected Assets
First, determine which systems, networks, or data have been affected by the incident. This should include hardware, software, and data assets. Consider both direct and indirect impacts.
Table 1: IRIS Connect Platform
Process and checklist to assess the damage of an incident to the IRIS Connect Platform
The following checklist will be used following notification of an incident:
No. | Test | Impact if Failed |
1 | Access platform login page | Critical |
2 | Login to the platform | Critical |
3 | Navigate around the platform without issue | High |
4 | Review recordings | High |
5 | Comment on recordings | Medium |
6 | Share recording | Medium |
7 | Add media comments to a recording | Medium |
8 | Use form | Medium |
9 | Desktop upload | Medium |
10 | Create a screen capture recording | Medium |
11 | Log in to the mobile app | Critical |
12 | Record on the mobile app | Critical |
13 | Upload from the mobile app | Medium |
14 | Review recording on the platform from the mobile app | High |
15 | Review recording on the platform from desktop upload | High |
16 | Review recording on the platform from screen capture | High |
Upon completion of the incident assessment, the Director of Technology or Cloud Infrastructure Manager should be notified.
3.2.1.2 Evaluate the Extent of Compromise
Determine the extent of the compromise on affected assets. This can include lost or stolen data, damaged systems, or disrupted services. Identify if the incident is ongoing or has been contained.
3.2.1.3 Assess Business Impact
Consider how the incident affects business operations. This may involve downtime, loss of productivity, financial cost for recovery, contractual penalties, or potential loss of business.
3.2.1.4 Regulatory and Legal Considerations
Identify any potential regulatory or legal implications. Depending on the nature of the incident and the data involved, there may be reporting obligations under data protection laws or industry-specific regulations.
3.2.1.5 Reputational Impact
Consider potential damage to the company's reputation. This includes customer trust, public image, and relationships with business partners.
3.3 Initial Response Procedure
Based on the conclusions drawn from the impact assessment a severity level can be determined.
3.3.1 Severity Response Determination
- Low Severity Incidents: These are addressed through standard operating procedures.
- Medium to High Severity Incidents: The IRT will immediately convene to begin response activities.
3.3.2 Internal Stakeholder Coordination
The Incident Manager leads coordination efforts with all relevant internal stakeholders. This involves:
- Regularly updating stakeholders on the status of the incident
- Coordinating the response efforts of different teams or departments
- Ensuring that all actions taken align with the overall response strategy and company policies
3.3.3 External Stakeholder Coordination
Depending on the nature and severity of the incident, it may be necessary to coordinate with external stakeholders. This could include customers, business partners, third-party service providers, law enforcement, and regulatory bodies. The Communication Manager is responsible for coordinating these communications, following these protocols:
- Assess the need for external communication: Determine which stakeholders need to be informed based on the incident's nature, potential impact, legal obligations, and contractual requirements.
- Prepare communication: Draft messages for each stakeholder group, ensuring the information is accurate, appropriate, and complies with company policy and legal requirements.
- Deliver communication: Use appropriate communication channels to deliver the messages, such as direct emails, phone calls, or public statements.
3.4 Investigation and Containment
The IRT will collect and analyze information about the incident, and containment strategies will be implemented to prevent further damage.
3.4.1 Foresenic Investigation Process
3.4.1.2 Preparation
Ensure that appropriate digital forensics tools are in place and that the Incident Response Team (IRT) is trained in digital forensics techniques and principles.
3.4.1.3 Identification
Upon an incident occurring, the IRT should quickly identify the systems and data that may contain critical evidence.
3.4.1.4 Preservation
The IRT should take steps to preserve the integrity of potential digital evidence, such as creating digital copies of relevant data and maintaining a secure chain of custody.
3.4.1.5 Collection
The IRT should collect digital evidence in a forensically sound manner, minimizing changes to the systems and data being collected.
3.4.1.6 Analysis
The IRT should analyze the digital evidence to understand the nature of the incident, the attacker's actions, and the potential business impact.
3.4.1.7 Documentation
The IRT should meticulously document every step of the forensic process, including actions taken, evidence collected, and findings.
3.4.1.8 Reporting
The IRT should produce a comprehensive but clear and understandable report of their forensic analysis, sharing it with the relevant stakeholders.
3.4.1.9 Review
After the conclusion of the incident, the forensic process and policy should be reviewed and updated based on lessons learned.
3.4.2 Incident Containment Procedure
3.4.2.1 Isolate Affected Systems
Upon detection of an incident, isolate the affected systems to prevent the spread of the incident within the network. This could involve disconnecting the system from the network or shutting it down entirely, depending on the nature and severity of the incident.
3.4.2.2 Apply Temporary Fixes
Apply temporary countermeasures to quickly mitigate the incident's effects. This can include patching software vulnerabilities, changing network configurations, or updating firewall rules. The priority is to prevent further harm while a more permanent solution is developed.
3.4.2.3. Backup Affected Systems and Data
Backup affected systems and data to preserve information for investigation and to prevent data loss. Ensure the backups are secure to avoid creating another potential point of compromise.
3.4.2.4. Update Access Controls
If the incident involved unauthorized access, update the access controls to lock out the attacker. This could include changing passwords, revoking access tokens, or updating encryption keys.
3.4.2.5. Monitor for Further Activity
Continue to monitor the system for further malicious activity. If the incident reoccurs, revisit the containment strategy and adjust as necessary.
3.4.2.6. Document Actions and Findings
Document all actions taken during containment, along with their results. This information will be crucial for the subsequent eradication and recovery steps, as well as for post-incident analysis and potential legal or regulatory needs.
3.5 Mitigte and Eradication Process
3.5.1 Mitigation Process
3.5.1.1 Initial Response
Upon detecting an incident, initiate the incident response process, notify the Incident Response Team (IRT), and start logging all incident-related information and actions.
3.5.1.2 Isolate Affected Systems
To limit the spread of the incident, isolate the affected systems from the network. The level of isolation depends on the severity of the incident.
3.5.1.3 Implement Interim Countermeasures
Deploy immediate countermeasures to reduce the impact of the incident, such as updating firewall rules, adjusting access controls, or installing patches.
3.5.1.4 Preserve Evidence
If required, create a forensic image of the affected systems for future analysis
3.5.2 Eradication Process
3.5.2.1 Identify Root Cause
Determine how the incident occurred, which might involve a deep-dive analysis of system logs, network traffic, and patterns of behavior.
3.5.2.2 Remove Cause of Incident
Once the root cause is identified, remove it from the system. This could mean deleting malicious files, closing network ports, or patching software vulnerabilities.
3.5.2.3 Validate Systems
Confirm that the affected systems are clean and fully functional. This may involve running system scans, performance monitoring, and user confirmation of system functionality.
3.5.2.4 Update Defense Mechanisms
Based on the findings, update or strengthen the security measures to prevent a similar incident in the future. This could include updating security software, improving access controls, or enhancing network security.
3.5.2.5 Document Findings and Actions
Keep a comprehensive record of all actions taken and findings during the mitigation and eradication process. This will support any potential legal requirements and will be valuable for post-incident reviews and future incident response planning.
3.6 Recovery
Affected systems will be restored to normal operation and continuously monitored to ensure that the threat has been completely eradicated and no further malicious activity occurs.
3.7 Closing the Incident
The IRT meet and close the incident upon agreement - the final decision being made by the Incident Response Manager.
3.8 Post-Incident Analysis
3.8.1 Lessons Learned Procedure
3.8.1.1 Initiate Review Meeting
After the incident has been fully resolved, schedule a review meeting involving all key incident response personnel. This should take place as soon as possible after the incident, while details are still fresh in people's minds.
3.8.1.2. Gather and Review Incident Data
Prior to the meeting, collect all incident-related data including logs, incident reports, and any other relevant documentation. These should be distributed to participants before the meeting.
3.8.1.3. Conduct the Review Meeting
During the meeting, go through the incident timeline and discuss each step of the response process. Identify what was done well and where improvements can be made.
3.8.1.4. Identify Lessons Learned
The main goal of the review meeting is to identify lessons learned. These may include gaps in the current response plan, needed improvements in tools or systems, training needs, and any other observations that could improve future responses.
3.8.1.5. Update Response Plan
Based on the lessons learned, update the Incident Response Plan. This may include changes to response procedures, updates to contact lists, or new training requirements.
3.8.1.6. Implement Changes
Begin implementing the changes identified as soon as possible. This may involve system updates, personnel training, or policy modifications.
3.8.1.7. Document the Process
Document the entire lessons learned process, including meeting notes, identified improvements, and any changes made. This documentation should be stored with the incident data for future reference.
4. Communication Plan
The IRT will regularly communicate with stakeholders, including employees, management, customers, and potentially the public (through Public Relations), to keep them informed about the situation and the steps being taken to resolve it.
4.1 Objective
To provide clear guidelines for internal and external communications before, during, and after a cybersecurity incident. This plan will ensure that accurate and consistent information is shared with the appropriate parties at the right time, thus helping to manage the incident, protect our reputation, and meet our legal and contractual obligations.
4.2 Pre-Incident Communication
- Establish clear lines of communication within the organization. All personnel should be aware of whom to report a potential cybersecurity incident to, and how to do so.
- Regularly inform staff about cybersecurity threats, as well as their roles and responsibilities in preventing and responding to incidents.
- Develop templates for internal and external communications during a cybersecurity incident, such as notifications to staff, customers, partners, and regulators.
4.3. Incident Detection and Analysis:
- Once a potential incident is detected, the person discovering it should immediately notify the Incident Response Team (IRT).
- The IRT should then analyse the incident to confirm whether it is a real incident and to determine its severity and impact.
4.4. Internal Communication During Incident Response
- Once an incident has been confirmed, the Incident Manager should inform senior management and other relevant stakeholders within the organization.
- Regular updates should be provided to relevant internal parties, including information about the incident, its impact, actions being taken, and any required support or actions from them.
- The Incident Manager should coordinate all internal communications to ensure consistency and to avoid any confusion or misinformation.
4.5 External Communication During Incident Response
- Depending on the nature and severity of the incident, it may be necessary to inform external parties such as customers, partners, regulatory bodies, or law enforcement.
- The Communication Manager should coordinate all external communications, using the pre-prepared templates as needed, and ensuring that all communication is accurate, consistent, and complies with legal and contractual requirements.
4.6 Post-Incident Communication
- Once the incident is resolved, a post-incident report should be prepared and shared with relevant internal and external stakeholders. This report should include an overview of the incident, the actions taken, the outcomes, and any lessons learned or improvements to be made.
- Any necessary follow-up communication should be carried out, such as updates to customers, or reporting to regulators.
4.6.1 Voluntary information sharing process
4.6.1.1 Objective
To contribute to broader cybersecurity situational awareness by voluntarily sharing pertinent, non-sensitive cybersecurity incident information with external stakeholders.
Process Outline:
4.6.1.2 Incident Classification and Information Extraction
Upon detection and initial analysis of a cybersecurity incident, the Incident Response Team (IRT) will classify the incident based on its severity, scope, and impact. The IRT will extract non-sensitive but useful information for sharing, such as the type of threat, attack vectors used, and impact observed.
4.6.1.3 Information Review and Approval
The extracted information will be reviewed by the Incident Manager, Legal and Compliance team to ensure that it does not contain any sensitive, confidential, or personally identifiable information. This step is crucial to ensure that the shared information complies with company policies, as well as legal and regulatory requirements.
4.6.1.4 Sharing with Industry Forums
IRIS Connect is part of several cybersecurity forums. If an incident reveals new threat information or an innovative response strategy, the relevant details will be shared with these forums. This information sharing will help all participants to improve their cybersecurity defenses and response strategies.
4.6.1.5 Sharing with Cybersecurity Firms and Researchers
IRIS Connect collaborates with cybersecurity firms and researchers to help advance the field. Non-sensitive incident information may be shared with these parties to contribute to cybersecurity knowledge and development of more robust cybersecurity solutions.
4.6.1.6 Sharing with Law Enforcement and Regulatory Agencies
For serious incidents that may have legal implications or where there is a risk to broader public safety, IRIS Connect will voluntarily share relevant incident information with law enforcement and regulatory agencies. This information sharing can support efforts to pursue threat actors and develop more effective cybersecurity policies.
4.6.1.7 Feedback and Review
Feedback from external stakeholders regarding the shared information will be reviewed and considered for incorporation into our cybersecurity practices. The voluntary information sharing process will also be reviewed regularly and after each use, to identify any issues or improvements.
By following this process, IRIS Connect can contribute to broader cybersecurity situational awareness, helping to strengthen not just our own cybersecurity, but also that of our industry and community.
4.7 Review and Update Communication Plan
- After each significant incident, or at least annually, the Communication Response Plan should be reviewed and updated as needed.
- This review should consider any issues or improvements identified during recent incidents, as well as changes in the organization, technology, or legal or regulatory environment.
5. Legal Considerations
IRIS Connect will comply with all relevant UK and international laws and regulations in its response to security incidents. This includes any requirements for notifying affected individuals and regulatory bodies in the event of a data breach.
6. Plan Testing, Maintenance, and Improvement
The IRP will be tested annually (or after a significant business change) to test the effectiveness of the incident response capability. and identify potential weaknesses or deficiencies.
Incident response testing may include the use of checklists, walk-throughs or tabletop exercises, and simulations (parallel or full interrupt). Incident response testing can include understanding and analysing the effects on organizational operations and assets and individuals due to incident response.
Testing should coordinate with related organizational elements responsible for related plans e.g. Contingency Plans, Disaster Recovery Plans to ensure a cohesive test and a holistic review is conducted.
This IRP will be reviewed and updated following the testing, or after a significant incident, to ensure its ongoing effectiveness.
7. Training and Awareness
All staff will be given annual training on the IRP to ensure that they are familiar with their roles and responsibilities in the event of an incident.
8. Conclusion
This IRP provides the foundation for IRIS Connect to effectively respond to and recover from security incidents, helping to protect the confidentiality, integrity, and availability of its information assets.