8. Security Operations and Detection Engineering

Introduction and Context

Security operations translate an organisation’s security strategy into continuous observation, interpretation, and action. While preventive controls attempt to reduce the likelihood of compromise, no modern organisation can assume that prevention will always succeed. Misconfigurations, stolen credentials, vulnerable applications, insider misuse, supply-chain compromise, and novel attacks may bypass preventive measures. A security operations centre (SOC) therefore provides the capability to identify suspicious activity, determine its significance, contain harm, and support recovery.

Detection engineering is the disciplined design, implementation, testing, and improvement of methods used to identify malicious or policy-violating behaviour. It is broader than writing SIEM queries. It includes understanding threats, selecting useful telemetry, modelling attacker behaviour, expressing detection logic as maintainable code, measuring performance, and integrating detections with investigation and response processes.

An effective SOC is consequently a socio-technical system. Technology such as log platforms, security information and event management (SIEM), endpoint detection and response (EDR), network sensors, and security orchestration, automation and response (SOAR) is necessary but insufficient. People, processes, governance, architecture, and measurement determine whether those technologies produce reliable security outcomes.

This chapter examines how SOC capabilities are designed and operated, how detection use cases are engineered, and how organisations evaluate detection coverage and response performance. It also considers automation, behavioural analytics, threat hunting, governance, and emerging developments in detection engineering.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the purpose, architecture, and operating model of a modern SOC.

2. Distinguish the roles of logging, SIEM, SOAR, EDR/XDR, and network telemetry.

3. Design detection use cases from threat scenarios and adversary behaviours.

4. Apply detection-as-code, behavioural baselines, and threat-hunting methods.

5. Evaluate detection coverage, fidelity, investigation effort, and response time.

6. Analyse the organisational, ethical, and governance issues surrounding security monitoring.

7. Recommend improvements to SOC capability using evidence-based performance measures.

The SOC as a Decision and Response System

A SOC receives observations from an organisation’s digital environment and converts them into decisions. The basic flow is often represented as:

data collection → normalisation and enrichment → detection → triage → investigation → response → recovery and learning.

Data collection includes authentication events, endpoint process activity, cloud audit records, network flows, DNS queries, email events, application logs, vulnerability information, and threat intelligence. Normalisation makes data from different systems comparable, while enrichment adds context such as asset criticality, user role, geolocation, ownership, vulnerability state, or known indicators.

Detection identifies patterns that may represent an attack. A detection does not automatically establish that an incident has occurred. Triage determines whether an alert is credible, relevant, and sufficiently important to warrant investigation. Investigation reconstructs events, tests hypotheses, identifies scope, and determines whether containment is required. Response may include disabling an account, isolating an endpoint, blocking an indicator, revoking a token, or restoring a service.

The SOC must balance two forms of failure. A false negative allows malicious activity to remain undetected, potentially increasing impact. A false positive consumes analyst time and may cause alert fatigue, delayed response, or inappropriate action. Detection engineering therefore seeks not simply to produce more alerts, but to produce alerts that are timely, actionable, explainable, and proportionate to risk.

SOC Operating Models

A centralised SOC provides common monitoring and response for multiple business units. It can promote consistency and economies of scale, but may lack local context. A distributed model places analysts within business or regional units, improving contextual understanding while creating risks of duplicated tooling and inconsistent standards. A hybrid model combines central detection engineering and platform management with local operational expertise.

Organisations may also use managed detection and response (MDR) providers, co-managed SOC arrangements, or a virtual SOC. These approaches can improve access to specialised skills, but require carefully defined responsibilities, service levels, data-handling rules, escalation paths, and exit arrangements. Outsourcing operational tasks does not eliminate the organisation’s accountability for security, privacy, and regulatory compliance.

Maturity is better assessed through capability than through staffing or product count. A mature SOC can explain what it monitors, why a detection exists, how it is tested, who owns it, how quickly alerts are investigated, and what evidence supports improvement.

Telemetry: The Evidence Base for Detection

Telemetry is the recorded evidence from which detections and investigations are constructed. Its usefulness depends on more than volume. A log that lacks timestamps, identity, asset context, or sufficient detail may be difficult to interpret even if it is collected reliably.

Important telemetry sources include:

• Identity and access data: authentication success and failure, multifactor authentication events, privilege changes, session creation, token use, and directory modifications.
• Endpoint telemetry: process creation, command-line arguments, parent-child relationships, file changes, registry or configuration changes, network connections, and security-control events.
• Network telemetry: DNS, proxy, firewall, flow, routing, email, and intrusion-sensor records. Full packet capture may provide deeper evidence but has significant storage, privacy, and processing implications.
• Cloud and SaaS audit data: administrative actions, role assignments, API calls, object access, workload activity, and changes to security configurations.
• Application and database logs: unusual transactions, access failures, privilege changes, data exports, and errors that may indicate exploitation or abuse.
• Contextual data: asset inventory, business criticality, vulnerability status, user department, maintenance windows, and approved change records.

A telemetry strategy should begin with security questions rather than with a desire to collect everything. For example, the question “Can we detect unauthorised privilege escalation in the cloud?” implies a need for identity events, role-change records, resource context, and possibly approval data. Data-source selection should consider coverage, quality, retention, cost, latency, privacy, and resistance to tampering.

Log integrity is a major concern. Attackers may delete or alter local records, so important events should be transmitted securely to a separate, access-controlled repository. Time synchronisation is equally important: inconsistent clocks can distort event sequences and make investigations unreliable. Retention should reflect legal obligations, investigation requirements, threat dwell time, and available resources rather than an arbitrary number of days.

SIEM, SOAR, EDR/XDR, and Network Security Platforms

A SIEM aggregates and analyses security-relevant events. Its functions commonly include ingestion, parsing, normalisation, correlation, search, alerting, dashboards, case management, and reporting. SIEM is valuable when it combines otherwise disconnected signals—for example, a suspicious login, a new privileged role, and an endpoint connection to an unusual destination.

SIEM implementations often fail when organisations ingest large volumes of low-value data without a clear use-case strategy. Cost, storage pressure, query performance, and analyst overload follow. A sound implementation defines data owners, parsing standards, priority sources, retention tiers, and detection objectives.

SOAR platforms coordinate procedures across security tools. A playbook might enrich an alert with identity and asset information, query endpoint evidence, check reputation services, open a case, notify an owner, and request approval before isolating a device. Automation should be graduated. Low-risk, reversible actions can often be automated, whereas disruptive actions—such as disabling a production account—may require human approval.

EDR focuses on endpoint visibility and response. It can record process trees, command execution, persistence mechanisms, file activity, and network connections, and may support isolation or remediation. XDR extends correlation across multiple control domains, such as endpoint, identity, email, cloud, and network. The label XDR does not guarantee superior detection; its value depends on integration quality, data access, analytical logic, and operational usability.

Network detection and response platforms analyse network telemetry for suspicious communications, scanning, lateral movement, protocol misuse, and command-and-control patterns. Encrypted traffic reduces content visibility, increasing the importance of metadata, endpoint evidence, identity signals, and carefully governed decryption strategies.

These technologies are complementary. EDR may show the process that initiated a connection; DNS telemetry may reveal the domain involved; identity data may identify the user; SIEM may correlate the events; and SOAR may coordinate containment. Tool deployment without a coherent evidence model, however, produces fragmented investigations.

From Threat Scenarios to Detection Use Cases

A detection use case is a defined security objective supported by data, logic, operational procedures, and ownership. “Detect ransomware” is too broad to be an immediately useful use case. A more precise objective might be: “Identify rapid encryption-like file modification by a process not normally associated with bulk file operations, prioritise activity on critical servers, and provide evidence for rapid containment.”

Use-case engineering can follow these stages:

1. Define the threat and business concern. Identify the adversary behaviour, assets at risk, likely impact, and relevant threat model.

2. Describe observable behaviour. Translate the scenario into events or patterns that should appear in available telemetry.

3. Assess data feasibility. Confirm that required fields exist, are timely, trustworthy, and retained for the necessary period.

4. Design detection logic. Use rules, statistical methods, sequences, thresholds, or combinations of signals.

5. Specify alert content. Include the reason for alerting, affected entities, evidence, confidence, severity, and recommended investigation steps.

6. Test and tune. Use benign simulations, historical data, adversary emulation, and production feedback.

7. Operationalise. Assign ownership, define escalation and response actions, and document dependencies.

8. Measure and review. Examine true positives, false positives, missed detections, latency, and business value.

A detection should answer three questions for an analyst: What happened? Why might it matter? What should be done next? A rule that produces only an indicator without context transfers excessive work to the analyst and may be unsuitable for a high-volume environment.

Detection Logic and the Pyramid of Behaviour

Detection may target atomic indicators such as hashes or domains, but indicators change quickly and can be shared by benign systems. Behavioural detections generally provide greater resilience. Examples include unusual credential use, suspicious parent-child process relationships, abnormal administrative actions, or access sequences inconsistent with a user’s normal role.

The adversary-behaviour perspective encourages mapping detections to a recognised knowledge base, such as the MITRE ATT&CK framework. Such mapping helps communicate coverage and identify gaps, but a technique mapping alone is not proof of effective detection. Coverage should consider platforms, prerequisites, visibility, detection quality, and response feasibility.

Detection logic may be:

• Signature-based: matches known strings, hashes, patterns, or indicators.
• Rule-based: evaluates explicit conditions, thresholds, or event sequences.
• Correlation-based: combines signals from different sources.
• Anomaly-based: identifies deviation from an established baseline.
• Statistical or machine-learning based: estimates unusualness or classification from data.
• Risk-based: combines multiple observations into a prioritised risk score.

No single method is sufficient. Signatures are precise for known threats, while behavioural methods may identify novel activity but produce more uncertainty. Good engineering uses layered detections and documents their assumptions.

Detection-as-Code and Engineering Discipline

Detection-as-code treats detection content as a managed engineering artefact rather than an informal query stored only in a production console. Rules, parsers, tests, documentation, configuration, and deployment procedures can be maintained in version control. Changes can undergo peer review, automated validation, testing, approval, and rollback.

A detection repository should normally record its purpose, data sources, query logic, severity, owner, technique mapping, expected false positives, dependencies, test cases, and response guidance. Continuous integration can check syntax, schema compatibility, prohibited constructs, naming standards, and test results. Continuous delivery can promote approved detections across development, test, and production environments.

Testing should include positive cases, in which malicious or suspicious behaviour should trigger the detection, and negative cases, in which legitimate activity should not. Tests may use synthetic events, replayed data, controlled adversary emulation, or production-like test environments. Changes to parsers and data schemas must be tested because a technically correct rule may silently fail when field names or event formats change.

Detection-as-code also improves accountability. A change is attributable, reviewable, and reversible. Nevertheless, code management does not remove the need for analyst judgement. Operational feedback, threat intelligence, and changing business processes must still inform the detection lifecycle.

Behavioural Baselines and Threat Hunting

A baseline describes expected activity for an entity, such as a user, host, service account, application, or network segment. Baselines may include normal login times, source locations, administrative actions, process relationships, data-transfer volumes, or access relationships. A deviation is not automatically malicious. A developer may legitimately work unusual hours during an incident, and a backup service may create large data transfers according to schedule.

Baseline quality depends on time period, peer grouping, seasonality, data completeness, and adaptation controls. A baseline that learns from compromised activity may gradually treat attacker behaviour as normal. For this reason, high-risk changes and baseline updates should be governed and, where appropriate, reviewed.

Threat hunting is a proactive, hypothesis-driven search for malicious activity that may not have generated an alert. A hunt begins with a proposition such as: “An attacker who obtained cloud credentials may have created persistence through a new privileged application.” The hunter identifies relevant data, searches for expected traces, tests alternative explanations, and documents findings. A successful hunt may produce a new detection, improve telemetry, reveal a control gap, or show that the hypothesis is unsupported.

Hunting and detection engineering reinforce each other. Detections operationalise repeatable findings; hunts explore uncertainty and discover what existing detections miss. Neither should be confused with unfocused searching or the accumulation of unprioritised queries.

Measuring SOC and Detection Performance

Metrics should support decisions rather than create an appearance of productivity. Common measures include:

• Mean time to detect (MTTD): the elapsed time between relevant activity and detection. The starting point must be defined carefully.
• Mean time to acknowledge (MTTA): the time between alert creation and an analyst accepting responsibility.
• Mean time to respond or contain (MTTR): the time from detection or confirmation to an appropriate response action.
• Alert fidelity: the proportion of alerts that represent genuinely suspicious or actionable activity.
• False-positive rate: the proportion of alerts incorrectly classified as malicious or requiring action.
• Detection latency: the delay between an observable event and production of an alert.
• Investigation effort: analyst time or steps required to reach a disposition.
• Coverage: the proportion of prioritised threats, assets, techniques, or scenarios for which effective detection exists.
• Telemetry health: completeness, freshness, parsing success, and availability of important data sources.

Detection coverage should not be expressed as a single simplistic percentage. A useful coverage model distinguishes whether the organisation has visibility, a tested detection, adequate context, an assigned response, and acceptable performance for a given threat scenario. A detection that exists but cannot distinguish legitimate administration from abuse may provide nominal rather than practical coverage.

Response time also requires interpretation. A low average may hide severe delays affecting critical assets. Median, percentile, severity-weighted, and business-impact measures are often more informative than averages alone. Metrics should be segmented by incident type, business unit, asset criticality, and shift.

SOC leaders should combine quantitative and qualitative evidence. A reduction in alert volume may indicate better tuning—or an ingestion failure. A high number of closed cases may represent efficiency—or superficial triage. Metrics must therefore be reviewed alongside quality sampling, incident outcomes, analyst feedback, and control validation.

Case Study: Improving Detection for a Hybrid Financial Services Environment

Background

The following is an illustrative case. A mid-sized financial services organisation operated data centres, cloud workloads, remote endpoints, and several SaaS platforms. Its SOC used a SIEM, an EDR platform, and separate cloud and identity consoles. The organisation received approximately 18,000 security alerts each month, but investigations were inconsistent and ownership of detection rules was unclear.

Situation and Problem

An internal review found that identity logs from one cloud environment were delayed, several endpoint fields were parsed differently across operating systems, and many SIEM rules depended on undocumented assumptions. Analysts frequently searched multiple consoles manually. The organisation had no reliable measure of coverage for credential theft or privilege escalation.

Analysis

The SOC mapped priority scenarios to assets and telemetry. Two high-risk scenarios were selected: use of a stolen privileged identity and unauthorised creation of persistent cloud access. Analysis showed that the required events existed, but they lacked consistent user, source, and resource identifiers. Existing rules generated alerts for every unusual login, producing many false positives during travel and maintenance periods.

Approach and Solution

The detection engineering team first established an event schema and improved time synchronisation and identity enrichment. It created version-controlled detections for unusual privileged authentication, new role assignments, and creation of long-lived access credentials. The rules correlated identity, cloud audit, asset, and approved-change data.

A risk-based workflow grouped related events into cases rather than producing separate alerts. Analysts received the affected identity, source context, target resource, historical activity, and recommended validation steps. SOAR automation enriched cases and requested approval before disabling an account. EDR data was queried when the identity activity was associated with an endpoint session.

The team tested the detections with benign administrative activity and controlled simulations. It introduced weekly review of false positives and monthly review of telemetry health. Coverage was reported by scenario, platform, and asset criticality rather than by the number of rules deployed.

Outcome

The organisation reduced duplicate alerts and improved investigation consistency. More importantly, it could demonstrate which high-priority scenarios were covered, which depended on unavailable telemetry, and which had no tested response procedure. The programme also exposed a governance issue: business units had created privileged accounts without common ownership or expiry requirements.

Learning Points

The case illustrates that detection improvement is not achieved by adding rules alone. Data quality, identity context, case design, response authority, testing, and governance are equally important. It also demonstrates why detection coverage should be tied to explicit scenarios and business risk.

Challenges, Risks, and Common Mistakes

A common mistake is treating alert volume as evidence of security capability. Excessive low-value alerts cause fatigue and encourage analysts to close cases without adequate investigation. The opposite mistake—aggressive suppression—can hide real attacks. Suppression should be narrowly scoped, documented, time-limited where appropriate, and periodically reviewed.

Another risk is dependence on a single vendor’s data model or analytical claims. Organisations should retain access to raw evidence where feasible, understand portability constraints, and test whether critical detections continue to operate during platform degradation. Blind spots may arise from unsupported operating systems, unmanaged devices, encrypted traffic, shadow IT, or cloud services outside central administration.

Automation can propagate errors at scale. An incorrect playbook may disable many legitimate accounts or delete evidence. Actions should therefore be classified by risk, tested, logged, and subject to approval controls. Emergency procedures should exist for reversing automated actions.

Machine-learning detections present additional limitations. Models may be difficult to explain, sensitive to changes in business behaviour, biased by incomplete training data, and vulnerable to manipulation. Human review remains necessary for high-impact decisions. Model drift, feature quality, and feedback loops require active governance.

Analyst capability is another limiting factor. A technically advanced platform cannot compensate for unclear procedures, insufficient training, excessive workload, or poor collaboration with infrastructure and business teams. SOC design should address career development, shift handover, psychological workload, and knowledge retention.

Governance, Privacy, and Professional Responsibility

Security monitoring involves the collection and analysis of information about people. Organisations should define a legitimate purpose, collect proportionate data, restrict access, establish retention limits, and protect monitoring records. Employees should receive appropriate notice consistent with law and organisational policy. Sensitive data may require masking, field-level access control, or separate handling procedures.

SOC governance should define ownership of telemetry, detection content, incidents, automated actions, and evidence. Access to investigative data should follow least privilege and be logged. Chain-of-custody requirements may apply where evidence could support disciplinary or legal proceedings. Analysts must distinguish suspicion from fact and avoid unnecessary disclosure of personal information.

Regulatory obligations vary by jurisdiction and sector, but commonly include requirements for incident reporting, records protection, access control, resilience, and auditability. A SOC should coordinate with legal, privacy, risk, compliance, human resources, and communications functions. Technical capability without authority to act is ineffective; authority without documented safeguards is dangerous.

Current Developments and Best Practices

Security operations are increasingly shaped by cloud-native architectures, identity-centric attacks, software supply-chain risk, and machine-speed automation. Extended detection platforms are integrating endpoint, identity, email, network, and cloud evidence. Security data lakes and open schemas aim to improve analytical flexibility, although they introduce governance and cost challenges.

Generative AI is being evaluated for alert summarisation, query assistance, case enrichment, documentation, and analyst training. Its outputs may be incomplete or confidently incorrect, and sensitive telemetry may be exposed if services are poorly governed. AI should assist, not silently replace, accountable decision-making. Prompt and data controls, output validation, audit logging, and restricted use cases are essential.

Effective SOC programmes commonly follow these practices:

• prioritise scenarios by business risk and adversary behaviour;
• build telemetry requirements before purchasing additional tools;
• maintain detection content in version control with peer review and testing;
• enrich alerts with identity, asset, vulnerability, and change context;
• use automation for repeatable, low-risk actions and approval for disruptive actions;
• measure quality, latency, coverage, and business impact rather than alert counts alone;
• validate detections through exercises, hunts, simulations, and incident learning;
• treat parsers, integrations, and data pipelines as production security controls;
• review privacy, retention, access, and evidence-handling requirements;
• invest in analysts, documentation, handover, and cross-functional relationships.

Chapter Summary

Security operations provide the organisational capability to observe digital activity, detect harmful behaviour, investigate evidence, and coordinate response. A modern SOC combines people, processes, telemetry, SIEM, SOAR, EDR/XDR, network data, identity context, and governance. Detection engineering converts threat scenarios into tested, maintainable, and operationally useful detections. Detection-as-code improves reviewability and deployment discipline, while behavioural baselines and threat hunting extend visibility beyond known indicators.

SOC performance should be evaluated through meaningful measures such as detection latency, response time, alert fidelity, investigation effort, telemetry health, and scenario-based coverage. Metrics require careful definitions and interpretation. Automation and AI can improve scale, but they introduce risks involving error propagation, explainability, privacy, and accountability. The strongest SOC programmes link technical evidence to business risk, continuously test their assumptions, and use operational learning to improve both detections and organisational controls.

Key Terms

Security Operations Centre (SOC): A function that monitors, investigates, and responds to security events and incidents.

Detection engineering: The disciplined design, testing, deployment, and improvement of security detections.

Telemetry: Recorded observations from systems, networks, applications, identities, and security controls.

SIEM: A platform that collects, normalises, correlates, searches, and presents security events.

SOAR: Technology that orchestrates security workflows and automates response actions.

EDR: Endpoint detection and response capability providing endpoint visibility, analysis, and containment.

XDR: Cross-domain detection and response combining evidence from endpoint and other security domains.

Detection use case: A defined security objective supported by data, logic, procedures, and ownership.

Detection-as-code: Management of detection content as version-controlled, tested, reviewable engineering artefacts.

Threat hunting: Proactive, hypothesis-driven searching for malicious activity not necessarily identified by alerts.

Behavioural baseline: A model of expected activity for a user, host, service, application, or network entity.

False positive: An alert incorrectly classified as malicious or actionable.

False negative: Malicious or policy-violating activity that a detection fails to identify.

Detection coverage: The extent to which prioritised threats, assets, or scenarios have effective and tested detection.

MTTD: Mean time to detect relevant activity.

MTTA: Mean time to acknowledge an alert.

MTTR: Mean time to respond to or contain a security event or incident.

Alert fidelity: The degree to which alerts accurately represent suspicious and actionable activity.

Telemetry health: The completeness, freshness, correctness, and availability of security data.

Review Questions

Short Answer Questions

1. Why is a SOC considered a socio-technical system rather than merely a collection of security tools?

2. Distinguish between SIEM and SOAR.

3. What is the purpose of detection-as-code?

4. Why should behavioural baseline deviations not be treated automatically as evidence of compromise?

5. Define detection latency and explain why it matters.

Long Answer Questions

1. Explain the complete lifecycle from telemetry collection to response and learning in a modern SOC.

2. Discuss how an organisation should engineer a detection use case from a threat scenario.

3. Compare the roles and limitations of SIEM, EDR/XDR, network telemetry, and SOAR.

4. Explain how detection coverage and response-time metrics should be designed and interpreted.

5. Analyse the governance, privacy, and professional responsibilities associated with security monitoring.

Analytical / Application Questions

1. A SOC has a rapidly increasing alert queue but no increase in confirmed incidents. Design an evidence-based plan to determine whether the problem is poor detection fidelity, analyst capacity, telemetry failure, or inadequate triage.

2. An organisation wants to detect stolen cloud administrator credentials. Specify the telemetry, detection logic, enrichment, testing method, response workflow, and performance measures you would recommend.

3. A SOAR playbook automatically disables accounts following unusual privileged logins, but legitimate administrators are frequently locked out. Analyse the risks and redesign the automation using graduated response and governance controls.

22. Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes an effective SOC from a collection of security products?

A. It generates the largest possible number of alerts.

B. It integrates people, processes, telemetry, decisions, and response authority.

C. It uses only products from one vendor.

D. It eliminates the need for human investigation.

Correct Answer: B. It integrates people, processes, telemetry, decisions, and response authority.

Question 2

An organisation wants to detect unauthorised cloud privilege escalation. Which data combination is most useful?

A. Only antivirus signatures and email subjects

B. Only network bandwidth measurements

C. Identity events, cloud audit logs, resource context, and approved-change data

D. Only workstation inventory records

Correct Answer: C. Identity events, cloud audit logs, resource context, and approved-change data

Question 3

What is the principal benefit of detection-as-code?

A. It guarantees that every alert is a true positive.

B. It removes the need for threat modelling.

C. It makes detection content version-controlled, testable, reviewable, and reversible.

D. It replaces all SIEM functionality.

Correct Answer: C. It makes detection content version-controlled, testable, reviewable, and reversible.

Question 4

Why should an unusual behavioural baseline deviation not automatically generate a high-confidence incident?

A. Baselines cannot be used in cybersecurity.

B. Legitimate changes, incomplete data, and seasonal activity can also cause deviations.

C. Attackers never deviate from normal behaviour.

D. Baseline systems only analyse network packets.

Correct Answer: B. Legitimate changes, incomplete data, and seasonal activity can also cause deviations.

Question 5

Which SOC metric measures the time between alert creation and an analyst accepting responsibility?

A. MTTD

B. MTTA

C. MTTR

D. Detection coverage

Correct Answer: B. MTTA

Question 6

A detection rule exists for a technique, but the required log source is delayed and lacks user identifiers. How should this be assessed?

A. As complete practical coverage

B. As nominal coverage with a telemetry and quality gap

C. As a false positive by definition

D. As proof that the technique is irrelevant

Correct Answer: B. As nominal coverage with a telemetry and quality gap

Question 7

Which response is most appropriate when a SOAR action could disable a production administrator account?

A. Execute it without logging to maximise speed.

B. Prohibit all automation permanently.

C. Use risk-based approval, audit logging, testing, and a reversal procedure.

D. Allow any analyst to modify it directly in production.

Correct Answer: C. Use risk-based approval, audit logging, testing, and a reversal procedure.

Question 8

What is the central purpose of threat hunting?

A. To search proactively for malicious activity that may not have generated an alert.

B. To replace incident response after every alert.

C. To collect all available data without a hypothesis.

D. To suppress alerts from unusual users.

Correct Answer: A. To search proactively for malicious activity that may not have generated an alert.

Question 9

Why can alert volume be a misleading measure of SOC performance?

A. High alert volume always indicates excellent coverage.

B. Low alert volume may result from either effective tuning or a telemetry failure.

C. Alert volume has no relationship to analyst workload.

D. Alert volume is determined only by legal requirements.

Correct Answer: B. Low alert volume may result from either effective tuning or a telemetry failure.

Question 10

Which practice best supports reliable detection coverage measurement?

A. Counting the number of rules regardless of data quality or response capability

B. Reporting one overall percentage without identifying scenarios or assets

C. Evaluating prioritised scenarios for visibility, tested detection, context, response, and performance

D. Measuring only the number of vendor products deployed

Correct Answer: C. Evaluating prioritised scenarios for visibility, tested detection, context, response, and performance