Digital Forensics, Investigation and Cyber Resilience

Introduction and Context

Digital systems now support banking, healthcare, manufacturing, government, education and critical infrastructure. Their dependence creates two related requirements. First, organizations must be able to investigate security events in a manner that is technically sound, legally defensible and ethically responsible. Second, they must continue delivering essential services despite disruption. Digital forensics addresses the first requirement; cyber resilience addresses the second.

Digital forensics is the disciplined identification, collection, preservation, examination, analysis and presentation of information from digital devices and services. A forensic investigation may support criminal prosecution, civil litigation, regulatory reporting, internal disciplinary action, insurance claims or organizational learning. Cyber resilience is the capability to anticipate, withstand, recover from and adapt to adverse cyber events while maintaining important business functions.

These capabilities are interdependent. Poor forensic preservation can prevent an organization from discovering the true cause of an incident. Weak resilience planning can allow a technically contained compromise to become a prolonged business crisis. Effective practice therefore integrates incident response, evidence management, root-cause analysis, business continuity, disaster recovery, crisis communication and resilience testing.

This chapter treats investigation as both a technical and governance activity. Tools alone do not establish truth. Reliable conclusions depend on clearly defined authority, sound methods, validated evidence, competent personnel, accurate records and cautious interpretation.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the purpose, scope and phases of digital forensic investigation.

2. Design forensic-readiness capabilities before an incident occurs.

3. Preserve, acquire, validate and document digital evidence appropriately.

4. Apply investigation methods, timeline analysis and root-cause analysis.

5. Distinguish business continuity, disaster recovery and incident response.

6. Use recovery objectives and resilience metrics in planning decisions.

7. Design crisis communication for technical and non-technical stakeholders.

8. Evaluate ethical, legal, privacy and governance constraints.

9. Plan and assess tabletop, technical and operational resilience exercises.

10. Critically assess the limitations of forensic conclusions and recovery plans.

1. Foundations of Digital Forensics

1.1 Digital evidence

Digital evidence is information of potential value to an investigation that exists in digital form or is transmitted by a digital system. Examples include files, system logs, authentication records, email, browser artifacts, memory contents, cloud audit trails, mobile-device data, network captures, source-code repositories and records from operational technology.

Digital evidence differs from many physical forms of evidence in several ways:

• It can be copied exactly, but the original state may change rapidly.
• It is often distributed across endpoints, networks, cloud services and third parties.
• Timestamps may use different time zones, clock settings or synchronization states.
• Metadata can be as important as visible content.
• Encryption, deletion, virtualization and proprietary formats may restrict access.
• Large volumes require automated processing, but automated output still requires validation.

A useful distinction is between content, such as the text of an email, and metadata, such as its sender, routing information, creation time or access history. Evidence may also be direct, circumstantial, exculpatory or inculpatory. Investigators must preserve evidence that may weaken as well as support an initial hypothesis.

1.2 Investigation objectives and hypotheses

An investigation should begin with explicit questions rather than an assumption that a particular user or malware family is responsible. Typical questions include:

• What happened?
• When did it happen?
• Which assets, identities and data were affected?
• How did the activity begin and progress?
• Was the activity authorized, accidental or malicious?
• What controls failed or were bypassed?
• What actions are required to contain, recover and prevent recurrence?

Investigators should record initial hypotheses and the evidence that would support or contradict them. This reduces confirmation bias. For example, “an employee exfiltrated customer data” is a weak starting assumption unless alternative explanations—such as compromised credentials, automated synchronization or a software defect—are also considered.

1.3 The forensic process

Although terminology varies among organizations and jurisdictions, a defensible process commonly includes:

1. Preparation and authorization: define authority, scope, roles, tools, legal constraints and safety requirements.

2. Identification: locate relevant systems, accounts, data sources, witnesses and time periods.

3. Preservation: prevent alteration, document the state of systems and protect evidence from loss.

4. Collection or acquisition: obtain data using methods appropriate to the source and investigation purpose.

5. Examination: extract, normalize, filter and organize relevant information.

6. Analysis: interpret relationships, timelines, behavior and competing explanations.

7. Reporting: present methods, findings, limitations and supporting exhibits.

8. Review and closure: retain records, learn from the event and securely dispose of material when authorized.

The phases are iterative. New evidence may require a revised collection plan, and containment decisions may alter what evidence remains available. Emergency action is sometimes necessary before complete preservation; such action must be documented, justified and separated from later forensic analysis.

2. Forensic Readiness

Forensic readiness is the ability of an organization to collect and use evidence efficiently when an incident occurs. It does not mean recording everything forever. Excessive collection can increase cost, privacy exposure and legal risk. Readiness means identifying likely investigative needs and preparing proportionate sources, controls and procedures in advance.

2.1 Elements of a readiness program

A mature program normally includes:

• Governance: approved policies, authority to investigate, escalation thresholds and decision rights.
• Asset and data inventories: knowledge of systems, owners, dependencies, data classifications and retention periods.
• Logging strategy: defined events, fields, time precision, retention, access controls and monitoring coverage.
• Time synchronization: consistent use of authoritative time sources and documented handling of clock drift.
• Evidence procedures: acquisition, hashing, storage, transfer, access and disposal procedures.
• Trained personnel: investigators, system administrators, legal advisers, privacy specialists, communications staff and business owners.
• Supplier arrangements: contractual access to cloud logs, telecommunications records, managed-security data and incident assistance.
• Tool validation: testing of forensic tools against known datasets and recording tool versions.
• Exercises: periodic tests of collection, decision-making, communication and recovery.

A logging policy should connect events to investigative questions. Authentication logs may support identity and access analysis; endpoint telemetry may reveal process execution; DNS and proxy logs may help identify command-and-control activity; database audit logs may establish access to sensitive records. Logs should be protected against unauthorized modification, and access to them should itself be auditable.

2.2 Readiness trade-offs

Logging has financial, technical and legal costs. High-volume telemetry may overwhelm storage and analysts, while sparse logging may leave decisive gaps. Organizations should prioritize systems according to business criticality, threat exposure, regulatory obligations and the likely value of evidence. A risk-based approach is preferable to an assumption that every event must be retained at identical granularity.

Cloud environments require special planning. The customer may not control the underlying infrastructure, volatile memory or physical disks. Evidence may be obtained through provider APIs, audit services, snapshots, access logs and legal or contractual processes. Investigators must understand the provider’s retention period, timestamp conventions, tenant isolation and chain-of-custody capabilities.

3. Evidence Preservation and Integrity

3.1 First-response principles

The first responder should protect people and business-critical operations while minimizing unnecessary changes to potential evidence. Important actions include recording the time and identity of responders, photographing or documenting system state where appropriate, noting whether a device is powered on, isolating systems in a controlled manner and seeking specialist advice before volatile data is lost.

A powered-on system may contain valuable memory-resident evidence, encryption keys, active sessions and network connections. However, collecting live data changes the system. A powered-off device may preserve some storage contents but lose volatile evidence. There is no universal rule; the decision depends on the investigation, threat, safety implications, encryption state and available expertise.

3.2 Chain of custody

Chain of custody is the chronological record showing who had evidence, when, why, how it was transferred and what was done to it. A sound record normally identifies:

• a unique evidence identifier;
• source device, account or service;
• date, time and time zone;
• collector and authorizing person;
• acquisition method and tool version;
• storage location and access restrictions;
• integrity verification values;
• every transfer, analysis action and return or disposal decision.

Chain of custody does not prove that evidence is true. It supports confidence that the item presented is the item collected and that handling was controlled.

3.3 Hashing and forensic images

A cryptographic hash is a fixed-length value computed from data. If the data changes, a secure hash algorithm is expected to produce a different value with extremely high probability. Investigators may hash source media, forensic images, exported logs and reports. Hashing supports integrity verification; it does not establish authorship, intent or the meaning of a file.

A forensic image is a bit-level or otherwise justified representation of a storage source. Write blockers or equivalent controls may be used to prevent alteration during acquisition. The image should be verified after acquisition, and the original should be protected while analysis is performed on a working copy. Some sources, such as cloud records and live network traffic, cannot be captured as traditional physical images; their acquisition method and limitations must be documented instead.

4. Investigation Methods and Analysis

4.1 Source-oriented analysis

Different sources answer different questions:

• Endpoint artifacts: processes, persistence mechanisms, file activity, user logons and malware traces.
• Memory: running processes, injected code, network connections, credentials and encryption material.
• Network data: communications, data movement, scanning and command-and-control patterns.
• Identity systems: authentication, privilege changes, token use and impossible-travel indicators.
• Cloud and SaaS logs: administrative actions, object access, API calls and configuration changes.
• Application and database logs: transactions, queries, errors and data access.
• Human evidence: interviews, procedures, approvals and operational context.

No single source should automatically be treated as authoritative. A timestamp in an endpoint log may conflict with a centralized identity record. Correlation should account for clock differences, log delays, duplicated events and missing records.

4.2 Timeline reconstruction

Timeline analysis organizes events chronologically and links them to systems, identities and actions. A reliable timeline records the source and confidence of each event rather than presenting all timestamps as equally precise. Investigators should normalize time zones, preserve original timestamps, document transformations and identify gaps.

A timeline can reveal an attack sequence such as initial access, privilege escalation, discovery, lateral movement, collection, exfiltration and impact. It can also reveal benign explanations, such as scheduled administration or automated backup activity. Timeline evidence should therefore be interpreted with system knowledge and corroboration.

4.3 Root-cause analysis

Root-cause analysis seeks the conditions that allowed an event to occur or increase its impact. It should not stop at the last visible technical action. A useful analysis considers:

• immediate cause, such as exploitation of a vulnerable service;
• contributing causes, such as excessive privileges or weak segmentation;
• latent organizational conditions, such as unclear ownership, inadequate staffing or ineffective change control;
• failed or absent controls;
• detection and response delays;
• recovery weaknesses.

The “five whys” technique can help explore causal chains, but it should not be used mechanically. Complex incidents usually have multiple interacting causes. Fault-tree, barrier-analysis and causal-graph approaches can provide a more structured representation. Root cause is not necessarily one person’s error; blaming an individual can obscure systemic conditions and discourage accurate reporting.

4.4 Reporting and evidentiary reasoning

A forensic report should distinguish facts, interpretations and unresolved questions. It should describe scope, methods, sources, relevant findings, confidence, limitations and recommendations. Conclusions should be proportional to evidence. For example, “the account authenticated from the address at 02:14 UTC” is different from “the account owner performed the action.” The latter requires additional evidence about credential use, device control and possible compromise.

Reports should be reproducible where possible. Another competent investigator should understand how evidence was acquired and how conclusions were derived. Sensitive information should be minimized and distributed according to need and authority.

5. Incident Response, Business Continuity and Disaster Recovery

These disciplines overlap but are not identical.

• Incident response identifies, contains, eradicates and learns from a security incident.
• Business continuity management prepares the organization to maintain or restore prioritized products and services during disruption.
• Disaster recovery focuses particularly on restoring technology, information and infrastructure after a disruptive event.
• Crisis management coordinates strategic decisions, stakeholder communication and organizational legitimacy under severe uncertainty.

A continuity plan begins with a business impact analysis. The analysis identifies critical activities, dependencies, maximum tolerable disruption and consequences of unavailability, integrity loss or confidentiality breach. Recovery priorities should be based on business impact rather than solely on technical convenience.

5.1 Recovery objectives

The recovery time objective (RTO) is the targeted maximum duration within which a service or activity should be restored after disruption. The recovery point objective (RPO) is the targeted maximum age of data that the organization can accept losing, expressed as a time interval before the disruption.

If a system has an RPO of 15 minutes, the recovery design aims to limit data loss to approximately the most recent 15 minutes, subject to implementation and operational assumptions. RTO and RPO are objectives, not guarantees. They depend on backup completion, detection time, decision time, infrastructure availability, personnel and testing.

Other useful measures include:

• Mean time to detect (MTTD): average time from the occurrence or onset of an event to detection.
• Mean time to respond (MTTR): a term whose exact definition must be specified; it may mean time to begin response, contain an incident or restore service.
• Maximum tolerable downtime: the longest period a process can be unavailable before unacceptable consequences arise.
• Service recovery level: the capacity or functionality available after recovery.

Metrics must have clear start and end points. Otherwise, comparisons between teams or incidents are misleading.

5.2 Recovery strategies

Strategies include preventive controls, redundant infrastructure, offline or immutable backups, alternate processing facilities, manual workarounds, prioritized restoration and reciprocal arrangements. Backups are not sufficient unless they are protected from attackers, include necessary configurations and are periodically restored in a controlled test.

Cyber recovery requires caution. Restoring compromised systems without identifying persistence mechanisms can reintroduce the attacker. Recovery should include identity resets, vulnerability remediation, integrity checks, clean rebuilds where justified, heightened monitoring and a controlled return to service.

6. Crisis Communication and Governance

During a cyber crisis, communication is part of risk management. Poor communication can cause misinformation, regulatory breaches, reputational damage and unsafe operational decisions. A crisis communication plan should identify audiences, authorized spokespersons, approval processes, secure communication channels, escalation criteria and prepared holding statements.

Messages should be accurate, timely, comprehensible and appropriately bounded. Organizations should state what is known, what is being investigated, what actions recipients should take and when the next update will occur. They should avoid speculation, unsupported attribution and unnecessary technical detail. Internal staff need actionable guidance; regulators may require specific facts; customers may need information about exposure and protective measures; executives need decisions, impacts and options.

Legal and privacy teams should participate without turning every communication into delay. Notification duties vary by jurisdiction, sector, contract and type of data. Investigators should preserve confidentiality and privilege where applicable, but privilege must not be assumed merely because a lawyer is copied on an email.

7. Cyber Resilience Models and Testing

Cyber resilience is broader than prevention. A resilient organization can absorb disruption, continue essential functions, recover reliably and adapt based on learning. A practical capability model includes:

1. Anticipate: understand threats, dependencies, scenarios and failure modes.

2. Withstand: use protective architecture, segmentation, identity controls and redundancy.

3. Recover: restore trustworthy services and data according to prioritized objectives.

4. Adapt: improve architecture, policies, skills and assumptions after exercises or incidents.

Resilience testing should progress from low-risk discussion to realistic technical validation. Methods include tabletop exercises, walkthroughs, backup restoration tests, communication drills, red-team activities, failover tests, purple-team exercises and full operational simulations. Each test should define objectives, assumptions, success criteria, safety controls, observers and a process for tracking corrective actions.

A test that merely confirms that participants can follow a script provides limited assurance. Strong tests introduce uncertainty, conflicting information and realistic decision pressure while avoiding unnecessary operational harm. Results should be converted into assigned actions with owners, deadlines and verification evidence.

8. Illustrative Case: Ransomware in a Regional Hospital

Background

This fictional case concerns North Valley Hospital, a regional healthcare provider with an electronic medical-record system, imaging services, laboratory systems and administrative networks. The hospital had endpoint protection, centralized authentication and nightly backups. However, some clinical devices used legacy operating systems, network segmentation was incomplete and restoration procedures had not been tested for eighteen months.

Problem

At 06:40 on a weekday, clinicians reported that several workstations displayed ransom messages. The security team observed unusual authentication activity from a service account. Imaging access became intermittent, and an administrative file server was encrypted. Hospital leaders needed to protect patient safety, preserve evidence and maintain essential care.

Analysis and approach

The incident commander authorized network isolation of affected segments while clinical leaders activated downtime procedures. Responders documented system states and preserved volatile data from selected systems before shutdown. They acquired endpoint images from representative machines, exported identity and network logs, and requested cloud audit records from a service provider. Hashes and transfer records were maintained for each evidence item.

Timeline analysis showed that an exposed remote-access account had been used three days earlier. The attacker created a privileged account, moved laterally through a flat network segment and disabled backup agents before encryption. The initial assumption that a single phishing email caused the incident was not supported. Root-cause analysis identified several interacting causes: weak remote-access authentication, excessive service-account privilege, incomplete segmentation, inadequate monitoring of privileged-account creation and untested recovery procedures.

The hospital prioritized emergency care, medication administration and patient identification. It rebuilt compromised identity infrastructure from known-clean sources, reset credentials, blocked the remote-access pathway, segmented clinical systems and restored critical services from protected backups. Restoration occurred in stages, with integrity checks and enhanced monitoring. Communications to staff emphasized downtime procedures and prohibited unsanctioned reconnection of devices. External notifications were coordinated with legal and privacy officers.

Outcome

Emergency clinical services continued through manual procedures, although elective procedures were postponed. Core systems were restored after validation. The hospital did not claim certainty about the identity of the attacker because available evidence supported intrusion and encryption but not definitive attribution. A post-incident program introduced phishing-resistant authentication for privileged access, separate backup credentials, immutable backup copies, improved segmentation, centralized detection of privilege changes and quarterly recovery exercises.

Learning points

The case demonstrates that resilience is not equivalent to having backups. Evidence preservation must occur alongside containment. Business priorities must guide restoration. Root-cause analysis must examine architecture and governance rather than assigning blame to the first visible user. Finally, communication and clinical workarounds are operational controls, not merely public-relations activities.

9. Ethical, Legal and Professional Considerations

Investigators may encounter private communications, health information, employee records, credentials and data belonging to unrelated parties. Collection should be lawful, necessary, proportionate and limited to the authorized scope. Access should follow least privilege, and sensitive material should be encrypted and retained only as long as justified.

Cross-border investigations create jurisdictional and data-transfer issues. Cloud evidence may be stored in multiple countries, and provider access may require formal processes. Organizations should obtain appropriate advice before collecting personal devices, monitoring employees or transferring evidence internationally.

Professional integrity requires accurate reporting, disclosure of limitations, protection of exculpatory evidence and avoidance of unsupported attribution. AI-assisted tools can help classify artifacts, summarize logs and identify anomalies, but their outputs require validation. Investigators should preserve relevant prompts, model versions and input limitations when AI materially influences analysis. Confidential evidence should not be submitted to an unapproved external service. Automation can accelerate examination; it cannot replace accountable expert judgment.

10. Challenges and Limitations

Digital investigations face encryption, anti-forensic activity, missing logs, cloud dependency, immense data volumes, proprietary formats, volatile evidence and attacks against monitoring infrastructure. Attackers may manipulate timestamps, delete records or use legitimate administration tools. Conversely, normal automation can resemble malicious behavior.

Resilience programs also have limitations. Recovery objectives may be politically negotiated rather than technically tested. Exercises can become predictable. Backups may contain corrupted or malicious data. Metrics can reward rapid closure rather than trustworthy recovery. Supply-chain dependencies may remain outside direct organizational control.

These limitations require humility and layered assurance. Corroborate across independent sources, document uncertainty, repeat tests under varied conditions and update assumptions as technology and threats change.

Best-Practice Guidance

Organizations should:

• establish authority, roles and escalation paths before incidents;
• classify critical services and map technical and supplier dependencies;
• synchronize clocks and protect high-value logs;
• validate forensic tools and maintain controlled evidence storage;
• preserve evidence before unnecessary alteration while meeting safety needs;
• separate facts from interpretations in reports;
• use root-cause analysis to identify systemic control weaknesses;
• define RTO, RPO and metric boundaries explicitly;
• maintain protected, tested and recoverable backups;
• rehearse technical recovery and crisis communication together;
• involve legal, privacy, business and communications functions;
• treat AI outputs as assistive evidence requiring human validation; and
• track lessons to verified corrective action.

Chapter Summary

Digital forensics provides a structured means of discovering, preserving, analyzing and presenting digital evidence. Its reliability depends on authorization, appropriate acquisition, chain of custody, integrity verification, source correlation and transparent reporting. Forensic readiness prepares logging, personnel, contracts, tools and procedures before an incident.

Investigation should reconstruct events while testing alternative hypotheses and distinguishing facts from interpretations. Root-cause analysis extends beyond the immediate technical trigger to contributing controls, architecture and governance. Incident response, business continuity, disaster recovery and crisis management are related but distinct capabilities.

Cyber resilience integrates anticipation, protection, continuity, recovery and adaptation. RTO and RPO help translate business priorities into recovery objectives, but they require explicit definitions and practical testing. Crisis communication must be accurate, timely and coordinated. Ethical and legal duties require proportional collection, privacy protection, lawful authority and honest disclosure of uncertainty. Finally, resilience is demonstrated not by policy statements but by tested capability, verified recovery and implemented learning.

Key Terms

Digital forensics: The systematic examination and interpretation of digital evidence.

Digital evidence: Information in digital form that may support an investigation.

Forensic readiness: The ability to collect and use evidence efficiently and defensibly.

Chain of custody: A chronological record of evidence handling and transfers.

Cryptographic hash: A fixed-length value used to help verify data integrity.

Forensic image: A justified representation of data from a storage source.

Volatile evidence: Data that may disappear when a system changes state or loses power.

Timeline analysis: Reconstruction of events using ordered and correlated records.

Root-cause analysis: Systematic examination of immediate, contributing and latent causes.

Incident response: Activities to identify, contain, eradicate and learn from security incidents.

Business continuity: Capability to maintain prioritized activities during disruption.

Disaster recovery: Restoration of technology, data and infrastructure after disruption.

Recovery time objective: Target maximum time to restore a service or activity.

Recovery point objective: Target maximum acceptable age of data that may be lost.

Crisis communication: Coordinated communication during significant uncertainty or disruption.

Cyber resilience: Capability to anticipate, withstand, recover from and adapt to cyber events.

Tabletop exercise: Discussion-based test of plans, decisions and coordination.

Exculpatory evidence: Evidence that may reduce or disprove responsibility or liability.

Chain of evidence integrity: Confidence that evidence remained controlled and unaltered.

Maximum tolerable downtime: Longest acceptable period of process unavailability.

Review Questions

Short Answer Questions

1. What are the principal phases of a digital forensic investigation?

2. Why is chain of custody important, and what does it not prove?

3. Distinguish recovery time objective from recovery point objective.

4. Why should investigators record alternative hypotheses?

5. Name two ways in which cloud forensics differs from traditional disk forensics.

Long Answer Questions

1. Explain how an organization can design a forensic-readiness program, including logging, evidence storage, personnel and supplier arrangements.

2. Discuss the relationship and differences among incident response, business continuity, disaster recovery and crisis management.

3. Explain how timeline analysis and root-cause analysis contribute to a defensible investigation.

4. Evaluate the ethical, privacy and legal issues involved in collecting employee, cloud and cross-border digital evidence.

5. Design a cyber-resilience testing program that includes discussion-based, technical and recovery exercises.

Analytical / Application Questions

1. A company discovers that an administrator account was used to delete logs before a ransomware event. Propose an evidence-preservation and investigation strategy, identifying likely sources and limitations.

2. A payment service has an RTO of two hours and an RPO of ten minutes, but restoration tests take five hours and backups run hourly. Analyze the gaps and recommend priorities.

3. Using the hospital case, distinguish the immediate cause, contributing causes and latent organizational causes. Recommend three controls and explain how each should be tested.

Multiple Choice Questions with Answers

Question 1

Which activity most directly supports forensic readiness before an incident?

A. Deleting old logs to reduce storage costs

B. Defining relevant logging, retention and evidence-handling procedures

C. Allowing every employee to access forensic images

D. Waiting until an incident occurs to identify system owners

Correct Answer: B. Defining relevant logging, retention and evidence-handling procedures

Question 2

What is the primary purpose of maintaining a chain of custody?

A. To prove who committed the incident

B. To guarantee that a hash algorithm is collision-free

C. To document controlled possession and handling of evidence

D. To replace the need for investigator expertise

Correct Answer: C. To document controlled possession and handling of evidence

Question 3

Which statement best describes a recovery point objective?

A. The target time required to restore a service

B. The target maximum age of data that may be lost

C. The time required to detect an intrusion

D. The duration of a crisis communication meeting

Correct Answer: B. The target maximum age of data that may be lost

Question 4

Why should a forensic investigator preserve original timestamps when normalizing a timeline?

A. To conceal inconsistencies between systems

B. To allow later review of transformations and time assumptions

C. To ensure all events appear to occur simultaneously

D. To eliminate the need for corroborating evidence

Correct Answer: B. To allow later review of transformations and time assumptions

Question 5

Which conclusion is most appropriately worded for a forensic report?

A. The account owner definitely performed the action

B. The attacker was certainly a specific criminal group

C. The account authenticated from the recorded address at the stated time

D. The employee must be responsible because the password was used

Correct Answer: C. The account authenticated from the recorded address at the stated time

Question 6

Which capability is primarily associated with business continuity?

A. Maintaining prioritized business activities during disruption

B. Computing a hash of a forensic image

C. Extracting strings from volatile memory

D. Attributing malware to a threat actor

Correct Answer: A. Maintaining prioritized business activities during disruption

Question 7

A system has an RPO of 15 minutes. What does this objective primarily limit?

A. The maximum intended age of recoverable data loss

B. The number of investigators assigned to the case

C. The time required to notify regulators

D. The number of failed authentication attempts

Correct Answer: A. The maximum intended age of recoverable data loss

Question 8

Which approach best reflects sound root-cause analysis?

A. Blaming the first user whose account appears in the logs

B. Examining immediate, contributing and organizational conditions

C. Considering only the malware’s file name

D. Ignoring controls that did not directly fail

Correct Answer: B. Examining immediate, contributing and organizational conditions

Question 9

Why can live acquisition be valuable during a forensic investigation?

A. It guarantees that the system will not change

B. It may capture volatile data such as active sessions and memory

C. It eliminates the need for authorization

D. It always produces a physical disk image

Correct Answer: B. It may capture volatile data such as active sessions and memory

Question 10

Which is the strongest example of a resilience test?

A. Reading the recovery policy once

B. Checking that a backup file exists without restoring it

C. Restoring critical services from protected backups against defined objectives

D. Asking staff whether they believe recovery would work

Correct Answer: C. Restoring critical services from protected backups against defined objectives