An alert says a workstation sent 300 DNS queries in a minute. The SIEM shows you the alert, but the evidence behind it came from somewhere else: an agent on the endpoint, a scanner's last report, a DLP policy or a sensor watching a copy of the network traffic. Knowing which tool sees what tells you where to look next, and what to deploy before you need it.
On the CompTIA Security+ SY0-801 exam these tools sit under objective 4.4, which expects you to explain the tools and concepts organizations use to monitor their environment and generate alerts. This lesson covers agent-based and agentless monitoring, benchmarks, vulnerability scanners, antivirus, DLP and orchestration, and how port mirroring and taps feed packet analyzers. The SIEM that most of these tools report to is covered earlier in this section.
Monitoring tools differ in where they sit and what they can see
Every monitoring tool has a vantage point, and its blind spots come from that position. Tools on the host, such as agents, antivirus and endpoint DLP, see processes, files and logons, but nothing about the devices around them. Tools that reach the host over the network, such as agentless collectors, vulnerability scanners and compliance checkers, see configuration and installed software at the moment they look, but not what happens between visits. Tools on the wire, such as IDS sensors and packet analyzers fed by port mirroring or a tap, see conversations between devices, but not what a process did on a host or what is inside encrypted traffic.
A mature program layers all three and sends their output to one place, so one tool's blind spot is covered by another's view. On the exam, the right tool is usually the one positioned to see the evidence the scenario describes.
Agents see more from inside the host, while agentless tools are easier to deploy
An agent is software installed on the monitored system that collects data and sends it to a central server: a log forwarder, an EDR sensor, a vulnerability scanning agent, a DLP agent or a file integrity monitor. Because it runs on the host, an agent sees process launches, command lines, file changes and USB use as they happen. It keeps reporting when a laptop is at a hotel instead of on the corporate network, and many agents can act as well as watch, for example by isolating an infected host.
Agentless monitoring puts no software on the target. A central system connects with built-in remote protocols and credentials, such as WinRM or WMI for Windows, SSH for Linux and network devices, SNMP, or a cloud provider's API. Or it simply receives what the device already sends, such as syslog or NetFlow.
| Factor | Agent-based | Agentless |
|---|---|---|
| Deployment | Install and update on every host | Nothing to install on targets |
| Visibility | Deep and continuous | Snapshots at each poll or scan |
| Devices off the corporate network | Still report over the internet | Missed until they return |
| Printers, appliances, IoT, OT | Often can't run an agent | Usually the only option |
| Main risk | Agent disabled or never deployed | Privileged credentials stored centrally |
The trade-offs drive real decisions. Agents take effort to deploy and maintain across operating systems, use some CPU and memory, and are a target: attackers try to stop them, so an agent that stops checking in should raise an alert. Agentless tools need network reachability and an account with enough rights to read what they need, which makes the collecting server a valuable target in turn.
Most organizations use both. A scenario about laptops that rarely connect to the office, or about watching process activity as it happens, points to agents. A scenario about devices that can't run third-party software, or about avoiding installs on fragile systems, points to agentless monitoring.