8.2 Operate and Monitor Security Platforms

Continuous monitoring is how 3.3 stays true after the report is filed

Knowledge area 3.4 — Operate and monitor security platforms is the SSCP outline's continuous monitoring job. Assessments tell you what was true during the scan window. Platforms tell you what is true now: a firewall rule that appeared at 02:14, an application that started throwing 500s, a host that stopped shipping logs. Domain 3 is 15% of the exam; 3.4 is where systems administrators and security operations center (SOC) analysts live.

The outline splits the work into four piles you should be able to name without hunting: source systems, events of interest, log management, and security information and event management (SIEM). Time synchronization is not listed as its own bullet, but it is a prerequisite for log integrity and for SIEM correlation. If clocks disagree, you do not have a timeline — you have a pile of rumors with timestamps.

Source systems: if it can speak, it should be in scope

A source system is anything that emits security-relevant telemetry. The outline's examples are the classification set to memorize.

If a system is in the asset inventory from 3.3 and it cannot send logs, that is a monitoring gap, not a mysterious "quiet" asset. Printers and building sensors can be sources when they sit on the production network; they are not the exam's primary examples. Do not collect only firewall denies and pretend application and host logs are optional. Attackers live in all four columns.

Events of interest: what you are actually hunting

Events of interest are the classes of telemetry that indicate error, abuse, or control failure. The outline lists six; learn them as a set.

A CAT stem that describes a missing log source is an omission. A stem that describes a configuration change with no ticket is an unauthorized change. A stem that describes payment-card data in a cleartext log is a compliance violation. Naming the class correctly drives whether you tune a signature, open an incident, or escalate to compliance.

You cannot keep every successful workstation login forever at full fidelity and still have a usable platform. That is what aggregation and tuning are for. You can keep privileged authentications, change events, and compliance-relevant failures.

Log management: policy, integrity, preservation, architecture, configuration, aggregation, tuning

Log management is the discipline that makes telemetry trustworthy enough to use in an investigation or an audit. The outline's word list is the study checklist.

Policy. Write down what is collected, from which sources, at what severity, who may read it, how long it is kept, and how exceptions are approved. A log policy is an administrative control (knowledge area 1.3) that 3.4 implements. Without it, every engineer has a different idea of "enough."

Integrity. Logs must not be editable by the people whose actions they record. Forward off-box, restrict delete, hash or use append-only / write-once storage, and protect transport with TLS (or a vendor equivalent) rather than cleartext syslog across untrusted networks. Network Time Protocol (NTP) — or a successor such as Network Time Security — is an integrity control: a timestamp the originator can pick is not evidence. If the firewall administrator can also edit the firewall's logs on the SIEM, accountability from Domain 1.2 is gone.

Preservation. Retention follows legal, regulatory, and investigative need. The Payment Card Industry Data Security Standard (PCI DSS) requires audit logs be retained for at least 12 months, with at least 3 months immediately available for analysis. Other laws and contracts differ; the SSCP job is to implement the stated period and to freeze (legal hold) when counsel says so, not to invent a number. Overwriting logs every 24 hours to save disk fails preservation.

Architectures. Typical patterns: syslog or event forwarders on hosts, collectors per site, a central store, and a SIEM that reads the store. Agents versus syslog, push versus pull, and cloud-native audit APIs all count. Storing logs only on the generating host is the architecture that dies when that host is hit by ransomware.

Configuration. Standardize time-zone handling (prefer Coordinated Universal Time on collectors), facility and severity mapping, which Event IDs or facilities are forwarded, and disk thresholds. A collector that drops when the disk is full is a self-inflicted omission.

Aggregation. Combine duplicates, parse into common fields (user, source IP, destination, action), and enrich with asset owner and classification. Aggregation is how 10,000 identical failures become one usable event plus a count.

Tuning. Remove true noise, keep true signal. Tuning is not "delete whatever annoys the night shift." It is changing a parser, adding a filter for a known-good backup subnet, or raising a threshold after you understand the traffic. Tuning that drops compliance-relevant events is a policy failure.

Scenario: clock skew breaks correlation

Tuesday, 14:02 local. The perimeter IPS reports a brute-force burst from 203.0.113.50 against the VPN. The Windows domain controller, whose clock is 15 minutes slow after a failed NTP peer, records a spray of failed authentications at 13:47. The SaaS email gateway, set to a different zone and not using NTP, stamps related mailbox-rule changes at 18:02 UTC without a zone tag. The SIEM engineer tries to build one incident timeline and cannot join the three streams. Managers ask whether it is one attacker or three. You cannot answer.

Arrival time at the collector is not a substitute. Collectors delay, batches queue, and a compromised host can wait before forwarding. Fix NTP (or equivalent) so every in-scope source uses a trusted, authenticated time source, monitor for skew, and alert when a host's offset exceeds a small threshold. Increasing SIEM retention to seven years will not align 13:47 with 14:02. Disabling host logging until clocks are "replaced" removes evidence during the outage. Clock skew is a log-integrity incident, not a cosmetics problem.

SIEM: real-time monitoring, analysis, tracking, audit

A security information and event management (SIEM) platform aggregates logs and, depending on the product, detections, then supports four jobs the outline names:

• Real-time monitoring — dashboards, streaming alerts, and on-call notification when a rule matches now, not at tomorrow's report.
• Analysis — search, correlation, reconstruction of an event of interest across sources.
• Tracking — cases, assignments, status, and time-to-acknowledge so work does not live in a chat scrollback.
• Audit — evidence that monitoring itself occurred: which analyst viewed a case, whether a detection rule was disabled, whether a log source went dark.

SIEM is not a magic box. Garbage parsers in, garbage correlation out. If NTP is wrong, correlation that uses time windows is wrong. If the only source is the firewall, the SIEM cannot see a local administrator added on a host.

Machine-learning correlation engines can reduce noise; they still need an owner, a baseline, and a way to detect model drift in the detector (Domain 3's AI overlay). An automated rule that auto-closes cases without an audit trail fails the tracking and audit parts of 3.4.

The pipeline above is the mental model to draw on the exam: sources, synchronized clocks, aggregation, then SIEM functions. A collector that stores events but never alerts is a delayed report generator, not real-time monitoring. A SIEM that alerts but cannot show who disabled a rule last Friday fails audit. A SIEM that cannot assign a case fails tracking.

Operating the platform on a real shift

Start from the inventory. For each critical asset, name at least one source-system category that covers it and at least one event of interest you must not drop. Confirm logs leave the host, time is synchronized, and the SIEM still parses them after the last vendor update. When a manager wants "less noise," tune with evidence. When a manager wants to save disk by wiping logs daily, quote preservation — including the PCI DSS 12-month / 3-month immediately-available rule when cardholder data is in scope — and the investigation you will fail next month.

CAT items in 3.4 usually hide in a choice between collecting the right sources, protecting log integrity (including time), and using the SIEM for live monitoring rather than as a write-only archive. Pick the option that preserves a defensible timeline.