> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Bitdefender GravityZone alert integration

> Send malware, ransomware, network attack and incident detections from Bitdefender GravityZone to Flashduty On-call through the Event Push Service.

The GravityZone Event Push Service posts detection events to a URL as JSON-RPC 2.0 `addEvents` requests. Once connected, each detection event becomes one alert in Flashduty On-call. The detection events GravityZone pushes carry no recovery signal, so turn on auto-close for the channel.

<div className="hide">
  ## In Flashduty On-call

  ***

  You can get the push URL in either of the following ways.

  ### Use a dedicated integration

  1. In the Flashduty console, select **Channels** and open a channel
  2. Select **Settings** → **Integrations** → **Dedicated integrations**, then click **Add an integration**
  3. Select **Bitdefender** and click **Save**
  4. Open the generated integration card and copy the **push URL**

  ### Use a shared integration

  1. In the Flashduty console, select **Integration Center → Alert Events**
  2. Select **Bitdefender** and enter an integration name
  3. Configure the default route and select a channel; you can add more rules under **Routes** after the integration is created
  4. Click **Save** and copy the generated **push URL**
</div>

## In GravityZone

***

The Event Push Service is configured only through the GravityZone public API; the console has no screen for it.

<Steps>
  <Step title="Create an API key">
    1. Sign in to GravityZone Control Center, click the user icon in the upper-right corner, and select **My Account**
    2. In the **API keys** section, generate an API key and select **Event Push Service API**
    3. In the **Control Center API** section of the same page, copy the **Access URL**; it is written as `CONTROL_CENTER_APIs_ACCESS_URL` below
  </Step>

  <Step title="Set the push service">
    Send a `setPushEventSettings` request to `CONTROL_CENTER_APIs_ACCESS_URL/v1.0/jsonrpc/push`. Use HTTP POST with `Content-Type: application/json` and HTTP Basic authentication, the API key as the user name and an empty password:

    ```bash theme={null}
    curl -s -u "<API_KEY>:" -H "Content-Type: application/json" \
      -X POST "CONTROL_CENTER_APIs_ACCESS_URL/v1.0/jsonrpc/push" \
      -d '{
        "jsonrpc": "2.0",
        "id": "flashduty-setup",
        "method": "setPushEventSettings",
        "params": {
          "status": 1,
          "serviceType": "jsonRPC",
          "serviceSettings": {
            "url": "<Flashduty push URL>",
            "requireValidSslCertificate": true
          },
          "subscribeToEventTypes": {
            "av": true,
            "hd": true,
            "aph": true,
            "avc": true,
            "dp": true,
            "fw": true,
            "antiexploit": true,
            "network-monitor": true,
            "network-sandboxing": true,
            "ransomware-mitigation": true,
            "exchange-malware": true,
            "new-extended-incident": true
          }
        }
      }'
    ```

    `"result": true` means the settings were saved. `serviceType` must be `jsonRPC`. The Event Push Service needs the receiver to support TLS 1.2 or later and sends from a fixed set of IP addresses; if you restrict the Flashduty endpoint by IP, allow the addresses listed on the [setPushEventSettings](https://www.bitdefender.com/business/support/en/77209-135319-setpusheventsettings.html) page.
  </Step>

  <Step title="Send a test event and verify">
    Call `sendTestPushEvent` with `eventType` set to `av`. GravityZone posts an event with `"_testEvent_": true` to the push URL:

    ```bash theme={null}
    curl -s -u "<API_KEY>:" -H "Content-Type: application/json" \
      -X POST "CONTROL_CENTER_APIs_ACCESS_URL/v1.0/jsonrpc/push" \
      -d '{"jsonrpc":"2.0","id":"flashduty-test","method":"sendTestPushEvent","params":{"eventType":"av"}}'
    ```

    Flashduty opens a separate Info alert titled `Bitdefender GravityZone test notification`. Every test opens a new alert, and none is recovered, so close them by hand. Then use the [EICAR test file](https://www.eicar.org/) on a managed endpoint to trigger a real Antimalware detection and confirm that Flashduty receives a Warning alert.
  </Step>
</Steps>

## Turn on auto-close

***

Detection events are one-shot, and GravityZone never pushes a recovery. In the channel that receives them, turn on [auto-close](/en/on-call/channel/create-edit) with a suggested duration of 24 hours, counted from **Incident trigger**. While an alert is open, a repeat detection of the same threat merges into it; a detection after it closes creates a new alert.

## Supported event types

***

Only the detection events in the table create alerts. Status and inventory events (such as `modules`, `sva`, `registration`, `task-status`, `install`, `uninstall`, `uc` and `adcloud`) are ignored: Flashduty returns success and does nothing, so do not subscribe to them.

| `module` | Meaning | Alert title | Severity |
| :- | :- | :- | :- |
| `av` | Malware detection | Antimalware: malware name on host | Critical when `final_status` is `ignored` or `still present`, otherwise Warning |
| `hd` | HyperDetect | HyperDetect: malware name or attack type | Same as `av` |
| `aph` | Antiphishing | Antiphishing: blocked URL | Warning |
| `avc` | Advanced Threat Control (ATC) | Advanced Threat Control: suspicious process path | Critical when `status` is `avc_allowed`, otherwise Warning |
| `dp` | Data Protection | Data Protection: rule name | Warning |
| `fw` | Firewall | Firewall | Info |
| `antiexploit` | Advanced Anti-Exploit | Advanced Anti-Exploit: threat type | Warning |
| `network-monitor` | Network Attack Defense | Network Attack Defense: detection name | Warning |
| `network-sandboxing` | Sandbox Analyzer | Sandbox Analyzer: threat type | Warning |
| `ransomware-mitigation` | Ransomware Mitigation | Ransomware Mitigation: attack type | Critical |
| `exchange-malware` | Exchange malware | Exchange malware: malware name | Warning |
| `new-extended-incident` / `new-incident` | GravityZone incident | Incident: attack types | Critical for `severity` `high`, Warning for `medium`, Info for `low`; without it, `severity_score` decides (above 75 Critical, above 50 Warning, otherwise Info) |

GravityZone publishes no severity scale for detection events, so these levels are a mapping made from the event fields. To change them, configure routing or alert processing rules on labels in the channel.

## Alert Key

***

GravityZone detection events have no event ID, so Flashduty builds the Alert Key from the parts of an event that do not change: `module`, `companyId`, the endpoint ID (`computer_id`, or `endpointId` for Sandbox Analyzer), and the threat identity of that event type. Antimalware uses the malware type, name and file path; Antiphishing uses the phishing type and URL; Ransomware Mitigation uses the attack type and attack source. Changes to the action taken, counters, times, hashes, host name and IP do not change the Alert Key.

Incidents use `incident_id`. `new-incident` and `new-extended-incident` share one Alert Key, so version updates of one incident merge into one alert. Events without an endpoint ID or `incident_id` are rejected.

## Batches

***

One `addEvents` request can carry several events. Flashduty creates one alert per event and processes them sorted by Alert Key. It handles at most 100 events per request; the rest create no alerts and the response returns an error. If one event is malformed, the others are still created and the response names the malformed event's position and the reason.

## Labels

***

| Label | Source |
| :- | :- |
| `module` | Event type |
| `company_id` | `companyId` |
| `host` / `computer_id` / `ip` | Endpoint name, endpoint ID, IP |
| `detected_at` | Detection time recorded by GravityZone |
| `malware_name` / `malware_type` / `final_status` / `file_path` | Malware detection fields |
| `url` / `aph_type` / `status` | The matching fields of Antiphishing, ATC, Firewall and similar modules |
| `incident_id` / `incident_number` / `version` / `severity` / `main_action` / `attack_types` / `killchain` | Incident fields |

User names, mail senders and recipients, mail subjects and incident nodes (`nodes`) are never written to labels or the description.

## About signatures

***

GravityZone sends `md5(api_key, md5(request body))` in the `Event-Push-Service-Md5` header, and you can set an `authorization` header in `serviceSettings`. Flashduty verifies neither. The `integration_key` in the push URL is the only credential, so keep it safe.

## Troubleshooting

***

* **`setPushEventSettings` returns an error**: confirm the API key has Event Push Service API selected and that `serviceType` is `jsonRPC`
* **Flashduty receives nothing**: confirm the push URL is a publicly reachable HTTPS address that supports TLS 1.2 or later; GravityZone treats anything other than a 2xx response as a failure
* **Invalid parameter response**: the response lists the position of the failing event; the usual causes are a missing `computer_id` (or `endpointId`), a missing `incident_id`, or a `method` other than `addEvents`
* **The alert never closes**: detection events carry no recovery, so turn on auto-close for the channel or close the alert by hand; the Info alert from a test event also needs closing by hand
* **Too many alerts**: subscribe only to the event types in the table above; modules such as `fw` and `dp` can raise many alerts when a rule matches often

For more information, see [Push event JSON RPC messages](https://www.bitdefender.com/business/support/en/77209-135325-push-event-json-rpc-messages.html) in the GravityZone documentation.