JupiterOne implements an information security Incident Response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.
The Incident Response process addresses:
These policies were adapted from work by the [HIPAA Collaborative of Wisconsin Security Networking Group][ir-1]. Refer to the linked document for additional copyright information.
JupiterOne policy requires that:
(a) All computing environments and systems must be monitored in accordance to the policies and procedures specified in the following JupiterOne policies and procedures:
(b) All alerts must be reviewed to identify security incidents. Incidents are documented in the GitHub Security Tracking Repo by the Security Team.
(c) Incident response procedures are invoked upon discovery of a valid security incident.
(d) The Security Incident Response Team and Management must comply with any additional requests by law enforcement in the event of criminal investigation or national security, including but not limited to warranted data requests, subpoenas, and breach notifications.
The Security Incident Response Team (SIRT) has the following responsibilities:
Current members of the JupiterOne SIRT:
The JupiterOne incident response process follows the process recommended by SANS, an industry leader in security.
JupiterOne’s incident response defines security events and incident types as: Event, Non-Impact Incident, Incident with Impact, and Breach.
Any observable computer security-related occurrence in a system or network with a negative consequence. Examples:
An event that did result in degraded performance, SIRT team activity, or follow up tickets. This may not be a malicious incident, but could be a reported critical vulnerability that requires triage. No customer facing utility was involved/degraded. Examples:
A confirmed attack / indicator of compromise, often resulting in data breaches. Examples:
A confirmed attack or event that resulted in customer data, PII, or other regulatory data to be exposed or in some way altered. Examples:
JupiterOne employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email or Slack). In practice this means keeping an eye out for security events, and letting the Security team know about any observed precursors or indications as soon as they are discovered.
Any event escalated to any type of incident shall trigger an associated playbook. Playbooks are stored in the JupiterOne [Engineering Wiki](https://github.com/jupiterone/wiki/), and follow the basic SANS incident response flow, outlined below:
Immediately upon observation JupiterOne members report suspected and known Events, Precursors, Indications, and Incidents.
The individual receiving the report facilitates the collection of additional information about the incident, as needed, and notifies the Security Officer (if not already done).
The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident.
If the issue is an event or non-security related the Security Officer forwards it to the appropriate resource for resolution.
If the issue is a security incident the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior leadership by email or Slack.
The lead member of the SIRT team facilitates initiation of an Incident Issue in the GitHub Security Tracking Repo and documents all findings and details in the Issue.
The Security Officer or delegated JupiterOne representative notifies any affected Customers and Partners.
In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to JupiterOne and potentially external.
In this Phase, JupiterOne’s Development and Security Teams attempt to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This ensures that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.
The Eradication Phase represents the SIRT’s effort to remove the cause, and the resulting security exposures, that are now on the affected system(s).
Strengthen the defenses surrounding the affected system(s), where possible (a risk assessment may be needed and can be determined by the Security Officer). This may include the following:
Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.
The Recovery Phase represents the SIRT’s effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.
The technical team determines if the affected system(s) have been changed in any way.
The Analysis & Follow-up Phase represents the review of the security incident to look for “lessons learned” and to determine whether the process that was taken could have been improved in any way. It is recommended all security incidents be reviewed shortly after resolution to determine where response could be improved. Timeframes may extend to one to two weeks post-incident.
It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding the JupiterOne’s expectation for them, relative to security responsibilities. The incident response plan is tested annually. IR1
Incident Classifications are based of the work done by ENISA in developing a comprehensive IR Taxonomy.
Reference: ENISA Taxonomy Guide
Abusive Content – Spam, Harassment, Child Porn, Sexual or Violent content, etc.
Malicious Code – Virus, Worm, Trojan, Spyware, etc.
Information Gathering – Scanning, Sniffing, Social Engineering
Intrusions and Intrusion Attempts – Brute Force, 0-days, Account Compromise
Availability Attack – DOS, DDOS, Sabotage
Change Management – Unauthorized changes to production systems, deployment of misconfigurations
Vulnerable - Reported vulnerabilities
Fraud - Unauthorized use of resources, Copyright, Masquerade
Other - All other incidents that don’t fit above descriptions
Critical – Incident that involves immediate and significant interruption to business operations and/or breach of critical or confidential data
Major – Incident that involves immediate interruption to business operations but will not likely result in immediate data breach
Minor – All other confirmed incidents
The following special cases are considered when responding to an incident:
In the event of an attack that involves suspected criminal activities, the SIRT and management team will inform law enforcement.
Members of the cross-discipline insider threat incident handling team include:
If an incident constitutes an emergency – for example, an ongoing sabotage campaign where data is being deleted - JupiterOne plans to utilize an Emergency Operations Mode. Below outlines the two different operational modes. In both cases activation must be approved by at least two of the following before being enacted:
In emergency operations mode, temporary access may be granted to security and/or engineering team to access the production environments to perform forensics, root cause analysis, eradication/remediation, or other necessary activities for incident recovery.
JupiterOne’s Read Only Mode pauses all write activity in a production AWS account. Customers still can read their data, but no further edits can be made.This is accomplished by access policies in production AWS environments.
An example for when this Emergency Mode might be activated: A threat actor is writing continuous short bursts of data, at a large scale, causing increasing costs and system instability. While we investigate and eradicate the threat we will implement a Read-Only Mode in order to prevent the threat from continuing.
JupiterOne’s System Offline Mode completely isolates a production system. This is accomplished by a combination of access control policies and firewall policies. During this time period customers will not be able to access their data.
An example for when this Emergency Mode might be activated: A threat actor has been able to compromise a production account and is exfiltrating large amounts of data.
At least once per year, JupiterOne security and engineering teams jointly performs a Red Team exercise and/or a simulated “drill” of an emergency cyberattack that results in one or more CRITICAL incidents. IR1 Depending on the type of exercise, the duration may range from 2-4 hours (simulated “drill”) to a couple of weeks (full Red Teaming exercise).
The exercise will follow a cyberattack playbook. It may be conducted with all internal resources or with the help of an external security consulting firm. The goal of the exercise is to ensure all parties involved receive proper training to handle an actual incident and to test out the documented procedures in order to identify gaps ahead of a real event. Senior leadership team may be invited to participate in the “drill” depending on the nature of the exercise or receive a readout of the outcome.
A record is created for each reported incident in GitHub Security Tracking Repo. Each incident record contains details about the incident capturing the incident attributes and progression, including the following as applicable:
If a more detailed post-mortem is applicable, the Security and/or Development Teams will create the write-up and link it in the incident record.