Incident Response Plan
Version | 1.4 |
Owner | CTO |
Last Updated On | Sep 2, 2024 |
Last Updated by | @Bruno Belizario |
Approved by | @Sean Oldfield |
Last Review | Sep 2, 2024 |
Subscribe to an RSS feed to be notified when we update the Incident Response Plan (note: you will need to cut and paste the "Subscribe to an RSS feed" URL into an RSS Feed Reader to monitor updates).
Purpose
This document establishes the plan for managing information security incidents and events and offers guidance for employees or incident responders who believe they have discovered, or are responding to, a security incident.
Scope
This policy covers all information security, data privacy events, or severe application regression incidents.
Incident and Event Definitions
A security event is an observable occurrence relevant to the confidentiality, availability, integrity, or privacy of company-controlled data, systems, or networks.
A security incident is a security event that results in loss or damage to the confidentiality, availability, integrity, or privacy of company-controlled data, systems, or networks.
Incident Reporting & Documentation
Reporting
If an ecoPortal employee, contractor, user, or customer becomes aware of an information security event or incident, possible incident, imminent incident, unauthorized access, policy violation, security weakness, or suspicious activity, then they shall immediately report the information using one of the following communication channels:
Email issues@ecoportal.co.nz information or reports about the event or incident
Google Chat using the channel #tech-infrastructure-questions
In the event of an application regression. The Incident Reporting Board present in Appendix D.
Reporters should act as good witnesses and behave as if they are reporting a crime. Reports should include specific details about what has been observed or discovered.
Severity
Tech Team shall monitor incident and event tickets and shall assign a ticket severity based on the following categories.
S3/S4 - Low and Medium Severity
Issues meeting this severity are simply suspicions or odd behaviours. They are not verified and require further investigation. There is no clear indicator that systems have tangible risks and do not require emergency response. This includes lost/stolen laptops with disk encryption, suspicious emails, outages, strange activity on a laptop, etc.
S2 - High Severity
High-severity issues relate to problems where an adversary or active exploitation hasn’t been proven yet, and may not have happened, but is likely to happen. This may include lost/stolen laptops without encryption, vulnerabilities with direct risk of exploitation, threats with risk or adversarial persistence on our systems (e.g.: backdoors, malware), and malicious access to business data (e.g.: passwords, vulnerability data, payments information).
S1 - Critical Severity
Critical issues related to actively exploited risks involving a malicious actor or threats that put any individual at risk of physical harm. Identification of active exploitation is required to meet this severity category. For application regressions this can also include system unavailability.
Escalation and Internal Reporting
The incident escalation contacts can be found below in Appendix A.
S1 - Critical Severity: S1 issues require immediate notification to Tech Team management.
S2 - High Severity: A Trello card must be completed, and the appropriate manager (see S1 above) must also be notified via e-mail or Google with a link to the card.
S3/S4 - Medium and Low Severity: A Trello card may be created at the descretion of the incident responder and assigned to the appropriate department for response, except in the case of application regressions.
Documentation
All reported security events, incidents, and response activities shall be documented and adequately protected in the Trello Board specified in Appendix D. This includes, but it’s not limited to, associated evidence of the reported incident e.g. report e-mails or Google threads, and all remediation steps including required code/infrastructure changes, and subsequent customer communication.
A root cause analysis may be performed on all verified S1 security incidents. A root cause analysis report shall be documented and referenced in the incident ticket. An abbreviated report will be attached to the Status Page. The root cause analysis shall be reviewed by the Tech Team manager, who shall determine if a post-mortem meeting is required.
Incident Response Process
For critical issues, the response team will follow an iterative response process designed to investigate, contain exploitation, eradicate the threat, recover system and services, remediate vulnerabilities, and document a post-mortem report including the lessons learned from the incident.
Summary
Event reported
Triage and analysis
Investigation
Containment & neutralization (short-term/triage)
Recovery & vulnerability remediation
Hardening & Detection improvements (lessons learned, long-term response)
Detailed
CTO or Tech Lead will manage the incident response effort
If necessary, a central “War Room” will be designated, which may be a physical or virtual location (i.e., Google Meet)
A recurring Incident Response Meeting will occur at regular intervals until the incident is resolved
Legal and executive staff will be informed as required
Incident Response Meeting Agenda
Update Incident Ticket and timelines
Document new Indicators of Compromise (IOCs)
Perform investigative Q&A
Apply emergency mitigations
External Reporting / Breach Reporting
Plan long-term mitigations
Document Root Cause Analysis (RCA)
Additional items as needed
Special Considerations
Internal Issues
Issues, where the malicious actor is an internal employee, contractor, vendor, or partner, require sensitive handling. The incident manager shall directly contact helene@ecoportal.co.nz (primary) or beks@ecoportal.co.nz (secondary) and will not discuss it with other employees. These are critical issues where follow-up must occur.
Compromised Communications
Incident responders must have Google messaging arranged before listing themselves as incident members. If there are IT communication risks, an out-of-band solution will be chosen and communicated to incident responders via cell phone.
Root Account Compromise
If an AWS root account compromise is known or expected, refer to the playbook in Appendix C.
Additional Requirements
Suspected and reported events and incidents shall be documented
Suspected incidents shall be assessed and classified as either an event or an incident
The incident response shall be performed according to this plan and any associated procedures.
All incidents shall be formally documented, and a documented root-cause analysis shall be performed
Suspected and confirmed unauthorized access events shall be reviewed by the Incident Response Team. Breach determinations shall only be made by the CEO (manuel@ecoportal.co.nz)
ecoPortal shall promptly and properly notify customers, partners, users, affected parties, and regulatory agencies of relevant incidents or breaches in accordance with ecoPortal policies, contractual commitments, and regulatory requirements, as determined by CEO (manuel@ecoportal.co.nz).
This Incident Response Plan shall be reviewed and formally tested at least annually. Results of IR plan testing activities including findings and lessons learned will be formally documented and maintained to support security, compliance, and audit requirements
External Communications and Breach Reporting
Legal and executive staff shall confer with technical teams in the event of unauthorized access to company or customer systems, networks, and/or data. Legal staff along with the CEO shall determine if breach reporting or external communications are required. Breaches shall be reported to customers, consumers, data subjects, and regulators without undue delay and in accordance with all contractual commitments and applicable legislation.
No personnel may disclose information regarding incidents or potential breaches to any third party or unauthorized person without the approval of legal and/or executive management.
Mitigation and Remediation
Legal and executive staff shall determine any immediate or long-term mitigations or remedial actions that need to be taken as a result of an incident or breach. If mitigations or remedial actions are needed, executive staff shall direct personnel with respect to planning, communicating, and executing those activities.
Cooperation with Customers, Data controllers, and Authorities
As needed and determined by legal and executive staff, the company shall cooperate with customers, Data Controllers, and regulators to fulfill all of its obligations in the event of an incident or data breach.
Roles & Responsibilities
Every employee and user of any ecoPortal information resources has responsibility for the protection of the information assets. The table below establishes the specific responsibilities of the incident responder roles.
Response Team Members
Role | Responsibility |
Incident Manager | The Incident Manager is the primary and ultimate decision maker during the response period. The Incident Manager is ultimately responsible for resolving the incident and formally closing incident response actions. See Appendix A for Incident Manager contact information. These responsibilities include:
|
Incident Response Team (IRT) | The individuals who have been engaged and are actively working on the incident. All members of the IRT will remain engaged in incident response until the incident is formally resolved, or they are formally dismissed by the Incident Manager. |
Engineers (Support and Development) | Qualified engineers will be placed into the on-call rotation and may act as the Incident Manager (if primary resources are not available) or a member of the IRT when engaged to respond to an incident. Engineers are responsible for understanding the technologies and components of the information systems, the security controls in place including logging, monitoring, and alerting tools, appropriate communications channels, incident response protocols, escalation procedures, and documentation requirements. When Engineers are engaged in incident response, they become members of the IRT. |
Users | Employees and contractors of ecoPortal. Users are responsible for following policies, reporting problems, suspected problems, weaknesses, suspicious activity, and security incidents and events. |
Customers | Customers are responsible for reporting problems with their use of ecoPortal services. Customers are responsible for verifying that reported problems are resolved. |
Legal Counsel | Responsible, in conjunction with the CEO and executive management, for determining if an incident presents legal or regulatory exposure as well as whether an incident shall be considered a reportable breach. Counsel shall review and approve in writing all external breach notices before they are sent to any external party. |
Executive Management | Responsible, in conjunction with the CEO and Legal Counsel, for determining if an incident shall be considered a reportable breach. An appropriate company officer shall review and approve in writing all external breach notices before they are sent to any external party. ecoPortal shall seek stakeholder consensus when determining whether a breach has occurred. The ecoPortal CEO shall make a final breach determination in the event that consensus cannot be reached. |
Management Commitment
ecoPortal management has approved this policy and commits to providing the resources, tools, and training needed to reasonably respond to identified security events and incidents with the potential to adversely affect the company or its customers.
Exceptions
Requests for an exception to this Policy must be submitted to and authorized by the COO (helene@ecoportal.co.nz) for approval. Exceptions shall be documented.
Violations & Enforcement
Any known violations of this policy should be reported to the COO (helene@ecoportal.co.nz). Violations of this policy may result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.
Appendix A - Contact Information
Name | Position | Phone | |
---|---|---|---|
Chief Technology Officer | +64 21 207 4880 | ||
DevOps Engineer | +55 22 99967 9572 | ||
Lead Frontend Engineer | +64 21 947 878 | ||
Manuel Seidel | CEO |
| |
Helene | COO |
| |
Beks | HR Manager |
|
Appendix B – AWS Root Account Compromise Playbook
Incident Response Runbook – Root Usage
Objective
The objective of this runbook is to provide specific guidance on how to manage Root AWS account usage. This runbook is not a substitute for an in-depth Incident Response strategy. This runbook focuses on the IR lifecycle:
Establish control.
Determine impact.
Recover as needed.
Investigate the root cause.
Improve.
The Indicators of Compromise (IOC), initial steps (stop the bleeding), and the detailed CLI commands needed to execute those steps are listed below.
Assumptions
CLI configured and installed.
Reporting process is already in place.
Trusted Advisor is active.
Security Hub is active.
Indicators of Compromise
Activity that is abnormal for the account.
Creation of IAM users.
CloudTrail turned off.
Cloudwatch turned off.
SNS paused.
Step Functions paused.
Launching of new or unexpected AMIs.
Changes to the contacts on the account.
Steps to Remediate – Establish Control
AWS documentation for a possible compromised account calls out the specific tasks listed below. The documentation for a possible compromised account can be found at: What do I do if I notice unauthorized activity in my AWS account?
Contact AWS Support and TAM as soon as possible.
Change and rotate Root password and add an MFA device associated with Root.
Rotate passwords, access/secret keys, and CLI commands relevant to remediation steps.
Review actions taken by the root user.
Open the runbooks for those actions.
Close incident.
Review the incident and understand what happened.
Fix the underlying issues, implement improvements, and update the runbook as needed.
Further Action Items – Determine Impact
Review created items and mutating calls. There are may be items that have been created to allow access in the future. Some things to look at:
IAM Cross account roles.
IAM Users.
S3 buckets.
EC2 instances.
SQS queues.
ECR repositories.
ECS clusters, services and tasks.
Parameter Store.
Appendix C - Notifiable Authorities
Jurisdiction | Governing Legislation | Notifiable Authorities |
---|---|---|
New Zealand | Office of the Privacy Commissioner https://www.privacy.org.nz/responsibilities/privacy-breaches/notify-us/report-a-breach/ | |
Australia | Office of the Australian Information Commissioner | |
ACT Public Sector | ||
Europe | Local Supervisory Authorities:
|
Appendix D - Incident Collection Form
We created a Trello Board (https://trello.com/b/nzjhbfqZ/incident-response-plan) to manage the reported incidents. The Incident Collection Form was created inside a template card (https://trello.com/c/upReKW5E/1-incident-collection-form-template-title-goes-here) on this board.
Appendix E - GDPR Breach Procedures for Personally Identifiable Information (PII) of EU Residents
Notification to Data Subjects
In the event that a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, ecoPortal, as Data Controller, shall communicate the personal data breach to the data subject without undue delay.
The communication to the data subject shall describe in clear and plain language the nature of the personal data breach and contain at least the following information:
(a) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;
(b) describe the likely consequences of the personal data breach;
(c) describe the measures taken or proposed to be taken by ecoPortal to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.
Notification to Data Controllers (i.e. Customers)
ecoPortal as a Data Processor shall notify the customer, as Data Controller, without undue delay after becoming aware of a personal data breach. The notification shall:
(a) describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
(b) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;
(c) describe the likely consequences of the personal data breach;
(d) describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.
Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay.
ecoPortal shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken.
Exceptions to the Breach Reporting Requirements
Communication to the data subject shall not be required if any of the following conditions are met:
(a) technical controls, such as encryption, render the personal data unintelligible to any person who is not authorized to access it
(b) the breach will not result in a high risk to the rights and freedoms of data subjects
(c) it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.