SCAP — A Common Language Across Diverse Security Tools
An enterprise network typically runs multiple security tools simultaneously: a next-generation firewall, an intrusion prevention system, a vulnerability scanner, and an endpoint security platform. Each product may identify the same underlying vulnerability, but describe it using different names, different scoring criteria, and different remediation guidance. When the same flaw is called three different things by three different tools, correlation is impossible and automated response requires manual translation.
The Security Content Automation Protocol (SCAP), maintained by NIST at scap.nist.gov, solves this by providing a standardized language that all SCAP-compliant security tools use to identify, describe, and report vulnerabilities and configuration states. A vulnerability identified by the NGFW, the IPS, and the vulnerability scanner is now the same named, numbered entity across all three — enabling the tools to collaborate rather than produce duplicate, inconsistent findings.
SCAP's practical value is automation. With a common language in place, a vulnerability scanner can identify a non-compliant system, pass that finding in a standard format to a patch management system, which can then automatically push the required fix — all without human intervention. This pipeline can run continuously across thousands of devices and multiple operating systems. SCAP automation covers three areas the exam specifically tests: ongoing monitoring (continuously checking compliance states), notification and alerting (informing administrators of non-compliance), and remediation of non-compliant systems (automatically applying patches or configuration corrections).
Security Benchmarks — CIS and the Minimum Security Bar
A security benchmark is a curated set of security configuration settings that represent the minimum acceptable security posture for a specific technology. Benchmarks exist for operating systems, mobile devices, cloud providers, network devices, databases, and virtually every enterprise technology. Applying a benchmark turns a default-configured system — which is typically configured for ease of use, not security — into one that meets a recognized security standard right from deployment.
The Center for Internet Security (CIS), at cisecurity.org, publishes the most widely referenced benchmark library. CIS benchmarks are free, community-validated, and available for a comprehensive range of platforms. A mobile device benchmark, for example, might specify: disable screenshots; disable screen recordings; prevent voice calls when the screen is locked; force encrypted backups; disable additional VPN profiles; configure a lost-phone recovery message. Each setting closes a specific exposure that the default configuration would leave open.
Benchmarks are the starting point for compliance checking: the benchmark defines what "secure" looks like; agent-based or agentless scanning tools then measure each device against that benchmark and report deviations. The benchmark is the specification; the scanning tool is the measurement instrument.
Agent-Based vs. Agentless Compliance Checking
Compliance scanning tools use one of two architectures to check whether a device meets the security benchmark: installing a persistent agent, or performing an on-demand agentless check.
Agent-based monitoring installs software on the device that runs continuously. The agent monitors the system in real time, detects configuration drift or policy violations the moment they occur, and can send immediate alerts. Because the agent is always running, it provides continuous coverage even between scheduled scans. The trade-off: agents must be installed on every managed device, which requires a deployment process, and the agent software and its compliance definitions must be kept current through ongoing updates.
Agentless monitoring performs a compliance check without any permanent software on the target device. The check typically runs when the device connects to the network or authenticates through a VPN concentrator — the agentless tool executes in memory, performs its assessment, and removes itself when finished. There is no ongoing maintenance burden because nothing is permanently installed. The trade-off: because nothing is running between checks, the agentless system provides no continuous monitoring and generates no real-time alerts if the device is non-compliant outside of a check window.
The choice between agent and agentless is a trade-off between coverage depth and deployment overhead. High-risk systems that require continuous monitoring benefit from agents; broad-coverage scans of diverse or guest devices where agent deployment is impractical use agentless checks.
SIEM — Log Collection, Correlation, and Forensic Analysis
The Security Information and Event Management (SIEM) platform is the operational hub of enterprise security monitoring. It collects log data from servers, firewalls, VPN concentrators, cloud services, intrusion detection systems, endpoints, and any other source that can generate security-relevant events. All of this data flows into a central database where the SIEM's analytical capabilities can process it.
Four SIEM functions the exam specifically covers: Real-time log collection — events are ingested as they occur, not in periodic batch uploads. Centralized reporting — a single reporting engine operates against all data sources, producing consistent cross-platform reports. Data correlation — the SIEM links events from different systems that would appear unrelated when viewed in isolation; a failed VPN authentication followed by a successful login from a different account at the same IP address, followed by large file transfers, is an attack pattern visible only through correlation. Forensic analysis — because all events are retained in the database over time, the SIEM supports post-incident investigation; investigators can reconstruct what happened before, during, and after a security event by querying historical log data.
Anti-Virus and Anti-Malware — Effectively the Same Tool Today
Anti-virus software was originally designed to detect a specific category of malicious software: viruses, which spread by attaching to legitimate programs. The original threat model included Trojans, worms, and macro viruses. Malware is the broader term for all malicious software, including spyware, ransomware, fileless malware, keyloggers, and more sophisticated modern threats that do not fit the classic virus definition.
The practical answer for the exam: anti-virus and anti-malware are effectively the same thing today. Modern anti-virus platforms have expanded their detection capabilities far beyond traditional virus signatures and now cover the full malware spectrum. The naming distinction is a historical artifact — vendors continue to use both terms for marketing reasons, but a modern "anti-virus" product is also an anti-malware product. The exam may test awareness of the original definitional distinction (anti-virus = viruses specifically; anti-malware = broader malicious software), but the operational guidance is to use a comprehensive solution that covers both.
DLP — Stopping Data Before the Attacker Gets It
Data Loss Prevention (DLP) systems monitor data in motion, data at rest, and data in use to prevent sensitive information from leaving the organization without authorization. DLP is the control that stands between sensitive data and the many paths an attacker (or careless insider) might use to exfiltrate it.
DLP targets the most valuable and regulated data categories: Social Security numbers, credit card numbers, medical records, confidential business documents, and any other data that would create legal liability, regulatory penalties, or reputational damage if disclosed. The DLP system inspects content in transit and blocks transfers that match sensitive data patterns — stopping a Social Security number from being emailed to an external address, for example, even if the user's email account is legitimately accessible.
Because sensitive data exists and moves across many channels, a single DLP appliance is rarely sufficient. Comprehensive DLP requires: endpoint clients that monitor data on workstations and laptops; cloud-based systems that monitor data moving through cloud storage, email platforms, and collaboration tools; and network-layer inspection for traffic exiting the organization. These layers work together to cover the full range of paths through which data could leak.
SNMP — Polling and Traps for Network Device Monitoring
The Simple Network Management Protocol (SNMP) is the foundational protocol for collecting operational metrics from network-connected devices. SNMP uses a Management Information Base (MIB) — a structured database of metrics maintained on each monitored device. Each metric in the MIB is identified by an Object Identifier (OID), a numerical sequence that uniquely identifies the specific data point (interface traffic volume, CPU utilization, error counts, etc.).
The primary SNMP operation is polling: a network management station sends a request to a device over UDP port 161, asking for the current value of a specific OID. The device responds with the current value. By polling at regular intervals — every five or ten minutes — the management station builds a time-series record that can be graphed: interface traffic over the past 24 hours, CPU utilization trends, error rate history. This historical data is invaluable for capacity planning and anomaly detection.
The limitation of polling is latency: if a critical event occurs between polls, the management station does not know about it until the next poll. SNMP traps address this by reversing the flow: the monitored device proactively sends an unsolicited notification to the management station over UDP port 162 when a configured threshold is crossed. If CRC errors on an interface increase by five, the device sends the trap immediately — the management station reacts in real time rather than waiting for the next polling interval. SNMP traps are the proactive alerting mechanism within the SNMP framework.
NetFlow — Traffic Flow Statistics and Anomaly Detection
NetFlow is a network monitoring technology that collects statistics about traffic flows passing through the network — recording who is communicating with whom, over what protocols, at what volumes, and for how long. Unlike SNMP (which measures device-level metrics like interface byte counts), NetFlow provides conversation-level visibility: it answers "what applications are being used, between which endpoints, and in what volumes?"
NetFlow uses a probe-and-collector architecture. A NetFlow probe observes network traffic — either through software built into a router or switch, or through an external hardware probe connected via a SPAN port (Switched Port Analyzer) or physical network tap. The probe compiles flow summaries and sends them to a NetFlow collector, which aggregates the records and provides them to a reporting application. The probe does not capture full packet contents — it records metadata (source/destination IPs, ports, protocol, byte count, duration) — making NetFlow storage-efficient relative to full packet capture.
NetFlow reporting surfaces: top-10 conversations on the network; top-10 endpoints by traffic volume; protocol distribution; and anomalous traffic patterns such as sudden flows to external IP addresses not seen before (exfiltration indicator) or high-volume flows to a single destination (DDoS participation indicator). NetFlow is the tool of choice for understanding normal and anomalous traffic patterns at the network layer.
Vulnerability Scanners — Minimally Invasive Weakness Assessment
A vulnerability scanner probes systems to identify potential security weaknesses without exploiting them — this distinguishes it from a penetration test, which actively attempts exploitation. The scanner's goal is to gather as much information as possible about a system's attack surface: which services are running, which versions, which known vulnerabilities match the observed configuration.
Vulnerability scanners perform: port scanning to identify open services; system identification to determine OS type and version; software version detection matched against CVE databases; and security configuration analysis to identify misconfigurations that could be exploited. The output is a prioritized list of findings rated Critical, High, Medium, Low, and Informational.
An important operational point that the exam tests: scans should be run both internally (from inside the network, simulating an insider threat or attacker who has already gained network access) and externally (from outside the perimeter, showing what an external attacker sees). The internal and external views can differ significantly — a service that is firewalled from external access may still be reachable internally. Running only external scans leaves the internal attack surface unmeasured. After scanning, findings must be verified — not everything a scanner reports is accurate, and false positives require investigation before remediation resources are spent.