System Audits, Monitoring and Assessments


JupiterOne shall audit, monitor, and assess the access and activity of systems and applications that process or store production and/or sensitive data such as customer data in order to ensure compliance.

Audit activities may be limited by application, system, and/or network auditing capabilities and resources. JupiterOne shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of JupiterOne to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, JupiterOne shall audit access and activity to detect, report, and guard against:

This policy applies to all JupiterOne systems that store, transmit, or process customer data.

Policy Statements

JupiterOne policy requires that:

(a) All critical computing systems and software, both virtual and physical, must enable audit logging.

(b) Audit logs must include sufficient information to identify who did what, when, where.

(c) An annual audit of JupiterOne security controls must be conducted, either by a designated internal audit team or a qualified external audit firm. AUDT1

Controls and Procedures

Types of System Audits

JupiterOne’s auditing processes include the following:

Configuration and Activity Monitoring

This refers to the logging, monitoring, scanning and alerting of a system, account, or environment, which may be achieved using real-time automated scripts/software or a manual review/testing. This type of auditing is performed continuously as part of JupiterOne operations.

!!! tip “Examples include:”

* User: User and account-level audit trails generally monitor and log all
  commands directly initiated by the user, all identification and
  authentication attempts, and data and services accessed.
* Application: Application-level audit trails generally monitor and log
  all user activities, including data accessed and modified and specific
* System: System-level audit trails generally monitor and log user
  activities, applications accessed, file integrity, and other
  system-defined specific actions.
* Network: Network-level scans or audit trails generally monitor
  information on what is operating, perform penetrations, and identify
* Traffic: Incoming and outgoing traffic to into and out of
  production/restricted environments. For example, firewall logs or VPC
  flow logs in AWS.
* Data: This includes all successful and failed attempts at production
  data access and editing.

Data associated with above events will include origin, destination, action performed, timestamp, and other relevant details available.

Access Review

This refers to the review of all user and service accounts and permissions across JupiterOne operational environments, including on-premise systems, cloud environments such as AWS accounts, and other accounts such as Google G Suite-managed applications.

Compliance and Controls Audit

This refers to the audit performed against the Technical, Administrative, and/or Physical controls as defined in JupiterOne policies and procedures, to measure their adoption and effectiveness. This type of auditing is typically performed by either a designated internal audit team or an external audit firm, at defined intervals or prompted by a trigger event.

!!! tip “Potential trigger events include:”

* Scheduled compliance audit/assessment <sub>[AUDT1](/defined-review-periods.html)</sub>
* High risk or problem prone incidents or events, or as part of
  post-incident activities
* Business associate, customer, or partner complaints
* Identification of significant security vulnerabilities
* Atypical patterns of activity
* Failed authentication attempts
* Remote access use and activity
* Activity post termination
* Random audits

Security Events Analysis

Security logs, events, and audit trails are reviewed by the Security Team with the assistance of automated systems and processes.

Internal/Manual Auditing Activities

Additional manual reviews, such as user accounts and access auditing, may be necessary from time to time. These activities may be triggered by the events listed above.

Responsibility for audit activity is assigned to JupiterOne’s Security Officer.

Security Officer Audit Activity Responsibilities

The Security Officer shall:

Manual Audit Details

The manual audit process shall define and include:

Audit Requests

  1. A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Security Officer, Customer, Partner, or an Application owner or application user.

  2. A request for an audit for specific cause must include time frame, frequency, and nature of the request.

  3. A request for an audit must be reviewed and approved by JupiterOne’s Security Officer before proceeding. Under no circumstances shall detailed audit information be shared with parties without proper permissions and access to see such data.

    • Should the audit disclose that a workforce member has accessed customer data inappropriately, the minimum necessary/least privileged information shall be shared with JupiterOne’s Security Officer to determine appropriate sanction/corrective disciplinary action.
    • Only de-identified information shall be shared with a Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by JupiterOne’s Security Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that JupiterOne consider seeking guidance from the Risk Management Team and/or legal counsel.

Review and Reporting of Audit Findings

  1. Audit information that is gathered for specific-cause must be reviewed in a timely manner, at least monthly, by the responsible workforce member(s). AUDT4 Additional reviews are performed as needed to assure the proper data is being captured and retained.

  2. The reporting process shall allow for meaningful communication of the audit findings to relevant workforce members, Customers, or Partners.

    • Significant findings shall be reported immediately in a written format. JupiterOne’s security incident response form may be utilized to report a single event.
    • Routine findings shall be reported to the sponsoring leadership structure in a written report format.
  3. Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval.

  4. Security audits constitute an internal, confidential monitoring practice that may be included in JupiterOne’s performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative-level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable information shall not be included in the reports).

  5. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.

Remediation of Control Deficiencies

Most controls are continuously monitored and reported via automation on the JupiterOne Platform.

Control deficiencies identified as a result of an internal or external system audit are documented and reviewed with management.

The Security Team works with the corresponding control owner to prioritize and mitigate the control deficiency, including applying corrective actions, implementating additional controls or adjusting existing controls as needed.

Audit Trails and Application Security Events Logging Standard

JupiterOne logging standards requires application and system logs to contain sufficient information to determine who did what, when, where to ensure recording of security and audit events and to generate evidence for unauthorized activities.

All systems and software developed at JupiterOne must have security events logging enabled as part of or in addition to standard application logging.

Security Log Event System Requirements

Security events and audit logs MUST:

Security Log Event Attributes

All security log events must have the following attributes at minimum:

Security Log Event Types

The following types of security events must be logged at minimum:

Security Log Event Sensitive Fields

All application and system logs must remove or mask:

Security Event Log Examples and Configuration Guides

Examples of recommended application events for logging and their auditing purpose:

Events Purpose
Client requests and server responses forensics and debugging - details level is defined by application
Successful and unsuccessful login attempts authentication
Successful and failed access to application resources authorization, escalation of privileges
Excessive amount of requests from the client brute-forcing, malicious bots, denial of service attacks
E-mails sent by an application spamming, social engineering

Details and guidance for logging configuration in JupiterOne systems is documented at:

Audit Trail Integrity - Security Controls and Log Retention

  1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.
  2. All audit logs are protected in transit and encrypted at rest to control access to the content of the logs.
  3. Whenever possible, audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges.

    • Separate systems are used to apply the security principle of “separation of duties” to protect audit trails from hackers.
    • JupiterOne logging servers may include AWS CloudTrail, which provides easy reviewing of audit log data. AWS CloudTrail provides message summarization, reduction, and reporting functionality.
  4. Audit log data is retained locally on the audit log server or in the source environment for a period of three months.
  5. Beyond that, audit log data is encrypted and moved to warm storage (currently S3) using automated scripts, and is retained for a minimum of three years.
  6. Raw event audit data may be purged after one month / 30 days as long as the required details are sufficiently covered in aggregated audit logs/reports.
  7. Aggregated reports summarizing audit activities shall be retained for a period of seven years, and may be kept in cost-effective cold storage like AWS Glacier.

Auditing Customer and Partner Activity

  1. Periodic monitoring of Customer and Partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between JupiterOne and the 3rd party. JupiterOne will make every effort to assure Customers and Partners do not gain access to data outside of their own Environments.
  2. If it is determined that the Customer or Partner has exceeded the scope of access privileges, JupiterOne’s management and security must remedy the problem immediately.

Auditing and Assessment Tools

JupiterOne’s Security Officer is authorized to select and use assessment tools that are designed to detect vulnerabilities and intrusions. For example, vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls.

Use of such tools against JupiterOne systems and environments are prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:

Training, Education, Awareness and Responsibilities

  1. JupiterOne workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and customer data. JupiterOne’s commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies. JupiterOne workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies.
  2. JupiterOne Platform Customers are provided with necessary information to understand JupiterOne auditing capabilities. Customers are responsible for the logging, auditing and retention of any application hosted outside of JupiterOne environments, even though the applications may integrate with the JupiterOne Platform API. Customer applications, if any, hosted within the JupiterOne environments will follow the auditing standards and procedures defined in this document.