Policy Owner: Principal Engineer

Effective Date: 2023-05-01

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 or data privacy events or 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 which results in loss or damage to the confidentiality, availability, integrity, or privacy of company controlled data, systems or networks.

Incident Reporting & Documentation

Reporting

If a CloudCard 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 respond to the suspected incident by following the Incident Response Checklist via the Incident Response Plan - Quick Reference page.

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.

Quick Reference

Employees will be directed to the Incident Response Plan - Quick Reference page when responding to an incident. This page will ensure that employees coordinate response actions, document incident response actions in a consistent manner, and escalate incident response to appropriate personnel.

Severity

CloudCard Customer Support 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 behaviors. They are not verified and require further investigation. There is no clear indicator that systems have tangible risk and do not require emergency response. This includes lost/stolen laptop 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 laptop without encryption, vulnerabilities with direct risk of exploitation, threats with risk or adversarial persistence on our systems (e.g.: backdoors, malware), malicious access of business data (e.g.: passwords, vulnerability data, payments information).

S1 - Critical Severity

Critical issues relate to actively exploited risks and involve 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.

Escalation and Internal Reporting

The incident escalation contacts can be found in the Incident Response Checklist.

S1 - Critical Severity: A team member follows the Incident Response Checklist and notifies all of management to join the Incident Response call.

S2 - High Severity: A team member follows the Incident Response Checklist, and a Principal Engineer is notified to join the Incident Response call.

S3/S4 - Medium and Low Severity: A team member follows the Incident Response Checklist, and a member of the Engineering Team is notified to join the Incident Response call.

Documentation

All reported security events, incidents, and response activities shall be documented and adequately protected in the CloudCard Google Drive’s Incident Response folder.

If management verifies an incident as Critical, a root cause analysis must be performed. A root cause analysis report shall be documented and referenced in the incident ticket. The root cause analysis shall be reviewed by a Principal Engineer, and a post-mortem meeting will be performed to ensure all relevant staff are aware of the findings of the analysis.

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

• A Principal Engineer will manage the incident response effort

• If necessary, a central “War Room” will be designated, which will be a physical room for any collocated employees, and the Online Meeting Room will be linked in the Incident Response Plan - Quick Reference document.

• 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 Incidents

Incidents in which the malicious actor is an internal employee, contractor, vendor, or partner require sensitive handling. The incident manager shall contact the CEO directly and will not discuss these issues with other employees. These are critical issues that require follow-up.

Compromised Communications

Incident responders must arrange text message alerts 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 call.

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

• 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

• Incident responders shall collect, store, and preserve incident-related evidence in accordance with industry guidance and best practices, such as https://csrc.nist.gov/publications/detail/sp/800-86/final

• Suspected and confirmed unauthorized access events shall be reviewed by the Incident Response Team. Breach determinations shall only be made by a Principal Engineer.

• CloudCard shall promptly and properly notify customers, partners, users, affected parties, and regulatory agencies of relevant incidents or breaches in accordance with CloudCard policies, contractual commitments, and regulatory requirements, as determined by management in consultation with legal counsel.

• This Incident Response Plan shall be reviewed and formally tested at least annually, as described in Appendix: Preparedness Testing. 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

The Managing Director shall confer with the Principal Engineer and legal counsel teams in the event of unauthorized access to company or customer systems, networks, and/or data. The Managing Director shall then, in consultation with legal counsel, 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. The Customer Support team will handle the communications at the direction of the Managing Director.

No personnel may disclose information regarding incident or potential breaches to any third party or unauthorized person without the approval of the Managing Director.

All statements about the breach will be honest, and no key details will be withheld that would help consumers protect themselves and their information. No data will be publicly shared if it might put consumers at further risk.

The customer support team will anticipate questions that people will ask and articulate answers to those questions. The website will be updated with answers to questions in clear plain english so as to communicate in a concise and effective manner. As call and email volume increases, the customer support team will prioritize these questions on the website and add any additional entries if necessary.

Mitigation and Remediation

The Managing Director, in consultation with the Principal Engineer and legal counsel, shall determine any immediate or long term mitigations or remedial actions that need to be taken as a result of an incident or breach. In the event that mitigations or remedial actions are needed, the Managing Director shall direct personnel with respect to planning, communicating and executing those activities.

Cooperation with Customers, Data Controller and Authorities

As needed and determined by Managing Director in consultation with legal counsel, 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.

After Action Review / Lessons Learned

CloudCard shall conduct a lessons learned session after the resolution of any security incident, during which CloudCard employees and key stakeholders shall take stock of the incident; get to the root of how and why it happened; evaluate how well the IRP worked to resolve the issue; and identify improvements that need to be made.

The After Action Review will consist of five steps:

1. Identify and collect all comments and recommendations that may be useful for future projects.

2. Document all findings and share them with key stakeholders.

3. Analyze and organize all documentation for future application.

4. Store documentation in a repository that can be accessed by all key stakeholder.

5. Retrieve documentation for use on current or future incidents.

Several key questions will be asked and answered:

• What security, system, and/or process weakness were undercovered as a result of this incident whether or not they contributed to the breech?

• How can we improve the IRP?

• What parts of the icident response process worked well?  Did we do anything positive that needed to be added to the IRP?

Roles & Responsibilities

Every employee and user of any CloudCard information resources has responsibilities toward the protection of the information assets. The table below establishes the specific responsibilities of the incident responder roles.

Response Team Members

Management Commitment

CloudCard 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 affect the company or its customers adversely.

Exceptions

Requests for an exception to this Policy must be submitted to management for approval. Exceptions shall be documented.

Violations & Enforcement

Any known violations of this policy should be reported to management. 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: Incident Collection

When handling an incident, employees should follow the steps in the Incident Response Plan - Quick Reference to fill out the Google Document for a New Incident.

Appendix: Playbooks

Common or foreseeable incident scenarios should be collected in the Google Drive Incident Response> Playbooks folder for easy reference during an incident.

Appendix: - Preparedness Testing

At least once every 12 months, CloudCard shall test the IRP with a tabletop exercise to validate the IRP and organizational and system preparedness. Incident response plan testing should address:

• Communication – Testing of the processes that facilitate communication between incident handlers will ensure:

  • Up-to-date contact information between internal and external stakeholders (e.g., law enforcement, third-party security providers)

  • Working systems for incident escalations 

  • Industry-standard encryption of the communication devices 

  • Available facility for communication and incident management

• Analysis tools – Similarly, incident response testing should ensure that the tools used to conduct threat analysis are functioning optimally. The hardware and software used in the incident analysis phase include:

  • Cloud-based reports and analysis scripts for accessing pertinent incident information

  • Laptops for connecting to remote resources and managing the response.

• Analysis resources – There should also be resources available for all incident analysis processes. Incident response plan testing will ensure up-to-date:

  • Documentation for all security protocols

  • Network diagrams and critical asset inventory