Incident Response, Forensics and Cyber Resilience

Introduction and Context

Cybersecurity cannot be reduced to preventing every intrusion. Even well-designed controls can fail because of zero-day vulnerabilities, stolen credentials, insider misuse, supply-chain compromise, misconfiguration, or human error. Consequently, postgraduate security professionals must be able to manage incidents systematically, preserve reliable evidence, restore business services, and improve organisational resilience.

Incident response is the organised process through which an organisation prepares for, detects, analyses, contains, eradicates, and recovers from adverse cybersecurity events. Digital forensics supplies the methods for identifying, collecting, preserving, examining, and interpreting digital evidence. Cyber resilience extends these capabilities by focusing on the organisation’s ability to continue delivering important services, absorb disruption, adapt to changing threats, and improve after an incident.

These disciplines are interdependent but not identical. Incident response is operational and time-sensitive. Forensics is evidential and analytical. Business continuity and disaster recovery are service-oriented. Crisis communications are organisational and reputational. Effective security leadership integrates all four without allowing one objective—such as rapid restoration—to destroy another, such as evidence integrity.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the incident-response lifecycle and distinguish events, alerts, incidents, and crises.

2. Design preparation, detection, triage, containment, eradication, recovery, and lessons-learned activities.

3. Apply principles of digital and network forensics while maintaining evidence integrity and chain of custody.

4. Analyse incident severity, business impact, dependencies, and recovery priorities.

5. Coordinate technical teams, executives, legal advisers, regulators, suppliers, and affected stakeholders.

6. Integrate incident response with business continuity, disaster recovery, and cyber-resilience strategy.

7. Evaluate the use and limitations of automation and artificial intelligence in response operations.

1. Foundations of Incident Response

1.1 Events, alerts, incidents, and crises

An event is any observable occurrence in a system, such as a login, process execution, or network connection. An alert is an event or group of events judged sufficiently suspicious to require review. An incident is an event, or series of events, that threatens the confidentiality, integrity, or availability of information or services and requires coordinated action. A crisis is a high-impact situation that exceeds routine operational handling and may threaten safety, legal compliance, essential services, financial viability, or organisational legitimacy.

The distinctions matter because treating every event as an incident overwhelms analysts, while treating a serious incident as routine delays escalation. Classification should consider affected assets, confidence in the diagnosis, scope, duration, data sensitivity, operational consequences, legal obligations, and potential for propagation.

1.2 Objectives and competing priorities

Incident response commonly seeks to:

• protect life, safety, and essential services;
• limit damage and prevent further compromise;
• establish what happened and how;
• preserve evidence suitable for investigation or legal proceedings;
• restore trustworthy operations;
• meet notification and reporting obligations; and
• learn from the event.

These objectives can conflict. Disconnecting a compromised server may stop an attacker but destroy volatile evidence. Rebuilding a system may restore service but remove artefacts needed to determine the initial access vector. Public disclosure may protect customers but increase reputational impact if facts are uncertain. Leaders therefore make explicit, documented decisions based on risk, authority, and the current level of confidence.

1.3 Roles and governance

A mature response capability defines responsibility before an incident occurs. Typical participants include a security operations centre, incident commander, system and network administrators, digital forensic specialists, threat intelligence analysts, legal counsel, privacy officers, risk managers, human resources, public relations, executive leadership, and business-service owners. External participants may include managed security providers, cyber-insurance representatives, law enforcement, regulators, specialist forensic firms, and critical suppliers.

The incident commander coordinates the response, maintains priorities, assigns actions, controls meetings, and ensures that decisions are recorded. The commander need not be the most technically senior person. Technical leads determine facts within their domains, while legal and communications specialists advise on obligations and messaging. A RACI matrix—responsible, accountable, consulted, and informed—helps prevent ambiguity, but it must be supported by practical playbooks and exercises.

2. The Incident-Response Lifecycle

Many organisations use a lifecycle based on preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. These phases are not strictly linear. New evidence can return a team from recovery to containment, and lessons learned should continuously improve preparation.

2.1 Preparation

Preparation includes governance, policies, playbooks, contact lists, logging, monitoring, asset inventories, secure backups, identity controls, endpoint protection, network segmentation, forensic tooling, communications procedures, and trained personnel. It also includes agreements that permit rapid access to external expertise and evidence-preservation services.

Preparation should be risk-based. An organisation should identify critical services, their dependencies, acceptable interruption periods, sensitive information, likely attack paths, and available recovery resources. Tabletop exercises test decision-making, while technical simulations test detection, isolation, restoration, and evidence handling. Preparation is incomplete if it consists only of purchasing tools; people must know who may authorise disruptive actions and how to operate when normal systems are unavailable.

2.2 Detection and analysis

Detection combines endpoint, network, identity, application, cloud, physical, and user-reported signals. Useful sources include authentication logs, DNS records, firewall flows, proxy logs, endpoint telemetry, email security systems, cloud audit trails, vulnerability data, and threat-intelligence reports.

Analysis begins with validation. Analysts ask whether the alert is technically plausible, whether it represents malicious activity, what systems and accounts are involved, and whether the activity is ongoing. They establish a timeline, preserve relevant data, identify indicators of compromise, and develop hypotheses that are tested against independent evidence.

A useful analytical discipline is to distinguish:

• facts: directly observed and reproducible findings;
• inferences: conclusions supported by several facts; and
• assumptions: propositions not yet verified.

This distinction reduces confirmation bias and prevents uncertain claims from being presented as established truth.

2.3 Triage and severity assessment

Triage determines priority, scope, ownership, and immediate action. Severity may be based on the sensitivity of affected data, criticality of services, number of systems, attacker privileges, persistence, regulatory exposure, safety implications, and likelihood of continuing harm.

A simple qualitative matrix can combine impact and likelihood, but organisations should avoid false precision. A low-confidence alert involving a highly critical system may warrant urgent investigation even when impact is not yet confirmed. Triage should also identify whether the case is a single endpoint infection, a credential compromise, a widespread intrusion, a destructive attack, a data breach, or a supply-chain event.

2.4 Containment

Containment limits the attacker’s access and the incident’s spread. Short-term actions may include isolating endpoints, disabling accounts, blocking malicious domains, revoking tokens, restricting remote access, or separating network segments. Long-term containment may involve temporary architecture changes, additional monitoring, emergency patching, or migration to clean infrastructure.

Containment decisions should be proportionate and reversible where possible. Before isolation, teams should consider volatile evidence, operational safety, patient or public impact, and whether the attacker may interpret the action as detection and accelerate destructive behaviour. A compromised identity should not merely have its password changed if active sessions, application tokens, delegated permissions, and persistence mechanisms remain valid.

2.5 Eradication

Eradication removes the cause and persistence of compromise. Activities may include deleting malicious accounts and scheduled tasks, removing malware, correcting vulnerabilities, rotating credentials and keys, rebuilding systems from trusted images, and addressing insecure configurations. The team must investigate the initial access vector and lateral movement; otherwise, eradication may be superficial.

Reimaging is often safer than attempting to clean a deeply compromised host, especially when privileged access or kernel-level persistence is suspected. However, reimaging should occur only after required evidence has been captured or an authorised decision has accepted its loss.

2.6 Recovery

Recovery restores services in a controlled manner and confirms that restored systems are trustworthy. It includes validating backups, rebuilding in a clean environment, applying security controls, monitoring for recurrence, testing business functions, and gradually returning systems to normal operation.

Recovery is not complete merely because a server responds to a network request. Service owners should verify data integrity, authentication, interfaces, performance, dependencies, security monitoring, and user-facing functionality. Heightened monitoring after restoration can reveal residual attacker access or reinfection.

2.7 Lessons learned

A post-incident review should be blameless but not responsibility-free. It should examine detection time, decision latency, control effectiveness, communication quality, evidence gaps, supplier performance, recovery assumptions, and whether the incident exposed systemic governance weaknesses. Actions require owners, deadlines, measures of completion, and executive oversight.

Useful measures include time to detect, time to triage, time to contain, time to recover, percentage of critical assets covered by logging, backup restoration success, and recurrence of similar root causes. Metrics must be interpreted carefully: a shorter recovery time may reflect better capability, but it may also reflect premature restoration or under-reporting.

3. Digital and Network Forensics

3.1 Forensic principles

Digital evidence is fragile, duplicable, and easily altered. Core principles include minimising changes to original evidence, documenting every handling step, using validated tools, maintaining reproducibility, recording time sources and time zones, and preserving original media or logically equivalent copies.

Evidence should be relevant, reliable, sufficient, and obtained lawfully. Technical validity does not automatically make evidence admissible; jurisdictional rules, authorisation, privacy law, employment agreements, and contractual terms may govern collection and use.

3.2 Evidence sources

Endpoint evidence includes disk images, memory captures, event logs, browser artefacts, shell history, registry data, scheduled tasks, installed software, and security-agent records. Network evidence includes full packet captures, flow records, DNS queries, proxy logs, firewall records, VPN logs, email headers, wireless-controller data, and authentication traces. Cloud evidence may include control-plane audit logs, identity-provider records, object-access logs, container events, and snapshots.

Each source has strengths and limitations. Full packet capture may reveal content and protocol details but is expensive, incomplete in encrypted environments, and subject to retention constraints. Flow records provide useful communication patterns but normally cannot show payloads. Endpoint logs may identify process ancestry but can be disabled or manipulated by a privileged attacker. No single source should be treated as a complete account.

3.3 Collection and chain of custody

A collection plan identifies the questions to be answered, relevant systems, time window, volatile data, authorisation, personnel, tools, storage, and transfer method. Volatile data—such as memory, active network connections, running processes, and temporary tokens—may need priority collection. Collection order depends on the investigative question and the likelihood that an action will alter evidence.

Chain of custody records what was collected, by whom, when, from where, using which method, how it was hashed or sealed, who accessed it, and when it was transferred. Cryptographic hashes can demonstrate that a file or image has not changed since hashing. A hash supports integrity verification; it does not prove that the original item was authentic, complete, or lawfully obtained.

3.4 Timeline analysis

Investigators normalise timestamps, document clock drift, distinguish event time from log-ingestion time, and account for daylight-saving and time-zone differences. They correlate independent sources to reconstruct actions such as initial access, credential use, privilege escalation, lateral movement, data staging, exfiltration, and persistence.

A timeline should express confidence. For example, an authentication record may strongly establish that an account was used, but it may not establish which human used it if credentials were stolen. Correlation is strongest when different systems independently support the same event.

3.5 Network-forensic reasoning

Network forensics examines communications and traffic patterns to understand scope, command-and-control, data movement, and policy violations. Analysts may investigate unusual DNS entropy, rare destinations, beacon periodicity, abnormal protocol use, unexpected east-west traffic, and deviations from a system’s normal communication profile.

Encryption limits content inspection but does not eliminate metadata. Source and destination, timing, volume, certificate information, DNS behaviour, and endpoint process context may remain useful. Analysts must avoid equating unusual behaviour with maliciousness: software updates, backups, virtualisation, and business changes can produce similar patterns.

4. Crisis Communications and Coordination

Communication is a control function, not merely public relations. Internal personnel need clear instructions, executives need decision-quality information, customers need accurate and useful guidance, and regulators may require timely notification. Messages should distinguish confirmed facts, current impact, uncertainty, protective actions, and next update time.

A communications plan should define spokespersons, approval routes, secure channels, audience groups, notification thresholds, media handling, customer support scripts, and procedures for communicating when corporate email or collaboration systems are compromised. Out-of-band channels should be tested in advance.

Legal and regulatory duties vary by jurisdiction and sector. Breach notification may depend on the type of data, materiality, risk to individuals, contractual commitments, and the role of the organisation as controller, processor, or service provider. Organisations should avoid delaying all action until every fact is known, but should also avoid speculation, unsupported attribution, or claims that an investigation cannot justify.

Attribution is particularly uncertain. Technical indicators may suggest a toolset or infrastructure associated with a threat actor, but tools are copied, infrastructure is rented, and attackers deliberately plant misleading evidence. Operational response should normally focus first on harm reduction and recovery rather than public attribution.

5. Continuity, Disaster Recovery, and Cyber Resilience

Business continuity maintains or restores important business functions during disruption. Disaster recovery focuses more specifically on restoring technology, data, and infrastructure. Cyber resilience includes prevention, protection, response, recovery, adaptation, and learning in the presence of intelligent adversaries.

Business impact analysis identifies critical processes, dependencies, maximum tolerable disruption, recovery priorities, and minimum acceptable service levels. Two common planning measures are the recovery time objective (RTO), the target time within which a service should be restored, and the recovery point objective (RPO), the target maximum period of data loss measured in time. These are planning objectives, not guarantees.

For example, if a payroll service has an RTO of eight hours and an RPO of one hour, recovery planning should aim to restore service within eight hours and limit unrecoverable transaction loss to approximately one hour. Achieving these targets depends on backup frequency, restoration speed, staff availability, dependencies, and whether the backup environment is itself compromised.

Cyber resilience requires special attention to trustworthy recovery. Attackers may encrypt production systems and backups, corrupt recovery documentation, compromise identity infrastructure, or remain dormant in replicated environments. Effective controls include offline or immutable backups, separate administrative credentials, tested restoration, multiple recovery paths, segmentation, golden images, dependency maps, manual workarounds, and predefined degraded-service modes.

Resilience can be viewed as a capability cycle: anticipate likely disruption, withstand initial effects, recover essential services, and adapt based on evidence. The objective is not perfect continuity at any cost. It is proportionate continuity of important outcomes while maintaining safety, integrity, and legal obligations.

6. Applied Case: Illustrative Ransomware Incident in a Research University

Background

This fictional case concerns Northbridge University, which operates research laboratories, student services, finance systems, and a hybrid cloud environment. The university has endpoint detection, central identity management, and daily backups. However, several laboratory systems use legacy software, and network segmentation is incomplete.

Problem

At 02:15 on a Monday, the security team receives alerts showing unusual PowerShell activity on a finance workstation and repeated authentication attempts against a domain administrator account. At 02:40, several file servers become unavailable. Users report ransom notes, while a research laboratory reports that instrument-control data cannot be accessed.

Analysis

The incident commander activates the major-incident plan. The team places the affected identity accounts into a restricted state, isolates known encrypted hosts, and blocks suspected command-and-control destinations. Before shutting down selected systems, forensic specialists capture memory from a high-value server and preserve relevant authentication, VPN, endpoint, and firewall logs.

Timeline analysis shows that an attacker entered through a compromised remote-access account three days earlier. Multifactor authentication was not enforced for a legacy VPN profile. The attacker performed reconnaissance, obtained additional credentials through a vulnerable workstation, and later used a privileged account. The ransomware deployment was preceded by deletion attempts against online backups.

Investigators initially suspect that research data was exfiltrated. Network-flow analysis identifies a large outbound transfer from one laboratory segment to a cloud-storage destination, but endpoint and proxy evidence is needed to determine whether the transfer was legitimate. The team therefore reports exfiltration as possible rather than confirmed.

Approach and solution

The university prioritises safety-critical research and student welfare services. It moves essential identity services to a clean recovery environment, disables the affected VPN profile, rotates privileged credentials, and establishes an out-of-band communications channel. Restoration proceeds from immutable backups after malware scans and integrity checks. Laboratory systems are rebuilt in a segmented network, with temporary manual procedures for critical experiments.

Legal counsel and the privacy office assess whether personal or confidential research data was accessed. The university notifies relevant authorities within applicable deadlines and provides staff and students with practical guidance. A specialist firm assists with forensic validation and negotiates only under executive and legal governance; payment is not treated as a substitute for recovery planning.

Outcome

Core student and finance services resume after thirty hours, while some laboratory functions require several days. Investigation confirms unauthorised access to a limited administrative data set but does not establish that research data was exfiltrated. The university implements phishing-resistant multifactor authentication for remote access, separates laboratory networks, protects backups with independent administration, expands logging, and conducts a recovery exercise.

Learning points

The case demonstrates that a security alert becomes strategically important when it affects identity, backups, and critical services. It also shows the value of evidence preservation before destructive recovery actions, cautious language about uncertain exfiltration, service prioritisation, and investment in recovery architecture rather than reliance on perimeter prevention alone.

7. Automation, Artificial Intelligence, and Contemporary Practice

Security orchestration and automation can enrich alerts, quarantine endpoints, revoke tokens, enrich indicators, and open response cases. Automation is valuable for repetitive, high-confidence actions, particularly when response speed is important. However, automated isolation can disrupt essential services, and automated blocking can be manipulated by poisoned intelligence or false positives.

Machine-learning systems can detect behavioural anomalies, classify malware, summarise incidents, and assist analysts in searching large evidence sets. They remain vulnerable to incomplete training data, concept drift, adversarial manipulation, opaque reasoning, and automation bias. Generative AI may draft timelines or queries, but outputs require verification against primary evidence. Sensitive evidence must not be placed into an unapproved external service.

Contemporary practice increasingly involves cloud-native systems, software supply chains, identity-centric attacks, ransomware-as-a-service, deepfakes, and attacks on operational technology. Response plans must therefore include cloud-provider evidence acquisition, software bills of materials, identity telemetry, third-party notification paths, and safety-aware procedures for industrial or medical environments.

8. Challenges, Limitations, and Ethical Governance

Incident response is constrained by incomplete visibility, encrypted traffic, short log-retention periods, legacy systems, skills shortages, cross-border data restrictions, and dependency on suppliers. Evidence may be unavailable because logging was not enabled before the incident. Investigators should document these limitations rather than overstate certainty.

Privacy is a central ethical concern. Monitoring employee communications, collecting memory, or examining personal devices can reveal sensitive information unrelated to the incident. Collection should be necessary, proportionate, authorised, access-controlled, and retained only as long as justified. Investigators should separate investigative relevance from curiosity and use legal counsel where jurisdiction is uncertain.

Organisations also face ethical decisions about disclosure, attribution, ransom negotiation, surveillance, and use of offensive countermeasures. Defensive response must not become unauthorised access to another party’s systems. Governance should define authority, escalation, conflicts of interest, evidence access, and independent review.

Best Practices for Strategic Capability

1. Maintain an accurate inventory of critical assets, identities, services, and dependencies.

2. Define incident categories, severity levels, escalation thresholds, and decision rights.

3. Collect and retain logs that support both detection and forensic reconstruction.

4. Test out-of-band communications and maintain current contact information.

5. Protect backups against the same identity and network failures that affect production.

6. Use documented playbooks, but allow incident commanders to adapt to novel conditions.

7. Preserve evidence before remediation when operationally and legally feasible.

8. Separate confirmed facts, analytical judgments, and unresolved hypotheses.

9. Exercise technical recovery and executive decision-making together.

10. Track lessons learned to verified improvements rather than merely producing reports.

Chapter Summary

Incident response is a coordinated capability for managing cybersecurity incidents from preparation through recovery and improvement. Its lifecycle includes preparation; detection and analysis; triage; containment; eradication; recovery; and lessons learned. Effective response balances rapid harm reduction with evidence preservation, operational safety, legal compliance, and trustworthy restoration.

Digital forensics provides disciplined methods for collecting and interpreting endpoint, network, identity, cloud, and application evidence. Chain of custody, validated tools, timestamp normalisation, corroboration, and explicit confidence statements support reliable conclusions. Network forensics is strongest when multiple sources are correlated and metadata is interpreted in context.

Crisis communications must be accurate, authorised, audience-appropriate, and candid about uncertainty. Business continuity and disaster recovery translate technical recovery into service outcomes through impact analysis, RTOs, RPOs, resilient backups, dependency mapping, and tested restoration. Cyber resilience extends these ideas by enabling organisations to anticipate, withstand, recover from, and learn through disruption.

Automation and AI can improve speed and analytical capacity, but human oversight, privacy protection, governance, and evidence verification remain essential. Strategic maturity is demonstrated not by the absence of incidents, but by the organisation’s ability to detect them, limit harm, preserve trust, restore important services, and convert experience into stronger capability.

Key Terms

Incident response: Organised management of a cybersecurity incident from preparation through improvement.

Event: An observable occurrence in a system or network.

Alert: An event or group of events requiring investigation.

Incident: A threat or compromise requiring coordinated security action.

Crisis: A high-impact situation exceeding routine operational handling.

Triage: Prioritising and classifying cases according to urgency, scope, and impact.

Containment: Actions that limit an incident’s spread or ongoing harm.

Eradication: Removal of malware, persistence, vulnerabilities, and unauthorised access.

Recovery: Restoration and validation of trustworthy services.

Digital forensics: Systematic examination of digital evidence.

Network forensics: Analysis of network communications and traffic records.

Chain of custody: Documentation of evidence handling from collection to presentation.

Volatile evidence: Data that may disappear or change when a system is powered off or altered.

Indicator of compromise: Observable evidence associated with malicious activity.

RTO: Target time for restoring a service.

RPO: Target maximum period of data loss measured in time.

Business continuity: Capability to maintain important functions during disruption.

Cyber resilience: Ability to withstand, recover from, adapt to, and learn from cyber disruption.

Incident commander: Person responsible for coordinating response decisions and activities.

Immutable backup: Backup designed to resist modification or deletion during a defined period.

Review Questions

Short Answer Questions

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

2. What are the principal objectives of incident response?

3. Why is chain of custody important in digital forensics?

4. Define RTO and RPO.

5. Why should incident reports distinguish facts, inferences, and assumptions?

Long Answer Questions

1. Explain the incident-response lifecycle and discuss how activities may overlap between phases.

2. Describe a forensic collection plan for a suspected credential-compromise incident.

3. Analyse the relationship between incident response, business continuity, disaster recovery, and cyber resilience.

4. Discuss the governance and ethical issues involved in collecting employee or customer digital evidence.

5. Evaluate the benefits and limitations of automation and artificial intelligence in security operations.

Analytical / Application Questions

1. A hospital detects ransomware on a clinical workstation while its backup administrator account shows suspicious activity. Propose a prioritised containment and recovery strategy, including evidence-preservation decisions.

2. Network logs show a large encrypted outbound transfer from a research server, but no payload data is available. Explain how investigators should assess whether exfiltration occurred and how the organisation should communicate uncertainty.

3. An organisation meets its stated recovery time but restores systems from backups whose administrative credentials were also compromised. Critically evaluate whether recovery was successful and recommend resilience improvements.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily associated with the containment phase?

A. Removing all vulnerabilities from the organisation

B. Isolating a compromised endpoint from the network

C. Writing the final lessons-learned report

D. Calculating the annual security budget

Correct Answer: B. Isolating a compromised endpoint from the network

Question 2

What does a cryptographic hash primarily help demonstrate about collected evidence?

A. That the evidence was collected lawfully

B. That the evidence has not changed since it was hashed

C. That a named person caused the incident

D. That the evidence is complete in every respect

Correct Answer: B. That the evidence has not changed since it was hashed

Question 3

Which statement best describes an RPO?

A. The target time to restore a service

B. The maximum number of users allowed during recovery

C. The target maximum period of data loss measured in time

D. The time required to detect an attack

Correct Answer: C. The target maximum period of data loss measured in time

Question 4

Why should a response team distinguish facts from assumptions?

A. To eliminate the need for technical evidence

B. To reduce confirmation bias and communicate uncertainty accurately

C. To avoid involving legal advisers

D. To ensure every incident is publicly attributed

Correct Answer: B. To reduce confirmation bias and communicate uncertainty accurately

Question 5

Which evidence source is generally most useful for observing running processes and active connections at a specific moment?

A. A memory capture

B. A printed asset inventory

C. A long-term risk register

D. A public press release

Correct Answer: A. A memory capture

Question 6

What is the main purpose of an incident commander?

A. To perform every technical investigation personally

B. To coordinate priorities, decisions, resources, and communication

C. To replace all business-service owners

D. To approve unrelated software purchases

Correct Answer: B. To coordinate priorities, decisions, resources, and communication

Question 7

Which recovery measure best protects against attackers deleting ordinary online backups?

A. Using the same administrator account for production and backups

B. Increasing the number of perimeter firewalls only

C. Maintaining immutable or offline backups with independent administration

D. Reducing backup retention to one day

Correct Answer: C. Maintaining immutable or offline backups with independent administration

Question 8

Why is public attribution of a threat actor often uncertain?

A. Attackers never reuse tools or infrastructure

B. Technical indicators can be copied, rented, or deliberately falsified

C. Network evidence cannot contain timestamps

D. Attribution is determined solely by backup systems

Correct Answer: B. Technical indicators can be copied, rented, or deliberately falsified

Question 9

Which statement best characterises cyber resilience?

A. A guarantee that incidents will never occur

B. The ability to anticipate, withstand, recover from, adapt to, and learn from disruption

C. A policy concerned only with public relations

D. A replacement for business continuity planning

Correct Answer: B. The ability to anticipate, withstand, recover from, adapt to, and learn from disruption

Question 10

What is a major limitation of automated incident-response actions?

A. They can never operate quickly

B. They may cause operational harm when alerts are false or systems are critical

C. They cannot process any security telemetry

D. They always preserve every form of volatile evidence

Correct Answer: B. They may cause operational harm when alerts are false or systems are critical