Chapter 1: Security Operations
Security operations is the daily work of defending an organization: watching what happens on the network, on
endpoints, in the cloud, and in identity systems; deciding whether something is normal, suspicious, or malicious;
and acting fast enough that an incident never becomes a breach. The CySA+ exam tests this work as a craft, not
as a vocabulary list. You will be asked to read a log excerpt and spot the attack, to choose the right tool for a
detection problem, to judge whether a piece of threat intelligence is worth acting on, and to know when
automation helps and when it makes things worse. This chapter builds that judgment. It is organized the way an
analyst's day is organized: the tools and data sources first, then the indicators those tools produce, then the
intelligence that gives indicators meaning, then hunting, automation, measurement, and finally the newest part
of the job - working safely with artificial intelligence.
Before you start: setting up your lab
Several procedures in this book ask you to try a tool yourself. Do that inside a lab virtual machine on your own
computer, never against systems you do not own. Setting one up takes five steps:
1. Name the machine. Use a name that says what it is for, for example SOC-Lab.
2. Give it memory. 4096 MB is enough for the command-line tools in this book.
3. Give it a disk. A dynamically allocated virtual disk keeps the lab small until you need the space.
4. Attach it to a host-only or NAT network, so lab traffic stays on your own computer.
5. Review the summary and finish. Boot the machine once and confirm it starts cleanly before you install any
tools.
GUI walkthrough: setting up a lab virtual machine, step by step (illustrated)
1. Security operations tools and data sources
No single tool sees everything. A firewall sees traffic crossing a boundary but not what a process did on a laptop.
An endpoint agent sees process behavior but not what happened on a server it does not cover. A cloud log sees
API calls but not the network packets behind them. Security operations is therefore a stitching job: each tool
contributes a partial view, and the analyst's job is to combine those views into one story. The exam expects you
to know what each major tool class is good at, what it is blind to, and which one to reach for in a given scenario.
1.1 SIEM: the central nervous system
SIEM. A Security Information and Event Management system collects logs and events from many sources,
normalizes them into a common format, correlates them against rules, and raises alerts when a pattern
matches known malicious or anomalous behavior. It is the analyst's primary workspace for investigation.
A SIEM does three things that matter for the exam. First, it aggregates: it pulls logs from firewalls, servers,
endpoints, cloud services, and identity providers into one place, so an analyst can follow an attacker across
systems without opening ten consoles. Second, it normalizes: different vendors write logs in different formats,
and the SIEM maps them onto common fields such as source address, destination address, user, and action, so
one query can search them all. Third, it correlates: a single failed login means little, but a failed login followed by
a successful login from an unusual country followed by a large data download is a pattern worth an alert. That
correlation is what turns raw logs into detections.
The quality of a SIEM depends entirely on the quality and completeness of its inputs. If a critical system does not
forward logs, the SIEM is blind there, and no rule can compensate. Log forwarding failures, clock drift between
systems, and unparsed log formats are the most common reasons real investigations stall, and the exam likes
scenarios built around exactly those gaps.
When a question asks what to do first after a SIEM alert, the answer is almost never "block the address" or
"isolate the host." Triage first: verify the alert against raw logs, check whether the activity is expected (a
scheduled backup, an administrator's task), and confirm the scope before taking disruptive action.
1.2 EDR, XDR, and NDR
EDR. Endpoint Detection and Response is software on workstations and servers that records process
execution, file changes, registry activity, and network connections, detects suspicious behavior, and lets
analysts isolate a host, kill a process, or collect forensic data remotely.
XDR. Extended Detection and Response goes beyond the endpoint: it correlates telemetry from endpoints,
network, email, cloud, and identity into one detection and response workflow, so an alert carries context from
every layer instead of just one.
Network Detection and Response (NDR) watches network traffic itself - flows, DNS queries, and packet metadata
- and is especially valuable where endpoint agents cannot run, such as on printers, medical devices, industrial
controllers, and unmanaged devices. NDR sees lateral movement, beaconing to command-and-control servers,
and data exfiltration patterns that host-based tools may miss.
The distinction the exam tests is scope. EDR answers "what did this host do?" NDR answers "what crossed the
network?" XDR answers "what happened across all of it, in one timeline?" When a question describes an attack
that touches email, endpoint, and cloud in one chain, XDR is the tool class that ties the chain together. When it
describes a device with no agent, NDR is the answer.
Tool class Primary view Best at Blind to
SIEM Logs and events, all Correlation across systems, long Anything not forwarded as a log
sources investigations
Tool class Primary view Best at Blind to
| SIEM Logs and events, all | Correlation across systems, long | Anything not forwarded as a log | |
|---|---|---|---|
| sources | investigations | ||
| EDR One host's behavior Process trees, malware execution, host | Devices without agents | ||
| isolation | |||
| XDR All layers, one timeline Cross-layer attack chains Depends on which products feed it | |||
| NDR Network traffic and | Unmanaged devices, beaconing, exfiltration Encrypted payload content without | ||
| flows | decryption | ||
| Packet | Full packet contents Deep protocol analysis, proof of what was | Scale - full capture is expensive to store | |
| capture | sent |
1.3 Packet analysis, UEBA, and threat intelligence platforms
Packet analysis is the deepest view available and the most expensive to keep. Analysts use it when they need
ground truth: what exactly did this connection carry, in what order, with what flags and payloads? It is the right
tool for confirming a suspected exfiltration, dissecting an unusual protocol, or proving what a malware sample
actually sent. It is the wrong tool for "watch everything all the time," because full packet capture at enterprise
scale quickly becomes unmanageable. Flow records and metadata are the everyday compromise: they describe
who talked to whom, when, for how long, and how much data moved, without storing the content.
UEBA. User and Entity Behavior Analytics builds a baseline of normal behavior for users and devices - usual
login times, usual locations, usual data volumes - and flags deviations from that baseline. It is designed to
catch insider misuse and compromised accounts, where the activity may use legitimate credentials and
therefore evades signature-based detection.
TIP. A Threat Intelligence Platform collects, normalizes, and distributes threat intelligence - indicators,
adversary profiles, and reports - and feeds them into detection tools such as the SIEM and firewalls, so
intelligence becomes blocking and alerting rules rather than PDFs nobody reads.
Asset discovery underpins all of this. You cannot protect what you do not know exists, and the exam returns to
this theme repeatedly: an un-inventoried server, a forgotten cloud bucket, or a shadow IT application is where
incidents begin. Discovery combines active scanning, passive network observation, cloud provider inventories,
and configuration management data. The analyst's question is always the same: is this asset known, owned,
patched, and monitored? An asset that fails any of those four checks is a finding in itself.
Tools detect; analysts decide. A SIEM rule, an EDR alert, or a UEBA anomaly score is a claim about reality, not
reality itself. Every alert carries a false positive rate, and every tool has a blind spot. The analyst's value is in
weighing the alert against context - asset criticality, user role, business timing, and corroborating evidence
from another tool - before acting. Questions that present a single alert and ask for an immediate disruptive
response are usually testing whether you will skip this step.
Match the tool to the evidence, not to the buzzword. "We need to see what a process did on a host" is EDR. "We
need to see traffic from devices with no agents" is NDR. "We need one timeline across email, endpoint, and
cloud" is XDR. "We need to search a month of logs from every system" is SIEM.
CertCrack.com's SIEM raises an alert for a large outbound transfer from a server that has no EDR agent
installed. Which tool class would best confirm what data actually left the network, and why is the SIEM alone
not enough here?
Answer: Packet capture or NDR flow analysis, because the SIEM only holds the logs that were forwarded to it -
it cannot show packet contents or traffic from a host it does not monitor. The SIEM tells you something
happened; network evidence tells you what happened.
Figure: the SIEM pipeline, from log sources to triage
2. Indicators and log analysis
An indicator is a piece of evidence that something happened. Indicators come in grades. Atomic indicators - a
single IP address, a file hash, a domain name - are cheap to collect and cheap for an attacker to change.
Computed indicators - a pattern of behavior, a sequence of actions - are harder to evade. Host and network
indicators describe different parts of the same attack, and the exam expects you to read both.
2.1 Network indicators
Network indicators include unusual DNS queries (long subdomain labels, high query volume, queries to newly
registered domains), beaconing (regular, small outbound connections at fixed intervals, often to an address with
no legitimate business purpose), unexpected protocols on unexpected ports, and large or oddly timed data
transfers. A single indicator rarely proves malice; the exam's log questions usually present a sequence, and the
skill is reading the sequence as a story: reconnaissance, then initial access, then persistence, then command and
control, then exfiltration.
DNS deserves special attention because it is so often the channel attackers abuse. Legitimate DNS queries are
short, human-readable, and bursty. Tunneling hides data in subdomain labels, producing long, high-entropy
queries at steady volume. A sudden spike in DNS queries from one host, especially to a domain registered days
ago, is one of the most reliable early warnings available.
Open Wireshark on your own computer and capture two minutes of your own traffic. Filter for dns and look
for repeated queries to the same domain at regular intervals - that rhythm is what beaconing looks like. Never
capture traffic on a network you do not own or manage.
Spotting a brute-force pattern in the auth log, step by step
One failed login means little. Dozens of failures from one address in a few minutes mean a brute-force attempt.
Work through the log this way, on your own systems only:
1. Open the authentication log and search for failed password attempts.
2. Group the failures by source address and count them.
3. Look for the pattern: many failures, one address, a short window, often against a single account or a
spread of common usernames.
4. Treat a match as an incident indicator: block or rate-limit the source, check whether any attempt
succeeded, and review what that account can reach.
Terminal session: spotting a brute-force pattern in the auth log with grep (genuine output)
2.2 Endpoint indicators
Endpoint indicators include processes launching from unusual locations (a word processor spawning a shell, a
script interpreter running from a temporary folder), persistence mechanisms (new scheduled tasks, new
services, new registry run keys, new startup items), credential access (a process reading the memory of the
authentication subsystem), and defense evasion (security tools being disabled, logs being cleared, event
auditing being turned off). Any one of these in isolation can have a benign explanation; several together, in a
short window, on a host whose user has no reason to do them, is the shape of a compromise.
Indicator of compromise (IoC). An artifact observed during or after an incident - such as a malicious IP
address, domain, file hash, or registry key - that indicates a system has been attacked or compromised. IoCs
are useful for detection and blocking but decay quickly as attackers change infrastructure.
Indicator of attack (IoA). A behavioral pattern that indicates an attack is in progress, such as a process
injecting code into another process or a user account suddenly accessing resources it never touched before.
IoAs are harder to evade than IoCs because they describe what the attacker does, not what the attacker uses.
2.3 Cloud and identity indicators
Cloud logs record a different kind of evidence: API calls. Who created a resource, who changed a policy, who
assumed a role, who disabled logging? The most dangerous cloud indicators are control-plane changes: a new
access key created for a privileged account, a storage bucket policy changed to public, a logging service
disabled, a new administrator added at an unusual hour. These are the cloud equivalents of a burglar cutting
the alarm wires, and the exam treats them with matching seriousness.
Identity indicators are often the earliest sign of account compromise: logins from impossible travel (two
locations too far apart in too little time), logins at hours the user never works, a sudden change in multi-factor
authentication settings, or a service account - which should never log in interactively - suddenly doing so.
Privilege escalation shows up as a normal account gaining administrative rights, or an administrative account
being used in a way it never is during business hours.
# Example: cloud audit excerpt, CertCrack.com production account
2026-10-20T03:14:02Z user=svc-backup action=CreateAccessKey result=Success
2026-10-20T03:14:47Z user=svc-backup action=PutBucketPolicy bucket=certcrack-backups
2026-10-20T03:15:31Z user=svc-backup action=StopLogging service=cloudtrail
Reading this sequence, an analyst should notice three things: a service account performing interactive-style
administrative actions, a storage policy change, and logging being disabled - in the middle of the night. Any one
of them is worth a ticket; together they are an incident.
In log-analysis questions, read the sequence, not the single line. Attackers leave a chain: something unusual,
then something privileged, then something that hides the trail. The correct answer usually names the earliest
reliable indicator or the next investigative step, not the loudest single event.
Correlation beats collection. Storing more logs does not make an organization safer; connecting the logs you
already have does. A SIEM full of unparsed, unreviewed data is a warehouse, not a defense. The exam rewards
answers that prioritize tuning, parsing, and alert triage over simply buying more storage or more feeds.
An analyst at CertCrack.com sees a user account log in from two countries six hours apart, then download ten
times its usual daily data volume. Which two indicator classes are present, and what is the single most useful
next check?
Answer: Identity indicators (impossible or unusual travel plus abnormal volume) and a behavioral anomaly.
The most useful next check is whether the session is legitimate - contact the user through a known channel
and check the device and session details - before assuming compromise or blocking the account outright.
Looking up a suspicious domain, step by step
When a log shows a domain you do not recognize, resolve it before you judge it:
1. Look up the domain and read the answer section for the addresses it resolves to.
2. Check whether those addresses are already known to threat intelligence or to your own blocklists.
3. Compare the result with what the log showed: a domain resolving to an unexpected country or to a newly
registered address raises the suspicion further.
4. Record the finding with the query time, because DNS answers change and the evidence must be
reproducible.
Terminal session: looking up a domain with dig (genuine output)
Creating a cloud storage bucket, step by step
The console path is: storage service, create bucket, fill in the form, create.
1. Type a globally unique bucket name. Bucket names are shared across all customers, so a name anyone
else holds is rejected.
2. Pick the region closest to the users who will read the data.
3. Keep public access blocked. A bucket that stores logs or backups must never be world-readable; the exam
treats an open bucket as a finding, not a convenience.
4. Click Create bucket and confirm the bucket appears in your account before you upload anything into it.
GUI walkthrough: creating a storage bucket in the cloud console, step by step (illustrated)
The same creation from the command line, for administrators who script their setups:
Terminal session: creating a cloud storage bucket and a compute instance with the AWS CLI (illustrated session, placeholder values)
3. Threat intelligence lifecycle and frameworks
Threat intelligence is not a feed of bad IP addresses. It is a process that turns raw data about adversaries into
decisions: what to block, what to hunt for, what to patch first, and what to tell leadership. The exam tests the
process and the frameworks that structure it, because those are what separate an analyst who reacts to alerts
from one who anticipates attacks.
3.1 The intelligence lifecycle
The lifecycle has six stages, and each one feeds the next:
• Direction. Leadership and analysts agree on what they need to know: which adversaries matter, which
assets matter most, and which decisions the intelligence must support. Without direction, teams collect
everything and use nothing.
• Collection. Gathering data from internal sources (logs, incidents, malware samples) and external sources
(commercial feeds, open-source reports, industry sharing groups, vendor advisories).
• Processing. Normalizing, de-duplicating, and enriching raw data - resolving an IP to its owner, matching a
hash to known malware, adding context to an indicator.
• Analysis. Turning processed data into judgments: what is this adversary trying to do, how capable are
they, and what does that mean for us specifically?
• Dissemination. Delivering the finished intelligence to the people who need it, in a form they can use:
blocking rules for engineers, hunt hypotheses for analysts, risk summaries for executives.
• Feedback. Consumers report what was useful, what was wrong, and what they still need, and the cycle
starts again with better direction.
Questions about the lifecycle usually test the order or the purpose of a stage. "Analysts collected a feed but
nobody uses it" is a dissemination failure. "The team tracks every threat actor equally" is a direction failure.
Match the symptom to the stage.
Figure: the threat intelligence lifecycle
3.2 Intelligence types and sources
Intelligence comes in four levels, and the exam expects you to tell them apart:
Level Audience Content Example
| Strateg | Executives, | Long-term trends, adversary motives, | "Ransomware groups increasingly target backup |
|---|---|---|---|
| ic | board | risk | systems" |
| Operati | Security | Campaigns, adversary capabilities, | "This group is actively targeting SaaS providers this |
| onal | leadership | targeting | quarter" |
| Tactical Analysts, | Techniques, procedures, indicators "This group uses scheduled tasks for persistence" | ||
| engineers | |||
| Techni | Detection tools Atomic indicators A malicious hash, IP, or domain | ||
| cal | |||
| Sources matter as much as levels. Internal data - your own incidents, your own logs - is the most relevant |
intelligence you have, because it describes attacks against your environment specifically. External feeds are
broader but noisier, and their indicators decay: an IP address that was malicious last month may be reassigned
to a legitimate user today. Sharing communities (industry groups, government programs) offer a middle
ground: intelligence from organizations with similar threats, usually vetted better than a raw commercial feed.
STIX and TAXII. STIX (Structured Threat Information Expression) is a standard language for describing threat
intelligence - indicators, attack patterns, identities, and relationships between them - in machine-readable
form. TAXII (Trusted Automated Exchange of Indicator Information) is the transport protocol used to share
STIX objects between organizations and tools.
3.3 Frameworks: ATT&CK, Diamond, Kill Chain, pyramid of pain
MITRE ATT&CK. A knowledge base of adversary behavior organized into tactics (the attacker's goals, such as
persistence or exfiltration) and techniques (the methods used to achieve them, such as scheduled tasks or
credential dumping). Analysts use it to map observed activity to known behavior, to find coverage gaps in their
detections, and to describe attacks in a common language.
Diamond Model. A framework that describes every intrusion as four connected features: adversary, capability,
infrastructure, and victim. The power of the model is in its pivots: from one known feature (say, a malicious
domain), you can pivot to the others (which adversary uses it, what capability it delivers, who else was
targeted).
Cyber Kill Chain. A seven-phase model of an intrusion: reconnaissance, weaponization, delivery, exploitation,
installation, command and control, and actions on objectives. Its value is defensive: breaking any one phase
stops the attack, so defenders look for the earliest phase they can reliably detect and disrupt.
Pyramid of pain. A ranking of indicator types by how hard they are for an attacker to change: hashes and IP
addresses at the bottom (trivial to change), domain names and network artifacts in the middle, and tools,
tactics, techniques, and procedures at the top (expensive to change, because they require the adversary to
relearn how they operate). Detections aimed at the top of the pyramid are more durable than those aimed at
the bottom.
These frameworks complement each other rather than competing. The Kill Chain tells you where in the attack
you are. ATT&CK tells you what the attacker is doing in detail. The Diamond Model tells you how the pieces
connect. The pyramid tells you where to invest detection effort for lasting value. Exam questions often present
one observed behavior and ask which framework best describes it, or present a detection gap and ask which
framework best finds it.
When a question describes mapping observed activity to tactics and techniques to find detection gaps, the
answer is ATT&CK. When it describes pivoting from one known indicator to find the adversary behind it, the
answer is the Diamond Model. When it describes disrupting an attack at its earliest phase, the answer is the Kill
Chain.
Figure: the pyramid of pain — higher indicators cost the adversary more to change
3.4 Sigma, YARA, and detection content
Sigma. An open, generic format for writing detection rules (log-based) that can be translated into the query
language of different SIEMs. One Sigma rule can serve many platforms, which is why sharing communities
publish detections in Sigma form.
YARA. A pattern-matching tool for identifying and classifying malware samples by rules that describe strings,
byte sequences, and structural features of files. Where Sigma detects behavior in logs, YARA identifies
malicious files.
The exam point is practical: analysts rarely write every detection from scratch. They adapt shared content -
Sigma rules, YARA rules, community ATT&CK mappings - to their own environment, test it against their own logs,
and tune it to reduce false positives. A rule that fires constantly on legitimate activity will be ignored, which is
worse than having no rule at all.
CertCrack.com receives a threat feed containing 10,000 IP addresses. The SOC blocks all of them automatically.
Within a week, legitimate customers are blocked and the attackers have moved to new addresses anyway.
Which two concepts from this section explain what went wrong?
Answer: The pyramid of pain - IP addresses sit at the bottom, so blocking them is cheap for the attacker to
evade and risky for legitimate traffic. And dissemination without analysis - the feed was pushed straight to
blocking without assessing relevance, confidence, or expiry, which is the opposite of an intelligence lifecycle.
Open the MITRE ATT&CK Navigator in your browser (free, no install) and build a layer for one technique you
studied, such as credential dumping. Click through its mitigations and data sources, then write down which of
your own log sources would actually detect it.
4. Threat hunting
Threat hunting is the proactive search for threats that automated detection missed. It starts from a hypothesis -
a reason to believe something might be present - and tests that hypothesis against data. The difference from
alert triage is direction: triage starts from an alert the tools produced; hunting starts from a question the analyst
asks.
4.1 Hunt types
• Structured hunts follow a framework, usually ATT&CK: pick a technique that matters to your environment,
check whether your detections would catch it, and search the data for evidence of it. This is systematic and
repeatable.
• Unstructured hunts start from an observation: an unusual log entry, a tip from a colleague, a news report
about a new campaign. The analyst follows the thread wherever it leads. This is flexible but harder to
measure.
• Entity-driven hunts focus on a specific user, host, or asset - usually a high-value target such as a domain
administrator account or a payment system - and examine everything around it for signs of compromise.
4.2 Building and testing a hypothesis
A good hypothesis has three parts: a trigger (why you are looking), a predicted behavior (what you expect to find
if the threat is present), and a data source that can prove or disprove it. "Attackers are using scheduled tasks for
persistence" is a trigger. "We would see new scheduled tasks created by non-administrative processes on
workstations" is the predicted behavior. "Endpoint process and scheduled-task logs" is the data source. A hunt
that ends with "we found nothing" is not a failed hunt - it is a tested hypothesis, and it tells you your controls are
working or your data is incomplete, both of which are useful answers.
Hunting also has a measurement problem the exam touches on: hunts are judged by whether they produce
findings, improve detections, or validate coverage - not by how many queries were run. A hunt that finds
nothing but produces a new detection rule for the technique tested has delivered value.
In hunting questions, the correct hypothesis is specific, testable, and tied to data you actually collect. "Hackers
might be in our network" is not a hypothesis. "We would see PowerShell downloading payloads from external
addresses in our proxy logs" is.
Hunting assumes breach. The premise is not "we are safe until an alert fires" but "an attacker may already be
present and our tools missed them." That mindset changes priorities: instead of waiting for high-confidence
alerts, analysts spend time on high-value techniques, high-value assets, and the gaps between tools. It is the
same logic that makes penetration testing valuable - you test your defenses before an adversary does.
5. Automation and orchestration
Analysts face more alerts than humans can triage by hand, and the repetitive parts of the job - enriching an alert
with context, checking an address against threat feeds, opening a ticket, gathering host details - are exactly the
parts machines do well. Automation handles single tasks. Orchestration coordinates many tools into one
workflow. SOAR platforms are where the two meet.
5.1 What to automate, and what not to
Good automation candidates share three traits: they are frequent, they are well understood, and the cost of
being wrong is low. Enriching an alert with asset ownership, geolocation, and threat-feed reputation is a perfect
candidate. Quarantining a production database server on the basis of one unconfirmed alert is not. The exam
repeatedly tests this judgment: automation should reduce analyst workload and response time, never remove
human judgment from high-impact decisions.
SOAR. Security Orchestration, Automation, and Response platforms connect security tools through workflows
called playbooks: when a trigger fires, the playbook runs a sequence of automated steps - enrich, decide, act,
document - across tools that would otherwise require manual work in each console.
A typical enrichment playbook runs like this: an alert fires in the SIEM; the playbook queries the asset inventory
for the host's owner and criticality; it checks the suspicious address against the TIP; it pulls recent authentication
logs for the user involved; and it writes all of it into a ticket, ranked by severity. The analyst then starts from a
complete picture instead of spending twenty minutes assembling one. A response playbook goes further: for a
high-confidence phishing alert, it might remove the message from all mailboxes, block the sender domain, and
reset the credentials of users who clicked - but only after a human approves the disruptive steps.
5.2 Playbooks, workflows, and safety
Playbooks must be tested in a safe environment before they run against production, because an automation
error scales instantly: a bad rule that blocks one address is a nuisance, but a bad playbook that isolates every
host matching a common pattern is an outage. Version control for playbooks, approval gates for disruptive
actions, and automatic rollback or pause conditions are not optional extras - they are the controls that make
automation trustworthy.
When a question asks about the main benefit of SOAR, the answer is usually consistency and speed of
response, not "replacing analysts." When it asks about the main risk, the answer is usually automated actions
taken on false positives, or playbooks running without testing and approval.
Automation multiplies both good and bad decisions. A well-tuned playbook that enriches alerts saves every
analyst, every day. A poorly tuned playbook that acts on low-confidence alerts creates incidents of its own -
blocked legitimate users, isolated production hosts, deleted evidence. The discipline of automation is the same
as the discipline of detection: start narrow, measure false positives, expand only when the error rate is
acceptable, and keep a human in the loop for anything irreversible.
CertCrack.com builds a playbook that automatically isolates any host the EDR flags. After a week, several
developers are locked out during a product release because a legitimate build tool triggered the rule. What
two automation principles were violated?
Answer: The action was high-impact but the trigger was low-confidence, so human approval should have gated
it. And the playbook was deployed without measuring its false positive rate on real traffic first - it should have
run in monitoring-only mode, been tuned against legitimate build activity, and only then been allowed to act.
6. SecOps metrics: MTTD and MTTR
You cannot improve what you do not measure, and security operations has two headline metrics that the exam
expects you to define, compute, and interpret correctly.
MTTD. Mean Time to Detect is the average time between an incident starting and the security team detecting
it. Shorter MTTD means less time for an attacker to operate undetected.
MTTR. Mean Time to Respond (sometimes called Mean Time to Remediate) is the average time between
detection and resolution - containment, eradication, and recovery. Shorter MTTR means less damage from
each incident that does occur.
Both are averages over a period, and both are usually computed from incident records:
MTTD = (sum of detection times for all incidents) / (number of incidents)
MTTR = (sum of response times for all incidents) / (number of incidents)
where detection time is measured from the first malicious activity to the first alert or discovery, and response
time from detection to the incident being closed.
The exam tests interpretation more than arithmetic. A falling MTTD with a rising MTTR means detection is
improving but response is not keeping up - a staffing or process problem, not a tooling problem. A very low
MTTD can also be a warning sign: if detection times collapse because analysts are now counting every noisy
alert as a detection, the metric improved on paper while nothing got safer. Metrics must be paired with quality
measures - false positive rates, incidents that were missed entirely (which never enter the average at all), and
the severity of the incidents behind the numbers.
Other metrics worth knowing: alert volume and triage time (how many alerts analysts handle and how long each
takes), dwell time (how long an attacker was present before detection - closely related to MTTD but measured
per incident), and detection coverage (which ATT&CK techniques have a working detection, and which do not).
Coverage is the metric that connects measurement back to hunting: a technique with no detection is a
technique worth hunting for.
If a question gives you detection and response times and asks for MTTD or MTTR, check carefully which
interval it describes. Detection time ends at discovery; response time starts at discovery. Confusing the two is
the most common error, and the exam sets the trap deliberately.
7. AI in security operations
Artificial intelligence has entered the SOC in three roles: as a triage assistant, as a detection engine, and as a risk
of its own. The exam treats all three, and it treats the risks as seriously as the benefits.
7.1 Where AI helps
AI assists triage by summarizing long alert timelines, correlating related events, suggesting next investigative
steps, and drafting incident summaries. It assists detection through anomaly models - the same UEBA idea,
extended to more data types - that learn normal behavior and flag deviations too subtle for static rules. It assists
analysts by answering questions about internal documentation, past incidents, and tool usage, which shortens
the time a junior analyst spends searching for context. In each case the pattern is the same: AI accelerates the
analyst's work; it does not replace the analyst's judgment.
7.2 Where AI fails: hallucination, drift, and bias
Hallucination. When a generative AI model produces confident-sounding output that is false - inventing a log
entry, a CVE reference, a tool command, or an incident detail that never existed. Hallucinations are dangerous
precisely because they read plausibly.
Analysts must verify AI output against primary evidence before acting on it. An AI summary that claims a host
communicated with a malicious address must be checked against the actual logs; an AI-suggested command
must be reviewed before it runs. The exam's AI questions frequently hinge on this single discipline: trust, but
verify against the source data.
Model drift. The gradual degradation of a model's accuracy as the real world changes around it: attacker
techniques evolve, the organization's traffic patterns shift, and the data the model was trained on stops
matching the data it now sees. Drift is why models need continuous retraining and monitoring, not one-time
deployment.
Bias. Systematic error in a model's output caused by unrepresentative training data or flawed assumptions -
for example, a model trained mostly on one region's traffic that misjudges another region's normal behavior,
or a triage model that deprioritizes alerts from systems it rarely saw in training. Bias produces both false
positives and missed detections, and it is hardest to spot because the model's errors look like confident
judgments.
7.3 Prompt injection, shadow AI, and governance
Prompt injection. An attack in which malicious instructions are hidden inside data the AI processes - a log
entry, an email, a web page, a file - so that the model follows the attacker's instructions instead of the
analyst's. Because AI assistants read untrusted content as part of their job, this is a live attack surface, not a
theoretical one.
The defenses are procedural as much as technical: treat AI output that references untrusted data with suspicion,
restrict what actions an AI assistant can take without human approval (especially anything destructive or
externally visible), and sanitize or isolate untrusted content before it reaches the model.
Shadow AI is the organizational counterpart: staff using unapproved AI tools with company data, often with
good intentions and no security review. The risks are data leakage (sensitive logs or source material sent to an
external service), unvetted output entering decisions, and a complete absence of audit trails. The governance
response mirrors the response to shadow IT: an approved tool list, clear data-handling rules for AI tools, training
for staff, and monitoring for unapproved usage.
AI governance in the SOC therefore has four pillars the exam expects you to recognize: approved tools and data
boundaries (what data may go to which AI service), human oversight for consequential decisions (no
autonomous blocking, deletion, or external communication on AI judgment alone), validation of AI output
against primary evidence, and ongoing monitoring for drift, bias, and misuse. An organization that deploys AI
triage without any of these has bought speed at the price of accountability - and the exam will ask you to spot
that trade.
AI questions on the exam almost always resolve to one of three answers: verify the output against primary
evidence, keep a human in the loop for consequential actions, or restrict the data the AI can access. If an
option suggests letting the AI act autonomously on high-impact decisions, it is almost certainly wrong.
An AI triage assistant at CertCrack.com summarizes an incident and cites a log entry that, when the analyst
checks the SIEM, does not exist. What is this failure called, and what is the correct analyst response?
Answer: Hallucination. The analyst should disregard the invented detail, verify every other claim in the
summary against primary evidence, and report the failure so the tool's reliability can be assessed - not act on
the summary as written.
Chapter check
1. A SOC wants one timeline showing an attack that moved from a phishing email to an endpoint to a cloud
account. Which tool class is designed to provide that cross-layer timeline?
A. Packet capture
B. XDR
C. NDR
D. A vulnerability scanner
2. An analyst notices long, high-entropy DNS queries at steady volume from a single workstation to a domain
registered three days ago. What does this most likely indicate?
A. A misconfigured DNS resolver
B. DNS tunneling
C. A failed software update
D. Normal web browsing
3. A threat report states: "This adversary group is actively targeting SaaS providers this quarter and uses
scheduled tasks for persistence." Which intelligence levels are present in this report?
A. Strategic only
B. Operational and tactical
C. Technical only
D. Strategic and technical
4. An analyst maps observed attacker behavior to tactics and techniques and finds that no detection covers the
persistence technique used. Which framework did the analyst use, and what did the exercise reveal?
A. The Diamond Model; the adversary's identity
B. The Cyber Kill Chain; the earliest attack phase
C. MITRE ATT&CK; a detection coverage gap
D. The pyramid of pain; the cost of changing indicators
5. A hunt hypothesis states: "If attackers are using PowerShell to download payloads, we will see PowerShell
processes making external connections in our proxy logs." What makes this a good hypothesis?
A. It is broad enough to cover all attacks
B. It is specific, testable, and tied to data the team collects
C. It assumes the attackers have already been detected
D. It requires no data to evaluate
6. A SOAR playbook automatically deletes user accounts flagged by a low-confidence UEBA alert. What is the
primary problem with this playbook?
A. It runs too slowly
B. It takes an irreversible action on low-confidence evidence without human approval
C. It uses too many tools
D. It creates tickets automatically
7. Over one quarter, CertCrack.com's MTTD falls from 6 hours to 2 hours while its MTTR rises from 4 hours to 9
hours. What does this pattern most likely mean?
A. Detection tooling failed
B. Detection improved but response capacity did not keep up
C. Fewer incidents occurred
D. Analysts stopped recording incidents
8. An AI assistant used for triage recommends blocking a partner's IP address based on an instruction hidden in
a log entry it processed. What is this attack called?
A. Model drift
B. Hallucination
C. Prompt injection
D. Shadow AI
Answer key
1. B. XDR correlates telemetry across email, endpoint, cloud, and identity into one timeline. Packet capture
shows packet contents, NDR shows network traffic, and a vulnerability scanner finds weaknesses rather than
attack activity.
2. B. Long, high-entropy subdomain queries at steady volume are the classic shape of DNS tunneling, which
hides data in DNS queries. The newly registered domain strengthens the suspicion.
3. B. The campaign and targeting information is operational intelligence, and the persistence technique is
tactical intelligence. Strategic intelligence would address long-term trends for executives, and technical
intelligence would be atomic indicators.
4. C. Mapping behavior to tactics and techniques and checking detection coverage is ATT&CK's core use. The
Diamond Model pivots between adversary, capability, infrastructure, and victim; the Kill Chain orders attack
phases; the pyramid ranks indicator durability.
5. B. A good hypothesis predicts specific observable behavior and names the data source that can prove or
disprove it. Broad or data-free hypotheses cannot be tested.
6. B. Deleting accounts is irreversible and high-impact, so it must not run automatically on low-confidence
evidence. Human approval gates exist for exactly this kind of action.
7. B. Faster detection with slower response points to a response bottleneck - staffing, process, or tooling on the
response side - not a detection failure.
8. C. Prompt injection is malicious instruction hidden in data the model processes, causing it to follow the
attacker's direction. Drift is accuracy loss over time, hallucination is invented output, and shadow AI is
unapproved tool use.
Analyst Toolkit: Emulation and Analysis Tools
The main sections of this chapter introduced the platforms of the security operations centre. This toolkit section covers the specialist tools the official CS0-004 objectives name for two jobs inside security operations: proving whether your detections actually work (breach attack simulation), and reading what the network is telling you (packet, log, and detection-rule tooling). The exam tests these tools the same way it tests everything else in this chapter — a situation, and a choice of which tool fits it.
6. Breach attack simulation
Breach attack simulation (BAS) answers the question every other tool cannot: would our defences actually detect and stop a real technique? The objectives name two open-source approaches that differ in scale — small, single-technique tests versus full automated campaigns.
Atomic Red Team. An open-source library of small, focused tests, maintained by Red Canary, each mapped to a single MITRE ATT&CK technique — for example, executing a specific credential-dumping method or a specific persistence mechanism. An analyst picks it to validate one detection at a time: run the atomic test in a controlled way, then check whether the SIEM and EDR saw it and alerted correctly. Its output is the test execution itself plus the analyst's record of what the defensive stack did (or missed); results are typically logged per technique in a coverage tracker or spreadsheet.
Caldera. An open-source adversary-emulation platform built by MITRE. Caldera deploys lightweight agents ("Sandcat" and others) on target systems and runs operations: chained sequences of technique "abilities" selected by automated planners, which can adapt based on what earlier steps discovered — emulating a campaign rather than a single action. A security team picks it for repeatable purple-team exercises and continuous validation of detection coverage across many techniques at once. Its output is an operation report: which abilities ran on which agent, what each returned, and the facts the campaign collected along the way.
| Tool | Unit of work | Automation level | Best for |
|---|---|---|---|
| Atomic Red Team | One ATT&CK technique per test | Manual or lightly scripted | Validating a specific detection, gap-hunting technique by technique |
| Caldera | Multi-step operations chaining techniques | Highly automated, planner-driven | Campaign emulation, purple-team programs, continuous validation |
One technique vs. a campaign.
BAS is not a vulnerability scan and not a pentest.
7. Network and log analysis tooling
The main guide leans on these tools in every chapter, so they get their own toolkit section. None of them exploits or scans; they observe — packets, network metadata, alerts, files, and logs — and the analyst's craft is turning their output into decisions.
Wireshark. A free, open-source graphical packet analyser. Wireshark captures traffic (or opens a saved capture) and decodes hundreds of protocols into a readable, filterable view, letting the analyst follow a single conversation end to end. An analyst picks it to answer "what exactly happened on the wire?" — inspecting a suspicious download, a plaintext credential, a malformed handshake. Its output is the packet list itself: frames with timestamps, endpoints, protocol interpretations, and the decoded contents of each packet, down to the bytes.
tcpdump. A command-line packet capture tool available on virtually every Unix-like system. tcpdump captures traffic with Berkeley Packet Filter (BPF) expressions to select exactly what matters and can write captures to a file for later analysis in Wireshark. An analyst picks it on servers and appliances where no GUI exists, or to grab a targeted capture quickly during an incident. Its output is either printed packet summaries (timestamp, endpoints, flags, length) or a saved .pcap file.
Zeek. An open-source network security monitoring framework (known for years as Bro). Instead of storing raw packets or firing signature alerts, Zeek observes traffic and writes rich, structured logs of what it saw: connections, DNS queries, HTTP requests, TLS certificates, files transferred, and more. An analyst picks it for hunting and incident reconstruction: "show me every DNS lookup this host made last week" is a quick query over Zeek's dns.log, long after the packets themselves are gone. Its output is those log files — most famously conn.log, dns.log, http.log, and files.log — ready for a SIEM or command-line analysis.
Snort. A long-established open-source intrusion detection and prevention system (from Cisco Talos). Snort inspects traffic against a large ruleset of signatures for known attacks, malware traffic, and policy violations, alerting in detection mode or blocking in inline prevention mode. An analyst picks it as a network sensor watching for known-bad patterns at a choke point. Its output is alerts: timestamped records naming the rule and its ID, the classification and priority, and the endpoints involved.
Suricata. An open-source IDS, IPS, and network security monitoring engine, multi-threaded for high-speed links. Suricata consumes Snort-compatible rules as well as its own, and beyond alerting it can log protocol transactions and extract files from traffic, emitting structured JSON (EVE) output. An analyst picks it where Snort-style detection is wanted at higher performance, or where alert-plus-context logging feeds a SIEM. Its output is alerts alongside transaction logs — HTTP, DNS, TLS and more — in one event stream.
YARA. An open-source pattern-matching tool (from VirusTotal) used to identify and classify files — most famously malware samples. Analysts write YARA rules from strings, byte patterns, and conditions observed in known samples; a match means "this file looks like the family or behaviour I described." An analyst picks it to sweep endpoints, mail gateways, or a folder of recovered files for a specific threat, and malware researchers use it to organise whole families. Its output is a list of matches: the rule name and the file (or process memory) that triggered it.
Sigma. An open format — not a scanner — for writing detection rules over log data (the "generic signature format for SIEM systems"). A Sigma rule describes a suspicious pattern in vendor-neutral YAML; converters translate it into the query language of Splunk, Microsoft Sentinel, Elastic, and many others. An analyst picks Sigma to write a detection once and share or run it anywhere — it is how the community distributes detections for new attacks. Its output is the rule itself, and, after conversion, the alerts each SIEM raises when the pattern matches its logs.
| Tool | Observes | Produces | Pick it when… |
|---|---|---|---|
| Wireshark | Packets, in a GUI | Decoded packet view | You must read one conversation byte by byte |
| tcpdump | Packets, from the CLI | Packet summaries or .pcap files | You are on a headless server mid-incident |
| Zeek | Network behaviour | Structured protocol logs | Hunting or reconstructing activity over days/weeks |
| Snort | Traffic vs. signatures | Alerts (IDS) or blocks (IPS) | Known-attack detection at a choke point |
| Suricata | Traffic vs. rules + protocols | Alerts + JSON transaction logs | High-speed detection plus rich logging |
| YARA | Files (and memory) | Rule matches | Classifying/sweeping for known malware traits |
| Sigma | Log data (format, not a sensor) | Portable detection rules | One detection must run on many SIEMs |
Zeek is the odd one out.
YARA matches files; Sigma matches logs.
Want the full CompTIA CySA+ (CS0-004) package?
This guide is free to read. Get the full CS0-004 practice exam — 750 questions plus 10 PBQs — with the complete PDF and online access.
Get CS0-004 Full Access — $10