¶ 1. Introduction
To maintain the trust of our employees, customers, and partners and meet regulatory requirements, it is essential that we do everything we can to protect confidential information and systems in the face of a cyberattack. The better prepared we are to respond to a potential cyberattack, the faster we can eradicate any threat and reduce the impact on our business.
This document describes the overall plan for responding to information security incidents at Door. It defines the roles and responsibilities of participants, definition of incidents, relationships to other policies and procedures and reporting requirements. The goal of the Security Incident Response Plan is to:
- detect and react to security incidents,
- determine their scope and risk,
- respond appropriately to the incident,
- communicate the results and risk to all stakeholders, and
- reduce the likelihood of the incident from reoccurring.
Effective incident response involves every part of our organization, including IT teams, legal, technical support, human resources, corporate communications, and business operations. It is important that you read and understand your role as well as the ways you will coordinate with others.
This plan will be updated annually to reflect organizational changes, new technologies and new compliance requirements that inform our cybersecurity strategy. We will conduct regular testing of this plan to ensure everyone is fully trained to participate in effective incident response.
Door’s Information Security Program Manager is responsible for the maintenance and revision of this document.
¶ 2. Definitions
Use of ‘Door’ in this policy relates to Door Ventures Inc and Door Ventures Ltd as opposed to the Door platform.
¶ Events
An event is an exception to the normal operation of IT infrastructure, systems, or services. Not all events become incidents.
¶ Incident
An incident is an event that, as assessed by Door’s Information Security Program Manager, violates the Data Security Policy; Information Security Policy; other Door policy, standard, or code of conduct; or threatens the confidentiality, integrity, or availability of Information Systems or Client Data.
Incidents may be established by review of a variety of sources including, but not limited to monitoring systems, reports from staff or outside organisations and service degradations or outages.
Service outage procedures are detailed in Door’s Business Continuity Plan.
Incidents will be categorised according to the potential for restricted data exposure or criticality of resource using High-Medium-Low categories. The initial severity rating may be adjusted during plan execution. Detected vulnerabilities will not be classified as incidents. (See Appendix A: Threat Classification)
In addition to the company environment, Door employs platform monitoring to help identify any data breaches on the Door platform. Door has allocated staff members to monitor this. In the absence of indications of sensitive data exposure, vulnerabilities will be communicated, and the Information Security Program Manager will pursue available technology remedies to reduce that risk.
¶ 3. Methodology
This plan outlines the most general tasks for Security Incident Response and will be supplemented by specific internal guidelines and procedures. These internal guidelines and procedures are subject to amendment as technology changes.
¶ 3.1 Evidence Preservation
The goal of Incident Response is to reduce and contain the scope of an incident and ensure that technology assets are returned to service as quickly as possible. Rapid response is balanced by the requirement to collect and preserve evidence.
¶ 3.2 Customer Service Agreements, Governance
Door has service agreements with its customers. Interruption will be minimised alongside this agreement. However, Door’s management supports the priority of investigation activities where there is significant risk, and this may result in temporary outages or interruptions. Door will communicate any relevant issues to its customers.
¶ 3.3 Staffing for an Incident Response Capability, Resiliency
Door will endeavour to maintain sufficient staffing and third-party augmentation to investigate each incident to completion and communicate its status to other parties while it monitors the tools that detect new events.
¶ 3.4 Training
The continuous improvement of incident handling processes implies that those processes are periodically reviewed, tested and translated into recommendations for enhancements. Door staff will be periodically trained on procedures for reporting and handling incidents to ensure that there is a consistent and appropriate response to incidents, and that post-incident findings are incorporated into procedural enhancements.
¶ 4. Incident Response Phases
Door’s incident process encompasses six phases:
¶ 1. Preparation
Review and codify an organizational security policy, perform a risk assessment, identify sensitive assets, define which are critical security incidents the team should focus on, and build a Computer Security Incident Response Team (CSIRT).
¶ 2. Identification
Monitor IT systems and detect deviations from normal operations and see if they represent actual security incidents. When an incident is discovered, collect additional evidence, establish its type and severity, and document everything.
The response time depends on several factors, such as the type of incident, the criticality of the resources and data that are affected, the severity of the incident, existing Service Level Agreements (SLA) for affected resources, the time and day of the week, and other incidents that the team is handling. Generally, the highest priority is handling incidents that are likely to cause the most damage to the organization or to other organizations.
¶ 2.1 Security Incident Classification & Resolution
Incidents will be classified based on severity and accordingly resolution timelines will be decided. CSIRT will use the criteria defined below when assigning labels.
¶ 2.1.1 Severity
The severity is used to indicate the actual or potential impact and helps determine the timeline for resolution. Severity should remain the highest level assessed once triage has been done. If it is determined the severity was inaccurately assessed, it should be updated with why the adjustment was made and how we arrived at that conclusion clearly documented in the issue comments.
| Impact | Example |
|---|---|
| Critical | Severe impact to production data confidentiality, integrity or availability is likely if immediate action is not taken. Current controls do not satisfactorily mitigate the risk. Possibility of mass customer impact. Or, reputational risk is severe. |
| High | Impact to production data confidentiality, integrity or availability is likely if one or more security controls are circumvented. Current controls mitigate the initial risk. Customer impact or high likelihood of customer impact. Or, reputational risk is high. |
| Moderate | Unlikely to impact production data confidentiality, integrity or availability unless multiple security controls fail or are bypassed. Current controls mitigate the initial risk. No customer impact. Or, reputational risk is moderate. |
| Low | No risk to impact production data confidentiality, integrity or availability unless multiple security controls fail or are bypassed. Current controls are adequate. No risk of customer impact. Reputational risk is low or highly unlikely. |
¶ Considerations for determining severity:
Every time there is a security incident, evaluation of the scope and exposure of the risk, the confidentiality level, and more. By doing so, we split the issue into multiple, easier to assess, sub-issues. Here are a few examples:
How many of the following areas of the CIA Triad apply?
- Confidentiality
- Integrity
- Availability
Affected Surface - What is the affected surface?
- Door infrastructure
- Customer data
- Cloud accounts
- One particular application
- A customer’s instance
- Employee’s laptop/desktop
Exploitability - How easy is it to exploit the issue?
- Very easily - Attacker simply needs to run a command or script to trigger the issue.
- Requires some effort - Attacker requires specific conditions such as someone else to be logged in to exploit the issue.
- Difficult - Attacker requires specific conditions that are difficult to achieve.
Visibility - Who can see this issue?
- Everyone
- Someone with specific access
- Only one employee
The more areas of the CIA Triade that apply combined with the significance of the Affected Surface, Exploitability, and Visibility should be used to determine an estimated Severity.
¶ 2.1.2 Expected Resolution timeline:
| Severity | Example | Expected Resolution timeline |
|---|---|---|
| Critical | Unauthenticated RCE vulnerability on production instances. | Immediate response from CSIRT is needed with a resolution timeline of 12 hours. |
| High | A patched RCE vulnerability on production instances. | The issue can wait until next business day with the resolution time of 1 working day |
| Moderate | A patched RCE vulnerability on production instances that is being rolled out to the wider public. | No urgent action required, but actively monitored by CSIRT. Medium incidents have 3 days resolution timeline. |
| Low | A previously revoked and investigated access token has been discovered. | No action required, monitored in case the situation changes. Medium incidents have 1 week of resolution timeline. |
| Eventually | False positives kept open for review, informational notices. | No action required, handled when/if CSIRT has spare cycles. |
¶ 3.Containment
Perform short-term containment, for example by isolating the network segment that is under attack. Then focus on long-term containment, which involves temporary fixes to allow systems to be used in production, while rebuilding clean systems.
¶ 4. Eradication
Remove malware from all affected systems, identify the root cause of the attack, and take action to prevent similar attacks in the future.
¶ 5. Recovery
Bring affected production systems back online carefully, to prevent additional attacks. Test, verify and monitor affected systems to ensure they are back to normal activity.
¶ 6. Lessons Learned
No later than two weeks from the end of the incident, perform a retrospective of the incident. Prepare complete documentation of the incident, investigate the incident further, understand what was done to contain it and whether anything in the incident response process could be improved.
¶ 5. Guidelines for the Incident Response Process
In the process of responding to an incident, many questions arise, and problems are encountered, any of which may be different for each incident. This section provides guidelines for addressing common issues. The Door Information Security Program Manager and legal counsel may be consulted for questions and incident types not covered by these guidelines.
¶ 5.1 Insider Threats
In the case that the Door Information Security Program Manager is a person of interest in an incident, Door’s Co-Founders will assign another person to be responsible.
¶ 5.2 Interactions with Law Enforcement
All communications with external law enforcement authorities are made after consulting with legal counsel.
¶ 5.3 Communication Plan
All client communications about an incident or incident response will be prepared and agreed with the Door Information Security Program Manager and Co-Founders.
¶ 5.4 Roles, Responsibilities & Contact Information
This Security Incident Response Plan must be followed by all personnel, including all employees, temporary staff, consultants, contractors, suppliers and third parties operating on behalf of Door. All personnel are referred to as ‘staff’ within this plan.
Below are details about the roles and responsibilities of each member of Door to prevent and respond to a workplace incident. It is not an exhaustive list of duties but designed to give each employee a general understanding of their role and the roles of other employees in incident response and prevention.
¶ Incident Response Team Responsibilities
The Incident Response Lead is responsible for:
- Making sure that the Security Incident Response Plan and associated response and escalation procedures are defined and documented. This is to ensure that the handling of security incidents is timely and effective.
- Making sure that the Security Incident Response Plan is current, reviewed and tested at least once each year.
- Making sure that staff with Security Incident Response Plan responsibilities are properly trained at least once each year.
- Leading the investigation of a suspected breach or reported security incident and initiating the Security Incident Response Plan when needed.
- Reporting to and liaising with external parties, including pertinent business partners, legal representation, law enforcement, etc., as is required.
- Authorizing on-site investigations by appropriate law enforcement or third-party security/forensic personnel, as required during any security incident investigation. This includes authorizing access to/removal of evidence from site.
¶ Security Incident Response Team (SIRT) members are responsible for:
- Making sure that all staff understand how to identify and report a suspected or actual security incident.
- Advising the Incident Response Lead of an incident when they receive a security incident report from staff.
- Investigating and documenting each reported incident.
- Taking action to limit the exposure of sensitive data and to reduce the risks that may be associated with any incident.
- Gathering, reviewing, and analysing logs and related information from various central and local safeguards, security measures and controls.
- Documenting and maintaining accurate and detailed records of the incident and all activities that were undertaken in response to an incident.
- Assisting law enforcement during the investigation processes. This includes any forensic investigations and prosecutions.
- Initiating follow-up actions to reduce likelihood of recurrence, as appropriate.
- Determining if policies, processes, technologies, security measures or controls need to be updated to avoid a similar incident in the future. They also need to consider whether additional safeguards are required in the environment where the incident occurred.
¶ All staff members are responsible for:
- Making sure they understand how to identify and report a suspected or actual security incident.
- Reporting a suspected or actual security incident to the Incident Response Lead (preferable) or to another member of the Security Incident Response Team (SIRT).
- Reporting any security related issues or concerns to line management, or to a member of the SIRT.
- Complying with the security policies and procedures of Door.
¶ Door Personnel Responsibilities
CSO/CISO
- Name: Lead InfoSec Analyst
Not public
Not publicResponsibilities- Strategic lead. Develops technical, operational, and financial risk ranking criteria used to prioritize incident response plan.
- Authorizes when and how incident details are reported.
- Main point of contact for executive team and Board of Directors.
Incident Response Team Lead
- Name: Head of Client Ops
- Not public
- Not public
Responsibilities- Central team lead that authorizes and coordinates incident response across multiple teams and functions through all stages of a cyber incident.
- Maintains incident response plan, documentation, and catalog of incidents.
- Responsible for identifying, confirming, and evaluating extent of incidents.
Identity and Access Team Lead and Team Members
- Name: Lead InfoSec Analyst
- Not public
- Not public
Responsibilities- Responsible for privilege management, enterprise password protection and role-based access control.
- Discovers, audits, and reports on all privilege usage.
- Conducts random checks to audit privileged accounts, validate whether they are required, and re-authenticate those that are.
- Monitors privileged account uses and proactively checks for indicators of compromise, such as excessive logins, or other unusual behavior.
- Informs incident response team of potential attacks that compromise privileged accounts, validates and reports on the extent of attacks.
- Takes action to prevent the spread of a breach by updating privileges.
IT Operations and Support(internal)
- Name: Head of Engineering
- Not public
- Not public
Responsibilities- Manages access to systems and applications for internal staff and partners.
- Centrally manages patches, hardware and software updates, and other system upgrades to prevent and contain a cyberattack.
Legal Counsel
- Name: ****
- Not public;
- Not public
Responsibilities- Confirms requirements for informing employees, customers, and the public about cyber breaches.
- Responsible for checking in with local law enforcement.
- Ensures IT team has legal authority for privilege account monitoring.
Audit & Compliance
- Name: ****
- Not public;
- Not public
Responsibilities- Communicates with regulatory bodies, following mandated reporting requirements.
Human Resources
- Name: Director of HR
- Not public
- Not public
Responsibilities- Coordinates internal employee communications regarding breaches of personal information and responds to questions from employees.
Regulatory Contacts
- Name: ***
- Not public;
- Not public
Responsibilities- Receives information about a breach according to timeline and format mandated by regulatory requirements.
Marketing & Public Relations Lead
- Name: ****
- Not public;
- not public
Responsibilities- Communicates externally with customers, partners, and the media.
- Coordinates all communications and request for interviews with internal subject matter experts and security team.
- Maintains draft crisis communications plans and statements which can be customized and distributed quickly in case of a breach.
Web & Social Media Lead
- Name: Senior Content Strageist
- Not public;
- Not public
Responsibilities- Posts information on the company website, email, and social media channels regarding the breach, including our response and recommendations for users.
- Sets up monitoring across social media channels to ensure we receive feedback or questions sent by customers through social media.
Technical Support Lead(Internal)
- Name: Lead InfoSec Analyst
- Not public
- Not public
Responsibilities- Provides security bulletins and technical guidance to employees in case of a breach. Including password changes, or other system changes.
Technical Support Lead(External)
- Name: ****
- Not public
- Not public
Responsibilities- Provides security bulletins and technical guidance to external users in case of a breach.
¶ 6. Documentation, Tracking and Reporting
All incident response activities will be documented. Incidents will be prioritised and ranked according to their potential to disclose restricted data.
To demonstrate and improve the effectiveness of Door’s incident response team and security tools, Door requires a record of all actions taken during each phase of an incident. Supporting documentation is required, including all forensic evidence collected such as activity logs, memory dumps, audits, network traffic, and disk images. (See Appendix B: Incident Response Checklist)
As an investigation progresses, its ranking may change, resulting in a greater or lesser prioritisation of Door resources. Incidents will be reviewed post-mortem to assess whether the investigational process was successful and effective. Subsequent adjustments may be made to methods and procedures used by Door to improve the incident response process.
¶ 7. Escalation
At any time during the incident response process, the Door Co-Founders and the Information Security Program Manager may be called upon to escalate any issue regarding the process or incident. They will determine if, and when, an incident should be escalated to external authorities.
¶ 8. Review and Revision
This policy will be reviewed as it is deemed appropriate, but no less frequently than every 12 months.
Further information and advice on this policy can be obtained from Rob Sanders, rsanders@doorfunds.com
¶ APPENDIX
¶ Appendix A: Threat Classification
The CIA Triad (Confidentiality, Integrity, and Availability) is a framework for incident classification that helps to prioritize the level of incident response required for a cyberattack.
Confidentiality– Incidents involving unauthorized access to systems, including privileged account compromise. The more confidential the data or the more important the systems are to the business, the higher the potential impact.Integrity– Incidents involving data poisoning, including leveraging a privileged account to corrupt or modify data. The more sensitive the data, the higher the potential impact.Availability– Incidents that impact the availability or proper functioning of services, such as Distributed Denial of Service (DDoS) or ransomware, including use of privileged accounts to make unauthorized changes. The more critical the services to the business, the higher the potential impact.
When ranking the level of risk to the organization and the type of incident response required, Door must consider the extent to which privileged accounts are compromised, including those associated with business users, network administrators, and service or application accounts. When privileged accounts are involved in the breach, the level of risk increases exponentially as does the response required.
¶ Appendix B: Incident Response Checklist
¶ Cyber Incident Phase: Incident Discovery and Confirmation
ACTION TAKEN
- Describe how the team first learned of the attack (security researcher, partner, employee, customer, auditor, internal security alert, etc.).
- Analyze audit logs and security applications to identify unusual or suspicious account behavior or activities that indicate a likely attack and confirm attack has occurred.
- Describe potential attacker, including known or expected capabilities, behaviors, and motivations.
- Identify access point and source of attack (endpoint, application, malware downloaded, etc.) and responsible party.
- Prepare an incident timeline to keep an ongoing record of when the attack occurred and subsequent milestones in analysis and response.
- Check applications for signatures, IP address ranges, files hashes, processes, executables names, URLs, and domain names of known malicious websites.
- Evaluate extent of damage upon discovery and risk to systems and privileged accounts. Audit which privileged accounts have been used recently, whether any passwords have been changed, and what applications have been executed. (See Appendix A for more information on Threat Classification).
- Review your information assets list to identify which assets have been potentially compromised. Note integrity of assets and evidence gathered. (See Appendix A for more information on Threat Classification).
- Diagram the path of the incident/attack to provide an “at-a-glance” view from the initial breach to escalation and movement tracked across the network.
- Collect meeting notes in a central repository to use in preparing communications with stakeholders.
- Inform employees regarding discovery.
- Analyze incident Indicators of Compromise (IOCs) with threat intelligence tools.
- Potentially share information externally about breach discovery. You may choose to hold communications during this phase until you have contained the breach to increase your chances of catching the attacker. If so, make sure this aligns with your compliance requirements.
¶ Cyber Incident Phase: Containment and Continuity
ACTION TAKEN
- Enable temporary privileged accounts to be used by the technical and security team to quickly access and monitor systems.
- Protect evidence. Back up any compromised systems as soon as possible, prior to performing any actions that could affect data integrity on the original media.
- Force multi-factor authentication or peer review to ensure privileges are being used appropriately.
- Change passwords for all users, service, application, and network accounts.
- Increase the sensitivity of application security controls (allowing, denying, and restricting) to prevent malicious malware from being distributed by the attacker.
- Remove systems from production or take systems offline if needed.
- Inform employees regarding breach containment.
- Analyze, record, and confirm any instances of potential data exfiltration occurrences across the network.
- Potentially share information externally regarding breach containment (website updates, emails, social media posts, tech support bulletins, etc.).
¶ Cyber Incident Phase: Eradication
ACTION TAKEN
- Close firewall ports and network connections.
- Test devices and applications to be sure any malicious code is removed.
- Compare data before and after the incident to ensure systems are reset properly.
- Inform employees regarding eradication.
- Potentially share information externally regarding eradication (website updates, emails, social media posts, tech support bulletins, etc.).
¶ Cyber Incident Phase: Recovery
ACTION TAKEN
- Download and apply security patches.
- Close network access and reset passwords.
- Conduct vulnerability analysis.
- Return any systems that were taken offline to production.
- Inform employees regarding recovery.
- Share information externally regarding recovery (website updates, emails, social media posts, tech support bulletins, etc.).
¶ Cyber Incident Phase: Lessons Learned Review forensic evidence collected.
ACTION TAKEN
- Assess incident cost.
- Write an Executive Summary of the incident.
- Report to executive team and auditors if necessary.
- Implement additional training for everyone involved in incident response and all employees.
- Update incident response plan.
- Inform employees regarding lessons learned, additional training, etc.
- Potentially share information externally (website updates, emails, social media posts, tech support bulletins, etc.).
¶ Appendix C: Compliance & Legal Obligations
¶ HIPAA and HITECH
Any organization that creates, receives, maintains, or transmits electronic protected health information (ePHI) in the United States must meet HIPAA requirements for access control and data sharing.
- Reporting requirements – The HIPAA Breach Notification Rule, 45 CFR §§ 164.400-414, requires HIPAA covered entities and their business associates to provide notification following a breach of unsecured protected health information.
- Similar breach notification provisions implemented and enforced by the Federal Trade Commission (FTC) apply to vendors of personal health records and their third-party service providers, pursuant to section 13407 of the HITECH Act.
- Learn more – https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
¶ SOX
Sarbanes-Oxley (SOX) is designed to reduce corporate fraud by requiring an increase in the strength and granularity of security controls for financial auditing and reporting.
- Reporting requirements – Companies must disclose failure of security safeguards and security breaches to SOX auditors.
- Learn more – https://www.sarbanes-oxley-101.com/
¶ EU GDPR
Any organization dealing with EU citizens’ Personally Identifiable Information is obligated to meet standards for effective data protection, adequate security measures, and privacy by design to comply with EUGDPR.
- Reporting requirements – Under GDPR, breach notification is mandatory in all member states where a data breach is likely to result in a risk for the rights and freedoms of individuals. This must be done within 72 hours of first having become aware of the breach. Data processors are required to notify their customers, the controllers, without undue delay after first becoming aware of a data breach.
- Learn more – https://www.eugdpr.org/key-changes.html