8.3 Analyze Monitoring Results

Analysis is what turns a dashboard into a decision

Knowledge area 3.5 — Analyze monitoring results is the last Domain 3 task: you already collected telemetry (3.4) and you already run assessments (3.3). Now you have to decide what the data means and tell someone in a form they can act on. The outline's four bullets are the workflow: compare to security baselines, use visualizations, metrics, and trends, perform event data analysis, then document and communicate findings (including escalation).

SOC analysts fail 3.5 in two opposite ways. They either treat every red pixel as an incident (no baseline, no noise reduction), or they treat every noisy signature as "the IDS being the IDS" and miss a compliance violation sitting in the same queue. SSCP items test whether you can tell those apart.

Security baselines and anomalies

A security baseline in monitoring is the documented normal for a system or population: typical login hours, typical east-west flows, typical event volume, typical process trees, typical API query rates. It is related to the configuration baseline in Domain 1, but here you are baselining behavior and telemetry, not only a gold image.

Anomalies are deviations from that normal that survive a first sanity check. A file server that suddenly speaks to an unfamiliar autonomous system is an anomaly only if you know what it usually speaks to. Without a baseline, everything is either ignored or paged.

Correlation joins events across time and source so a single story appears: five failed VPN authentications, a success, a new mailbox forwarding rule, and an unusual SaaS token grant may be one account-takeover, not four tickets. Correlation depends on common time (NTP from 3.4), common identity fields, and parsers that actually extract those fields. Correlation windows that are too tight miss slow attacks; windows that are too wide glue unrelated noise together.

Noise reduction is the disciplined removal of known-good or duplicate signal so analysts can see the rest. Techniques include:

• Filter a signature on a documented backup subnet after you prove the traffic is the backup job.
• Aggregate 8,000 identical IDS hits into one event with a count.
• Require two independent sources before paging (firewall deny and EDR process start).
• Use machine-learning correlation to surface outliers against the baseline, with a human reviewing the model's own drift.

Noise reduction is not deleting last quarter's tickets so the dashboard looks green. It is not disabling a signature because it is annoying. It is changing the detection so the next event is more likely to be real.

False positives and false negatives

Every detection trades two error types.

A manager who wants "fewer tickets" is asking you to reduce false positives. That is legitimate. The SSCP trap is reducing them by methods that increase false negatives. A signature with a 90% false-positive rate that also caught two real ransomware command-and-control beacons last quarter should be tuned (scope, threshold, correlation with EDR) or replaced, not blindly disabled. If you disable it, you have bought a quiet night and a possible missed beacon.

The opposite trap is leaving every signature in default-on, paging the on-call for backup traffic every night, and training the organization to ignore the queue. That is how a true compliance violation sits unworked for a week.

Tune toward the risk of the missed event. For ransomware beacons and cardholder-data leaks, tolerate more false positives while you improve the rule. For informational IDS signatures on a lab VLAN, tolerate fewer pages.

Visualizations, metrics, and trends

The outline names notifications, dashboards, and timelines as the ways you look at results.

Notifications are the push: SMS, email, chat, ticket. They need a severity, a runbook link, and a route that matches hours of operation. A critical notification that only emails a shared inbox at 02:00 is not a notification, it is a hope.

Dashboards are the pull: current counts of open cases, log-source health (omissions), top talkers, detection-rule status. Dashboards support metrics — volume, true-positive rate, time to acknowledge, number of unparsed sources — and trends over days and weeks. A spike in VPN failures after a phishing wave is a trend you should see without opening every event. A slow climb in exception tickets for an old cipher is a trend that belongs in the risk register.

Timelines are how you present a single incident or anomaly: ordered events across sources. They are unusable if clocks are skewed. They are the artifact you attach when you escalate.

Visualizations do not replace narrative. A pretty dashboard is not self-documenting evidence for an auditor or a chief information security officer (CISO). Metrics should not be gamed: rebuilding a "baseline" every hour from the noisiest sensor guarantees a busy-looking chart and no anomaly detection. ISC2 does not publish a required SSCP mean-time-to-detect number; use the organization's stated service levels, and do not invent a universal minute count.

Machine-learning trend tools can highlight drift in user behavior or in a model's own error rate. Treat model drift in a detection engine as an anomaly in the monitoring platform: the detector stopped matching last month's true positives. That is a 3.5 finding about the tool, and it is also a Domain 3 AI topic ISC2 explicitly folded into this knowledge area.

Event data analysis

Event data analysis is the craft of reading the correlated set and answering who, what, when, where, on which asset, using which identity, and whether it is still happening.

A practical sequence:

1. Confirm the event is still in policy scope (not a decommissioned honeypot you forgot).
2. Pivot on identity, source IP, host, hash, or token across SIEM, EDR, and application logs.
3. Build a timeline. Note gaps (omissions) as facts.
4. Check change tickets, vulnerability-scan context (is this host already a known overdue CVE?), and threat intelligence.
5. Decide the class: error, omission, anomaly, unauthorized change, compliance violation, policy failure — or a true security incident that will move to Domain 4.
6. Record what you ruled out. Negative findings ("no evidence of data leaving the segment") are analysis, not wasted time.

Analysis is not the same as containment. If you are about to isolate a host, you have crossed into incident response (Chapter 9). 3.5 is the judgment and communication step that decides whether that handoff happens.

Document and communicate findings, including escalation

Document means a durable record: ticket or case with sources, timestamps (including time zone), assets, identities, what you checked, what you did not check, and a current severity. Chat screenshots are not the record. If you tuned a signature, document the filter and the expiry review date so the next analyst knows why backup VLAN 40 is quiet.

Communicate means the right audience gets the right level:

Escalation is the act of moving a finding to someone with the authority or the playbook to act. Escalation paths should be written: when to page, when to wait for business hours, when to notify legal, when a compliance violation bypasses the "it's probably a false positive" instinct.

Scenario: noisy IDS versus a compliance violation

The overnight queue has two items.

Item A: an IDS signature named ET POLICY Backup Traffic fires 4,000 times from the backup subnet to the SAN. It has fired every night for months. Analysts are used to closing it as a false positive. The correct 3.5 action is noise reduction: document that the source and destination match the backup procedure, tune the signature (suppress that pair, or move it to informational), and record a review date. Escalating Item A to the CISO every night trains leadership to ignore you.

Item B: the payment application began writing full primary account numbers to an application debug log after a vendor "trace on" flag was left enabled. There is no malware. The SIEM parsed the field. This is a compliance violation and a policy failure, likely a PCI DSS logging and data-protection problem, and a confidentiality incident for cardholder data. You do not file it next to Item A as another noisy signature. You escalate to the application owner and the compliance/risk channel, preserve the log (integrity and preservation from 3.4), stop further cleartext writes, and document the finding with a timeline. Waiting because "it isn't ransomware" is a false negative in organizational terms: the event of interest was real and nobody with authority heard.

The exam wants that contrast. Noise gets tuned. Compliance and confirmed malicious activity get escalated. Both get documented. Neither gets deleted to pretty-up a dashboard.

How to attack a CAT analysis item

1. Find the baseline. If the stem gives you "normal," treat deviations as candidate anomalies.
2. Name the error type if someone proposes disabling a detection: are they cutting false positives at the cost of false negatives?
3. Separate tune from escalate. Backup-signature noise is a tune. Cardholder data in logs is an escalate.
4. Require documentation: sources, time, owner, next action. A dashboard is not the finding.

That is the close of Domain 3: assess with context, monitor with integrity, analyze against a baseline, and put the quiet part in a ticket someone can act on.