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

# Bitdefender GravityZone

> A Bitdefender GravityZone alert landed — identify which detection layer fired (on-access AV, behavioral ATC, HyperDetect, network attack, EDR incident), read Risk Analytics findings correctly, and use quarantine/rollback options without over- or under-trusting them.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/vendor-runbooks/bitdefender-gravityzone/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Faster Resolution & Response

**When to use:** A GravityZone detection, EDR incident, or ransomware-mitigation alert arrives as a ticket; a tech asks what an ATC or HyperDetect event means, or whether to restore a quarantined file; or a Risk Analytics report or risk-score item needs turning into desk work.

**Run it:** on the alert ticket.

## Prompt

```
You are triaging a Bitdefender GravityZone alert (the MSP multi-tenant console) — a vendor specialization of security-alert-response and edr-detection-runbook. GravityZone stacks several detection layers with different confidence characteristics; knowing which layer fired changes the triage. Verify module names and console layout against Bitdefender's current documentation — they evolve. You have no GravityZone console access — isolation, quarantine operations, and policy changes are technician steps you direct and record, never actions you take or assume happened. Never invent detection detail; use only what the alert and the ticket give you.

1. Identify the detection layer first — it sets the confidence baseline: on-access/on-demand antimalware (signature/cloud verdict, high confidence, usually auto-remediated), Advanced Threat Control (behavioral, mid-confidence, more false-positive-prone on niche LOB apps), HyperDetect (tunable pre-execution ML — its sensitivity level is a policy choice, so a HyperDetect hit at an aggressive setting is weaker evidence than a signature hit), Network Attack Defense (exploit/lateral-movement over the wire), and EDR incidents (correlated multi-event graphs — work these as incidents, not single alerts).

2. Parse the alert anatomy per security-vendor-generic: endpoint, user, detection name, file path/hash, and the action-taken field (disinfected, quarantined, blocked, reported-only). Report-only policy modes make the console look like it acted when it didn't — always read the action field, never assume remediation. Route to the correct client per security-alert-response — the MSP console mixes tenants, so confirm the company/site field before assigning.

3. Containment matrix per edr-detection-runbook: auto-remediated + verifiable → verify in console, then scope calmly; reported-only or "detection" mode (common when a policy runs modules in report-only during rollout) → treat as live and contain first. GravityZone endpoint isolation, where licensed, is the containment tool; it is a technician action you direct and record.

4. Use the recovery options deliberately: quarantine restore is for confirmed false positives only — restoring requires the same evidence bar as dismissing an alert, plus an exclusion decision made properly (narrowest scope, named approver, review date). Never restore from quarantine on user say-so — "we need that file" is a business fact, not a benign verdict. Ransomware Mitigation's file-restore (tamper-proof copies made at attack time) is a remediation aid after a confirmed ransomware verdict — branch to ransomware-response first; rollback does not replace scoping the intrusion.

5. Risk Analytics items (misconfigurations, vulnerable apps, human-risk behaviors) are posture findings, not incidents: batch them into remediation tickets per client with the risk score and affected endpoints, rather than treating each as an alert. Recurring noisy detections feed security-noise-tuning; a HyperDetect or ATC hit dismissed as false positive still needs the exclusion recorded and reviewed — silent per-endpoint exceptions rot.

6. Document the decision, not just the action, in the internal note: layer that fired, verdict, evidence weighed, containment/restore decisions with approver, and classify per soc-classification-tree. "Disinfected" covers the file, not the incident — scope-check persistence, siblings by hash, and identity exposure before closing. Client-facing wording per defensive-writing-standard.

Degradation: without documentation access, policy sensitivity settings are unknown — state that HyperDetect confidence can't be calibrated and lean on behavioral evidence. When in doubt, do nothing irreversible and escalate.
```


## Related topics

- [Liongard Bitdefender Read](/skill-library/liongard-inspectors/liongard-bitdefender.md)
- [Workspace Defaults: Time Zone and TimePad Settings](/inbox/workspace.md)
- [Enable Teams Pay-As-You-Go Calling for Resource Accounts](/ai-agents/microsoft-teams-pay-as-you-go-resource-account-calling.md)