Questions? Call 1.800.716.8955

Chapter 17

Security Alerting and Monitoring

Exam objective 4.4: Explain security alerting and monitoring concepts and tools.

This objective covers how an organization watches its environment for signs of trouble and turns raw events into decisions. It spans what gets monitored (systems, applications, and infrastructure), the activities that make monitoring useful (log aggregation, alerting, scanning, archiving, reporting, and alert tuning), the tools that collect and analyze data (benchmarks, agents and agentless collection, SIEM, antivirus, DLP, vulnerability scanners, orchestration, and packet analyzers), the protocols that move monitoring data around (NetFlow, SNMP, syslog, and SCAP), and supporting concepts such as automated alerts, port mirroring, dashboards, and network management systems.

This is an "explain" objective. You will not be asked to write SIEM correlation rules, but you must be able to recognize what each tool does, pick the right data source or protocol for a described need, and reason about problems such as alert fatigue, false positives, and log retention. Expect questions that describe a monitoring goal ("the team needs to see which hosts talked to which hosts and how much data moved") and ask for the tool or protocol that meets it (NetFlow).

Why Monitoring Matters

Preventive controls fail. Firewalls get misconfigured, users click links, and attackers find vulnerabilities before vendors patch them. Monitoring is the detective layer of defense in depth (Chapter 1): it shortens the time between when an attacker gets in and when defenders notice. Industry studies have repeatedly shown that the longer an intruder goes unnoticed—the dwell time—the more damage they do and the more an incident costs. Good monitoring reduces dwell time; poor monitoring lets breaches run for months.

Monitoring also serves goals beyond catching attackers:

  • Compliance — regulations and standards such as PCI DSS, HIPAA, and SOX require logging and log review, and auditors ask for evidence that it happens.
  • Operations and availability — the same telemetry that reveals an attack also reveals a failing disk, a saturated link, or an expired certificate.
  • Investigations — when an incident occurs, logs are the evidence used to reconstruct what happened (Chapter 21).
  • Accountability — the accounting part of AAA depends on records of who did what and when. Monitoring is only as good as the response it triggers. Collecting terabytes of logs nobody reviews is a cost, not a control. The rest of this chapter is about making sure the right data is collected, the right people are alerted, and the noise is kept low enough that real attacks are not ignored.

Monitoring Computing Resources

The objective lists three broad areas to monitor: systems, applications, and infrastructure. Each produces different telemetry and reveals different kinds of problems.

Systems

System monitoring watches individual hosts—servers, workstations, laptops, and virtual machines. Useful system data includes:

  • Operating system logs: Windows Event Logs (Security, System, Application) and Linux logs such as /var/log/auth.log, /var/log/secure, and the systemd journal.
  • Authentication events: successful and failed logons, privilege use, account creation, and group membership changes.
  • Process and service activity: new processes, unusual parent-child relationships (Word spawning PowerShell), new services, and scheduled tasks.
  • File integrity: changes to critical system files and configurations, detected by file integrity monitoring (FIM).
  • Resource utilization: CPU, memory, and disk. A sudden spike in CPU on an idle server may indicate cryptomining; a disk filling quickly may indicate ransomware staging or log flooding.
  • Endpoint security telemetry: alerts and behavioral data from antivirus, EDR, and host-based firewalls.

A few Windows event IDs come up often enough that recognizing them is worthwhile:

Event ID Meaning Why it matters

4624 Successful logon Baseline of normal access; unusual times or sources stand out 4625 Failed logon Bursts suggest brute force or password spraying

4720 User account created Attackers create accounts for persistence

4732 / 4728

Member added to a security group

Privilege escalation (for example, added to Administrators)

1102 Security audit log cleared Classic anti-forensics indicator

4688 New process created Reveals suspicious command lines when enabled with command-line auditing

Applications

Application monitoring watches the software that delivers business functions: web servers, databases, email systems, ERP platforms, and SaaS applications. Useful data includes web server access and error logs, application authentication logs, database query and audit logs, API gateway logs, and error rates and response times.

Application logs reveal attacks that system logs miss. A SQL injection attempt appears in a web access log as a strange query string; a credential stuffing attack appears as thousands of failed logins across many usernames from rotating IP addresses; an account takeover appears as a successful login followed by a change of the recovery email address. Application monitoring also catches availability problems such as rising error rates after a deployment.

203.0.113.45 - - [04/Oct/2026:02:14:07 +0000] "GET /products.php?id=1%27%20OR %20%271%27=%271 HTTP/1.1" 200 18342 "-" "sqlmap/1.8"

203.0.113.45 - - [04/Oct/2026:02:14:08 +0000] "GET /products.php?id=1%20UNION%20SELECT %20username,password%20FROM%20users-- HTTP/1.1" 500 512 "-" "sqlmap/1.8"

The entries above show SQL injection attempts (encoded ' OR '1'='1 and UNION SELECT) from a tool that even announces itself in the user-agent string. A web application firewall or SIEM rule watching for these patterns would alert on them.

Infrastructure

Infrastructure monitoring watches the shared components that everything else depends on: routers, switches, firewalls, wireless controllers, load balancers, DNS and DHCP servers, hypervisors, storage, and cloud control planes. Infrastructure telemetry includes firewall allow and deny logs, VPN connection logs, DNS query logs, DHCP lease logs, flow records, interface utilization and error counters, and cloud audit logs such as AWS CloudTrail or Azure Activity Log.

DNS logs deserve special mention: nearly all malware has to resolve names to reach its command-and-control infrastructure, so DNS query logs reveal beaconing, domain generation algorithms, and DNS tunneling. DHCP logs map IP addresses to MAC addresses and hostnames at a point in time, which is essential when an investigation needs to know which device had a given address yesterday.

Exam tip

Match the clue to the area. Failed logons and new processes point to systems. Strange query strings, API abuse, and application errors point to applications. Link utilization, firewall denies, routing changes, and DNS anomalies point to infrastructure. Cloud control-plane logs (who created or deleted a resource) are infrastructure monitoring for cloud environments.

Monitoring Activities

Collecting data is only the first step. The objective lists six activities that turn data into security value.

Log Aggregation

Log aggregation is collecting logs from many sources into a central location. Without aggregation, an analyst investigating an incident would need to log into dozens of devices, each with its own format, retention, and clock. With aggregation, all events are searchable in one place.

Aggregation involves several steps:

  • 1. Collection — logs are forwarded from sources by syslog, agents, APIs, or file transfer.
  • 2. Parsing — each source's format is broken into fields (timestamp, source IP, user, action).
  • 3. Normalization — fields from different vendors are mapped to a common schema, so "src_ip," "SourceAddress," and "client" all become one field.
  • 4. Enrichment — events are augmented with context such as geolocation, asset owner, asset criticality, or threat intelligence reputation.
  • 5. Storage and indexing — events are stored so they can be searched quickly.

Time synchronization is a prerequisite. If devices disagree about the time, events cannot be placed in the correct sequence and correlation fails. All devices should synchronize to a reliable time source using NTP, and logs should record time zones (ideally UTC).

Figure 17.1: Log aggregation collects, parses, normalizes, enriches, and stores events from many sources in one searchable place

Centralizing logs also protects them. An attacker who compromises a server can delete its local logs, but cannot easily reach copies already forwarded to a hardened log server. This is why log forwarding should be near real time.

Alerting

Alerting is notifying people or systems when monitored conditions indicate a possible problem. An alert is generated when an event or a pattern of events matches a rule, crosses a threshold, or deviates from a baseline. Alerts may be delivered to a SIEM console, a ticketing system, email, chat, or a paging service, and they usually carry a severity rating so that analysts can triage.

Common ways alerts are triggered:

  • Signature or rule match — an event matches a known-bad pattern (a known malicious hash, an IDS signature, a specific Windows event).
  • Threshold — a count exceeds a limit (more than 20 failed logons for one account in five minutes).
  • Correlation — several events across sources together form a suspicious pattern (a VPN login from another country followed by a large file transfer).
  • Anomaly or behavioral — activity deviates from a learned baseline (a user who normally downloads 50 MB per day downloads 30 GB).

Scanning

Scanning is actively probing systems to discover assets, open ports, configurations, and vulnerabilities. Unlike log collection, which passively receives what systems report, scanning goes out and asks. Monitoring programs schedule recurring scans—network discovery scans to find new or rogue devices, vulnerability scans to find missing patches and weak configurations (Chapter 16), and compliance scans that compare configurations to benchmarks. Scan results feed the SIEM and dashboards so that a new critical vulnerability on an internet-facing server becomes an alert rather than a line in a report nobody reads.

Archiving

Archiving is moving older monitoring data to long-term storage for retention. Active SIEM storage is expensive and fast; archive storage is cheaper and slower. A typical design keeps 30-90 days of "hot" searchable data and a year or more of archived data that can be restored when needed. Retention periods are driven by:

  • Regulatory and contractual requirements — for example, PCI DSS requires at least one year of audit log history, with the most recent three months immediately available for analysis.
  • Investigative needs — dwell times can be long, so investigators may need logs from many months before detection.
  • Legal holds — when litigation is anticipated, relevant logs must be preserved regardless of normal retention schedules (Chapter 25).
  • Cost and privacy — keeping data forever increases storage costs and privacy exposure. Archived logs must be protected for integrity: write-once (WORM) storage, hashing, and restricted access help ensure logs remain trustworthy evidence.

Reporting

Reporting summarizes monitoring data for different audiences. Analysts need detailed reports on specific events; managers need trends such as mean time to detect and respond, number of incidents by category, and patch compliance percentages; auditors need evidence that controls operate, such as a quarterly report of privileged account activity reviews. Reports can be scheduled (weekly vulnerability summary) or ad hoc (all activity from a given user during an investigation). Good reporting turns monitoring from an operational function into a source of risk information for leadership.

Alert Tuning

Alert tuning is adjusting detection rules, thresholds, and filters so that alerts are accurate and actionable. Untuned systems typically generate enormous numbers of alerts, most of them false positives. Analysts overwhelmed by noise begin ignoring alerts—a condition called alert fatigue—and real attacks slip through. Many major breaches were preceded by alerts that fired but were dismissed among thousands of others.

Understanding the four outcomes of any detection is essential:

Outcome Activity is malicious?

Alert fired? Effect

True positive Yes Yes Correct detection

False positive No Yes Wasted analyst time; contributes to alert fatigue True negative No No Correct silence

False negative Yes No Missed attack; the most dangerous outcome

Tuning techniques include:

  • Adjusting thresholds to fit the environment (a build server legitimately generates many authentications).
  • Allowlisting or suppressing known-benign activity, such as a vulnerability scanner that triggers IDS signatures every Tuesday night.
  • Adding context such as asset criticality so that the same event on a domain controller ranks higher than on a test VM.
  • Correlating multiple weak signals into one stronger alert rather than alerting on each.
  • Retiring rules that never produce true positives, and adding rules for new threats.
  • Reviewing tuning regularly, because environments change.

Common trap

Tuning is a balance. Making rules stricter reduces false positives but can increase false negatives. Suppressing an entire alert category to eliminate noise is a classic mistake—the goal is to remove the benign cases, not the detection. On the exam, when a scenario describes analysts ignoring alerts because there are too many, the answer is alert tuning (not buying another tool or hiring more analysts). A SOC receives 4,000 alerts per day for "possible port scan." Investigation shows that 95% come from the company's own vulnerability scanners and network monitoring system. The team creates a suppression rule for those specific source IPs during scheduled scan windows, raises the severity of port scans originating from user workstations, and correlates scan alerts with subsequent connection attempts. Daily alerts drop to 150, and the team notices a real internal scan from a compromised laptop within the first week.

Monitoring Tools

Benchmarks

A benchmark is a documented, consensus-based standard for securely configuring a particular system. The best-known are the CIS Benchmarks from the Center for Internet Security, which provide detailed hardening recommendations for operating systems, cloud platforms, databases, browsers, and network devices. Other examples include DISA STIGs (Security Technical Implementation Guides) used by the US Department of Defense and vendor security baselines.

In monitoring, benchmarks are used as the yardstick for configuration compliance scanning. Tools compare actual configurations against the benchmark and report deviations: password policy too weak, SMBv1 enabled, audit logging disabled. Continuous benchmark monitoring catches configuration drift— gradual divergence from the approved baseline—before it becomes a vulnerability. Chapter 14 discusses hardening and baselines in more detail, and Chapter 22 treats benchmarks as a governance guideline.

Agents and Agentless Collection

Monitoring data can be gathered with or without software installed on the monitored system. An agent is software installed on the host that collects data locally and sends it to a central server. EDR sensors, SIEM log forwarders, and vulnerability scanner agents are examples. An agentless approach collects data remotely using existing protocols and credentials—syslog, SNMP, WMI, SSH, or cloud APIs —without installing anything.

Factor Agent-based Agentless

Depth of visibility High: process, memory, file, and kernel activity

Limited to what protocols and APIs expose

Works when host is off the network

Yes; caches and forwards later No; requires connectivity at collection time Real-time detection and response

Yes; can block or isolate locally Generally periodic, read-only

Factor Agent-based Agentless

Deployment and maintenance

Must install, update, and manage on every host

Easier; nothing to install

Host performance impact Some CPU and memory usage Minimal on host; load on network and scanner Suitable for Managed endpoints and servers Network devices, appliances, IoT, systems where agents are not allowed

Network devices, printers, and embedded or IoT systems usually cannot run agents, so they are monitored agentlessly. Laptops that roam outside the corporate network benefit most from agents, because an agentless scanner cannot reach them when they are at a coffee shop.

Exam tip

If a scenario mentions remote workers whose laptops are rarely on the corporate network, choose an agent. If it mentions devices where software cannot be installed—appliances, medical devices, network gear, or vendor-managed systems—choose agentless.

Siem

A security information and event management (SIEM) system is the central platform for aggregating, correlating, analyzing, and alerting on security data from across the organization. The name combines two older functions: security information management (SIM, long-term log storage and reporting) and security event management (SEM, real-time monitoring and correlation).

Core SIEM capabilities include:

  • Log aggregation and normalization from hundreds of source types.
  • Correlation — rules that link related events across sources and time.
  • Alerting with severity and context.
  • Search and investigation — query interfaces for threat hunting and incident analysis.
  • Dashboards and reporting for SOC operations and compliance.
  • Retention — storage and archiving to meet legal and regulatory requirements.
  • User and entity behavior analytics (UEBA) in many modern SIEMs, which baselines normal behavior and flags anomalies.
  • Threat intelligence integration to flag known-malicious IPs, domains, and hashes.

A simple correlation rule might look like this in pseudocode:

rule "Possible password spray followed by success"

when count(event.id == 4625, distinct user) >= 15 from same src_ip within 10m and event.id == 4624 from same src_ip within 30m after

then alert severity=high, tag="T1110.003 Password Spraying"

No single event here is alarming—failed logons happen constantly—but the pattern of many failures across many accounts from one source, followed by a success, strongly suggests a password spray that found a weak password.

SIEMs are powerful but demanding. They require careful source onboarding, parsing, tuning, and skilled analysts. A SIEM that is fed too little data misses attacks; one that is fed everything without tuning drowns its users. Cloud-native SIEMs have reduced infrastructure burden but shifted cost to data ingestion volume, which forces careful choices about which logs to send.

Antivirus

Antivirus (AV) software detects and removes malicious code on endpoints and servers. Traditional antivirus relies on signatures—hashes and byte patterns of known malware—which makes it effective against known threats but weak against new or polymorphic malware. Modern products add heuristic analysis (looking for suspicious code characteristics), behavioral detection (watching what a program does), cloud reputation lookups, and machine learning models. Endpoint detection and response (EDR) extends this with continuous recording of endpoint activity, investigation tools, and response actions such as isolating a host.

From a monitoring standpoint, antivirus is both a protective control and a telemetry source. AV detections should be forwarded to the SIEM, and administrators should monitor AV health: an endpoint whose AV is disabled, out of date, or not reporting is itself a significant alert, because attackers routinely try to disable security tools.

Data Loss Prevention (DLP)

Data loss prevention (DLP) tools detect and prevent sensitive data from leaving authorized locations. DLP inspects content and context to identify sensitive data—credit card numbers (validated with the Luhn check), Social Security numbers, health records, source code, or documents labeled confidential— and applies policy when that data moves.

DLP is deployed in several places:

  • Endpoint DLP — an agent watches copying to USB drives, printing, screenshots, clipboard use, and uploads from the device.
  • Network DLP — inspects traffic at the egress point, including email (SMTP) and web uploads.
  • Cloud DLP — integrated with SaaS platforms or a cloud access security broker (CASB) to inspect files stored and shared in the cloud.

DLP actions include logging (monitor only), alerting, prompting the user for a justification, encrypting, quarantining, and blocking. Many organizations start DLP in monitor-only mode to learn normal data flows and tune policies before switching to blocking, because aggressive DLP rules disrupt legitimate business. Chapter 12 covers data classification, which DLP depends on to know what is sensitive.

Vulnerability Scanners

Vulnerability scanners probe systems for known vulnerabilities, missing patches, weak configurations, and default credentials, then report findings with severity ratings, usually based on CVSS scores. Examples include Nessus, Qualys, OpenVAS, and Rapid7 InsightVM. Scans may be credentialed (logging into the target for an accurate inside view) or non-credentialed (seeing only what an outside attacker sees). Chapter 16 covers vulnerability management in depth; for this objective, remember that scanners are a monitoring tool whose findings should flow into dashboards, tickets, and the SIEM, and that recurring scanning is how you detect newly introduced weaknesses.

Orchestration

Orchestration in monitoring refers to coordinating multiple security tools and automated actions into workflows. A security orchestration, automation, and response (SOAR) platform receives alerts from the SIEM and other sources, enriches them automatically (look up the IP's reputation, pull the user's details, check whether the hash is known), and runs playbooks that perform response steps—such as quarantining a host, disabling an account, or blocking a domain—either automatically or after analyst approval.

Orchestration addresses the scale problem: humans cannot manually enrich and triage thousands of alerts a day. By automating repetitive steps, orchestration lets analysts spend their time on judgment calls. Chapter 19 covers automation and orchestration in depth.

Packet Analyzers

A packet analyzer (also called a protocol analyzer or sniffer) captures network packets and decodes them so analysts can examine the traffic at every protocol layer. Wireshark is the best-known graphical analyzer; tcpdump and tshark are command-line tools.

  • # Capture DNS traffic on interface eth0 to a file for later analysis
  • tcpdump -i eth0 -w dns_capture.pcap port 53
  • # Display HTTP requests from a suspicious host without resolving names
  • tcpdump -nn -r capture.pcap 'host 10.1.20.55 and tcp port 80'

Packet captures provide the most detailed view of network activity possible—full content, not just metadata—which makes them invaluable for investigating exactly what an attacker sent or exfiltrated, analyzing malware command-and-control protocols, and troubleshooting. The trade-offs are volume (full capture consumes enormous storage), privacy concerns, and encryption: TLS-protected traffic shows only metadata such as IP addresses, ports, and the server name unless it is decrypted at a proxy or the session keys are available.

Contrast packet capture with flow data. A packet capture is like a recording of every phone call, including the words spoken. NetFlow is like a phone bill: who called whom, when, for how long, and how much data moved, but not what was said. Flow data is far smaller and can be kept much longer; packet capture is far richer but expensive to store.

Monitoring Protocols

Syslog

Syslog is the standard protocol for sending log messages across a network to a central collector. Nearly every network device, Linux and Unix system, and security appliance supports it. Traditional syslog uses UDP port 514, which is fast but unreliable and unencrypted—messages can be lost or read in transit. Syslog over TCP (commonly port 514 or 601) adds reliable delivery, and syslog over TLS (port 6514) adds encryption and server authentication. Common implementations include rsyslog and syslog-ng. Each syslog message carries a facility (the type of program that generated it, such as auth, kern, mail, or local0-local7) and a severity from 0 to 7:

<38>1 2026-10-04T02:31:17.004Z web01 sshd 4127 - - Failed password for invalid user
admin from 198.51.100.23 port 51422 ssh2

The number in angle brackets is the priority value, calculated as facility times 8 plus severity. Here 38 = 4 (auth) times 8 + 6 (informational).

Lower syslog numbers are worse: 0 is Emergency, 7 is Debug. A mnemonic for the order: "Every Awesome Cisco Engineer Will Need Ice-cream Daily" — Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug.

Snmp

The Simple Network Management Protocol (SNMP) monitors and manages network devices. An SNMP manager (the network management system) queries SNMP agents on devices for values stored in a Management Information Base (MIB), where each value is identified by an object identifier (OID)—for example, interface traffic counters, CPU load, or temperature. Managers poll agents on UDP 161; agents send unsolicited alerts called traps (or acknowledged informs) to the manager on UDP 162. SNMP versions differ sharply in security:

  • Version Authentication Encryptio
  • n
  • Security notes

SNMPv1 Community string in cleartext None Insecure; defaults "public" and "private" are well known SNMPv2c Community string in cleartext None Better performance and bulk operations, same weak security

SNMPv3 Per-user authentication (HMAC)

Yes (AES or DES)

The only version that should be used for secure management

Common trap

If a question asks how to secure SNMP, the answer is SNMPv3 with authentication and privacy (authPriv). Changing the community string from "public" helps a little, but v1 and v2c still send it in cleartext where any sniffer can capture it. Also disable SNMP write access (read-write communities) unless it is truly needed.

NetFlow

NetFlow, originally developed by Cisco, records metadata about network flows. A flow is a set of packets sharing the same key attributes—traditionally source IP, destination IP, source port, destination port, protocol, ingress interface, and type of service. For each flow, the exporting router or switch records counts of packets and bytes, start and end times, and TCP flags, then exports the records to a flow collector for storage and analysis. IPFIX (IP Flow Information Export) is the IETF standard based on NetFlow version 9; sFlow is a related sampling-based technology.

Flow data answers questions such as:

  • Which internal host is talking to that suspicious external IP, and how much data was sent?
  • Is there beaconing—small, regular connections at fixed intervals—from any workstation?
  • Which hosts suddenly began connecting to many other hosts on port 445 (lateral movement or worm spread)?
  • What consumes the most bandwidth on the WAN link?

Because flow records contain no payload, they are compact enough to retain for months and work even when traffic is encrypted. They cannot tell you what was in a file transfer, only that it happened and how large it was.

Scap

The Security Content Automation Protocol (SCAP) is a NIST suite of specifications (described in NIST SP 800-126) for expressing and exchanging security configuration and vulnerability information in standardized, machine-readable formats. SCAP lets different tools speak the same language, so a benchmark written once can be checked by any SCAP-compliant scanner.

Key SCAP components include:

  • CVE (Common Vulnerabilities and Exposures) — identifiers for publicly known vulnerabilities.
  • CCE (Common Configuration Enumeration) — identifiers for configuration settings.
  • CPE (Common Platform Enumeration) — standardized names for hardware, operating systems, and applications.
  • CVSS (Common Vulnerability Scoring System) — severity scoring for vulnerabilities.
  • XCCDF (Extensible Configuration Checklist Description Format) — a language for writing security checklists and benchmarks.
  • OVAL (Open Vulnerability and Assessment Language) — a language for describing how to test a system's state.

In practice, an organization can download a SCAP-formatted benchmark (for example, a DISA STIG), load it into a SCAP-validated scanner, and automatically check thousands of systems for compliance, producing results in a standard format that other tools can consume.

Exam tip

SCAP is the answer when a question asks about standardized, automated configuration compliance checking or about a common format so that different security tools can share vulnerability and configuration data. CVE names a vulnerability, CVSS scores it, CPE names a platform, XCCDF describes the checklist, and OVAL describes the test.

Protocol Purpose Port(s) Exam clue

Syslog Forward log messages to a collector

UDP/TCP 514, TLS 6514 Centralizing logs from devices

SNMP Poll device status; receive traps UDP 161 (poll), UDP 162 (traps)

Device health, interface counters, MIB, community string

NetFlow/

Ipfix

Export traffic flow metadata Commonly UDP 2055 (NetFlow), 4739 (IPFIX)

Who talked to whom, how much, no payload

SCAP Standardize security content and checks

Not a transport protocol Automated compliance, XCCDF, OVAL,

Cve, cpe

Additional Monitoring Concepts

Automated Alerts

Automated alerts are notifications generated and delivered by systems without human intervention when predefined conditions occur. They range from simple threshold alerts (disk 90% full, certificate expires in 14 days) to SIEM correlation alerts and AI-driven anomaly detections. Automation ensures alerts reach the right on-call person or team immediately, through the right channel, at any hour. Effective automated alerting includes severity levels and routing (critical alerts page the on-call engineer; low-severity alerts go to a queue), deduplication so the same problem does not generate hundreds of messages, escalation if an alert is not acknowledged within a set time, and integration with ticketing and SOAR so that alerts automatically become tracked cases. The risk is the same as for any alerting: too many automated alerts produce alert fatigue, so tuning applies here too.

Port Mirroring

Network monitoring tools such as IDS sensors, packet analyzers, and network detection and response (NDR) appliances need to see traffic, but modern switches send each frame only to the port where its destination lives. Port mirroring solves this by configuring a switch to copy traffic from one or more source ports or VLANs to a designated monitoring port. Cisco calls this SPAN (Switched Port Analyzer); RSPAN and ERSPAN carry mirrored traffic across the network to a remote sensor.

The alternative is a network TAP (test access point), a hardware device inserted in-line on a cable that passively copies all traffic to a monitoring port.

Figure 17.2: A SPAN port copies traffic inside the switch, while a TAP sits in-line on the cable and copies everything to the sensor Feature Port mirroring (SPAN) Network TAP

  • Cost Free; uses existing switch feature Requires purchasing hardware
  • Fidelity Can drop packets when oversubscribed; may omit
  • errored frames
  • Copies everything, including errors, at full line rate

Installation Configuration change, no downtime Inserted into a cable; brief outage to install Impact on production

Consumes switch resources Passive; fails open on most models

Best for Flexible, temporary, or low-volume monitoring Permanent, high-fidelity monitoring of critical links ! Cisco IOS example: mirror traffic from Gi1/0/10 to an IDS sensor on Gi1/0/24 monitor session 1 source interface Gi1/0/10 both

monitor session 1 destination interface Gi1/0/24

Real-world scenario

A security team deploys a new IDS sensor but sees almost no traffic other than broadcasts. The sensor is plugged into an ordinary switch port, so the switch delivers only frames addressed to the sensor itself. The fix is to configure port mirroring (SPAN) on the switch to copy the uplink traffic to the sensor's port, or to install a network TAP on the uplink.

Dashboards

A dashboard is a visual display that summarizes the current state of monitored systems at a glance: open alerts by severity, top talkers, failed logins over time, vulnerability counts by business unit, endpoint protection status, and similar metrics. SIEM, vulnerability management, EDR, and network monitoring tools all provide dashboards.

Good dashboards are designed for their audience. A SOC wall dashboard shows real-time alerts and queue status; an executive dashboard shows trends and risk posture; a compliance dashboard shows control status against requirements. Dashboards help spot patterns—a sudden spike in outbound DNS traffic, a jump in blocked logins—that are invisible in individual log entries. They support but do not replace alerting: nobody watches a dashboard every second, so important conditions must still generate alerts.

Network Management Systems

A network management system (NMS) is a platform that monitors and manages network devices, typically using SNMP polling and traps, plus syslog, flow data, and ICMP checks. An NMS discovers devices, maps topology, tracks availability and performance (uptime, latency, interface utilization, error rates), stores historical baselines, and alerts when devices go down or exceed thresholds. Examples include SolarWinds Network Performance Monitor, PRTG, Zabbix, and LibreNMS.

Although NMS platforms are primarily operational tools, they matter for security in several ways. They reveal availability attacks such as DDoS through sudden utilization spikes, detect unauthorized configuration changes, identify rogue devices appearing on the network, and provide performance baselines that make anomalies visible. Because an NMS holds credentials for and privileged access to every network device, it is also a high-value target—the 2020 SolarWinds Orion supply chain compromise showed how attackers can turn a trusted management platform into a backdoor into thousands of organizations (see Chapter 6 for supply chain vectors).

Exam tip

NMS answers point to SNMP-based availability and performance monitoring of network devices. SIEM answers point to security correlation across many log sources. When a question asks which system would show that a switch interface is saturated or a router is down, think NMS.

Putting It Together: A Monitoring Architecture

The tools in this chapter work together. A typical mid-sized organization might deploy:

  • Endpoint agents (EDR/AV and log forwarders) on all servers and laptops, sending telemetry to the

Siem.

  • Syslog from firewalls, switches, routers, and Linux servers to a log collector that forwards to the

Siem.

  • SNMP polling and traps from network devices to the NMS, which raises availability alerts and forwards critical events to the SIEM.
  • NetFlow/IPFIX exported from core routers and firewalls to a flow collector or NDR tool.
  • Port mirroring or TAPs at the internet edge and data center core, feeding an IDS and an on-demand packet capture appliance.
  • DLP on endpoints, email, and the cloud via CASB.
  • Vulnerability scanners running weekly credentialed scans and SCAP benchmark checks, with results flowing into dashboards and tickets.
  • SIEM correlating everything, with SOAR orchestration handling enrichment and routine response.
  • Dashboards for the SOC, IT operations, and leadership, plus scheduled reports for auditors.
  • Archiving to low-cost immutable storage that meets retention requirements.

Figure 17.3: A typical monitoring architecture in which sources feed the SIEM directly or through collectors, and the SIEM drives response, dashboards, reports, and archives

The objective lists "Orchestration" among monitoring tools and lists separate automation and orchestration content in objective 4.6. For 4.4, focus on orchestration as the glue that connects monitoring tools and automates triage; for 4.6 (Chapter 19), focus on use cases, benefits, and risks of automation more broadly.

Chapter Summary

  • Monitor systems (host logs, processes, FIM, resource use), applications (web, database, API, and SaaS logs), and infrastructure (network devices, DNS, DHCP, firewalls, hypervisors, cloud control planes).
  • Key activities are log aggregation (collect, parse, normalize, enrich, store—with synchronized time), alerting, scanning, archiving for retention and legal requirements, reporting for different audiences, and alert tuning to reduce false positives and alert fatigue without creating false negatives.
  • Benchmarks such as CIS Benchmarks and DISA STIGs define secure configurations and detect drift. Agents give deep, real-time visibility on hosts that can run them; agentless collection suits devices that cannot.
  • A SIEM aggregates and correlates security data, alerts, and supports investigation and compliance. Antivirus, DLP, and vulnerability scanners are both controls and telemetry sources. Orchestration (SOAR) automates enrichment and response. Packet analyzers capture full packet content.
  • Syslog (UDP 514, TLS 6514) forwards logs with severities 0-7. SNMP (UDP 161/162) monitors devices; use SNMPv3. NetFlow/IPFIX records flow metadata without payload. SCAP standardizes security content (CVE, CPE, CVSS, XCCDF, OVAL) for automated compliance checks.
  • Automated alerts deliver notifications with severity, routing, and escalation. Port mirroring (SPAN) or a TAP gives sensors a copy of traffic. Dashboards visualize status for each audience. An NMS monitors network availability and performance, largely via SNMP.

Key Terms

Dwell time; system monitoring; application monitoring; infrastructure monitoring; file integrity monitoring (FIM); log aggregation; parsing; normalization; enrichment; time synchronization (NTP); alerting; correlation; threshold; scanning; archiving; retention; WORM storage; reporting; alert tuning; alert fatigue; true positive; false positive; true negative; false negative; benchmark; CIS Benchmarks; STIG; configuration drift; agent; agentless; SIEM; UEBA; antivirus; EDR; data loss prevention (DLP); vulnerability scanner; credentialed scan; orchestration; SOAR; playbook; packet analyzer; Wireshark; tcpdump; syslog; facility; severity level; SNMP; MIB; OID; trap; community string; SNMPv3; NetFlow; IPFIX; flow collector; SCAP; XCCDF; OVAL; CPE; automated alert; port mirroring; SPAN; network TAP; dashboard; network management system (NMS).

Review Questions

  • 1. A SOC manager reports that analysts are closing many alerts without investigation because more than 90% of them turn out to be benign activity from internal IT tools. Which action BEST addresses this problem?
  • A. Deploy a second SIEM to share the load
  • B. Tune the alert rules to suppress known-benign sources and adjust thresholds
  • C. Disable all alerts with medium or low severity
  • D. Increase log retention to one year
  • 2. An investigator needs to determine which internal hosts communicated with a known command-and-control IP address over the past six months and how much data each sent. Full packet captures are retained for only 72 hours. Which data source is MOST likely to answer the question?
  • A. SNMP traps
  • B. NetFlow records
  • C. Antivirus logs
  • D. Syslog from the domain controller
  • 3. A network engineer must monitor interface utilization and receive alerts when routers reboot. The solution must authenticate and encrypt management traffic. Which protocol should be used?
  • A. SNMPv1
  • B. SNMPv2c
  • C. SNMPv3
  • D. Syslog over UDP
  • 4. A company wants to automatically check thousands of Linux servers against a government hardening checklist using tools from several vendors that all understand the same checklist format. Which of the following BEST supports this goal?
  • A. NetFlow
  • B. SCAP
  • C. SNMP
  • D. Port mirroring
  • 5. A newly installed IDS sensor connected to a core switch is only seeing broadcast traffic. Which of the following would allow the sensor to see traffic between servers on the switch? (Select TWO.)
  • A. Configure a SPAN session on the switch
  • B. Enable SNMP traps on the switch
  • C. Install a network TAP on the uplink
  • D. Configure the sensor as the default gateway
  • E. Forward syslog from the switch to the sensor
  • 6. A security team needs visibility into processes, file changes, and network connections on laptops used by employees who work remotely and rarely connect to the corporate VPN. Which approach is BEST?
  • A. Agentless scanning from the data center
  • B. Agent-based monitoring that caches and forwards telemetry
  • C. NetFlow export from the core router
  • D. SNMP polling of the laptops
  • 7. An auditor asks a company to show that it can produce firewall logs from eleven months ago, though analysts only search the last 90 days of data in the SIEM. Which monitoring activity addresses the auditor's request?
  • A. Alert tuning
  • B. Archiving
  • C. Scanning
  • D. Normalization
  • 8. A SIEM analyst notices that correlation rules are failing to link a VPN login with subsequent file server activity even though both occurred within minutes. Investigation shows the file server's clock is 17 minutes behind. Which of the following should be implemented?
  • A. NTP synchronization across all log sources
  • B. Port mirroring on the file server switch port
  • C. SNMPv3 on the VPN concentrator
  • D. DLP on the file server
  • 9. A security engineer reviews the following syslog severity values from a set of firewall messages: 2, 4, 6, and 7. Which value represents the MOST severe condition?
  • A. 2
  • B. 4
  • C. 6
  • D. 7
  • 10. A company wants to detect employees emailing spreadsheets containing customer credit card numbers to personal accounts and to block the messages. Which tool is MOST appropriate?
  • A. Vulnerability scanner
  • B. Network management system
  • C. Data loss prevention
  • D. Packet analyzer
  • 11. A malware investigation requires the analyst to see the exact HTTP requests and response bodies a compromised workstation exchanged with an unencrypted command-and-control server. Which tool provides this level of detail?
  • A. NetFlow collector
  • B. Packet analyzer
  • C. Network management system
  • D. SCAP scanner
  • 12. Which of the following are functions commonly performed by a SIEM? (Select TWO.)
  • A. Correlating events from multiple sources to identify attacks
  • B. Physically copying traffic from a network link
  • C. Aggregating and normalizing logs from diverse devices
  • D. Issuing digital certificates to endpoints
  • E. Encrypting data at rest on file servers

Answers and Explanations

  • 1. B. The analysts are suffering from alert fatigue caused by false positives. Tuning—suppressing known-benign sources, adjusting thresholds, adding context—reduces noise while preserving real detections. A second SIEM adds cost without fixing the rules. Disabling all medium and low alerts would create false negatives. Longer retention does not affect alert volume.
  • 2. B. NetFlow records metadata about every flow, including source, destination, and byte counts, and is compact enough to retain for months. SNMP traps report device events, not host conversations. Antivirus logs show detections on endpoints, not traffic volumes. Domain controller logs show authentication, not network flows to an external IP.
  • 3. C. SNMP is the protocol for polling interface counters and receiving traps such as reboots, and SNMPv3 is the only version that provides authentication and encryption. SNMPv1 and v2c send community strings in cleartext. Syslog over UDP could report a reboot but cannot poll utilization and is unencrypted.
  • 4. B. SCAP provides standardized formats (such as XCCDF checklists and OVAL tests) so that a benchmark can be evaluated by any SCAP-compliant tool. NetFlow records traffic, SNMP monitors devices, and port mirroring copies traffic; none standardizes configuration checklists.
  • 5. A, C. A SPAN (port mirroring) session copies traffic from source ports or VLANs to the sensor's port, and a network TAP passively copies traffic on a link. SNMP traps and syslog send device events, not copies of traffic. Making the sensor the default gateway would put it in the traffic path as a router, which is not a monitoring design and would disrupt the network.
  • 6. B. Agents installed on the laptops collect detailed process, file, and network data and can cache it until the device reaches the internet, then forward it to a cloud or central collector. Agentless scanning and SNMP require the laptop to be reachable, and NetFlow from the core router would not see traffic that never crosses the corporate network.
  • 7. B. Archiving moves older data to long-term storage to satisfy retention requirements, allowing logs to be restored when needed. Alert tuning adjusts detections, scanning probes systems, and normalization maps fields to a common schema; none provides long-term retention.
  • 8. A. Correlation depends on accurate timestamps. Synchronizing all sources with NTP ensures events line up in time. Port mirroring, SNMPv3, and DLP do not fix clock skew.
  • 9. A. Syslog severities run from 0 (Emergency) to 7 (Debug); lower numbers are more severe. Level 2 is Critical, 4 is Warning, 6 is Informational, and 7 is Debug.
  • 10. C. DLP inspects content for sensitive data patterns such as credit card numbers and can block or quarantine the email. A vulnerability scanner finds weaknesses, an NMS monitors network device health, and a packet analyzer captures traffic for analysis but does not enforce data policies.
  • 11. B. A packet analyzer captures and decodes full packets, including HTTP headers and bodies when traffic is unencrypted. NetFlow provides only metadata, an NMS monitors device availability and performance, and a SCAP scanner checks configurations.
  • 12. A, C. Core SIEM functions include aggregating and normalizing logs and correlating events across sources. Copying traffic from a link is done by a TAP or SPAN port. Issuing certificates is a certificate authority function, and encrypting data at rest is done by storage or file system encryption.
Use ← → to move between sections