Having recently completed a security tooling consolidation project for a financial services client, I was tasked with evaluating several EDR/XDR platforms, with Bitdefender GravityZone being a finalist. While their endpoint protection mechanisms are well-documented, the "Network Attack Discovery" feature's inner workings required some deep diving to understand its operational and architectural value. It is not merely a port scanner bolted onto an AV console.
At its core, GravityZone's Network Attack Discovery is a passive network sensor functionality. It leverages the existing GravityZone agent installed on endpoints to perform a dual role. First, the agent acts as a listening post, analyzing network traffic it can observe on its segment. Second, it can be configured to perform authorized, lightweight active probing. The system constructs a map of devices, services, and vulnerabilities by correlating data from these agents across your network, without requiring a dedicated hardware appliance at every subnet.
The technical workflow can be broken down into phases:
* **Discovery & Inventory:** Agents perform ARP monitoring and listen to broadcast/multicast traffic to identify live hosts (IP, MAC). They may also execute credentialed scans (using provided admin accounts) or agent-assisted scans of network segments to enumerate assets, including unmanaged devices like IoT or network printers.
* **Service Fingerprinting:** For discovered hosts, the system performs TCP/UDP port analysis and examines banner information from open ports to identify running services (e.g., SSH, RDP, SMB, HTTP) and their versions.
* **Vulnerability Correlation:** This is the critical phase. The collected service and version data is cross-referenced against Bitdefender's vulnerability intelligence databases. It does not perform deep, exploitative penetration testing. Instead, it identifies known vulnerabilities (CVEs) associated with the specific software versions detected. For example, finding an Apache Tomcat 8.5.19 server would trigger alerts for CVEs known to affect that exact version.
* **Risk Context & Visualization:** Findings are aggregated in the GravityZone Control Center. The true utility lies in the correlation with endpoint data; it can show you that a vulnerable service is running on a server that also has critical business data, thereby calculating a contextualized risk score.
A key architectural point is its distributed sensor model. The effectiveness is directly proportional to agent coverage. A network segment with no GravityZone-protected endpoints will be a blind spot, unless you deploy a dedicated "Network Sensor" virtual appliance. The scanning policies are centrally managed, allowing you to define sensitive subnets, configure scan schedules to avoid peak hours, and whitelist critical devices.
From a cost-optimization perspective, this feature eliminates the need for a separate, expensive network vulnerability scanner for basic continuous monitoring, provided you are already committed to the GravityZone ecosystem. However, for rigorous compliance scans (e.g., PCI ASV), you will likely still require a dedicated tool. Its strength is in providing operational, day-to-day visibility into your attack surface, directly linked to your endpoint security workflow, rather than being a standalone audit tool.
Passive network sensor is a generous term for an agent doing ARP snooping. That's basic network mapping, not exactly proprietary tech.
You mention it constructs a map from correlated agent data. My question is about the scale of that correlation. In a segmented network, an agent on a workstation segment sees a fraction of the traffic. How does it accurately map a server VLAN or IoT segment it can't directly observe? You'd need a critical mass of agents in every subnet, which gets expensive fast. The "authorized, lightweight active probing" is doing the heavy lifting, isn't it?
I'm skeptical of the architectural value if it's just turning every endpoint into a glorified nmap node.
It's exactly that. The "authorized, lightweight active probing" is just scheduled network discovery scans. The agents absolutely need to be on every subnet you care about, which is why they push so hard for 100% agent deployment. It's a network scanner with extra steps, marketed as a revolutionary feature.
If it ain't broke, don't 'upgrade' it.
You've got a solid start on the phases. The interesting bit is that correlation engine in the cloud - that's where the "attack discovery" magic (or marketing) really happens. It's not just building a map, it's trying to spot deviations against that baseline.
For example, if your standard web server suddenly starts sending weird traffic patterns to a database on a non-standard port, that's flagged. The passive listening on each endpoint feeds into that behavioral model. It's less about raw discovery and more about establishing a "normal" so it can yell when something's off.
But yeah, you're right, you still need enough agents in a segment to get a decent baseline, otherwise the model's blind.
Pipeline Pilot
Your breakdown of the phases is spot on. The inventory phase is crucial, but the real meat is what comes after that initial map is built.
Once it has a baseline of "normal" network behavior, that's when it starts hunting. If an asset on your developer VLAN, which usually just talks to a few internal repos, suddenly starts initiating connections to external IPs on port 1433, that's a huge red flag the system can catch. It's not just about what's *there*, but what those things are *doing* over time.
The catch, as others have hinted, is that baseline. If you have sparse agent coverage in a subnet, your "normal" is incomplete, and you'll either get noisy alerts or miss things entirely. It's a feature that genuinely rewards full deployment.
Cheers, Henry