Security Operations, Analytics and Incident Response

Introduction and Context

Security operations is the disciplined practice of continuously observing, analysing, protecting and improving an organisation’s information systems. It connects preventive controls—such as identity management, secure configuration and network segmentation—with detective and corrective capabilities. No preventive architecture is perfect: credentials may be stolen, software may contain vulnerabilities, insiders may misuse access, and attackers may exploit previously unknown techniques. Consequently, an organisation’s security posture depends not only on prevention but also on how quickly and intelligently it detects, contains, eradicates and learns from security incidents.

A modern security operations capability normally includes a security operations centre (SOC), centralised logging, security information and event management (SIEM), endpoint and network telemetry, detection engineering, threat intelligence, behavioural analytics and incident response. These capabilities must operate as an engineered socio-technical system. Technology generates observations, analysts interpret them, leaders allocate resources, and governance determines acceptable risk and legally permissible action.

This chapter examines the complete operational lifecycle from event generation to post-incident improvement. It also considers the limitations of automation, the quality of security data, measurement, privacy, evidence preservation and the use of artificial intelligence in operational defence.

Learning Objectives

After completing this chapter, a student should be able to:

1. Distinguish events, alerts, incidents and problems in a security operations context.

2. Design a defensible logging and telemetry strategy.

3. Explain SIEM architecture, detection engineering and behavioural analytics.

4. Evaluate SOC roles, workflows, metrics and escalation decisions.

5. Apply a structured incident-response lifecycle to a realistic attack.

6. Develop containment, eradication, recovery and lessons-learned actions.

7. Critically assess operational, ethical, legal and governance constraints.

1. From Security Events to Managed Incidents

An event is an observable occurrence, such as a successful login, a process starting or a firewall rule being triggered. An event is not necessarily suspicious. An alert is an event or combination of events that satisfies a detection rule or analytic threshold. An incident is a security event, or group of events, that has been assessed as affecting confidentiality, integrity, availability, authenticity or regulatory obligations. A problem is an underlying condition that causes, or could cause, repeated incidents—for example, an obsolete authentication service that repeatedly permits password attacks.

This distinction prevents two common errors. First, treating every event as an incident overwhelms the SOC. Second, treating every alert as proof of compromise encourages premature action and false positives. Analysts must establish context, confidence and potential impact.

A useful operational model is:

Observe → Triage → Investigate → Contain → Eradicate → Recover → Learn

The stages are iterative rather than strictly linear. New evidence may cause an investigator to return from containment to triage, or to expand the incident scope after recovery has begun.

Security Operations Centre Functions

A SOC may be internal, outsourced to a managed security service provider, or hybrid. Its functions commonly include:

• Monitoring: collecting and reviewing security telemetry.
• Triage: prioritising alerts according to confidence, asset criticality and potential harm.
• Investigation: reconstructing activity across identities, endpoints, applications and networks.
• Threat hunting: proactively searching for attacker behaviours not yet identified by alerts.
• Incident coordination: directing technical, legal, communications and business actions.
• Detection improvement: converting investigative knowledge into better detections.
• Reporting and assurance: communicating risk, performance and control effectiveness.

A mature SOC maintains clear handoffs, on-call arrangements, escalation criteria and authority boundaries. Analysts must know who can isolate a server, disable an account, approve a business outage or contact law enforcement.

2. Logging and Telemetry Engineering

Logging is the production and retention of records that describe activity in systems and services. Telemetry is broader: it includes logs, metrics, traces, endpoint observations, packet metadata, identity signals and cloud-provider activity. The objective is not to collect everything indiscriminately. It is to collect information that supports detection, investigation, compliance and recovery at an acceptable cost and privacy impact.

2.1 Sources of Security-Relevant Data

Important sources include:

• identity providers, authentication services and privileged-access systems;
• operating-system security logs and endpoint detection and response agents;
• DNS, proxy, firewall, VPN and network-flow data;
• cloud control-plane, storage, identity and workload logs;
• application authentication, authorisation and transaction logs;
• database audit trails;
• email security systems and collaboration platforms;
• vulnerability scanners, configuration-management systems and asset inventories;
• physical access systems where relevant to cyber investigations.

Source selection should follow risk. A payment platform requires detailed transaction and administrator auditing; a low-risk development sandbox may require less extensive retention. Critical assets need higher-fidelity and more tamper-resistant telemetry.

2.2 Properties of Good Logs

A useful log is:

• Accurate: it reflects the actual event and records time reliably.
• Consistent: fields use stable names, formats and meanings.
• Contextual: it identifies the user, asset, action, result and relevant object.
• Correlatable: timestamps, session identifiers, request identifiers and host identities permit joining records.
• Available: it can be queried during an investigation.
• Protected: unauthorised alteration or deletion is detectable or prevented.
• Economical: collection and storage costs are proportionate to investigative value.

At minimum, many security records should include an event timestamp, ingestion timestamp, source, asset, actor or account, action, object, result, network origin, authentication context and correlation identifier. Time synchronisation is essential. If systems use inconsistent clocks, the apparent order of actions may be wrong. Network Time Protocol should be securely managed, and the organisation should document how clock drift is handled.

2.3 Collection, Normalisation and Retention

A common pipeline is:

Source → Collector/Agent → Transport → Parser and Normaliser → Enrichment → Storage and Analytics

Normalisation maps different vendor formats into a common schema. Enrichment adds asset criticality, identity ownership, geolocation, vulnerability status or threat-intelligence context. Enrichment should be versioned because asset ownership and risk classifications change over time.

Retention should be based on legal requirements, contractual obligations, investigative needs, storage cost and the likely dwell time of an attacker. Retaining data longer is not automatically better: it increases exposure, privacy risk and discovery obligations. Logs containing personal data should have access controls, defined purposes, retention limits and appropriate deletion or anonymisation processes.

2.4 Log Integrity and Evidence

Operational logs may become forensic evidence. Controls include restricted write access, separate administrative identities, append-only or immutable storage, cryptographic integrity mechanisms, access auditing and documented chain of custody. A hash can help demonstrate that a collected file has not changed, but a hash alone does not prove that the original source was trustworthy. Evidence handling must document who collected data, when, from which system, using what method, and where it was stored.

3. SIEM Architecture and Detection Engineering

A security information and event management system aggregates, normalises, stores and analyses security data. A SIEM is not a substitute for good instrumentation or skilled investigation. It is an analytical layer whose value depends on data quality, detection logic and operational integration.

3.1 SIEM Capabilities

Typical capabilities include:

• indexed search across heterogeneous data;
• rule-based correlation;
• dashboards and alert queues;
• case management and investigation timelines;
• threat-intelligence matching;
• asset and identity context;
• retention and compliance reporting;
• integration with SOAR platforms, ticketing systems and endpoint controls.

Modern architectures may combine SIEM functions with extended detection and response (XDR), data lakes and cloud-native analytics. The labels vary, but the design questions remain: What data is collected? What decisions must be made? How quickly must they be made? Who is authorised to act?

3.2 Detection Engineering Lifecycle

Detection engineering treats detections as software and analytical products rather than ad hoc searches. A disciplined lifecycle is:

1. Define the threat behaviour. Describe the attacker objective and observable actions.

2. Identify data requirements. Determine which sources, fields and time resolution are necessary.

3. Write the analytic logic. Use rules, statistical methods or behavioural models.

4. Test against representative data. Include benign and malicious examples.

5. Deploy with ownership and documentation. Record assumptions, severity and response guidance.

6. Monitor performance. Examine false positives, false negatives, volume and analyst outcomes.

7. Tune and retire. Update for environmental changes and remove ineffective logic.

The MITRE ATT&CK knowledge base is frequently used to describe adversary tactics and techniques and to map detections to behaviours. Mapping is useful for coverage analysis, but a technique mapping is not proof that a detection is effective. Detection quality must be validated with realistic testing, such as controlled attack simulations or purple-team exercises.

3.3 Rule-Based Detection

A rule may identify a known indicator, such as a malicious hash, or a suspicious sequence, such as a privileged login followed by creation of a new access key and unusual data transfer. Rules are explainable and often fast, but they can be evaded by changing indicators or using legitimate administrative tools.

Correlation should consider sequence, identity, asset and time. A single failed login is usually weak evidence; hundreds of failures followed by a successful login from an unusual location are more meaningful. Rules should also account for approved maintenance, service accounts and known automation to reduce unnecessary alerts.

3.4 Measuring Detection Performance

Detection performance should be measured using a labelled set of outcomes. Let:

• TP = true positives, malicious cases correctly alerted;
• FP = false positives, benign cases incorrectly alerted;
• FN = false negatives, malicious cases missed;
• TN = true negatives, benign cases correctly not alerted.

Then:

Precision = TP / (TP + FP)

Precision answers: “Among the alerts raised, what proportion were genuinely malicious?” It is undefined when no alerts are raised.

Recall = TP / (TP + FN)

Recall answers: “Among the malicious cases present, what proportion were detected?” It is undefined when no malicious cases are present. The measures assume that the evaluation set is labelled with reasonable confidence. In real SOCs, false negatives are difficult to observe, so recall is often estimated through testing, threat hunting and retrospective review rather than directly measured.

For example, if a controlled evaluation contains 30 true positives and 10 false positives, precision is 30/(30+10) = 0.75, or 75%. If the evaluation contains 30 true positives and 5 false negatives, recall is 30/(30+5) ≈ 85.7%. These metrics should not be optimised in isolation: a highly sensitive rule may generate unmanageable workload, while a highly precise rule may miss important attacks.

4. Behavioural Analytics and Threat Hunting

Behavioural analytics identifies deviations from expected activity. User and entity behaviour analytics (UEBA) may analyse login times, locations, device relationships, administrative actions, data access and communication patterns. The aim is to identify unusual behaviour that does not depend on a known malicious indicator.

4.1 Baselines and Anomalies

A baseline describes normal behaviour for a user, service, device or peer group. An anomaly is a departure from that baseline. However, unusual does not mean malicious. A system administrator working during an emergency, a travelling executive or a newly deployed application may all appear anomalous.

Effective analytics therefore combines:

• deviation from historical behaviour;
• deviation from a comparable peer group;
• asset and identity criticality;
• sequence and timing of actions;
• known threat intelligence;
• business context and change-management records.

Statistical scores must be interpreted carefully. A simple standardised score, often written as z = (x − μ)/σ, assumes that the variable has a meaningful mean (μ) and standard deviation (σ), and that these estimates are appropriate for the population being analysed. Many security behaviours are seasonal, heavy-tailed or categorical, so a normal-distribution interpretation may be invalid. Robust baselines, percentiles, seasonal models and domain-specific rules may be preferable.

4.2 Threat Hunting

Threat hunting is a hypothesis-driven search for evidence of adversary activity. A hunt might ask: “Could an attacker have used stolen cloud credentials to create persistence without triggering our existing alerts?” The team identifies relevant data, searches for patterns, validates benign explanations, records findings and converts useful discoveries into detections or control improvements.

Hunting is valuable because it can expose blind spots, but it is resource-intensive and should be prioritised by threat scenarios, asset exposure and intelligence. A hunt without a hypothesis, scope or stopping rule can become an unfocused search.

5. SOC Processes, Roles and Metrics

SOC operating models commonly use tiers, although small teams may combine them. Tier 1 performs initial monitoring and enrichment; Tier 2 conducts deeper investigation and containment; Tier 3 handles advanced analysis, malware research, threat hunting and detection development. Incident managers coordinate major events. Specialists from identity, cloud, networking, legal, privacy, communications, human resources and business continuity join when required.

5.1 Triage and Prioritisation

Triage should consider at least:

• confidence that malicious activity occurred;
• criticality of the affected asset or process;
• scope and number of affected identities or systems;
• potential confidentiality, integrity and availability impact;
• attacker access and persistence;
• regulatory, contractual and safety consequences;
• time sensitivity and volatility of evidence.

A severity label is a communication device, not a substitute for judgement. A low-volume event affecting a domain administrator may be more urgent than thousands of blocked commodity scans.

5.2 Operational Metrics

Useful measures include mean time to detect (MTTD), mean time to acknowledge, mean time to contain (MTTC), mean time to recover (MTTR), alert backlog, escalation rate, detection coverage and recurrence rate. Each requires a clear definition. For example, MTTR might mean time from confirmed incident declaration to restoration of an approved service, not merely closure of a ticket.

Metrics can create harmful incentives. If analysts are rewarded only for closing tickets quickly, they may close difficult cases prematurely. Balanced scorecards should combine speed, quality, recurrence reduction, detection validation, stakeholder satisfaction and learning outcomes. Measurement must distinguish workload caused by poor detection quality from workload caused by genuinely high threat activity.

6. Incident Response Lifecycle

Incident response is an organised capability for managing and limiting the consequences of security incidents. It includes preparation, detection and analysis, containment, eradication, recovery and post-incident activity. Organisations should align their procedures with recognised guidance, such as NIST incident-response publications, ISO/IEC 27035 concepts and applicable sector requirements. Frameworks provide structure but do not remove the need for organisation-specific playbooks.

6.1 Preparation

Preparation includes:

• approved incident-response policy and authority matrix;
• asset inventory, dependency maps and contact lists;
• tested backups and recovery objectives;
• secure administrative access and emergency accounts;
• logging, endpoint isolation and forensic collection capability;
• tabletop exercises and technical simulations;
• legal, regulatory and communications procedures;
• relationships with providers, insurers, law enforcement and specialist responders.

Preparation should address degraded conditions. If identity infrastructure is compromised, responders may need an independent communication channel and trusted administrative workstations.

6.2 Detection and Analysis

The team validates the alert, identifies affected entities, establishes an initial timeline, preserves volatile evidence where appropriate, and determines whether the activity is ongoing. Analysis should test competing hypotheses rather than confirm the first suspicion. Important questions include: What account or process initiated the action? What permissions were available? How did the actor move? What data or systems were accessed? Is there evidence of persistence or destructive intent?

6.3 Containment

Containment limits spread and damage. Short-term actions may include isolating endpoints, disabling accounts, blocking indicators, restricting network paths or suspending a compromised integration. Long-term containment may involve rebuilding systems in a controlled segment or applying temporary compensating controls.

Containment involves trade-offs. Shutting down a system may prevent further damage but destroy volatile evidence or interrupt safety-critical operations. Decisions should document expected benefit, operational harm, authorisation and reassessment time.

6.4 Eradication

Eradication removes the cause and persistence mechanisms. Actions may include credential rotation, removal of malicious scheduled tasks, patching exploited vulnerabilities, deletion of unauthorised accounts, rebuilding compromised hosts and correcting insecure configurations. Merely deleting a malware file is insufficient if the attacker still possesses valid tokens or a second persistence mechanism.

Credential resets should consider password reuse, API keys, certificates, refresh tokens, service accounts and secrets embedded in automation. The scope should be based on evidence and plausible exposure, not only on the first confirmed account.

6.5 Recovery

Recovery restores services using trusted systems and validates that the threat has been removed. Steps include integrity checks, monitoring heightened-risk assets, phased restoration, user and owner confirmation, backup validation and rollback planning. Recovery is complete only when services meet defined security and business acceptance criteria.

6.6 Post-Incident Improvement

A post-incident review should be blameless but accountable. It should reconstruct decisions, identify control failures, evaluate response timing, capture evidence gaps and assign measurable corrective actions with owners and deadlines. A useful review distinguishes root causes from contributing conditions. For example, “phishing email” is an initiating vector, while excessive privileges, absent phishing-resistant authentication and inadequate token revocation may be contributing conditions.

7. Incident-Response Playbooks

A playbook translates policy into repeatable action. It should specify triggers, scope, roles, decision points, evidence, communication paths and closure criteria. It must remain adaptable: rigid automation can amplify an incorrect classification.

A ransomware playbook may include:

1. Validate encryption behaviour and identify the initial host.

2. Isolate affected endpoints while preserving critical services.

3. Protect identity infrastructure and privileged accounts.

4. Determine whether data was exfiltrated, not only encrypted.

5. Preserve samples, logs and relevant memory or disk evidence.

6. Notify the incident commander, legal counsel, privacy officers and business owners.

7. Block known infrastructure and disable compromised access.

8. Identify the entry vector and remove persistence.

9. Rebuild from trusted media and validate backups.

10. Restore in business-priority order with enhanced monitoring.

11. Assess notification, contractual and law-enforcement obligations.

12. Complete a lessons-learned review and improve detections.

Playbooks for business-email compromise, cloud credential theft, insider misuse, denial-of-service and supply-chain compromise differ in evidence and containment actions. Each should define what not to do—for example, communicating with an attacker from an unapproved account or deleting evidence before collection.

8. Applied Case: Illustrative Cloud Credential Compromise

Background

A fictional online retailer operates a cloud-hosted customer portal. It uses central identity management, cloud audit logs, endpoint telemetry for administrators and a SIEM. A privileged engineer’s account is protected by a password and a second factor based on a session token.

Problem

The SOC receives an alert that the engineer’s account created a new cloud access key from an unfamiliar network location. Fifteen minutes later, the account accessed an object-storage bucket and listed several databases. The activity occurred outside the engineer’s normal working pattern.

Analysis

The analyst first verifies that the engineer is not travelling and that no approved change exists. Identity logs show a successful login followed by token use from a device not previously associated with the engineer. Cloud audit records show creation of a long-lived access key, a change to a role policy and repeated reads of customer-data objects. Network telemetry identifies outbound transfers to an unfamiliar hosting provider.

The initial hypothesis is compromise of a session token or password, followed by privilege escalation and data discovery. Investigators compare object-access logs with egress records, identify the accessed objects and query other accounts for similar activity. They preserve relevant logs in protected storage and open a high-severity incident because customer data may have been exposed.

Approach and Solution

The incident commander authorises immediate revocation of the engineer’s sessions and access keys, suspension of the account pending verification, and removal of the unauthorised policy change. Cloud workloads are not shut down indiscriminately because doing so would interrupt customer service. Instead, network egress from the affected administrative role is restricted, and a trusted emergency account is used from a clean workstation.

The team searches for newly created keys, role changes, unusual object reads and persistence across all cloud accounts. It finds a second access key created for a service account, indicating broader scope. The service key is revoked, dependent applications are tested with replacement credentials, and all potentially exposed secrets are rotated. A forensic review determines that the engineer entered credentials into a fraudulent browser prompt; the attacker then obtained a session token through a malicious extension.

The organisation deploys phishing-resistant authentication for privileged users, restricts token lifetimes, removes standing administrative privileges, and introduces approval and detection controls for access-key creation and role-policy changes. It also improves cloud-data access logging and creates a detection for anomalous bulk reads followed by external transfer.

Outcome

Customer services remain available, unauthorised access is stopped, and the organisation establishes that a defined set of records was accessed. Legal and privacy teams assess notification duties under applicable law and contracts. A review finds that the original alert was generated within minutes, but the account suspension required manual approval and took longer than the technical detection. The corrective programme therefore addresses both technology and authority design.

Learning Points

1. Cloud control-plane logs are essential to identity and data investigations.

2. A valid account and valid token can be used maliciously; indicator matching alone is insufficient.

3. Containment must protect evidence and business continuity simultaneously.

4. Access-key and policy-change events deserve high-fidelity detection.

5. Incident response exposes governance problems, such as unclear emergency authority.

9. Automation, AI and Contemporary Developments

Security orchestration, automation and response (SOAR) can enrich alerts, create cases, block indicators and isolate endpoints. Automation is most appropriate for reversible, well-understood actions with low collateral risk. Examples include enriching an IP address, querying asset ownership or opening a ticket. High-impact actions—such as disabling a domain administrator or shutting down a production database—should normally require stronger confidence, approval or a carefully tested break-glass procedure.

Machine learning can support anomaly detection, entity scoring, malware classification, summarisation and analyst search. It can also generate false confidence, reproduce biased historical decisions, be manipulated by adversarial inputs and expose sensitive data to unauthorised systems. AI-generated explanations should be treated as hypotheses, not evidence. Organisations should retain human accountability, record model versions, monitor drift, protect prompts and outputs, and validate performance across relevant environments.

Contemporary operations increasingly address software supply chains, identity-centric attacks, cloud ephemeral workloads, encrypted traffic, ransomware extortion and attacks on operational technology. Detection strategies must therefore move beyond perimeter assumptions and incorporate identity, workload, data and business-process context. Zero-trust architectures reduce implicit trust but do not eliminate the need for monitoring and response.

10. Governance, Ethics and Legal Considerations

Security monitoring can involve employee communications, location data, personal identifiers and customer records. Monitoring should have a legitimate purpose, be proportionate, be transparent where appropriate, restrict access and follow applicable privacy and employment law. Excessive collection can damage trust and create a secondary breach risk.

Incident decisions may affect employees, customers, suppliers and the public. Organisations should avoid unnecessary disclosure of personal information, preserve due process in insider investigations and separate confirmed facts from speculation. Regulatory notification deadlines and content vary by jurisdiction and sector; legal counsel and privacy professionals should be engaged early rather than treating notification as a purely technical decision.

Governance should define data ownership, retention, access review, third-party responsibilities, evidence handling, breach reporting, risk acceptance and independent assurance. A SOC’s authority must be explicit, especially when an action could cause an outage or affect safety.

11. Challenges and Limitations

Security operations faces persistent limitations:

• Visibility gaps: unmanaged devices, encrypted traffic and cloud services may be poorly observed.
• Alert overload: weak rules and duplicate telemetry consume scarce analyst attention.
• Data quality problems: missing fields, clock errors and inconsistent identities undermine correlation.
• Adversarial adaptation: attackers change tools, use legitimate services and imitate normal behaviour.
• Skills and fatigue: continuous operations create burnout and dependency on a few experts.
• Measurement uncertainty: missed incidents are difficult to count, so apparent improvement may reflect reduced visibility.
• Third-party dependence: providers may control logs, response permissions and notification timing.
• Recovery complexity: backups may be infected, dependencies undocumented and restoration order unclear.

These limitations imply that security operations should be risk-based and continuously improved, not judged by the presence of a SIEM dashboard or a large number of alerts.

Best-Practice Design Principles

1. Start with critical business services and attack scenarios, not product features.

2. Maintain accurate asset, identity and dependency inventories.

3. Collect high-value telemetry with documented ownership and retention.

4. Treat detections as maintained engineering artefacts.

5. Test detections and playbooks through realistic exercises.

6. Use context—identity, asset criticality, change records and business impact—in triage.

7. Automate enrichment and low-risk actions before automating destructive actions.

8. Preserve evidence and document decisions contemporaneously.

9. Separate containment authority from routine ticket administration.

10. Measure quality, resilience and learning, not only speed or alert volume.

11. Design for privacy, legal review and third-party coordination.

12. Convert every significant incident into improved controls, detections or training.

Chapter Summary

Security operations integrates logging, SIEM, detection engineering, behavioural analytics, SOC processes and incident response into a continuous defensive capability. Events become useful only when they are reliable, contextual and correlated. SIEM platforms provide analytical infrastructure, while detection engineering supplies tested logic and operational guidance. Behavioural analytics and threat hunting extend detection beyond known indicators, but anomalies require context and careful interpretation.

Effective SOCs use structured triage, clear roles, meaningful metrics and escalation authority. Incident response progresses through preparation, detection and analysis, containment, eradication, recovery and post-incident improvement. Playbooks make action repeatable while preserving human judgement for high-impact decisions. Cloud and identity incidents demonstrate why valid credentials, tokens and administrative tools can be abused without traditional malware.

Finally, security operations is constrained by privacy, law, evidence requirements, data quality, adversarial adaptation and human capacity. Automation and AI can improve scale, but accountability, validation and governance remain essential. The most mature organisations treat every incident as both a threat-management event and an opportunity to improve architecture, process and organisational learning.

Key Terms

Event: An observable occurrence in a system or environment.

Alert: A notification generated when activity meets a detection condition.

Incident: An assessed event or group of events that threatens security or obligations.

Security Operations Centre (SOC): A function responsible for continuous security monitoring and response.

Telemetry: Observations from logs, metrics, traces, endpoints, networks and services.

SIEM: A platform for collecting, correlating, analysing and retaining security events.

Detection engineering: The systematic design, testing and maintenance of security detections.

Threat hunting: A hypothesis-driven search for previously unidentified adversary activity.

UEBA: User and entity behaviour analytics used to identify unusual activity.

Triage: Initial assessment and prioritisation of an alert or suspected incident.

Containment: Actions that limit the spread or impact of an incident.

Eradication: Removal of malicious access, persistence and underlying causes.

Recovery: Restoration and validation of trusted services.

Playbook: A documented set of procedures for a particular incident scenario.

SOAR: Security orchestration, automation and response technology.

False positive: A benign activity incorrectly classified as malicious.

False negative: Malicious activity that a detection fails to identify.

Chain of custody: Documentation showing how evidence was collected, controlled and transferred.

Mean time to detect (MTTD): A defined measure of elapsed time from relevant activity to detection.

Purple team: A collaborative exercise in which offensive and defensive teams improve controls and detections.

Review Questions

Short Answer Questions

1. Distinguish an event, an alert and an incident.

2. Why is time synchronisation important during an investigation?

3. What is the purpose of detection engineering?

4. State two risks associated with excessive security-log retention.

5. What is the primary objective of containment?

Long Answer Questions

1. Explain the architecture and operational value of a SIEM, including its limitations.

2. Describe the complete incident-response lifecycle and the decisions involved in each stage.

3. Compare rule-based detection, behavioural analytics and threat hunting.

4. Discuss how a SOC should select and interpret operational metrics.

5. Explain the legal, ethical and governance issues involved in employee and customer monitoring.

Analytical / Application Questions

1. A privileged cloud account creates an access key from an unfamiliar location, changes a role policy and downloads data. Develop an investigation and containment plan, identifying evidence, stakeholders and decision points.

2. A detection produces 20 true positives and 80 false positives in a test set. Calculate its precision and explain why precision alone is insufficient to assess the detection.

3. Design a ransomware-response playbook for a hospital. Explain how patient safety, evidence preservation, business continuity, communications and recovery priorities affect containment decisions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an alert from an incident?

A. An alert is always confirmed malicious activity.

B. An alert is generated by a detection condition, whereas an incident is an assessed security-impacting occurrence.

C. An incident is any event recorded in a log.

D. An alert can only be generated by a firewall.

Correct Answer: B. An alert is generated by a detection condition, whereas an incident is an assessed security-impacting occurrence.

Question 2

Which property most directly supports correlation of events from different systems?

A. Consistent timestamps and common identity or correlation fields

B. Maximum log retention regardless of purpose

C. Using a different timestamp format in every system

D. Disabling enrichment to reduce storage

Correct Answer: A. Consistent timestamps and common identity or correlation fields

Question 3

A detection evaluation has 30 true positives and 10 false positives. What is its precision?

A. 25%

B. 50%

C. 75%

D. 90%

Correct Answer: C. 75%

Question 4

Which activity is an example of threat hunting?

A. Automatically deleting every file with a particular extension

B. Searching for evidence that stolen cloud credentials created persistence despite no existing alert

C. Renewing a software licence

D. Archiving closed help-desk tickets

Correct Answer: B. Searching for evidence that stolen cloud credentials created persistence despite no existing alert

Question 5

Which action belongs primarily to eradication?

A. Identifying the initial alert

B. Removing persistence and rotating exposed credentials

C. Prioritising business services for restoration

D. Writing the final lessons-learned report

Correct Answer: B. Removing persistence and rotating exposed credentials

Question 6

Why should high-impact automated response actions usually have stronger controls?

A. They never affect production systems.

B. They may cause significant collateral damage if the detection is wrong.

C. They cannot be logged.

D. They eliminate the need for incident commanders.

Correct Answer: B. They may cause significant collateral damage if the detection is wrong.

Question 7

Which metric measures the proportion of raised alerts that are genuinely malicious?

A. Recall

B. Precision

C. Mean time to recover

D. Coverage

Correct Answer: B. Precision

Question 8

What is a central limitation of behavioural anomaly detection?

A. All unusual activity is necessarily malicious.

B. It cannot use identity information.

C. Legitimate unusual activity can resemble attack behaviour.

D. It requires no baseline.

Correct Answer: C. Legitimate unusual activity can resemble attack behaviour.

Question 9

In the illustrative cloud case, why were cloud control-plane logs important?

A. They replaced the need for identity controls.

B. They recorded administrative actions such as key creation and policy changes.

C. They automatically proved the attacker’s nationality.

D. They prevented all data exfiltration.

Correct Answer: B. They recorded administrative actions such as key creation and policy changes.

Question 10

Which is an appropriate post-incident improvement activity?

A. Deleting inconvenient evidence

B. Assigning corrective actions with owners and deadlines

C. Closing the incident before scope is understood

D. Measuring only the number of alerts generated

Correct Answer: B. Assigning corrective actions with owners and deadlines