Security Incident Response Procedures

In the event that RunWhen detects a security incident that may involve customer data, this document outlines key contacts and communication procedures.

RunWhen's highest priority is to maintain a safe and secure environment for customer data. To help protect customer data, we run an industry-leading information security operation that combines stringent processes, an expert incident response team, and multi-layered information security and privacy infrastructure. This document explains our principled approach to managing and responding to data incidents in the RunWhen Platform.

Incident response is a key aspect of our overall security and privacy program. We have a rigorous process for managing data incidents. This process specifies actions, escalations, mitigation, resolution, and notification of any potential incidents that impact the confidentiality, integrity, or availability of customer data.

Data Incident Definition

RunWhen defines a data incident as “a breach of RunWhen's security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Data on systems managed by or otherwise controlled by RunWhen.” While we take steps to address foreseeable threats to data and systems, data incidents don't include unsuccessful attempts or activities that don't compromise the security of customer data. For example, data incidents aren't unsuccessful login attempts, pings, port scans, denial of service attacks, and other network attacks on firewalls or networked systems.

Data Breach Types

There are four types of data breaches that the team at RunWhen has identified, noted below. These are not intended to be mutually exclusive over time -- during a breach, the incident may start as one type and be re-evaluated to a different type as the situation evolves.

• Workspace Potential Data Breach

• User Identity Data Breach

• User Suspected Breach

• Ongoing Breach

Data Breach Communications

Workspace Potential Data Breach - Contacting Users

If the team at RunWhen has reason to suspect that an incident has occurred involving a potential breach of Workspace data, the team will make all commercially reasonable efforts to contact all users that have "admin" role via email. A Workspace may have unlimited users with an "admin" role. This is configured in the corresponding workspace.yaml file and in the UI shown below.

User Identity Breach - Contacting users

If the team at RunWhen has reason to suspect that an incident has occurred involving a potential breach of user identity (login) data, the team will make all commercially reasonable efforts to contact the impacted users by their primary email. As users may use a variety of single-sign-on technologies to access RunWhen, the system maintains a primary email address for each user that can be edited on the profile page as shown below.

User Suspected Breach - Contacting RunWhen

If a user has reason to believe that there has been a security incident that RunWhen did not detect, the appropriate contacts can be reached via the email alias security-and-compliance [at] http://runwhen.com .

Ongoing Breach - Roles and Responsibilities

If either a RunWhen user or the RunWhen team has reason to suspect there is an ongoing breach, the company's standard protocol is below:

1. Communication: Establish contact between user with administrative privileges ("Admin User") for the Workspace and the "RunWhen Local" agent installed in any user cluster and the RunWhen escalation team ("RunWhen Team") (step referenced above).

2. Mitigate Risk of Concurrent Workspace Data Breach: Delete the RunWhen Local agent namespace in the end user cluster to ensure that any data currently at risk of being exposed is secured (Admin User). On receiving Admin User authorization to proceed, delete the RunWhen Local Object and corresponding authorization token in the RunWhen Platform (Runwhen team).

3. Mitigate Risk of Historic Workspace Data Breach:

   1. If the Workspace uses RunWhen-managed encrypted GCP buckets for Enterprise Task Output Data, RunWhen Team will request authorization for deletion from Admin User for either (a) deletion of historic data, or (b) rotation of credentials to access historic data and, upon receipt, proceed accordingly. If there is any ambiguity in the response, or if there is no response and the RunWhen Team has reason to believe there is material risk, the RunWhen Team will proceed with (b).

   2. If the Workspace uses user-managed storage, the Admin User is responsible for taking actions appropriate with their organization's security incident response procedures.

Breach Disclosure

If there is a data breach, the company will make commercially reasonable efforts to disclose an anonymized version of the event publicly via the company blog unless the User requests it remain private. Timelines may vary depending on the depth of remediation required.

PII Data

The RunWhen Platform is not intended to carry any individual identifiable data beyond names and emails of RunWhen users. This includes SSNs, Drivers License numbers, Passport Numbers, Health/Biomedical Information of RunWhen users or of users of the systems provided by organizations that use RunWhen. If for any reason this data is leaked into the RunWhen system via User or third party contributed troubleshooting code, the company will make commercially reasonable efforts to remove this code from the RunWhen Platform until the issue can be remediated, and to delete any Enterprise Task Output Data where it may have appeared stored in RunWhen-managed encrypted buckets.

Following Industry Best Practices

RunWhen follows industry best practices in this area, specifically matched to those of our cloud provider, Google Cloud Platform. The sections below are adapted from their processes.

Incident Response - Team Organization

When RunWhen declares an incident, we designate an incident commander who coordinates incident response and resolution. The incident commander selects specialists from different teams and forms a response team. The incident commander delegates the responsibility for managing different aspects of the incident to these experts and manages the incident from the moment of declaration to closure. The following diagram depicts this organization of various roles and their responsibilities during incident response.

Data incident response team organization

General Steps In Incident Response

Every data incident is unique, and the goal of the data incident response process is to protect customer data, restore normal service as quickly as possible, and meet both regulatory and contractual compliance requirements. The following table describes the main steps in the RunWhen incident response program.

To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.

To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.

The following activities occur:

• On-call responder evaluates the nature of the incident report.

• On-call responder assesses severity of the incident and the type of the breach

• On-call responder assigns incident commander.

Response team engagement

The following activities occur:

• Incident commander completes assessment of known facts.

• Incident commander designates leads from relevant teams and forms incident response team.

• Incident response team evaluates incident and response effort.

Resolution

Investigation

The following activities occur:

• Incident response team gathers key facts about the incident.

• Additional resources are integrated as needed to allow for expedient resolution.

• Re-assess data breach type

Containment and recovery

Operations lead takes immediate steps to complete the following:

• Limit ongoing damage in the case of a suspected ongoing breach.

• Fix underlying issue.

• Restore affected systems and services to normal operations.

Communication

The following activities occur:

• Key facts are evaluated to determine whether notification is appropriate.

• Communications lead developers a communication plan with appropriate leads.

See notes on communication for different types above

Closure

Lessons learned

The following activities occur:

• Incident response team retrospects on incident and response effort.

• Incident command designates owners for long-term improvements.

Continuous improvement

Program development

Necessary teams, training, processes, resources, and tools are maintained.

Prevention

Teams improve the incident response program based on lessons learned.

The following sections describe each step in more detail.

Identification

Early and accurate identification of incidents is key to effective incident management. The focus of the identification phase is to monitor security events to detect and report on potential data incidents.

The incident detection team employs advanced detection tools, signals, and alert mechanisms that provide early indication of potential incidents. Our sources of incident detection include the following:

• Testing: The security team may actively scan for security threats using penetration tests, quality assurance (QA) measures, intrusion detection, and software security reviews.

• Internal code reviews: Source code review may discover hidden vulnerabilities, design flaws, and verifies if key security controls are implemented.

• RunWhen-specific tooling and processes: Automated tooling specific to the team function is employed wherever possible to enhance our ability to detect incidents at product level.

• RunWhen employees: A RunWhen employee detects an anomaly and reports it

Coordination

When an incident is reported, the on-call responder reviews and evaluates the nature of the incident report to determine if it represents a potential data incident and initiates our incident response process.

After confirmation, the responder hands incident over to an incident commander who assesses the nature of the incident and implements a coordinated approach to the response. At this stage, the response includes completing the triage assessment of the incident, adjusting its severity if required, and activating the required incident response team with appropriate operational and technical leads who review the facts and identify key areas that require investigation. We designate a product lead and a legal lead to make key decisions on how to respond. The incident commander assigns the responsibility for investigation and the facts are assembled.

Many aspects of our response depend on the assessment of severity, which is based on key facts that are gathered and analyzed by the incident response team. These key facts include the following:

• Potential for harm to customers, third parties, and RunWhen

• Nature of the incident (for example, whether data was potentially destroyed, accessed, or unavailable)

• Type of data that might be affected

• Impact of the incident on our customers’ ability to use the service

• Status of the incident (for example, whether the incident is isolated, continuing, or contained)

The incident commander and other leads periodically re-evaluate these factors throughout the response effort as new information evolves to ensure that our response is assigned the appropriate resources and urgency. Events that present the most critical impact are assigned the highest severity. A communications lead is appointed to develop a communications plan with other leads.

Resolution

At the resolution stage, the focus is on investigating the root cause, limiting the impact of the incident, resolving immediate security risks (if any), implementing necessary fixes as part of remediation, and recovering affected systems, data, and services.

Affected data is restored to its original state wherever possible. Depending on what is reasonable and necessary in a particular incident, we might take a number of different steps to resolve an incident. For instance, there might be a need for technical or forensic investigation to reconstruct the root cause of an issue or to identify any impact on customer data. We might attempt to recover copies of the data from our backup copies if data is improperly altered or destroyed.

A key aspect of remediation is notifying customers when incidents impact their data. Key facts are evaluated throughout the incident to determine whether the incident affected customer data. If notifying customers is appropriate, the incident commander initiates the notification process. The communications lead develops a communication plan with input from the product and legal leads, informs those affected, and supports customer requests after notification.

We strive to provide prompt, clear, and accurate notifications containing the known details of the data incident, steps that we have taken to mitigate the potential risks, and actions that we recommend customers take to address the incident. We do our best to provide a clear picture of the incident so that customers can assess and fulfill their own notification obligations.

Closure

Following the successful remediation and resolution of a data incident, the incident response team evaluates the lessons learned from the incident. When the incident raises critical issues, the incident commander might initiate a post-mortem analysis. During this process, the incident response team reviews the causes of the incident and our response and identifies key areas for improvement. In some cases, this might require discussions with different product, engineering, and operations teams and product enhancement work. If follow-up work is required, the incident response team develops an action plan to complete that work and assigns project managers to lead the long-term effort. The incident is closed after the remediation efforts conclude.

Continuous improvement

At RunWhen, we strive to learn from every incident and implement preventative measures to avoid future incidents.

Actionable insights from incident analysis enable us to enhance our tools, training, processes, overall security and privacy data protection program, security policies, and response efforts. The key learnings also facilitate prioritization of engineering efforts and building of better products.

Security and privacy professionals enhance our program by reviewing our security plans for all networks, systems, and services, and by providing project-specific consulting services to product and engineering teams. Security and privacy professionals deploy machine learning, data analysis, and other novel techniques to monitor for suspicious activity on our networks, address information security threats, perform routine security evaluations and audits, and engage outside experts to conduct regular security assessments.