Skip to main content

Varonis

Bring Varonis SaaS threat detection into JupiterOne. Ingest your Varonis threat models and the alerts they raise, see which users and hosts each alert involves, and query, prioritize and alert on Varonis findings next to the rest of your assets.

Installation​

This integration connects to the Varonis SaaS API on your tenant (https://<your tenant>.varonis.io) and ingests your Varonis threat models and the alerts they raised. It authenticates with a Varonis API key, which it exchanges for a short-lived access token, and it only reads data. The integration is managed by JupiterOne and runs in the JupiterOne cloud, so no collector is needed.

This version supports Varonis SaaS. Self-hosted Varonis Data Security Platform (DatAdvantage) is not supported yet.

Prerequisites​

  • A Varonis SaaS tenant, and an administrator who can create API keys.
  • Access to JupiterOne with permission to configure integrations.

Configuration in Varonis​

Create an API key​

  1. Sign in to your Varonis SaaS tenant.
  2. Open Configuration > API Keys and create a new API key.
  3. Assign the key the Threat Detection Integrator role.
  4. Copy the key and store it somewhere safe.

Find your tenant hostname​

The hostname is the address you use to sign in to Varonis SaaS, without https:// or a path, for example acme.varonis.io.

Configuration in JupiterOne​

To install the Varonis integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Varonis. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Varonis account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The fields below.

Authentication fields​

FieldRequiredDescription
Varonis HostnameYesYour Varonis SaaS tenant hostname, for example acme.varonis.io. An https:// prefix is accepted; a path, port or IP address is not.
API KeyYesThe Varonis API key created above. It is masked in JupiterOne.

Alert settings​

FieldDefaultDescription
Alert Lookback30 daysHow many days of alerts to ingest, by alert time: 30, 60 or 90 days.
Minimum Alert SeverityMedium and aboveThe lowest alert severity to ingest: High, Medium and above, Low and above, or All (including Informational).

When you save the instance, JupiterOne exchanges the API key for an access token and reads your threat models. A wrong hostname or an API key that is invalid, expired or missing the Threat Detection Integrator role fails the check.

Click Create once all values are provided to finalize the integration.

Data Sources​

The data source is disabled by default, so a new instance ingests only the varonis_account entity until you enable it. To enable it, open the instance, turn on Threat Models and Alerts under Data Sources, and save. It is ingested on the next run.

Data SourceDescriptionEntities Created
Threat Models and AlertsVaronis threat models, and the alerts they raised in the lookback window at or above the minimum severity, with their severity, status, category, close reason, event count, asset path, MITRE tactic and whether sensitive data is involved.varonis_threat_model, varonis_alert
RelationshipRequires
varonis_account HAS varonis_threat_modelThreat Models and Alerts
varonis_threat_model GENERATED varonis_alertThreat Models and Alerts
User HAS varonis_alert (mapped)Threat Models and Alerts, and a User entity whose username matches
Host HAS varonis_alert (mapped)Threat Models and Alerts, and a Host entity whose hostname matches

Required permissions​

The API key needs the Threat Detection Integrator role. The integration only reads threat models and alerts; it never changes alert status or adds notes.

Notes​

  • Users and hosts are matched by name. An alert is related to the User entities whose username equals the SAM account name Varonis reports (without a DOMAIN\ prefix), and to the Host entities whose hostname equals the device hostname Varonis reports. Both the reported spelling and its lowercase form are matched, for up to 10 users and 10 hosts per alert. Directory integrations that store a different form, such as an email address, as username are not matched. Device names that are IP addresses are not matched.
  • The alert window rolls forward. Each run ingests the alerts from the last 30, 60 or 90 days. Alerts that fall out of the window, or below the minimum severity, are removed from the graph on the next run. Lowering the lookback or raising the minimum severity removes the alerts outside the new setting.
  • Alerted events are not ingested. The integration reads alerts, not the individual events behind them.
  • Raw data is not stored for alerts. Every alert field the integration reads is mapped to a property, so varonis_alert raw data holds only a redaction note.
  • Alert searches run asynchronously. Varonis runs each alert search on the tenant and the integration waits for it to finish, up to about three minutes, before it reads the results.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​