Logging & Monitoring

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Logging records events; monitoring is the review that turns them into detection

Logging writes an event down when it happens, while monitoring is the continuous review of those records and live telemetry to spot what matters: the two form a pipeline, not a synonym pair. Logs that accumulate without anyone analyzing them are the most common detective-control failure, because the control that was supposed to catch the attack (review) never actually runs. The whole subtopic exists to extract signal from logs, so every tool here is a way to analyze records rather than to generate more of them.

Trap Treating exhaustive logging as detection on its own. Collection without review detects nothing.

Centralize logs off the host so a compromise cannot erase the evidence

Logs left on the host that generated them are deleted or altered the moment that host is compromised, so forward them to a central, access-controlled store as close to real time as possible. Centralization also enables correlation: an event that looks innocuous in one server's log is obvious when many sources are read together. NIST SP 800-92 frames this as the core of security log management, and a write-once or append-only store further protects the record so even an intruder with admin rights cannot rewrite history.

Trap Leaving logs only on the originating host because they are also forwarded later in batch, giving an attacker a window to wipe them before they ship.

1 question tests this

• Following a suspected fraud incident, a security manager at a bank discovers that relevant logs are scattered across individual systems,…

Synchronize all clocks with NTP, or correlation and forensic ordering break

Every correlation depends on a shared, trustworthy clock, so synchronize all devices to a common time source using the Network Time Protocol (NTP). If two systems' timestamps disagree, no SIEM can correctly order their events and the true sequence of an attack is lost. Skewed clocks also weaken logs as forensic evidence because the ordering of records cannot be trusted.

Trap Blaming a SIEM's correlation rules for an incoherent timeline when the real cause is unsynchronized clocks.

1 question tests this

• Following a suspected fraud incident, a security manager at a bank discovers that relevant logs are scattered across individual systems,…

Signature detection catches known threats but is blind to anything novel

Signature-based detection matches activity against a database of known-bad patterns (hashes, exploit packet shapes, malicious URLs), making it precise and low-noise for known threats. Its structural weakness is that a zero-day or never-seen variant has no signature, so it passes straight through. Reach for anomaly/behavior-based detection instead when the threat may be previously unseen.

Trap Choosing signature-based detection to catch a zero-day. No signature exists yet for an attack nobody has seen.

1 question tests this

• A security architect at an e-commerce company is hardening the internet-facing tier that processes payment transactions. Threat…

Anomaly detection catches the unknown by modeling normal, at the cost of false positives

Anomaly- (behavior-) based detection first learns a baseline of normal, then flags statistically significant deviations from it, which lets it catch novel attacks that no signature covers. The trade-off is false positives: legitimate activity that drifts outside the baseline triggers alerts that must be tuned out. This is the right side of the signature-vs-anomaly choice whenever a stem says 'detect a previously unseen attack.'

Trap Picking anomaly-based detection for its low false-positive rate, when its strength is catching the unknown and it actually generates more false positives than signature matching, not fewer.

2 questions test this

• An organization is experiencing frequent zero-day attacks and needs to enhance their intrusion detection capabilities. The security team…
• An organization uses traditional signature-based antivirus software but is experiencing successful attacks from fileless malware and…

An IDS detects and alerts; an IPS sits inline and can block

An Intrusion Detection System (IDS) observes activity and raises an alert (a detective control that does not stop the attack) while an Intrusion Prevention System (IPS) sits inline in the traffic path and can drop or reset malicious connections, making it a preventive control. The placement is the whole difference: an IDS can tap a passive span/mirror port out of band, but an IPS must be inline, so a false positive or outage in an IPS can break legitimate traffic. NIST SP 800-94 treats them together as IDPS because most products now do both.

Trap Expecting an out-of-band IDS to stop an attack. It only alerts; only an inline IPS can block.

NIDS sees the wire, HIDS sees the host, so critical environments run both

A network IDS/IPS (NIDS/NIPS) inspects traffic on a segment and catches attacks crossing the wire, but is blind inside encrypted tunnels and to activity that never leaves the host. A host IDS/IPS (HIDS/HIPS) runs on the endpoint and sees local file changes, process behavior, and post-decryption activity, but only for that one machine. Because each covers the other's blind spot, defense in depth places network sensors at chokepoints and host sensors on critical systems rather than choosing one.

Trap Relying on a NIDS alone to detect an attack inside an encrypted session or one confined to the host, where only a HIDS can see it.

1 question tests this

• A security engineer at a healthcare organization needs to detect malware and unauthorized changes on a fleet of clinician workstations.…

A SIEM aggregates and correlates logs so scattered events become one alert

A Security Information and Event Management (SIEM) platform aggregates logs from many sources, normalizes them to a common format, and correlates them with rules so individually innocuous events combine into one high-fidelity alert. Its value is the centralized cross-source view that reconstructs an attack timeline no single host log reveals, which is exactly why it depends on NTP-synchronized clocks. SIEM correlation rules are usually signature-style, with anomaly analytics (UEBA) layered on for behavioral detection.

Trap Treating a SIEM as a detection engine that finds threats on its own, when its value is correlating the logs other tools generate and its rules are only as good as the sources and clocks feeding it.

9 questions test this

• A security operations manager at a retailer must satisfy auditors who require that authentication events, firewall denials, and endpoint…
• An organization's SIEM ingests logs from multiple sources including vulnerability scanners, patch management systems, and endpoint…
• A security operations team is implementing a SIEM solution to correlate vulnerability scanner data with security events. They want to…
• A security analyst at a manufacturing firm is investigating signs of a stealthy intrusion in which the attacker's individual actions each…
• An organization is implementing a SIEM solution to centralize security monitoring. The security team discovers that firewall logs use…
• An organization has deployed multiple honeypots across different network segments and wants to leverage the collected data for proactive…
• During the implementation of a SIEM solution, the security team discovers that logs from different network devices use inconsistent field…
• A security administrator is configuring a new SIEM solution and notices that firewall logs use a different timestamp format than Windows…
• A SIEM analyst observes that a single user account generated failed login attempts from three different geographic locations within a…

Browse all 9 questions →

UEBA detects the compromised insider by baselining behavior, not matching signatures

User and Entity Behavior Analytics (UEBA) builds a behavioral baseline per user and per entity (servers, devices, service accounts) and flags significant deviations: a mass download, an off-hours login from a new location, lateral movement never seen before. It is the answer for a compromised credential or malicious insider whose individual actions are authorized but whose pattern is abnormal. Signature tools miss this because no malware is involved; the account is legitimate, only its behavior is wrong.

Trap Reaching for antivirus or signature tools against a compromised valid account. No malware is present, so they see nothing wrong.

2 questions test this

• A security operations lead at a pharmaceutical firm is concerned about a trusted research scientist who holds legitimate access to…
• A security manager at a bank is concerned about insider threats and compromised-credential attacks that produce no known signature but…

Egress monitoring and DLP watch what leaves, because exfiltration is the loss event

Most monitoring focuses inbound, but the damage in a breach happens when data flows out, so egress monitoring and Data Loss Prevention (DLP) inspect outbound traffic for sensitive content. DLP enforces across data in motion (network), data in use (endpoints), and data at rest (storage). Egress filtering, allowing only expected destinations and protocols outbound, complements DLP by limiting command-and-control channels and blocking traffic to unexpected destinations.

Trap Concentrating monitoring and firewall rules on inbound traffic, leaving outbound exfiltration and command-and-control channels unwatched.

DLP only acts on content it can read, so network DLP must decrypt TLS first

DLP can inspect only content it can actually read, so strong end-to-end encryption or an unrecognized format defeats inspection entirely. That is why network DLP typically performs TLS termination/decryption at the egress point before examining the payload. Without it, an encrypted exfiltration channel passes uninspected. This makes decryption infrastructure, not the DLP engine itself, the usual missing piece when sensitive data still leaks.

Trap Assuming DLP transparently inspects encrypted traffic. It cannot read the payload until TLS is terminated and decrypted.

Continuous monitoring (ISCM) replaces the annual snapshot with ongoing awareness

Information Security Continuous Monitoring (ISCM), defined in NIST SP 800-137, is maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk-management decisions. It replaces the once-a-year audit snapshot so authorization decisions rest on current data and control drift is caught in days rather than at the next assessment. Logging and monitoring are the data sources; ISCM is the governance program that consumes them.

Trap Reading 'continuous' as fully automated and tool-only, when ISCM is a governance program that consumes monitoring data to drive risk decisions, not just a real-time scanner.

IOCs are easy to load but go stale; TTPs are durable, so hunt on behavior

Threat feeds deliver Indicators of Compromise (IOCs), malicious IPs, file hashes, domains, that are easy to load into a SIEM or IDS but trivially changed by the attacker, so they go stale fast. Tactics, Techniques, and Procedures (TTPs), catalogued in frameworks like MITRE ATT&CK, describe how an adversary operates and are far more durable because behavior cannot be rotated as cheaply as an IP. Detection built on TTP behavior is therefore more resilient than detection chasing individual IOCs.

Trap Relying solely on IOC feeds for detection. Attackers change indicators trivially, so IOC-only detection ages out quickly.

Threat hunting is the proactive, hypothesis-driven search for an attacker already inside

Threat hunting is the human-led search for adversaries who already slipped past automated detection, starting from a hypothesis ('if an attacker used this technique, here is the trace it would leave') and querying centralized logs to confirm or refute it. It assumes compromise has already happened rather than waiting for an alert to fire, which makes it the human counterpart to the automated pipeline. Hunting leans on TTP-level intelligence because behavior is what survives an attacker's evasion of indicator-based controls.

Trap Treating threat hunting as waiting for and triaging the alerts the SIEM fires, when it is a proactive hypothesis-driven search that assumes the alert never came.

1 question tests this

• A security operations lead at a software company receives a vendor threat report detailing a newly observed threat actor, including…

Threat intelligence is contextual adversary knowledge that tells detectors what to look for

Threat intelligence is curated, contextual knowledge about adversaries, delivered through threat feeds, that sharpens every detector by supplying what to watch for. It is the input layer to the SIEM and IDS, not a detection method itself: feeds carry both IOCs and TTPs. Good intelligence is timely and relevant to the organization's actual threat landscape, not just a raw firehose of indicators.

Trap Treating threat intelligence as a detection control in its own right, when it is the input that sharpens the SIEM and IDS rather than a tool that fires alerts itself.

Set log retention by the longest applicable requirement, since breaches surface late

Log retention is driven by the longest of the applicable requirements (regulation, contract, and the organization's own investigation needs) because many intrusions are discovered months after the initial breach. A log already rotated away cannot be investigated, so under-retaining destroys evidence you may not know you need yet. Retention is a policy decision that lands in monitoring as the parameter deciding whether the evidence still exists when an incident is found.

Trap Setting retention to the shortest period that satisfies any single regulation, when the controlling figure is the longest of all applicable legal, contractual, and investigative needs.

2 questions test this

• A facility security officer is reviewing surveillance camera footage retention policies. Recent regulatory guidance requires the…
• Following a suspected fraud incident, a security manager at a bank discovers that relevant logs are scattered across individual systems,…

Protect log integrity with write-once storage so the record itself is trustworthy

Logs are only useful as evidence if they have not been tampered with, so a central log store is commonly write-once or append-only to prevent alteration even by an administrator or an intruder with admin rights. Integrity protection is what lets a SIEM alert and a forensic timeline be trusted, since an attacker's first move is often to edit or clear logs. This complements centralization: moving logs off-box keeps them, and write-once storage keeps them honest.

Trap Assuming restrictive file permissions or admin-only access protect log integrity, when a privileged admin or an intruder with those rights can still alter them and only write-once/append-only storage prevents it.

2 questions test this

• Following a suspected fraud incident, a security manager at a bank discovers that relevant logs are scattered across individual systems,…
• An organization is establishing a research honeynet to study attacker behaviors over extended periods. To protect the integrity of…

Match DLP inspection to the data: exact data match for known DB values, corroborating context to cut false positives

Exact data match (EDM) compares content against actual values in a sensitive-source table, so it reliably catches specific records (a known SSN, medical-record number, or patient name) that pattern matching would miss. To suppress false positives on generic patterns like an SSN regex, require supporting evidence in proximity (keywords, corroborating identifiers, or a higher confidence threshold) so a match only fires with real context.

Trap Plain regex/pattern matching (or 'keyword only') flags every nine-digit number; it neither pins to known records like EDM nor carries the context that kills false positives.

4 questions test this

• A security administrator is implementing a DLP solution to protect patient health records. The organization maintains a database containing…
• A security analyst is configuring a DLP solution to protect sensitive patient records at a healthcare organization. The organization needs…
• An organization is experiencing a high false positive rate with their DLP policies that detect Social Security Numbers. Many legitimate…
• An organization is configuring DLP content inspection policies to detect protected health information. The security team wants to minimize…

Cut alert fatigue by continuously tuning detections to the environment's baseline, not by disabling them

A flood of benign alerts buries real intrusions, so the durable fix is continuous tuning of detection rules and thresholds against the organization's normal baseline. Specific levers: granular per-protocol allowlists/whitelists for known-benign activity, entity exclusions for a specific service account that generates legitimate noise (while still detecting the same behavior from other accounts), and risk-based prioritization so the highest-criticality alerts surface first. The goal is a better signal-to-noise ratio with detection capability intact.

Trap Turning off a noisy rule entirely. That restores quiet by creating a blind spot; tune or scope the exclusion instead.

4 questions test this

• A security analyst notices that the organization's IPS is blocking legitimate business transactions, causing customer complaints. The…
• A security analyst notices that a SIEM analytics rule is generating numerous false positive alerts for a specific service account that…
• A security operations team is experiencing alert fatigue from their SIEM deployment. Many alerts for patch compliance violations are being…
• A SOC manager at an insurance company finds that analysts are overwhelmed by a high volume of detection alerts, the vast majority of which…