Alerting and monitoring, and the tools CompTIA names

Objective 4.4 in this course covers alerting and monitoring — CompTIA's scope note for it explains monitoring tools and computing resource activities. It is the objective that connects the detection ideas scattered through Domain 2 to the investigation work in 4.9.

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.

The exam asks three things here. Which tool does what. What the stages of the monitoring lifecycle are. And — most usefully — what to do about alert volume, which is where the answer is tuning rather than more tooling.

The lesson

Monitoring computing resources: systems, applications and infrastructure

CompTIA splits what you monitor into three, and each answers different questions.

• Systems — operating systems and hosts. Authentication events, process creation, privilege use, service changes, scheduled tasks, file integrity, and resource utilisation. 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 they have to be deliberately enabled and forwarded.
• Infrastructure — network devices, firewalls, load balancers, hypervisors, cloud control planes. Traffic flows, configuration changes, and — critically — the cloud control plane audit log, which records who created, changed or deleted resources via API. In cloud incidents that log is often the whole story.

The practical point is coverage, and it is measurable: for each asset class in the inventory from 4.2, 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, scanning, reporting, archiving

CompTIA's monitoring activities, which form a lifecycle:

• Log aggregation — collecting logs centrally. This is a security control in itself and not only convenience: logs on a compromised host can be altered or deleted by the attacker, so forwarding them off the host immediately is what preserves them. Anti-forensic log clearing is a standard step in intrusions, and centralised copies are what survive it.
• Alerting — rules and analytics that turn events into notifications. The rule must define what happens next, or it is not an alert, it is a message.
• Scanning — the vulnerability and configuration scanning from 4.3, feeding the same picture.
• Reporting — periodic summaries for management and audit, covering coverage, volume, alert counts and response times.
• Archiving — retaining logs long enough to be useful. The exam's point is that intrusions are commonly discovered months after they began, so logs retained for thirty days may not cover the initial compromise. Retention is driven by regulation, by contract, and by the realistic time-to-discovery.

Two supporting ideas. Logs need accurate, synchronised time — NTP across the estate — because correlating two sources whose clocks differ by hours produces a timeline that is wrong rather than merely incomplete. And log integrity matters: write-once storage or cryptographic signing so a log entry can be shown not to have been altered, which is what makes it evidence rather than recollection.

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 it is a failure mode the exam expects you to recognise 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 the combination rather than the individual event — a failed login is nothing, fifty failed logins then a success is something;
• suppress known-benign sources, by name and with a recorded reason, rather than by broad exclusion — a wildcard exclusion added to quieten one scanner will also hide an attacker using the same subnet;
• and delete rules that no longer earn their place.

The reverse failure is equally real and less discussed: 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 this. Baselining — you cannot say what is anomalous until you have measured what is normal, so a period of observation precedes useful alerting. And alert triage priority, so that the limited analyst time goes to the highest-value alerts rather than the oldest.

SCAP, benchmarks, agent versus agentless, SIEM, antivirus, DLP, SNMP traps, NetFlow

The named tools, with what each is actually for:

• SCAP (Security Content Automation Protocol) — a standard set of specifications that lets tools express and check security configuration automatically. Its practical value is that a benchmark (CIS, STIG) can be machine-checked against every host, producing per-setting compliance. This is how the "maintain" stage of a baseline is measured.
• Benchmarks — the published secure configuration standards themselves.
• Agent-based monitoring installs software on the host: deep visibility, works off-network, can act locally; costs a privileged component everywhere and a deployment to maintain. Agentless uses existing protocols and credentials: nothing to install, less depth, needs network reach, and misses devices that are off the network.
• SIEM (security information and event management) — aggregates logs from everywhere, normalises them, correlates across sources, alerts, and stores for investigation. Its defining capability is correlation: linking a firewall event, an authentication event and a process event into one story.
• Antivirus / anti-malware — signature and heuristic detection of known malicious files. Necessary and, as Domain 2 established, structurally unable to catch fileless and living-off-the-land activity, which is EDR's job.
• DLP (data loss prevention) — identifies sensitive data and controls its movement. Covered in the next lesson.
• SNMP traps — devices pushing notifications when something happens, rather than waiting to be polled. Used for infrastructure health. Use SNMPv3; v1 and v2c send community strings in clear text.
• NetFlow and its relatives — records of conversations: who talked to whom, on what port, for how long, how many bytes. Not content. This is the right tool for beaconing, lateral movement and exfiltration volume, and it works even when everything is encrypted, which is why it has become more valuable rather than less.
• Vulnerability scanners from 4.3, feeding the same view.

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

Quarantine and alert response, and what happens after the alert fires

An alert is only a control if something follows it. CompTIA names the responses:

• Quarantine — isolating the affected item. For a file, moving it somewhere it cannot execute. For a device, restricting it to a remediation network. For an email, holding it before delivery. For a host, EDR network isolation, which cuts it off from everything except the management channel so investigation can continue on a live machine.
• Alert response and remediation/validation — the triage path: confirm whether it is real, contain if it is, remediate, and then validate that the remediation worked, which is the same closing step as 4.3's rescan.

What makes this work in practice is that each alert has a documented response — a playbook saying what to check, what to do, and when to escalate. Without one, response quality depends on which analyst is on shift. With one, it is consistent and it is automatable, which is where the automation lesson picks it up.

The measures to care about, and the ones an exam scenario will quote: mean time to detect and mean time to respond. Both are about flow. An organisation whose MTTD is falling is getting better even if its alert count is rising.

What to take into the exam

• Forwarding logs off the host immediately is what survives an attacker clearing them.
• Retention must cover realistic time-to-discovery — thirty days often does not reach the initial compromise.
• Alert fatigue is a named failure: the fix is tuning and correlation, not more alerts, and every exclusion is a blind spot that needs reviewing.
• You cannot detect anomalies without a baseline of normal.
• NetFlow = who talked to whom (works when encrypted); packet capture = what was said; SIEM = correlation across sources.
• SNMPv3, not v1/v2c, because the older versions send community strings in clear text.