Security Operations, Monitoring, and Logging

Attention is the scarce resource

The security operations floor exists because an organization cannot defend what it cannot see. That sentence sounds simple, but its consequences are not. Visibility is not the same as attention. A network with perfect telemetry and nobody watching produces no security at all, and an operations floor with a hundred alerting systems and no way to tell the real from the routine produces something worse: noise that buries the one signal that mattered. The scarce resource in security operations is not data, not tools, and not even skill. It is attention, and this domain is the discipline of engineering attention: deciding what to watch, deciding what counts as a deviation, and deciding which events deserve a human and which deserve an automated reply.

The exam tests this domain at the level of the decision-maker. It will not ask you to configure a log parser or write a correlation rule, though it will expect you to know what those things do and why they matter. It will ask you what the security operations center is for, which control requires a given logging behavior, what a baseline is and why deviation from it matters, what a data loss prevention system can and cannot do, and which framework a detection engineering team would use to map adversary behavior. The correct answers, again and again, come from a single habit of mind: ask what decision the monitoring is meant to support, and then ask whether the described control actually produces the evidence that decision needs.

This chapter builds the operations floor in the order a real one is built. First the room: the security operations center, its tiers, its vocabulary, and its metrics. Then the pipe: how telemetry gets collected, normalized, stored, and turned into alerts. Then the raw material: logging, what to log, how to keep it honest, and how long to keep it. Then the analytics: baselines, anomalies, and the cost of being wrong in each direction. Then the center of gravity: the SIEM and correlation. Then the instruments around it: endpoint and network detection, and data loss prevention. Then the adversary knowledge that makes all of it meaningful: MITRE ATT&CK, kill chains, and threat intelligence. And at the end, the controls and standards that anchor the whole floor, because a manager’s job is knowing which requirements are real and which are folklore.

The operations floor: what the SOC actually does

A security operations center, SOC for short, is a team and a facility organized around one purpose: detecting and responding to security events in time to matter. The SOC owns the monitoring mission. It receives alerts from a constellation of instruments, triages them, investigates the ones that look real, escalates the ones that look serious, and hands off confirmed incidents to the incident response capability. Along the way it keeps the record: logs, cases, timelines, and outcomes that let the organization know what actually happened and what it should do differently.

A common and useful way to understand a SOC is by its tiers, a staffing model that appears in job postings and SOC designs everywhere and that the exam expects you to recognize. Tier 1 analysts sit on the front line. They watch the alert queue, triage incoming alerts against known signatures and documented playbooks, and escalate anything they cannot resolve within scope. Their job is triage, not investigation. Tier 2 analysts do the investigation. They take escalated alerts, hunt through logs and endpoint telemetry, confirm or dismiss the finding, and write the case notes that turn a suspicion into a documented event. Tier 3 is the deep bench: the threat hunters, malware analysts, and senior responders who chase novel behavior, reverse-engineer samples, and design the detection rules the whole floor runs on. The tiers are not a standard, but they are the industry’s working answer to the attention problem, because they route attention by cost: cheap attention first, expensive attention only when the cheap kind says it is needed.

The SOC produces two products, and both matter to the exam. The first product is decisions: which alerts are real, which are noise, and which incidents are developing. The second product is the record: an accurate, tamper-evident account of what was observed, when, and what was done about it. The record matters because security operations runs in the past tense. By the time an alert fires, the adversary has already acted. The question is whether the floor can reconstruct what happened well enough to stop it from continuing and to prevent the next attempt. That reconstruction lives in logs, and the logs are worthless if nobody trusts them.

The vocabulary of escalation: events and incidents

Before going further, fix the vocabulary, because the exam leans on it. NIST Special Publication 800-61 Revision 2, the Computer Security Incident Handling Guide, defines an event as any observable occurrence in a system or network. A user logging in is an event. A firewall dropping a packet is an event. An email getting quarantined is an event. Events happen continuously and mostly mean nothing.

An incident is a different animal. Per the same publication, an incident is an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information it processes, stores, or transmits, or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. The distinction is not pedantry. It determines what gets escalated, who gets notified, what gets preserved, and what legal and notification obligations are triggered. Not every event is an incident, but every incident begins as a series of events, and the SOC’s most important judgment is telling the two apart before the series is over.

Metrics that tell the truth

The SOC is a cost center until it demonstrates otherwise, so it measures itself, and the exam likes the vocabulary of those measurements. Mean time to detect, MTTD, is the average time between when a malicious action occurs and when the organization learns of it. Mean time to respond, MTTR, is the average time between detection and containment or resolution. Both matter, and both are driven by the same design choices this chapter covers: what is logged, how fast the pipeline moves, how good the alerts are, and how ready the escalation path is. A floor that detects everything in three days has not failed at detection; it has failed at the part of the mission that protects the business.

The exam also rewards a skeptical reading of metrics. An alert count is a vanity number unless it is paired with how many alerts were real. MTTD is meaningless if it only measures the alerts someone happened to notice. The manager’s discipline is to measure the outcome, the time from attacker action to defender response, not the volume of activity on the floor. If a metric cannot be tied to a decision, it is decoration.

The monitoring pipeline: from telemetry to decision

Monitoring is a pipeline, and like every pipeline it is only as strong as its weakest stage. Four stages deserve names, because the exam will test your ability to say where a given problem lives.

Collection is the first stage. Instruments produce telemetry: firewalls log connections, servers log authentication and system events, endpoints log process activity, applications log their own behavior, identity systems log sign-ins, and network sensors log traffic. Nothing downstream is better than this raw stream. If a source is not instrumented, or an instrument is not configured to log, the floor is blind to that slice of reality no matter how clever its analytics are.

Normalization is the second stage. Telemetry arrives in a thousand dialects. One device says src_ip, another says source-address, a third encodes it as an integer. The pipeline must translate all of it into a common schema before anything can be compared across sources. Normalization is where a lot of false starts die: rules that could not see that the firewall’s field and the endpoint’s field named the same address in different dialects.

Storage is the third stage. Normalized events go into a store that must hold them long enough to support investigation, retention policy, and legal or regulatory demands. The storage decision is where cost shows up first, and it is why retention is a governance decision, not an engineering one. Chapter 10 of this book covered retention and disposal from the asset side; here the same forces play out on the logging side, and the section on retention below takes them up in that light.

Alerting is the fourth stage. The pipeline must decide, continuously, which events or combinations of events deserve a human. This is where attention gets spent, and where the design decisions of the rest of this chapter live: signatures, baselines, correlation rules, and the endless tuning that keeps the alert queue honest.

The pipeline has a characteristic failure mode that the exam loves: a description of a monitoring system that is complete in three stages and broken in the fourth, or complete in all four and broken because nobody reviews the output. The classic trap is the alert that fires perfectly and gets ignored because the queue is full of false positives. That is not a monitoring failure in the technical sense. It is an attention failure, and the manager treats it as a design problem, because a detection nobody acts on is not a detection.

Logging: the raw material of the record

Everything the floor does runs on logs, so the logging design deserves its own careful pass. The authoritative practical reference here is NIST Special Publication 800-92 Revision 1, the Cybersecurity Log Management Planning Guide, published in 2024. It replaces the 2006 edition and remains the standard the exam expects you to know by name when the topic is log management: what to log, where logs come from, how to protect them, and how long to keep them. The audit and accountability controls in NIST SP 800-53 Revision 5 operationalize the same ideas inside a control framework, and the section on controls at the end of this chapter maps them.

What to log and why

The logging decision is a coverage decision. The record is only as good as the events that go into it, and the events that matter are the ones that answer the investigator’s questions: who did what, when, from where, and with what result. NIST SP 800-92 frames logging as a planning activity: identify the sources that matter, the events those sources can record, and the retention and protection those events require, then build the logging infrastructure to match.

In practice, the high-value categories are stable and worth memorizing as a list. Authentication events, especially failures and privilege elevation. Administrative and privileged activity, because the attacker’s favorite first step after breaking in is grabbing an admin account. Access events to sensitive data and systems. Configuration changes, because a changed firewall rule or a modified service account is often the earliest clue of compromise. System events, crashes, and restarts. Network events, connections, protocols, and anomalies. Application events, failures, and security-relevant actions. And the security instrument’s own events: what the IDS flagged, what the antivirus quarantined, what the endpoint sensor observed. The principle behind the list is that the record must support reconstructing a timeline, and a timeline missing authentication events or privilege changes is a timeline that cannot show how an adversary moved.

The content of an individual log record is governed by the same logic and spelled out in NIST SP 800-53 Revision 5 control AU-3, Content of Audit Records. An audit record must establish what type of event occurred, when it occurred, where it occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event. That is the six-item answer the exam wants: type, time, location, source, outcome, identity. A log line that omits any of those is a log line that leaves a question open at the worst moment.

Sources: the instrument list

The log sources themselves form a short catalog that the exam occasionally quizzes directly. Network devices: firewalls, routers, switches, wireless controllers, VPN concentrators. Servers and their operating systems. Identity and access infrastructure: directory servers, authentication services, SSO brokers. Applications and databases. Email and web gateways. Endpoints and their security agents. Cloud services and their native audit trails. Physical access control systems, which matter more than most people expect, because a badge read at a door at 2 a.m. can explain a lot about an intrusion timeline. The point is not to memorize the catalog but to absorb its shape: logging should cover every layer where an attacker could act, from the network edge to the application layer to the physical door.

The transport and format also have a canonical answer. Syslog is the de facto standard for log transport on networked devices, and RFC 5424, published in 2009, defines the modern format that structured logging builds on. An exam answer that says logs should be sent to a central collection point over a standardized protocol such as syslog is an answer in the right shape. What matters for the exam is less the protocol details and more the design intent: centralize, standardize, and protect, because logs scattered across devices are logs that will be incomplete, inconsistent, and unprotectable.

Integrity: the log that cannot lie

Logs are evidence, and evidence has an integrity problem. An attacker who reaches the logging infrastructure can erase the record of their own activity, and an organization that cannot show its logs were not altered has logs that no one can rely on, not in an investigation, not in a lawsuit, not in front of a regulator.

Two mechanisms carry most of the weight. The first is protection of audit information, NIST SP 800-53 Revision 5 control AU-9, which requires protecting audit records and audit tools from unauthorized access, modification, and deletion. The practical translation: restrict who can touch the logs, separate the logging store from the systems being logged, and make deletion and modification privileged, noticed, and logged themselves. The second is write-once storage. Write once, read many, WORM for short, is a storage mode that physically or logically prevents any subsequent modification, including by the administrator who wrote the data. WORM is the answer when the requirement is that a log cannot be rewritten after the fact, which is exactly the requirement in environments where logs must survive an adversary with admin rights, such as those covered by PCI DSS, or where they must survive litigation.

The exam’s favorite shape for this topic is a scenario: an analyst finds that logs from a compromised server show the attacker’s activity up to a point, then go silent, and an administrator confirms the account used to manage the logging server was itself compromised. The insight the question is reaching for is that the logs stopped because the adversary reached the thing that writes and stores them. The defense is architectural: the logging store must be out of reach of the systems it logs, append-only, and separately protected. Control AU-12, Audit Record Generation, rounds out the design by requiring that the system actually provide the capability to generate the audit records and that the records be retrievable by the right people, so the floor can prove both that logging exists and that it can be read when needed.

Clocks: timestamps that agree

A timeline is only as good as the clocks that stamp it. If the endpoint, the firewall, and the identity server disagree about the time by forty minutes, then correlating their events into a single story is guesswork, and in an investigation the story is the whole point. NIST SP 800-53 Revision 5 control AU-8, Time Stamps, requires that the system use internal system clocks to generate timestamps for audit records and that those clocks be synchronized with an authoritative time source. The standard implementation is the Network Time Protocol, NTP, defined in RFC 5905, with systems pulling time from trusted sources. ISO/IEC 27001:2022 makes the same demand from the management-system side in Annex A control 8.17, Clock Synchronization, which requires the use of reliable time sources to synchronize the clocks of information processing systems.

The exam angle is the consequence, not the mechanism. A question will describe an investigation where events cannot be ordered, or where two sources contradict each other, and the answer will be the synchronization requirement: clocks must agree because correlation and reconstruction depend on it. When a log record and a security camera timestamp disagree by hours, the question is not which one is right; it is that the organization failed to keep them in agreement.

Retention: the tension nobody gets to avoid

How long do you keep the logs? The honest answer is the shortest period that satisfies the requirements, because logs cost money, attract legal exposure, and contain personal data. Three forces pull at the retention decision, and the exam tests all three.

Operational force: logs must survive long enough to support detection and investigation. A compromise discovered two months after the fact cannot be investigated if the logs only lasted thirty days. NIST SP 800-92 treats retention as an explicit planning input, and AU-11, Audit Record Retention, requires retaining audit records for the period established by organizational policy, aligned with the record retention requirements of the organization and applicable law.

Regulatory force: some regimes mandate minimums. Payment Card Industry Data Security Standard v4.0, Requirement 10, Log and Monitor All Access to System Components and Cardholder Data, is the exam’s canonical example. It requires logging for all access to cardholder data and to systems in scope, and it requires that audit log history be retained for at least 12 months, with at least the most recent 3 months immediately available for analysis. Twelve months total, three months hot: that pair is a classic exam fact and worth carrying into the Domain 7 practice test.

Legal and privacy force: logs contain personal data, and personal data cannot be kept forever just because keeping it is convenient. The EU General Data Protection Regulation, GDPR, Article 5(1)(e), the storage limitation principle, requires that personal data be kept in a form that permits identification of data subjects no longer than is necessary for the purposes for which it is processed. That means authentication logs that include usernames, IP addresses, and device identifiers need a documented retention rationale: a stated purpose, a legal basis, and a period tied to that purpose. The exam’s shape for this is a scenario in which an organization keeps logs indefinitely or for an arbitrary decade “just in case,” and the correct response is that retention must be defined, documented, and justified, not infinite.

And then there is the override: legal hold. When litigation or an official investigation is anticipated or underway, the organization must suspend routine deletion, including the deletion its retention schedule would otherwise mandate. A legal hold freezes the records, logs included, for the duration of the matter. The exam will offer a tempting option that deletes logs per schedule during pending litigation, and the correct answer preserves them. Legal hold beats retention schedule, always.

Baselining and anomaly detection

Logs are the raw material, but logs alone do not produce security, because nobody can read a million events a day. The floor needs a way to separate the routine from the strange, and the fundamental technique is the baseline.

A baseline is a measured picture of normal. Not a guess about normal: a measurement. Over a defined period, the organization records what its systems actually do: what time users log in, what traffic the network carries, what commands administrators run, what applications talk to what. The baseline becomes the yardstick, and monitoring works by deviation: anything that departs from the baseline is an anomaly, and anomalies get attention.

The exam expects you to recognize the two families of detection that sit on top of this idea. Signature-based detection matches events against known patterns of attack: a known malware hash, a known exploit string, a rule that says “this pattern means bad.” It is precise about what it knows and blind to everything else. Anomaly-based detection compares events against the baseline and flags what is statistically unusual, whether or not it is known. It can catch novel attacks, and it pays for that power with noise, because unusual is not the same as malicious, and the routine contains more unusual moments than any floor wants to chase. The mature program runs both, and the exam rewards the manager who knows each family’s blind spot: signatures miss what they have never seen, and anomaly detection cries wolf on everything it has never seen before.

Behavioral analytics takes the baseline idea to the level of people and entities. User and entity behavior analytics, UEBA for short, profiles the behavior of users and systems over time and flags deviations from their own patterns: an employee who logs in from a new country, a service account that suddenly runs at 3 a.m., a finance workstation that starts encrypting files in bulk. The power of the approach is that it detects the abuse of legitimate credentials, the attack that looks like normal work. The weakness is the same as all anomaly detection: context is everything, and a false positive in this family can accuse a real employee of a real crime. The floor runs these tools with the baseline updated continuously, which is exactly the idea behind NIST SP 800-137, the Information Security Continuous Monitoring guide, discussed in the controls section.

The cost of being wrong in each direction

Detection systems make two kinds of mistakes, and the exam loves the vocabulary. A false positive is an alert that fires when nothing is wrong. A false negative is the far more dangerous miss: no alert fires when an attack is actually underway.

The danger of false positives is not the alert; it is what the alert does to the people receiving it. A queue that is ninety percent noise trains the analyst to ignore the queue. Alert fatigue, the numbing that follows too many worthless alarms, is how real detections get buried, and it is a design failure as much as a human one. The fix is tuning: fewer, better rules, baselines that reflect reality, and severity calibration that matches the consequence of the underlying event.

The danger of false negatives needs no explanation beyond the name. A detection system tuned so aggressively that it stops flagging the things that matter is a system that creates the illusion of monitoring while the adversary operates freely. The manager’s question about any detection control is the same in both directions: when this tool is wrong, which way is it wrong, and what does that cost? The exam will hand you a scenario and ask you to name the failure mode, and the answer is always in the direction of the miss.

The SIEM: correlation at the center

The security information and event management system, SIEM, is the operational center of gravity for most floors, and the exam wants you to know exactly what it does and what it does not do. The name is the definition: security information management, the long-term collection, storage, and analysis of log and event data, combined with security event management, the real-time monitoring, correlation, and alerting. A SIEM is the aggregation point of the monitoring pipeline: it ingests normalized telemetry, stores it, and applies rules and correlation to produce alerts.

The single most examined distinction is aggregation versus correlation. Aggregation is the easy part: pulling events from many sources into one place, which any log collector can do. Correlation is the hard part: applying logic that connects events across sources and time to discover patterns that no single event reveals. The classic example is the login chain: five failed logins from one address, followed by a successful login, followed by a privilege change, followed by data access at a strange hour. Individually, none of those events is notable. Correlated, they are a story, and the SIEM’s correlation engine is the mechanism that assembles stories from fragments. The exam will offer you a system that collects everything but never connects it, and the correct answer is the one that adds correlation.

SIEM alerting runs on use cases: written definitions of what the floor cares about, expressed as rules, baselines, or behavioral models. A use case says, in effect, “when this pattern appears, make an alert at this severity.” The discipline of use case management is keeping the list small, current, and tied to real risk, because every use case is a promise to spend attention. A floor with four hundred rules and two analysts has four hundred ways to prove it cannot answer.

The exam also expects the manager’s view of SIEM operational costs. Ingestion is the expensive part: data volumes grow, storage grows, licensing grows, and the floor must decide what is worth collecting at all. And the SIEM is only as good as the correlation and the people who act on it. A SIEM that nobody reviews is a very expensive log archive. The adjacent technology, SOAR, security orchestration, automation, and response, is worth knowing as a name: it automates the repetitive parts of incident handling, enrichment, case creation, and playbook steps, so the human attention goes to the investigations that need judgment.

Detection beyond the SIEM: EDR, NDR, and the endpoint’s story

The SIEM aggregates what other instruments tell it, but some of the most important detection happens at the source, before any aggregation. Endpoint detection and response, EDR, is the endpoint’s own security agent, watching process activity, memory, files, and network connections on the machine itself. Its value to the exam’s story is that it sees the detail the network cannot: the process that spawned another process, the executable that loaded into memory, the lateral movement command that ran locally. EDR agents can also act, isolating an endpoint or killing a process, and the response half of the name is exactly that capability. Network detection and response, NDR, watches traffic from a network vantage point and catches what endpoints miss, especially activity that happens over the wire, like a device phoning home to an unknown command and control server. Extended detection and response, XDR, is the marketing-era umbrella: telemetry from endpoints, network, cloud, and identity fused into one detection story.

The exam’s angle here is placement and coverage. Each vantage point sees a different slice. Network sensors see the conversation but not the process; endpoint agents see the process but only on machines they cover; identity systems see the account but not the machine. The mature design assumes no single vantage point is enough, and the detection program deliberately layers them. A question that describes a detection gap will usually be answered by adding the missing vantage point, and a question that describes a redundant investment is usually testing whether you notice the layer was already covered.

Two more instruments belong on this list because the exam names them. Honeypots are decoy systems deliberately made to look valuable and vulnerable, placed where no legitimate user should ever touch them. Any contact is by definition suspicious, which makes them a clean signal source for monitoring, and their value to the exam is the logic: a system that nothing legitimate ever touches can flag every touch as hostile. Network-based intrusion detection and prevention systems, IDS and IPS, complete the perimeter picture: the IDS watches and warns, the IPS sits inline and can block, and both run signature and anomaly detection, which is where the baseline discussion of the previous section plugs directly in.

Data loss prevention: watching the data, not the adversary

Everything so far watches the adversary. Data loss prevention, DLP, watches the data instead. Where detection systems ask “is something bad happening?”, DLP asks “is protected data going somewhere it should not?”, regardless of who is carrying it and whether they mean harm. An employee who pastes customer data into a personal webmail account, a script that copies the payment database to a staging bucket, a laptop that syncs classified files to an unauthorized cloud drive: DLP exists for all of them.

DLP operates on data in the three states the exam wants you to recite: data in use, on a workstation, opened in an application, being edited; data in motion, crossing the network; and data at rest, stored in databases, file shares, and backups. Each state gets its own instrument family. Endpoint DLP agents watch data in use on the workstation: what can be copied to USB, printed, pasted into a browser, or uploaded. Network DLP sits at inspection points, typically egress, and examines data in motion leaving the organization. Storage and cloud DLP scan data at rest, discovering where sensitive data lives and flagging copies in the wrong place. The placement follows the data, and the exam will hand you a scenario and ask which deployment answers it: the laptop exfiltration is the endpoint agent, the mass upload is the network inspection, the forgotten backup copy is the at-rest scan.

DLP is content-aware in a way other security tools are not. It works by discovering sensitive data, typically through classification and content inspection such as pattern matching for credit card numbers or policy keywords, then applying policy to those findings, then reporting violations for the business to act on. This is why DLP depends on the classification work of Domain 2: a DLP system without a classification scheme is a system that does not know what it is protecting.

The exam’s favorite DLP questions are the limitations, and they deserve equal weight with the capabilities. DLP cannot inspect what it cannot see: encrypted traffic defeats network inspection without a decryption strategy, so an exfiltration channel over TLS can be invisible to the network sensor. DLP stops the accidental and the clumsy insider, but it is weak against a determined one who already has legitimate access and knows the policy, because the authorized channel for a business need is the authorized channel. And DLP is a detection and deterrence control, not a wall: it flags and reports, and the value depends on somebody reviewing the reports. The exam rewards the manager who knows that DLP’s reports are only as good as the follow-up process behind them.

Knowing the adversary: MITRE ATT&CK and threat intelligence

Detection design needs a map of what it is looking for, and the dominant map in the industry, and the one the exam expects you to know by name, is MITRE ATT&CK. ATT&CK, which stands for Adversarial Tactics, Techniques, and Common Knowledge, is a free, publicly maintained knowledge base of adversary behavior, built from real-world observations of intrusions. It organizes that behavior into a matrix the exam wants you to read fluently.

The matrix has three levels of detail, and the vocabulary is tested directly. Tactics are the why: the adversary’s operational goals during an intrusion, such as Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact, plus the preparation tactics Reconnaissance and Resource Development. Techniques are the how: the specific ways a tactic gets accomplished. Exploit a public-facing application, technique T1190, is a way of achieving Initial Access. Command and Scripting Interpreter, T1059, is a way of achieving Execution. Procedures are the particular instances: the actual commands, scripts, and tools an adversary or group uses to realize a technique. A group profile in ATT&CK reads as a chain of tactics, techniques, and procedures, which is why the framework is so useful to detection engineering: it turns the abstract idea of adversary behavior into a concrete list of behaviors that can be matched against telemetry.

The exam’s way of testing this is usually a mapping: here is an observed behavior, which tactic does it serve, or which technique would detect it. The habit to cultivate is reading behavior through the attacker’s goal. A question about an adversary maintaining a foothold after a reboot is testing Persistence. A question about moving from one workstation to the domain controller is testing Lateral Movement. A question about exfiltration over the same channel the adversary uses to command the compromised machine is testing Exfiltration, and the specific technique, T1041, Exfiltration over C2 Channel, is the kind of precise mapping a well-read candidate recognizes.

ATT&CK is not the only adversary model, and the exam may touch the others by name. The Lockheed Martin Cyber Kill Chain, published in 2011, describes an intrusion as seven sequential stages: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. It is the linear story of a single attack campaign, and the exam will test it at the stage level: the phishing email carrying a malicious attachment is Delivery, the stage that gets the weaponized payload to the target; the exploit firing is Exploitation; the beacon home is Command and Control. The Diamond Model, proposed by Sergio Caltagirone and colleagues in 2013, frames any intrusion event as four vertices: adversary, infrastructure, capability, and victim, with the analyst’s job being to fill in the missing pieces. Where the kill chain gives a timeline, the diamond gives a relationship map.

Intelligence: strategic, tactical, and technical

Monitoring without intelligence is surveillance without questions. Threat intelligence is information about adversaries that helps the floor decide what to watch, and it arrives at four altitudes worth naming because the exam distinguishes them. Strategic intelligence is written for executives: the threat landscape, the adversary groups relevant to the industry, the trends that shape risk decisions. Operational intelligence concerns specific campaigns and adversary capabilities: which groups are active, what they are targeting, how they operate. Tactical intelligence describes adversary tactics, techniques, and procedures, the ATT&CK-level detail that shapes detection engineering. Technical intelligence is the lowest altitude: the concrete indicators of compromise, IOCs, the malicious file hashes, IP addresses, domains, and certificates that can be matched mechanically against the environment. The feed of known-bad hashes and addresses that a SIEM ingests is technical intelligence, and the exam will test that association directly.

Sharing follows a standard shape worth naming. STIX, Structured Threat Information eXpression, is the OASIS standard for representing threat intelligence in a structured, machine-readable form, and TAXII, Trusted Automated Exchange of Intelligence Information, is the protocol for exchanging it. The exam rarely goes deeper than the names and their purpose: structured representation plus automated exchange.

The point of all of it, for the manager, is that intelligence must change behavior. An intelligence report that does not produce a new detection rule, a re-prioritized asset list, or a changed alert threshold is a cost with no return. And that is exactly what threat hunting institutionalizes: instead of waiting for alerts, the hunting team starts from intelligence and hypotheses, and actively searches the environment for evidence of behaviors that the automated detection may have missed. Hunting is proactive detection, and the exam treats it as the sign of a mature operations program, because it assumes the adversary may already be inside and that the floor’s job is to find the gap before the gap is exploited.

The controls and standards that anchor the floor

A security operations floor is not built on tooling alone; it is built on requirements, and the exam asks you to name them. The map of those requirements is worth laying out control by control, because the question format rewards knowing which control does what.

NIST SP 800-53 Revision 5: the AU and SI families

NIST SP 800-53 Revision 5, the Security and Privacy Controls for Information Systems and Organizations, carries this domain in two control families. The Audit and Accountability family, AU, is the logging backbone. AU-2, Event Logging, requires logging the events the organization determines are needed to support investigations, incidents, and accountability, and it expects those events to be chosen with an eye to what the organization must be able to reconstruct. AU-3, Content of Audit Records, sets the six content elements: type, time, location, source, outcome, and identity. AU-4, Audit Log Storage Capacity, requires that logging capacity be allocated so the floor does not silently lose events when storage fills. AU-5, Response to Audit Logging Process Failures, is the control the exam loves to test: it requires the system to alert when audit logging fails, so that a broken pipeline is a visible problem instead of a silent one. AU-6, Audit Record Review, Analysis, and Reporting, requires that audit records actually be reviewed, analyzed, and reported on, which is the control version of the attention problem. AU-8, Time Stamps, requires synchronized clocks. AU-9, Protection of Audit Information, requires protecting audit records and tools from unauthorized access, modification, and deletion. AU-11, Audit Record Retention, requires retention per organizational policy and law. And AU-12, Audit Record Generation, requires that the system be able to generate the audit records and provide them to authorized personnel.

The System and Information Integrity family, SI, carries the detection half. SI-4, System Monitoring, is the anchor: it requires monitoring the system to detect attacks and indicators of potential attacks, unauthorized local, network, and remote connections, and other indicators of potential compromise, and alerting on findings. SI-7, Software, Firmware, and Integrity Verification, requires verifying the integrity of software and firmware, which is the control behind file integrity monitoring and a cousin of the log integrity idea. Together the AU and SI families give the floor its entire skeleton: record it, protect the record, review the record, monitor for attack, verify the system is what it claims to be.

NIST SP 800-137: continuous monitoring

NIST Special Publication 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations, published in 2011, defines the management frame around all of this. Continuous monitoring, ISCM, is maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. The definition carries the whole philosophy of the domain: monitoring exists to support risk decisions, not to be an end in itself, and it must be ongoing because the environment, the adversary, and the risk picture change continuously. The exam will test the definition, and it will test the consequence: monitoring is not a quarterly exercise, it is a posture.

ISO/IEC 27001:2022 Annex A

From the management-system side, ISO/IEC 27001:2022 spells out the same discipline in Annex A controls, and three of them are exam-regulars. A 8.15, Logging, requires producing and storing logs that record activities, exceptions, faults, and other relevant events, protecting those logs against tampering and unauthorized access, and retaining them per defined requirements aligned with legal, regulatory, and business needs. A 8.16, Monitoring Activities, requires monitoring networks, systems, and applications for anomalous behavior, recording activities, and reviewing anomalies with the responsible parties, which is the ISO version of baselining plus review. A 8.17, Clock Synchronization, requires reliable time sources so clocks agree. Two more controls round out the incident side, though incident response itself is the next chapter’s subject: A 6.8, Reporting Information Security Events, requires a mechanism for people to report observed or suspected security events through the right channels in a timely way, and A 5.28, Collection of Evidence, requires procedures for identifying, collecting, acquiring, and preserving evidence, which is the governance version of the log integrity discussion. A candidate who can name A 8.15, A 8.16, and A 8.17 and say what each does has this corner of the exam covered.

PCI DSS v4.0 Requirement 10

For organizations that touch cardholder data, PCI DSS v4.0 Requirement 10, Log and Monitor All Access to System Components and Cardholder Data, is the specific, auditable driver of everything in this chapter. It requires automated audit trails covering all individual user access to cardholder data, all actions taken by users with root or administrative privileges, access to the audit trails themselves, invalid logical access attempts, and changes to identification and authentication mechanisms. It requires audit log records that include user identification, event type, date and time, success or failure, origination, and the identity of affected data, which is PCI’s own version of the AU-3 content list. It requires synchronized time across in-scope systems. It requires monitoring and alerting on suspicious events. And it requires retention: at least 12 months of audit log history, with at least 3 months immediately available for analysis. The exam pairs this with GDPR and legal hold questions to test whether you can hold the operational, regulatory, and legal forces in balance at once.

The manager’s reading of the whole floor

Every control in this section is a requirement to spend attention, and the manager’s job is to make sure the spending is real. Logs that are collected but never reviewed are not security; they are storage. Alerts that fire but get no action are not detection; they are noise. The continuous monitoring definition from SP 800-137 is the test for the whole floor: does the monitoring produce ongoing awareness that supports risk decisions? If the answer is no, the issue is not the tools, it is the design of attention. That is the mindset the exam rewards in every Domain 7 question: follow the decision, not the dashboard.

Practice questions

1. A security operations center receives an alert at 02:14 for a failed login followed by a successful login to the same account from the same foreign IP address. The tier 1 analyst confirms the pattern matches a documented playbook and escalates to tier 2 for investigation. Which SOC role performed the triage?

   A. Tier 3 threat hunter B. Tier 1 analyst C. Incident commander D. Forensic examiner

2. A user reports that she clicked a link in a phishing email. The email gateway quarantined the message before it reached her, and the click opened no page and downloaded nothing. No account activity or system change followed. Per the definitions used in NIST SP 800-61 Rev. 2, how should this occurrence be classified?

   A. Incident, because the user clicked a malicious link B. Event, because nothing jeopardized the confidentiality, integrity, or availability of any system C. Vulnerability, because the gateway configuration is suspect D. Incident, because phishing always requires notification

3. A vendor offers to consolidate all firewall, server, and application logs into a single searchable repository. The current SIEM already collects the same data. Which capability distinguishes a SIEM from the vendor’s proposed log aggregation?

   A. Centralized storage and search B. Normalization of heterogeneous formats C. Correlation rules that connect events across sources to produce alerts D. Long-term archival of raw events

4. A monitoring system profiles each user’s typical login times, locations, and devices over 90 days, then flags a finance analyst who signs in from a new country at 03:00. Which concept does this detection depend on?

   A. Signature matching against known malware B. Baselining normal behavior and detecting deviation C. Vulnerability scanning of the analyst’s workstation D. Configuration management of the finance application

5. An intrusion detection team tunes its rules so aggressively to eliminate every false positive that a real, novel attack proceeds undetected. What is the detection failure mode?

   A. False positive B. Alert fatigue C. False negative D. Baseline drift

6. An auditor asks what information the organization’s audit records must contain. Per NIST SP 800-53 Rev. 5, which control defines the required content of audit records?

   A. AU-2, Event Logging B. AU-3, Content of Audit Records C. AU-9, Protection of Audit Information D. SI-4, System Monitoring

7. An organization stores its authentication logs on the same server that hosts the application being logged, and the application’s administrator account can edit the logs. An attacker who compromises the application could therefore rewrite the record of the attack. Which NIST SP 800-53 Rev. 5 control is the organization failing to satisfy?

   A. AU-9, Protection of Audit Information B. AU-11, Audit Record Retention C. AU-4, Audit Log Storage Capacity D. SI-7, Software, Firmware, and Integrity Verification

8. During an investigation, an analyst cannot reconstruct the attack timeline because the firewall, the endpoint, and the identity server timestamped related events hours apart. Which requirement addresses this problem?

   A. Correlation rules in the SIEM B. Synchronization of system clocks to a reliable time source, as required by NIST SP 800-53 Rev. 5 AU-8 and ISO/IEC 27001:2022 Annex A 8.17 C. Write-once storage for all logs D. Longer log retention

9. A company is served with a lawsuit alleging misuse of customer data. Its retention policy deletes authentication logs after 90 days, and the next scheduled deletion is next week. What should the company do?

   A. Let the deletion proceed, because the retention policy is compliant B. Suspend deletion of relevant records under legal hold and preserve them C. Delete only the logs of employees not named in the lawsuit D. Rewrite the retention policy retroactively to 90 days

10. A payment processor must comply with PCI DSS v4.0. What does Requirement 10 require for audit log retention?

    A. No minimum, retention is purely organizational choice B. At least 12 months of audit log history, with at least the most recent 3 months immediately available for analysis C. At least 5 years, with 12 months immediately available D. Retention only for logs that recorded cardholder data access

11. An organization keeps authentication logs containing usernames, IP addresses, and device identifiers for ten years “just in case.” Under the EU GDPR, which principle is this practice most directly violating?

    A. Data portability B. Storage limitation, which requires that personal data be kept no longer than necessary for the purposes for which it is processed C. Right to erasure D. Confidentiality of processing

12. An organization wants to detect customers’ credit card numbers being pasted into webmail or uploaded to file-sharing sites as data leaves the corporate network. Which DLP deployment inspects data in this state?

    A. Endpoint DLP agent monitoring data in use B. Network DLP inspecting data in motion at egress C. Storage DLP scanning data at rest D. A file integrity monitoring tool

13. A network DLP sensor reports that it saw a large outbound data transfer, but an analyst cannot identify the content of the transfer. The connection used TLS to a legitimate-looking external service. What is the most likely explanation?

    A. The DLP sensor lacks a decryption strategy, so it cannot inspect the encrypted payload B. The DLP sensor is misconfigured and cannot see outbound traffic C. TLS guarantees the traffic was legitimate D. The transfer occurred over a protocol DLP does not parse

14. An organization adopting ISO/IEC 27001:2022 needs a control that requires producing and storing logs recording activities, exceptions, faults, and other relevant events, and protecting those logs against tampering and unauthorized access. Which Annex A control is this?

    A. A 8.16, Monitoring Activities B. A 8.15, Logging C. A 8.17, Clock Synchronization D. A 6.8, Reporting Information Security Events

15. A detection engineering team observes an adversary exploiting a vulnerability in a public-facing web application to gain its first foothold on the network. In MITRE ATT&CK, under which tactic would the technique T1190, Exploit Public-Facing Application, be classified?

    A. Persistence B. Lateral Movement C. Initial Access D. Exfiltration

16. An analyst describes an intrusion: an attacker crafted a malicious attachment, emailed it to a target, and the target opened it, executing the payload. In the Lockheed Martin Cyber Kill Chain, the delivery of the weaponized attachment by email is which stage?

    A. Weaponization B. Delivery C. Exploitation D. Command and Control

17. A SIEM ingests a feed of known malicious IP addresses, domains, and file hashes so it can flag matching activity in the environment. This feed is best described as which type of threat intelligence?

    A. Strategic B. Operational C. Tactical D. Technical

18. Which NIST SP 800-53 Rev. 5 control requires monitoring the system to detect attacks and indicators of potential attacks, unauthorized connections, and other indicators of potential compromise, and alerting on findings?

    A. AU-6, Audit Record Review, Analysis, and Reporting B. SI-4, System Monitoring C. AU-2, Event Logging D. SI-7, Software, Firmware, and Integrity Verification

19. An organization’s SIEM stopped receiving events from a critical firewall for six hours, and nobody noticed until a routine check the next day. Which control requires that the system alert when audit logging processes fail?

    A. AU-5, Response to Audit Logging Process Failures B. AU-4, Audit Log Storage Capacity C. AU-11, Audit Record Retention D. AU-3, Content of Audit Records

20. A security manager explains the organization’s monitoring program to a new board member as “maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions.” Which publication defines continuous monitoring in those terms?

    A. NIST SP 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations B. NIST SP 800-92 Rev. 1, Cybersecurity Log Management Planning Guide C. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations D. NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide

Answers and rationales

1. B. Triage of alerts against documented playbooks is the tier 1 analyst’s job. Tier 3 performs hunting and advanced analysis (option A), the incident commander leads response once an incident is declared (option C), and forensic examiners work evidence after escalation (option D).

2. B. Per NIST SP 800-61 Rev. 2, an event is any observable occurrence, and an incident requires actual or potential jeopardy to confidentiality, integrity, or availability, or a violation or imminent threat of violation of security policy. The quarantine contained the threat and no impact followed, so this is an event. Phishing itself does not make every occurrence an incident (option A), a vulnerability is a weakness, not an occurrence (option C), and notification obligations apply to incidents (option D).

3. C. Correlation, connecting events across sources and time to discover patterns no single event reveals, is the capability that distinguishes a SIEM from plain aggregation. Centralized storage and search (option A), normalization (option B), and archival (option D) are all features of the vendor’s log aggregation too.

4. B. The detection profiles normal behavior and flags deviation from it, which is baselining and anomaly detection. Signature matching works against known patterns (option A), vulnerability scanning assesses weaknesses (option C), and configuration management enforces baselines, it does not flag behavioral deviation (option D).

5. C. A real attack that triggers no alert is a false negative. A false positive is an alert when nothing is wrong (option A), alert fatigue is the numbing that follows excessive false positives (option B), and baseline drift is gradual change in the baseline itself (option D).

6. B. AU-3 requires audit records to establish the type of event, when and where it occurred, the source, the outcome, and the identity of associated individuals or subjects. AU-2 requires the events themselves to be logged (option A), AU-9 protects audit information (option C), and SI-4 is system monitoring (option D).

7. A. AU-9 requires protecting audit records and audit tools from unauthorized access, modification, and deletion, which fails when the administrator of the logged system can rewrite its own logs. Retention (option B), storage capacity (option C), and software integrity (option D) are real controls but none addresses the tampering path described.

8. B. Correlating events requires timestamps that agree, so AU-8 and ISO/IEC 27001:2022 Annex A 8.17 require synchronization to a reliable time source, implemented with NTP. Correlation rules (option A) are useless against inconsistent clocks, write-once storage (option C) preserves whatever the clocks said, and retention (option D) does not fix the time disagreement.

9. B. Legal hold overrides the routine retention schedule when litigation or an official investigation is anticipated or underway; the organization must preserve relevant records, logs included. Proceeding with deletion (option A) and selective deletion (option C) destroy evidence the company may have a duty to preserve, and rewriting policy retroactively (option D) does not restore deleted records.

10. B. PCI DSS v4.0 Requirement 10 requires retaining audit log history for at least 12 months, with at least the most recent 3 months immediately available for analysis. The other options misstate the minimum (options A and C) or invent a narrower scope than the requirement (option D).

11. B. GDPR Article 5(1)(e), storage limitation, requires that personal data be kept no longer than necessary for the purposes for which it is processed, and a ten-year “just in case” retention lacks a documented necessity and legal basis. Portability (option A), erasure rights (option C), and confidentiality (option D) are real GDPR concepts but not the principle the practice most directly violates.

12. B. Data leaving the network over egress is data in motion, and network DLP inspects that stream. The endpoint agent watches data in use on the workstation (option A), storage DLP scans data at rest (option C), and file integrity monitoring verifies files, it does not inspect content leaving the network (option D).

13. A. Network inspection cannot read encrypted payloads without a decryption strategy, such as TLS interception at the inspection point, so the sensor sees the connection but not the content. Misconfiguration is not indicated (option B), TLS proves encryption, not legitimacy (option C), and protocol parsing is not the issue since the sensor saw the transfer (option D).

14. B. ISO/IEC 27001:2022 Annex A 8.15, Logging, requires producing and storing logs of activities, exceptions, faults, and other relevant events, and protecting them against tampering and unauthorized access. A 8.16 is monitoring (option A), A 8.17 is clock synchronization (option C), and A 6.8 is reporting security events (option D).

15. C. Exploiting a public-facing application to gain the first foothold is Initial Access, and T1190 is classified there. Persistence keeps access after it is gained (option A), Lateral Movement moves within the network (option B), and Exfiltration steals data (option D).

16. B. Sending the weaponized payload to the target is Delivery. Weaponization is building the payload (option A), Exploitation is the vulnerability being triggered when the attachment opens (option C), and Command and Control is the beaconing after installation (option D).

17. D. Hashes, IPs, and domains are concrete indicators of compromise that can be matched mechanically, which is technical intelligence. Strategic serves executives (option A), operational concerns campaigns (option B), and tactical describes TTPs (option C).

18. B. SI-4, System Monitoring, requires monitoring to detect attacks, indicators of potential attacks, unauthorized connections, and other indicators of compromise, with alerting on findings. AU-6 is the review and reporting of audit records (option A), AU-2 is event logging (option C), and SI-7 is software and firmware integrity verification (option D).

19. A. AU-5 requires the system to alert when audit logging processes fail, so a silent six-hour gap violates it. Storage capacity (option B), retention (option C), and record content (option D) are real requirements but none makes the logging failure itself visible.

20. A. NIST SP 800-137 defines information security continuous monitoring as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. SP 800-92 Rev. 1 is log management planning (option B), SP 800-53 Rev. 5 is the controls catalog (option C), and SP 800-61 Rev. 2 is incident handling (option D).

Security operations, monitoring, and logging on one page

Hold the floor as an attention machine, and the whole domain answers itself. The SOC organizes attention in tiers: triage cheap, investigate expensive, hunt deepest. The pipeline collects, normalizes, stores, and alerts, and the alert stage is where design succeeds or fails. Logging is the raw material, and it is governed by content, integrity, clocks, and retention: AU-3 for what a record must say, AU-9 and write-once storage for keeping it honest, AU-8 and Annex A 8.17 for clocks that agree, AU-11 plus PCI DSS v4.0 Requirement 10 and GDPR storage limitation for how long it stays, and legal hold as the override that beats every schedule.

Detection runs on baselines: measure normal, flag deviation, and know which way your tools are wrong, because a false negative costs more than a false positive, and alert fatigue is a design failure, not a human one. The SIEM is the correlation center: aggregation stores, correlation connects, and use cases promise attention. EDR, NDR, and honeypots add vantage points, and DLP watches the data instead of the adversary, in use, in motion, and at rest, blind to encryption and honest about its limits. MITRE ATT&CK maps the adversary as tactics, techniques, and procedures; the kill chain gives the timeline; the diamond gives the relationship; and intelligence, from strategic to technical, must change behavior or it is a cost.

The controls are the skeleton: AU-2 through AU-12 and SI-4 for logging and monitoring in NIST SP 800-53 Rev. 5, SP 800-137 for the continuous monitoring frame, SP 800-92 Rev. 1 for log management planning, Annex A 8.15, 8.16, and 8.17 for the ISO/IEC 27001:2022 side, and PCI DSS v4.0 Requirement 10 where cardholder data is in scope. The one habit to carry into the Domain 7 practice test: when a question describes monitoring, ask what decision it supports, what it would miss, and who would notice it stopped working. The answer is in the design of attention, not in the name of the tool.