Alerting and monitoring, and the tools that do it

Objective 4.4 asks you to explain how an organisation watches its own estate: what it watches, what it does with what it collects, which tools and protocols carry the data, and how an alert becomes something a person acts on. It is the bridge between the detection ideas in Domain 2 and the investigation work in lesson 41.

Why this matters

Monitoring is where organisations spend a great deal and get less than they expected, for a reason the exam tests directly: collecting is not detecting. A SIEM full of logs nobody has written a rule against, or full of alerts nobody can triage, is an expense rather than a control.

Expect questions on which tool or protocol does what, and on alert volume, where the answer is tuning rather than more tooling.

The lesson

Monitoring systems, applications and infrastructure, with an agent or without one

What you monitor splits three ways, and each answers different questions.

• Systems -- operating systems and hosts. Authentication events, process creation, privilege use, service changes, scheduled tasks, file integrity and resource use. This is where host compromise shows up.
• Applications -- the software's own logs: errors, transactions, authentication and authorisation decisions, administrative actions. Application logs are where business-logic abuse appears, and they are the most commonly missing source because someone has to enable and forward them deliberately.
• Infrastructure -- network devices, firewalls, load balancers, hypervisors, cloud control planes. Traffic flows, configuration changes and the cloud control plane audit log, which records who created, changed or deleted resources through the API.

How the data is gathered is the other half of the choice:

• Agent-based monitoring installs software on the host. It gives deep visibility, keeps working when a laptop is off the corporate network, and can act locally. The cost is a privileged component on every machine and a deployment to maintain.
• Agentless monitoring uses what is already there -- remote management protocols, APIs, credentials, devices sending their own logs. Nothing to install, but less depth, it needs network reach, and it misses devices that are not connected when it looks.

The practical point is coverage, and it is measurable: for each asset class in the inventory from lesson 33, is anything being collected, and does it include the events you would need to answer "who did this?" Most monitoring gaps are coverage gaps, not tooling gaps.

Log aggregation, alerting, archiving and reporting, and dashboards that somebody reads

The monitoring activities form a loop.

• Log aggregation -- collecting logs centrally. This is a security control in itself, not only a convenience: logs on a compromised host can be altered or deleted by the attacker, so forwarding them off the host at once is what preserves them. Clearing logs is a standard step in intrusions, and the central copy is what survives it.
• Scanning -- the vulnerability and configuration scanning from lesson 34, feeding the same picture of the estate.
• Alerting -- rules and analytics that turn events into notifications. An automated alert should say what happens next, or it is not an alert, it is a message.
• Archiving -- keeping logs long enough to be useful. Intrusions are commonly discovered months after they began, so logs retained for thirty days may not reach back to the initial compromise. Retention is driven by regulation, by contract, and by realistic time-to-discovery.
• Reporting -- periodic summaries for management and audit: coverage, volume, alert counts and response times.

Dashboards are the live view, and they are only a control if someone reads them and knows what to do when a number moves. A good security dashboard shows a small number of things that should be acted on -- unhandled high-priority alerts, hosts that stopped sending logs, the time alerts wait before triage -- rather than every metric the tool can draw.

Logs also need synchronised time (NTP across the estate), or correlated timelines come out wrong, and integrity protection, which lesson 41 covers.

Alert tuning, and the false positive that trains people to ignore alerts

This is the part of the objective with the most practical weight.

An alert that fires constantly and is usually wrong does more harm than no alert at all. Analysts learn to dismiss it, the dismissal becomes reflex, and the one time it is real it is dismissed too. This is alert fatigue, and the exam expects you to recognise it by name.

Alert tuning is the ongoing work of fixing that:

• raise or lower thresholds so normal activity stops triggering;
• add context so a rule fires on a combination rather than a single event -- a failed login is nothing, fifty failed logins followed by a success is something;
• suppress known-benign sources by name and with a recorded reason, never by broad exclusion -- a wildcard added to quieten one scanner also hides an attacker using the same subnet;
• delete rules that no longer earn their place.

The reverse failure is just as real: tuning so aggressively that genuine activity is suppressed. Every exclusion is a blind spot, so exclusions need reviewing like any other exception.

Two ideas the exam pairs with tuning. Baselining -- you cannot call something anomalous until you have measured what is normal, so a period of observation comes before useful alerting. And triage priority, so limited analyst time goes to the highest-value alerts rather than the oldest.

SIEM, benchmarks and SCAP, vulnerability scanners, packet analysers and network management systems

The named tools, with what each is actually for:

• SIEM (security information and event management) -- collects logs from everywhere, normalises them into common fields, correlates across sources, alerts, and stores them for investigation. Its defining capability is correlation: linking a firewall event, an authentication event and a process event into one story.
• Benchmarks -- published secure configuration standards for a product, such as the CIS Benchmarks or the US DoD STIGs.
• SCAP (Security Content Automation Protocol) -- a family of standards that lets tools describe and check security configuration in a machine-readable way. Its value is that a benchmark can be checked automatically against every host, producing pass or fail per setting. That is how the "maintain" stage of a baseline from lesson 29 is measured.
• Vulnerability scanners -- the tools from lesson 34, feeding findings into the same view.
• Antivirus and DLP -- also monitoring sources: antivirus reports detections of known malicious files, DLP reports sensitive data on the move. Both are covered as controls in lesson 32.
• Packet analysers -- tools such as Wireshark or tcpdump that capture and decode traffic packet by packet, showing exactly what was sent, at a high storage cost and with little insight into encrypted content.
• Network management systems (NMS) -- platforms that watch network devices for availability, performance and configuration, usually by polling them and receiving their notifications. Built for operations, but a device that goes down, reboots unexpectedly or has its configuration changed is often a security event too.

The discriminator the exam uses most: flow records answer "who talked to whom"; a packet capture answers "what did they say"; a SIEM answers "do these separate events form one story".

Syslog, SNMP and NetFlow, port mirroring, and orchestration as a monitoring tool

The protocols and techniques that move monitoring data around:

• Syslog -- the standard way devices and Unix-like systems send log messages to a central collector. Each message carries a facility (what produced it) and a severity from 0 (emergency) to 7 (debug). Traditional syslog runs over UDP port 514, which is unencrypted and unacknowledged, so messages can be lost or read in transit; TCP and TLS-protected transport fix that and should be used for anything that matters.
• SNMP (Simple Network Management Protocol) -- how an NMS reads device status. The manager polls devices (UDP 161), and devices send traps unprompted when something happens (UDP 162). Use SNMPv3, which adds authentication and encryption; v1 and v2c send their community strings in clear text, and a community string is effectively a password.
• NetFlow -- records of conversations: source, destination, ports, duration, byte counts. Not content. It is the right tool for spotting beaconing, lateral movement and unusual transfer volumes, and it works even when the traffic is encrypted.
• Port mirroring -- configuring a switch to copy traffic from chosen ports or VLANs to a monitoring port, where an IDS or packet analyser listens. Often called SPAN. It is cheap because it uses the switch you already have, but a busy switch may drop mirrored packets, so it can miss traffic under load. A hardware tap, covered with device placement in lesson 22, copies every packet but needs to be installed inline on the cable.
• Orchestration -- automation that ties the tools together. As a monitoring tool it enriches an alert before a person sees it (who owns the host, what else that account did, what threat intelligence says about the address), can open the ticket, and can take a pre-approved step such as isolating a host through EDR. That is where alert response becomes consistent rather than dependent on who is on shift; lesson 38 covers automation in depth.

Measure the whole loop by mean time to detect and mean time to respond: falling times mean improvement even while the alert count rises.

What to take into the exam

• Collecting is not detecting; coverage gaps outnumber tooling gaps.
• Forwarding logs off the host immediately is what survives an attacker clearing them, and retention must reach back to realistic discovery times.
• Alert fatigue is fixed by tuning and correlation, not more alerts; every exclusion is a blind spot to review.
• NetFlow = who talked to whom; packet analyser = what was said; SIEM = correlation across sources; NMS = device health.
• Syslog over UDP 514 is unencrypted; SNMPv3, not v1 or v2c; port mirroring can drop packets, a tap does not.
• A dashboard nobody owns, and an alert with no next step, are not controls.