JupiterOne Integration for Elastic

JupiterOne provides continuous monitoring to surface problems impacting critical assets and infrastructure. Secure your attack surface with continuous asset discovery and attack path analysis. Reduce risk, triage incidents, and prioritize vulnerability findings with greater clarity and 85% fewer SecOps resources.

The JupiterOne integration for Elastic allows you to collect logs using JupiterOne API, then visualise the data in Kibana.

The JupiterOne integration uses the GraphQL endpoint to collect assests.

This integration periodically queries the JupiterOne API to retrieve details for assets of class alert, vulnerability, and finding.

This integration collects assets of the following classes:

• Alert.
• Vulnerability.
• Finding.

Integrating JupiterOne Alert, Finding, and Vulnerability data with SIEM dashboards delivers unified visibility into risk signals, asset classifications, and security posture across the environment. Dashboards summarize asset class, type, and source distributions, highlight classification and status trends, and surface key risk attributes such as category, level, and severity. Time-based severity trends, MITRE mappings, and product or device-based breakdowns help analysts understand threat patterns and prioritize response. Metrics for open alerts, closed alerts, open vulnerabilities, and affected entities provide quick operational insight, while tables of top device IPs and product versions add valuable investigative context. Together, these visualizations enable teams to track risks, monitor asset health, and strengthen overall detection and remediation efforts.

This integration installs Elastic latest transforms. For more details, check the Transform setup and requirements.

To collect data from JupiterOne, Authentication is handled using a API Token and Account ID, which serve as the required credentials.

1. Log in to the account you want to manage.
2. Go to Settings > Account Management.
3. In the left panel, click the Key Icon.
4. In the User API Keys page, click Add.
5. In the API Keys modal, enter the name of the key and the number of days before it expires, and click Create.

For more details, check Documentation.

This integration supports both Elastic Managed and Agent-based installations.

Elastic Managed integrations are only supported on Elastic Cloud Serverless and Elastic Cloud Hosted deployments. An Elastic Managed integration lets you ingest data from a cloud source while avoiding the orchestration, management, and maintenance associated with standard ingest infrastructure. Elastic runs the collector for you, so you can focus on your data instead of the infrastructure that collects it.

For more information, refer to Elastic Managed integrations and the Elastic Managed integrations FAQ.

Elastic Agent must be installed. For more details, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host.

1. In the top search bar in Kibana, search for Integrations.

2. In the search bar, type JupiterOne.

3. Select the JupiterOne integration from the search results.

4. Select Add JupiterOne to add the integration.

5. Enable and configure only the collection methods which you will use.

   • To Collect assets from JupiterOne API, you'll need to:

     • Configure URL, Account ID and API Token.
     • Enable the dataset.
     • Adjust the integration configuration parameters if required, including the Interval, etc. to enable data collection.

6. Select Save and continue to save the integration.

1. In the top search bar in Kibana, search for Dashboards.
2. In the search bar, type jupiter_one.
3. Select a dashboard for the dataset you are collecting, and verify the dashboard information is populated.

1. In the top search bar in Kibana, search for Transforms.
2. Select the Data / Transforms from the search results.
3. In the search bar, type jupiter_one.
4. All transforms from the search results should indicate Healthy under the Health column.

For more information on architectures that can be used for scaling this integration, check the Ingest Architectures documentation.

These inputs can be used in this integration:

• CEL

This integration dataset uses the following API:

• Asset: JupiterOne API.

The data streams below collect a full snapshot of JupiterOne risks and alerts on every polling interval, so their backing indices hold one copy of each record per interval.

The package bounds the growth of these source data streams with a retention that depends on the deployment type:

On self-managed and Elastic Cloud Hosted deployments the ILM policy applies. The data stream lifecycle shipped with the package is not used there. ILM counts the delete age from the rollover of a backing index, so a document can remain for up to the rollover age plus the delete age. On Serverless, ILM is not available and the data stream lifecycle applies instead. It also works per backing index: Elasticsearch rolls the write index over automatically on age, size, or document count, and deletes a backing index once the retention has passed since it rolled over. A document therefore stays for the retention plus up to one rollover interval. The rollover age is derived from the retention and is an implementation detail that Elasticsearch may change. Where the package installs a transform, the transform's destination indices are not affected by either.

To keep data for a different period:

• Self-managed and Elastic Cloud Hosted: edit the ILM policy in Kibana under Stack Management → Index Lifecycle Policies, or with PUT _ilm/policy/<policy name>. A package upgrade reinstalls the package's ILM policies, so check your change after upgrading.
• Serverless: set the retention on the data stream, for example PUT _data_stream/logs-jupiter_one.risks_and_alerts-default/_lifecycle with the body {"data_retention": "90d"}. Replace default with your namespace.

This integration includes one or more Kibana dashboards that visualizes the data collected by the integration. The screenshots below illustrate how the ingested data is displayed.