Configuration and Change Management


JupiterOne standardizes and automates configuration management through the use of automation scripts as well as documentation of all changes to production systems and networks. Automation tools such as Terraform automatically configure all JupiterOne systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.

Policy Statements

JupiterOne policy requires that:

(a) ALL production changes, including but not limited to software deployment, feature toggle enablement, network infrastructure changes, and access control authorization updates, must go through the approved change management process.

(b) Each production change must maintain complete traceability to fully document the request, including requestor, date/time of change, actions taken and results.

(c) Each production change must be fully tested prior to implementation.

(d) Each production change must include a response plan for dealing with failure should the change produce unwanted results.

(e) Each production change must include proper approval:

Controls and Procedures

Configuration Management Processes

  1. Configuration management is automated using industry-recognized tools like Terraform to enforce secure configuration standards.

  2. All infrastructure changes to production systems, network devices, and firewalls are reviewed and approved by Security Team before they are implemented to assure they comply with business and security requirements.

  3. All changes to production systems are tested before they are implemented in production.

  4. Implementation of approved changes is only performed by authorized personnel.

  5. Tooling is used to generate an up to date system inventory:

    • All systems are categorized and labeled by their corresponding environment, such as dev, test, and prod.
    • All systems are classified and labeled based on the data they store or process, according to the Data Classification Model.
    • The Security Team uses JupiterOne Platform to monitor all changes to IT assets and generate inventory lists, using API integrations and services provided by each cloud provider.
    • The JupiterOne Platform is used to generate the diagrams and asset lists required by the Risk Assessment phase of §Risk Management
    • The JupiterOne Change Management process ensures that all asset inventory created by automation is reconciled against real changes to production systems. This process includes periodic manual audits and approvals.
    • During each change implementation, the change is reviewed and verified by the target asset owner as needed.
  6. JupiterOne uses the CIS Benchmarks published by the Center for Internet Security as a baseline for hardening production systems.

    • Linux-based production systems use the [CIS Hardened Image( appropriate to their base distribution if available, or utilize a secure base image like Alpine Linux.
    • EC2 instances in AWS are provisioned using only hardened and approved Amazon Machine Images (AMIs).
    • Docker containers are launched using only approved Docker images that have been through security testing.
  7. All production IT assets in JupiterOne have time synchronized to a single authoritative source:

  8. All frontend functionality (e.g. user dashboards and portals) is separated from backend (e.g. database and app servers) systems by being deployed as separate servers, services, or containers.

  9. All software and systems are required to complete full-scale testing before being promoted to production.

  10. All code changes are reviewed to assure software code quality, while in development, to proactively detect potential security issues using pull-requests and static code analysis tools. More details can be found in the Code Promotion Processes section.

Configuration Monitoring and Auditing

All infrastructure and system configurations, including all software-defined sources, are centrally aggregated to the JupiterOne Platform which functions as a configuration management database (CMDB).

Configuration auditing rules are created according to established baseline, approved configuration standards and control policies. Deviations, misconfigurations, or configuration drifts are detected by these rules and alerted to the Security Team.

Production Systems Provisioning

  1. Before provisioning any systems, a request must be created and approved in the GitHub PRODCM Tracking Repo (PRODCM - Production Change Management).

  2. The Security Team must approve the provisioning request before any new system can be provisioned, unless a pre-approved automation process is followed.

  3. Once provisioning has been approved, the implementer must configure the new system according to the standard baseline chosen for the system’s role.

  4. If the system will be used to store sensitive information the implementer must ensure the volume containing this sensitive data is encrypted.

  5. Sensitive data in transit must always be encrypted.

  6. A security analysis is conducted once the system has been provisioned. This can be achieved either via automated configuration/vulnerability scans or manual inspection by the Security Team. Verifications include, but are not limited to:

    • Removal of default users used during provisioning.
    • Network configuration for system.
    • Data volume encryption settings.
    • Intrusion detection and virus scanning software installed.
  7. The new system is fully promoted into production upon successful verification against corresponding JupiterOne standards and change request approvals.

User Endpoint Security Controls and Configuration

  1. Employee laptops, including Windows, Mac, and Linux systems, are configured either:

    • Manually by the Security Team or the device owner; or
    • Automatically using a configuration management tool or equivalent scripts.
  2. The following security controls are applied at the minimum:

    • Disk encryption
    • Unique user accounts and strong passwords
    • Approved NTP servers
    • Approved security agents
    • Locking after 5 mins of inactivity
    • Auto-update of security patches
  3. The security configurations on all end-user systems are inspected by the Security Team through either a manual periodic review or an automated compliance auditing tool integrated with the JupiterOne Platform.

Production Server Hardening Guidelines and Processes

  1. Linux System Hardening: Linux systems have their baseline security configuration applied via automation tools. These tools cover:

    • Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
    • Stopping and disabling any unnecessary OS services.
    • Applying applicable CIS Benchmarks to OS and applications.
    • Configuring 15-minute session inactivity timeouts for SSH sessions.
    • Installing and configuring a virus scanner, if applicable.
    • Installing and configuring the NTP daemon, including ensuring that modifying system time cannot be performed by unprivileged users.
    • Configuring disk volumes for providers that do not have native support for encrypted data volumes, including ensuring that encryption keys are protected from unauthorized access.
    • Configuring audit logging as described in the Audit Logging section.
  2. Windows System Hardening:

    Windows systems are not used in JupiterOne production environments.

Configuration and Provisioning of Management Systems

  1. Provisioning management systems such as configuration management servers, remote access infrastructure, directory services, or monitoring systems follows the same procedure as provisioning a production system.

  2. Critical infrastructure roles applied to new systems must be clearly documented by the implementer in the change request.

Configuration and Management of Network Controls

All network devices, services, or controls on a sensitive network are configured such that:

In AWS, network controls are implemented using Virtual Private Clouds (VPCs) and Security Groups. The configurations are managed as code and stored in approved repos. All changes to the configuration follow the defined code review, change management and production deployment approval process.

Provisioning AWS Accounts

AWS Account Structure / Organization

JupiterOne maintains a single Organization in AWS, maintained in a top-level AWS account (master). Sub-accounts are connected that each hosts separate workloads and resources in its own sandboxed environment. The master account itself handles aggregated billing for all connected sub-accounts but does not host any workload, service or resource, with the exception of DNS records for JupiterOne root domain, using the AWS Route53 service. DNS records for subdomains are maintained in the corresponding sub-accounts.

Access to each account is funneled through our designated SSO provider, Google G Suite, which establishes a trust relationship to a set of predefined roles in the master account. Once authenticated, a user then leverages AWS IAM Assume Role capability to switch to a sub-account to access services and resources.

The account and network structure looks like the following:

SSO/IdP ── jupiterone-master
            │  └── billing and root DNS records only
            ├── jupiterone-dev
            │    └── VPC
            │        └── Subnets
            │             └── Security-Groups
            │                  └── EC2 instances
            │                       └── Docker containers
            ├── jupiterone-test
            │    └── VPC
            │         └── Subnets
            │              └── Security-Groups
            │                   └── EC2 instances
            │                        └── Docker containers
            ├── jupiterone-infra
            │    └── VPC
            │         └── Subnets
            │              └── Security-Groups
            │                   └── EC2 instances
            │                        └── Docker containers
            ├── jupiterone-prod-us
            │    └── VPC
            │         └── Subnets
            │              └── Security-Groups
            │                   └── EC2 instances
            │                        └── Docker containers
            ├── jupiterone-prod-us2


JupiterOne AWS environments and infrastructure are managed as code. Provisioning is accomplished using a set of automation scripts and Terraform code. Each new environment is created as a sub-account connected to jupiterone-master. The creation and provisioning of a new account follows the instructions documented in the “Bootstrap a new AWS environment” page of the Engineering wiki.

Automated change management for deploys to AWS

The JupiterOne Continuous Delivery Pipeline automates creation and validation of change requests. This is done in a 3-phase process:

Phase 1: Create/Validate Change Request Artifact

Jenkins is used for continuous delivery (build and deploy), and we employ Jenkins-GitHub PRODCM Tracking Repo automation such that:

Phase 2: Detect Change Details and Obtain Approval

A separate change-management-bot (cm-bot) is implemented to provide additional details to assist/automate the change artifact approval process:

!!! attention

      The following practices will fail this validation and result in
      manual processing, therefore should be avoided:

      * squashing commits on PR merges
      * commits after PR approval without re-approval

!!! important

  1. Note that the above flow does not catch weaknesses in design, and
  therefore does not replace the need for threat modeling and security
  review in the design phase.
  2. Additional requirements may be added later as the process continues
  to mature.

Phase 3: Detect Risky Changes, Deploy and Close

Jenkins job proceeds only with an approved and validated GitHub PRODCM Tracking Repo artifact.

Patch Management Procedures

Endpoint Devices

JupiterOne requires that endpoint devices are configured to automatically download and apply security updates shipped by the system vendor.

Cloud Resources

JupiterOne follows an immutable infrastructure methodology to keep the resources in the cloud environments immutable and up-to-date with security patches.

User Endpoints

JupiterOne requires auto-update for security patches to be enabled for all user endpoints, including laptops and workstations.

The auto-update configuration and update status on all end-user systems are inspected by Security Team through either manual periodic audits or automated compliance auditing agents installed on the endpoints.

Production Deploy / Code Promotion Processes

In order to promote changes into Production, a valid and approved Change Request (CR) is required. It can be created in the GitHub PRODCM Tracking Repo which implements the JupiterOne Change Management workflow, and manages changes and approvals.

GitHub PRODCM Tracking Repo Required Details

Each GitHub PRODCM Tracking Repo artifact requires the following information at a minimum:

Additional details are required for a code deploy, including:

Emergency Change

In the event of an emergency, the person or team tasked with emergency response is notified. This may include a combination or Development, Security, and/or Leadership.

If an emergency change must be made, such as mitigating a critical security vulnerability or recovering from a system downtime, and the standard change management process cannot be followed due to time constraint or personnel availability or other unforeseen issues, the change can be made by: