Skip to main content

Alerts

JupiterOne Alerts is a powerful tool that enables you to automatically monitor your workspace through the use of rules. By configuring rules, you are able to execute and leverage J1QL queries that run on a particular interval to run and look for findings on their designated interval. When these rules run a query and find results, you are notified by an alert, which can be configured to be sent through various channels of your choosing.

JupiterOne Alerts main view

By using Alerts, you can begin to embed JupiterOne into your existing security workflows. For example, if a security finding requires remediation, you could configure that alert to create a corresponding Jira ticket to then be addressed. Depending on severity, it could also send a Slack or email notification to the appropriate team. By creating custom rules, you can curate the alert behavior to your specific needs.

info

In addition to custom alerts, JupiterOne offers pre-configured rule packs that provide rules built around various tools and use cases. Read more about rule packs

Creating Alert Rules​

To create a single rule for alerts:

  1. Navigate to the Alerts and select the Rules tab.

  2. Click New Rule.

  3. Provide the following details for the new custom rule:

    • Name: Name for the alert rule.
    • Description: Brief description of the rule.
    • Severity: The level of severity for the particular alert (Info, Low, Medium, High, Critical)
    • Evaluation interval: The interval for which the system re-evaluates the rule (Disabled, 1 week, 1 day, 12 hours, 8 hours, 4 hours, 1 hour, 30 minutes)
    • Tags: Additional metadata tags to refer to the particular rule.
    • Users: The user(s) that should receive the alert.

      If no user(s) are specified, it will notify all JupiterOne workspace owners by default.

    • Query: The J1QL query used to monitor changes to trigger the alert.

    Tip: ORDER BY

    Best Practice: It is discouraged to use the ORDER BY J1QL keyword within the query powering an Alert Rule as it may cause unexpected rule evaluation failures and slower performance.​

  4. In the Action Trigger Conditions section, configure at what threshold the actions should run. The default is set up to trigger actions when the first query returns more than 0 results.

  5. Select the appropriate Actions for the rule to take when action trigger conditions are met. By default it will send a JupiterOne Alert.

note

Some configuration options may vary depending on your workspace plan with JupiterOne.

note

Rules that have failed to successfully run in over 30 days and have not received any updates will automatically be disabled and moved to the "System Disabled" state.

Additional configuration​

JupiterOne offers additional actions and flexibility around building alerts into workflows outside of JupiterOne. You can configure more complex actions such as sending an Alert notification to a designated Slack channel, or creating a Jira ticket based on an alert.

Actions​

When creating a rule, you can specify any of the following actions to be made when the alert is triggered:

  • Email: You provide the email addresses to alert and what you want in the email message.

  • Slack: You must first configure the Slack integration for JupiterOne by following these instructions. Ensure that you specify the channel in the format #channel.

    • Troubleshooting note: If you are having trouble with Slack messages not sending, ensure that the JupiterOne Slack integration has been set up with the correct permissions. The JupiterOne Slack integration must have the chat:write and chat:write.public permissions to send messages to Slack. Additionally, you will want to ensure that the Slack integration has been authorized.

  • JIRA: You must first configure the JIRA integration for JupiterOne by following these instructions. When you create a rule that triggers the creation of a Jira ticket, you provide the following:

    • Summary: title of the Jira ticket
    • Description: JupiterOne automatically lists the affected entities and the associated query, but you can edit this field to contain other information.
    • Project: ID of the Jira project to which you want to assign the ticket.
    • Issue Type: type of issue you want the Jira ticket to be, such as task or bug.
    • Entity Class: (mandatory field) the class of the new ticket entity that you want to assign to the ticket, such as vulnerability or policy. Integrations Instance: select the Jira instance from the dropdown menu.
    • Additional Fields: you can add any other of the Jira ticket fields if you want to return that information.
    • Auto-Resolve: Automatically closes Jira tickets when there are no more results that match the alert rule. For example, whenever the rule goes from zero results to >0 results, JupiterOne will open a new Jira ticket. Whenever the query returns an empty result set, the previously opened ticket will be marked as Resolved via the Jira integration. Note: this will not close any Jira tickets upon alert dismissal. Read more about the JupiterOne alert rule schema

  • ServiceNow: Select the integration instance from the dropdown menu and enter the content for the request body. The message body is sent to the /api/now/table incident endpoint. Go to the REST API Explorer page in your ServiceNow deployment to learn about additional fields. The request automatically assigns the number property to be j1:{rule-instance-id}.

  • SNS: The AWS account you want to send to must be configured as an AWS Integration, and the J1 IAM role for the AWS account you want to publish to must have the SNS:Publish permission.

  • SQS: The AWS account you want to send to must be configured as an AWS Integration, and the J1 IAM role for the AWS account you want to publish to must have the SQS:SendMessage permission.

  • Webhook: Sends a message to the specified webhook URL.

  • Tines Trigger: Pushes data from a JupiterOne query to a Tines action workflow.

Templates​

You can also use templates when adding rules. The template goes inside any property under the operations property for a rule. Templates can contain JavaScript-like syntax that have input variables automatically inserted for usage. See the alert rule schema for more information about the templates property.

Managing alerts​

From within the Alerts table, you are able to select and view individual alerts. By selecting a particular alert, you can view its activity and review the query and its results over time.

JupiterOne Alert activity view

From within the table, you can also edit the rule associated to the alert and dismiss the alert. Dismissing an alert will stop the alert from running until its the next evaluation has results.

Rule Evaluation History​

You can also view the history of rule evaluations whether they've created an alert or not. When you click into a rule from the Rules page, the Evaluation History tab will show you the following information:

JupiterOne Alert activity view

  • The results of the query(ies) associated with the rule configuration, as well as the evaluation duration.
    • If there were new entities found compared to the rule's last successful evaluation, you can toggle to view only the new entities. Note that if the query has changed between evaluation runs, the results may all be considered new.
  • Whether the condition to proceed to running actions was met.
    • The default condition on a rule is met when the number of the first query's results is greater than 0.
  • The actions that were taken, if any, and the status of those actions.
    • If there were action failures, there are logs to help troubleshoot the issue.

Contents