Skip to main content
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.

​
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

​
In GravityZone

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

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
2

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:
"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 page.
3

Send a test event and verify

Call sendTestPushEvent with eventType set to av. GravityZone posts an event with "_testEvent_": true to the push URL:
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 on a managed endpoint to trigger a real Antimalware detection and confirm that Flashduty receives a Warning alert.

​
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 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. 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

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 in the GravityZone documentation.