3. DFIR Frameworks and Investigation Models

Introduction and Context

Digital forensics and incident response (DFIR) require more than technical skill. Investigators must decide what to do, when to do it, why a particular action is justified, and how the action will withstand managerial, legal, regulatory, and judicial scrutiny. A structured framework provides that discipline. It establishes a common vocabulary, assigns responsibilities, sequences activities, and helps an organization make defensible decisions under pressure.

No single framework answers every DFIR question. Lifecycle models such as those associated with NIST and ISO/IEC 27035 organize incident management; NIST Special Publication 800-86 provides a practical guide for integrating forensic techniques into incident response; RFC 3227 emphasizes the order and preservation of digital evidence; and MITRE ATT&CK provides a knowledge base for understanding adversary behaviour. These instruments are complementary rather than interchangeable.

A mature DFIR capability therefore uses frameworks as instruments of judgment. During preparation, an organization may use NIST or ISO/IEC guidance to define roles and procedures. During evidence collection, it may apply RFC 3227 principles and NIST SP 800-86 methods. During analysis, MITRE ATT&CK can help map observed activity to tactics and techniques. During recovery and lessons learned, the organization returns to its governance and improvement processes to reduce recurrence.

Learning Objectives

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

1. Explain the purpose and structure of major DFIR frameworks and investigation models.

2. Compare the NIST incident response lifecycle with ISO/IEC 27035.

3. Apply NIST SP 800-86 and RFC 3227 principles to forensic acquisition and evidence handling.

4. Use MITRE ATT&CK to interpret adversary behaviour and support investigative decisions.

5. Design an integrated workflow covering preparation, detection, analysis, containment, eradication, recovery, and lessons learned.

6. Evaluate limitations, governance requirements, ethical issues, and practical trade-offs in framework selection.

Why Frameworks Matter in DFIR

An incident is not merely a technical event. It is also a problem of evidence, risk, authority, communication, and business continuity. An analyst who immediately deletes malicious files may remove useful evidence. A responder who isolates every system may interrupt critical services unnecessarily. An investigator who collects evidence without documenting its provenance may produce material that cannot be trusted.

A framework reduces such risks by separating related but distinct concerns:

• Incident management concerns coordination, prioritization, communications, and business decisions.
• Digital forensics concerns the identification, acquisition, preservation, examination, and interpretation of evidence.
• Threat-informed analysis concerns understanding adversary objectives, behaviours, and likely next actions.
• Governance concerns authorization, accountability, legal compliance, and oversight.

Frameworks also support repeatability. Two analysts responding to similar incidents should not produce radically different processes merely because they have different personal preferences. At the same time, frameworks are not rigid scripts. The appropriate response to ransomware affecting a laboratory differs from the response to suspected employee data theft. Professional competence lies in adapting a model while preserving its underlying principles.

The Core Lifecycle of an Investigation

Although terminology varies, most DFIR models contain a recognizable sequence.

Preparation establishes capability before an incident occurs. It includes policies, asset inventories, logging, time synchronization, contact lists, evidence-handling procedures, forensic tools, training, exercises, and agreements with legal counsel and external providers. Preparation also includes defining authority: who may isolate a host, approve a shutdown, contact law enforcement, or notify a regulator?

Detection and reporting begin when a suspicious event is identified. Sources may include endpoint alerts, network monitoring, identity logs, user reports, threat intelligence, or third-party notification. Detection is not the same as confirmation. An alert is an indication requiring triage; an incident is an event that has been assessed against organizational criteria.

Analysis determines scope, impact, cause, affected assets, attacker access, persistence mechanisms, and data exposure. It combines volatile evidence, disk artefacts, network records, identity information, cloud telemetry, malware analysis, and interviews. Analysis is iterative: new evidence may revise the initial hypothesis.

Containment limits damage and prevents continued access. Short-term containment may involve isolating a host or disabling an account. Longer-term containment may involve network segmentation, blocking indicators, or moving services to a controlled environment. Containment decisions require a balance between evidence preservation, operational continuity, and safety.

Eradication removes the cause and mechanisms of compromise. This may include deleting persistence, resetting credentials, patching vulnerabilities, rebuilding systems, removing unauthorized accounts, and addressing misconfigurations. Eradication should not be declared merely because visible malware has disappeared.

Recovery restores systems and business services in a controlled manner. Systems should be validated, monitored, and returned to operation according to risk-based priorities. Recovery includes heightened monitoring because adversaries may retain access or attempt reinfection.

Lessons learned transforms an incident into organizational improvement. The review should examine technical causes, decision quality, communication, control effectiveness, supplier dependencies, and resource constraints. A useful review asks not only “What failed?” but also “Which assumptions were wrong, and what evidence would have exposed the problem earlier?”

These stages are not strictly linear. Detection may trigger immediate containment before analysis is complete. Recovery may reveal additional compromise. Lessons learned may identify a need to revise preparation. A lifecycle is therefore better understood as a controlled feedback system than as a one-way pipeline.

NIST Incident Response Guidance

NIST incident response guidance has historically presented four broad phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. This model is influential because it combines operational response with planning and improvement.

Preparation includes both general organizational readiness and incident-specific readiness. Examples include defining incident categories and severity levels, establishing an incident response team, preparing forensic workstations, retaining logs, and conducting exercises. The quality of preparation determines how much uncertainty responders face during a crisis.

Detection and analysis involve monitoring, alert validation, prioritization, initial scoping, and documentation. NIST emphasizes that organizations should distinguish events from incidents and should preserve relevant information while investigating. Analysis should consider the technical facts as well as mission impact, affected stakeholders, and reporting obligations.

Containment, eradication, and recovery are grouped because these activities are closely connected, but they remain conceptually distinct. Containment limits current harm; eradication eliminates the underlying presence or weakness; recovery restores trustworthy service. Combining them in one broad phase should not lead responders to skip validation between steps.

Post-incident activity includes reporting, evidence retention, cost assessment, response evaluation, and corrective action. A post-incident review that produces no assigned actions, owners, and deadlines is unlikely to create meaningful improvement.

NIST’s principal strength is its operational clarity. Its limitation is that broad guidance must be translated into organization-specific playbooks. It does not, by itself, provide a complete forensic examination method or a detailed adversary knowledge base.

ISO/IEC 27035 and the Management of Information Security Incidents

ISO/IEC 27035 presents incident management as an organizational capability linked to information security management. Its emphasis is not limited to technical response; it includes planning, responsibilities, communication, assessment, response, and learning within a management system.

The standard is commonly understood through activities such as preparation, detection and reporting, assessment and decision, responses, and lessons learned. Detection and reporting establish a controlled route for raising potential incidents. Assessment and decision determine whether an event is an incident, its severity, the response authority, and the resources required. Response activities are then coordinated according to the chosen strategy.

ISO/IEC 27035 is particularly useful where an organization needs formal governance, auditable processes, defined roles, and integration with an information security management system. It encourages organizations to establish policies, incident criteria, reporting mechanisms, competence requirements, and continual improvement.

Compared with a purely operational model, ISO/IEC 27035 places stronger emphasis on management accountability and organizational integration. NIST is often adopted as a practical response workflow, while ISO/IEC 27035 can provide a governance-oriented structure for policy, responsibility, and continual improvement. The two can be used together: ISO/IEC 27035 may define the management system, and NIST procedures may support day-to-day response.

NIST SP 800-86: Integrating Forensics with Incident Response

NIST SP 800-86 focuses on integrating forensic techniques into incident response. It organizes forensic work around four broad activities: collection, examination, analysis, and reporting.

Collection identifies and acquires potential evidence. Sources may include files, operating-system artefacts, network traffic, application records, databases, memory, mobile devices, cloud services, and removable media. Collection should be guided by the investigative question. Acquiring everything is often impossible, costly, and operationally disruptive.

Examination processes collected data to identify and extract relevant information. This may include recovering deleted files, parsing event logs, extracting browser history, examining registry or configuration data, decoding malware, or filtering large datasets. Examination should preserve the original evidence and clearly distinguish original data from derived results.

Analysis interprets the examined information. Investigators construct timelines, correlate events across systems, test competing hypotheses, identify user or process actions, and estimate scope and impact. A timestamp alone rarely proves causation; it must be interpreted with time zones, clock drift, logging behaviour, and related evidence.

Reporting communicates methods, findings, limitations, and conclusions. A sound report states what was examined, how it was handled, what was found, what was not found, and how confident the investigator is. It should distinguish facts, interpretations, assumptions, and unresolved questions.

The value of SP 800-86 lies in connecting forensic discipline to operational response. It reminds responders that evidence collection is not an isolated laboratory activity but part of decision-making during an incident.

RFC 3227 and the Order of Volatility

RFC 3227, commonly cited as a guide for evidence collection and archiving, emphasizes principles for handling digital evidence. A central idea is the order of volatility: collect evidence that is most likely to disappear before evidence that is more persistent.

Volatile evidence may include CPU state, running processes, network connections, memory contents, temporary data, and certain session information. Less volatile evidence may include filesystems, system configuration, application logs, backup media, and printed records. The exact order depends on the system and the investigative objective; volatility is a guide, not an automatic command.

RFC 3227 also emphasizes documentation, minimizing changes to evidence, working from copies where possible, maintaining a chain of custody, and recording the identity of persons who handle evidence. Investigators should document time, location, system condition, tools, commands, collection decisions, storage media, and transfers.

The tension between volatility and operational safety is important. Capturing memory from a compromised server may preserve valuable evidence but alter system state. Delaying isolation may preserve network observations but permit data destruction. Such choices should be authorized, documented, and proportionate to risk.

MITRE ATT&CK as a Threat-Informed Investigation Model

MITRE ATT&CK is a knowledge base of adversary tactics, techniques, and procedures. It is not a complete incident response lifecycle, nor does it replace evidence-handling standards. Its contribution is behavioural interpretation.

Tactics represent adversary objectives, such as obtaining initial access, achieving persistence, escalating privileges, moving laterally, collecting information, or exfiltrating data. Techniques describe ways in which those objectives may be achieved. Procedures are concrete examples of how a technique may appear in practice.

During an investigation, ATT&CK can help analysts organize observations. For example, a suspicious scheduled task may indicate a persistence technique; use of remote services may suggest lateral movement; unusual archive creation may relate to collection or preparation for exfiltration. Mapping should be evidence-based. An analyst should not label activity solely because it resembles a technique; the available artefacts must support the interpretation.

ATT&CK supports detection engineering, threat hunting, reporting, gap assessment, and communication between technical and managerial teams. A coverage matrix may reveal that an organization has strong detection for credential access but weak visibility into cloud persistence. ATT&CK can also support prioritization by connecting observed behaviour to likely next steps.

Its limitations are equally important. ATT&CK is descriptive rather than prescriptive. A technique mapping does not establish attribution, intent, or legal responsibility. The framework evolves, may contain overlapping interpretations, and cannot represent every environment equally. It should therefore be used alongside organizational evidence and lifecycle models.

Integrating the Frameworks

The frameworks can be integrated through a single investigation workflow:

1. Prepare: Use NIST and ISO/IEC 27035 to define governance, roles, readiness, escalation, and improvement processes.

2. Detect and assess: Apply incident criteria, triage alerts, preserve initial observations, and determine severity and authority.

3. Collect: Use SP 800-86 and RFC 3227 principles to identify evidence sources, prioritize volatile data, document actions, and preserve integrity.

4. Analyze: Correlate evidence, build timelines, test hypotheses, and use ATT&CK to describe observed behaviours.

5. Contain: Select actions that limit harm while considering evidence preservation, service availability, and attacker adaptation.

6. Eradicate and recover: Remove persistence and weaknesses, rebuild or restore systems, validate trust, and monitor for recurrence.

7. Learn: Conduct a governed review, update controls and playbooks, improve ATT&CK detection coverage, and track corrective actions.

The integrated model prevents a common error: treating frameworks as competing checklists. Each answers a different question. NIST and ISO/IEC 27035 ask how the organization manages the incident. SP 800-86 asks how forensic work is performed. RFC 3227 asks how evidence is preserved. ATT&CK asks what adversary behaviour the evidence may represent.

Applied Scenario: A Suspected Cloud Account Compromise

Background

This illustrative case concerns a university research organization using cloud identity services, collaboration platforms, and virtual servers. The security operations team receives an alert that a privileged account authenticated from an unusual location and subsequently accessed storage containing research data.

Situation and Initial Assessment

The alert is initially an event, not yet a confirmed incident. The responder records the alert, preserves identity logs, checks whether multifactor authentication was used, and contacts the account owner through a trusted channel. The account owner denies the activity. Under the organization’s incident criteria, the event becomes a high-severity incident because a privileged identity and sensitive data are involved.

Framework-Based Analysis

The incident manager uses the organization’s NIST- and ISO-aligned process to assign roles, notify legal and management stakeholders, and establish an incident record. The forensic analyst follows SP 800-86 by collecting identity-provider logs, access tokens, cloud audit records, endpoint evidence from the account owner’s device, and relevant storage access records.

RFC 3227 principles influence the order of collection. Active sessions, token information, and volatile endpoint data are captured before systems are reimaged or sessions expire. Hashes, timestamps, collectors, and storage locations are recorded. Access to evidence is restricted and logged.

The analysis shows that the attacker first obtained access through a stolen session token, registered a new authentication method, created a forwarding rule, and accessed several files. These observations are mapped cautiously to ATT&CK techniques involving valid accounts, additional cloud credentials or authentication mechanisms, collection, and possible exfiltration. The mapping helps the team search for similar activity in other accounts but is not treated as proof of attribution.

Containment, Eradication, and Recovery

The team revokes active sessions and tokens, disables the compromised account temporarily, removes the unauthorized authentication method, and blocks the forwarding rule. Before deleting relevant cloud objects, investigators preserve records needed for examination. They then review privileged accounts for similar changes, rotate credentials, strengthen conditional-access policies, and search for persistence.

Recovery occurs in stages. The account is restored only after verification, enhanced monitoring is enabled, and affected data owners are consulted. Legal and privacy specialists assess notification duties based on the type and location of data involved.

Outcome and Learning Points

The investigation concludes that unauthorized access occurred, but the available evidence does not establish that all accessed files were downloaded. The report distinguishes confirmed access from unproven exfiltration. Corrective actions include improved token monitoring, alerts for new authentication methods, shorter session lifetimes for privileged accounts, clearer cloud evidence-retention settings, and an exercise focused on identity compromise.

The case demonstrates why no single framework is sufficient. Lifecycle guidance coordinated the response; forensic guidance structured evidence work; volatility principles protected transient evidence; and ATT&CK helped organize behavioural hypotheses and detection gaps.

Challenges and Common Mistakes

One frequent mistake is confusing speed with effectiveness. Rapid action is important, but undocumented or irreversible action may destroy evidence and obscure the root cause. A second mistake is collecting large volumes of data without defining investigative questions. More data can increase noise, privacy exposure, and analytical delay.

Another challenge is incomplete visibility. Cloud services, managed endpoints, encrypted communications, and third-party platforms may limit investigator access. Retention settings may be inadequate, and logs may use different time zones or identifiers. Attribution is also difficult: tools and infrastructure can be shared, compromised, or deliberately imitated.

Organizations commonly declare eradication too early, rebuild one machine while leaving an attacker’s identity access intact, or restore systems from unverified backups. They may also over-map activity to ATT&CK, treating a technique label as a conclusion rather than an analytical aid.

Frameworks have limitations. They may be interpreted as bureaucratic checklists, may not reflect small-team realities, and may lag behind new technologies. Effective implementation requires tailoring, exercises, metrics, and professional judgment.

Governance, Ethics, and Legal Considerations

DFIR activities should have a lawful and documented basis. Investigators must understand authorization boundaries, privacy obligations, employment rules, contractual restrictions, sector requirements, and potential litigation holds. Evidence from personal devices, employee communications, or cross-border cloud services can create significant legal and ethical issues.

The principle of proportionality is central. Collection should be relevant to the investigative purpose and limited where possible. Access to sensitive evidence should follow least privilege. Reports should avoid unsupported allegations and should clearly identify uncertainty. If law enforcement involvement is considered, the organization should preserve evidence and coordinate disclosure decisions with appropriate legal authorities.

Governance also includes independence and conflict management. An investigator responsible for a failed control may not be the only person evaluating the response. Major decisions should be documented with their rationale, approver, time, expected effect, and review point.

Technology, Automation, and Emerging Practice

Modern DFIR increasingly depends on centralized security information and event management, endpoint detection and response, cloud-native audit services, forensic platforms, and automation. Automation can enrich alerts, preserve logs, revoke tokens, isolate endpoints, and generate preliminary ATT&CK mappings. These capabilities reduce response time but do not eliminate the need for human validation.

Artificial intelligence may assist with timeline construction, anomaly detection, malware classification, report drafting, and natural-language search across evidence. Its outputs remain hypotheses. Analysts must verify source data, record the model or tool used, assess false positives, and prevent sensitive evidence from being exposed to unauthorized services. A generated explanation is not a substitute for provenance or expert reasoning.

Emerging practice is moving toward identity-centric detection, cloud and container forensics, software supply-chain investigations, and continuous threat-informed control validation. Organizations increasingly measure not only whether an incident was closed, but also time to detect, time to contain, evidence completeness, recurrence rate, control coverage, and the proportion of lessons learned that become verified improvements.

Best Practices for Applying DFIR Models

A defensible program should:

• tailor framework language to local roles, technologies, and legal conditions;
• maintain current asset, identity, data, and dependency inventories;
• define evidence-handling procedures before an incident occurs;
• preserve volatile evidence when justified and document deviations;
• separate facts, interpretations, assumptions, and confidence levels;
• use ATT&CK to improve detection and hunting rather than to assert attribution;
• exercise both technical responders and decision-makers;
• preserve cloud logs and confirm retention before an incident;
• assign owners and deadlines to lessons-learned actions; and
• test whether corrective actions actually reduce risk.

Chapter Summary

DFIR frameworks provide structure for decisions involving people, technology, evidence, and organizational risk. NIST offers a practical incident response lifecycle; ISO/IEC 27035 places incident management within governance and continual improvement; NIST SP 800-86 organizes forensic work into collection, examination, analysis, and reporting; RFC 3227 emphasizes volatility, documentation, and preservation; and MITRE ATT&CK supplies a threat-informed language for interpreting adversary behaviour. Their greatest value appears when they are integrated rather than used in isolation. Effective practitioners adapt the models to context while preserving authorization, evidence integrity, proportionality, analytical discipline, and continuous learning.

Key Terms

Digital forensics: The disciplined identification, preservation, examination, analysis, and reporting of digital evidence.

Incident response: Coordinated activity to detect, assess, contain, eradicate, and recover from security incidents.

Event: An observable occurrence in a system, network, application, or process that may or may not represent an incident.

Preparation: Readiness activities performed before an incident, including policies, tools, training, and role definition.

Containment: Actions intended to limit the spread, impact, or persistence of an incident.

Eradication: Removal of malicious presence, persistence, unauthorized access, and exploited weaknesses.

Recovery: Restoration and validation of affected systems and services.

Lessons learned: A structured review used to improve controls, processes, and future response.

Chain of custody: The documented history of evidence possession, handling, transfer, and storage.

Order of volatility: A principle prioritizing collection of evidence that is most likely to disappear.

Forensic acquisition: The controlled collection of data from a digital source for examination.

Evidence integrity: Confidence that evidence has not been improperly altered or corrupted.

NIST SP 800-86: Guidance for integrating forensic techniques into incident response.

ISO/IEC 27035: A standard for information security incident management and organizational improvement.

MITRE ATT&CK: A knowledge base describing adversary tactics, techniques, and procedures.

Tactic: An adversary objective represented in the ATT&CK knowledge base.

Technique: A method used by an adversary to achieve a tactical objective.

Volatile evidence: Digital information that can change or disappear quickly, such as memory or active sessions.

Threat hunting: Proactive searching for evidence of adversary activity that may have evaded automated detection.

Review Questions

Short Answer Questions

1. Why is a DFIR lifecycle considered iterative rather than strictly linear?

2. Distinguish an event from a confirmed incident.

3. What is the purpose of the order of volatility?

4. How does NIST SP 800-86 structure forensic work?

5. Why should ATT&CK not be treated as an attribution framework?

Long Answer Questions

1. Compare the NIST incident response lifecycle with ISO/IEC 27035 in terms of purpose, emphasis, and organizational use.

2. Explain how collection, examination, analysis, and reporting should be connected during a forensic investigation.

3. Discuss the relationship between containment, eradication, and recovery, including the risks of confusing them.

4. Describe how RFC 3227 principles can affect the handling of evidence during a live incident.

5. Develop an integrated DFIR process using NIST, ISO/IEC 27035, NIST SP 800-86, RFC 3227, and MITRE ATT&CK.

Analytical / Application Questions

1. A responder wants to immediately reimage a compromised server before collecting memory or documenting its state. Evaluate the decision using volatility, operational risk, and evidence-preservation principles.

2. An organization has strong endpoint alerts but cannot determine whether cloud accounts are being used for persistence. Design a framework-based improvement plan.

3. During an investigation, analysts map several observations to ATT&CK but have conflicting timestamps and incomplete logs. Explain how they should communicate conclusions and uncertainty.

22. Multiple Choice Questions with Answers

Question 1

Which framework is most directly concerned with integrating forensic collection, examination, analysis, and reporting into incident response?

A. NIST SP 800-86

B. MITRE ATT&CK

C. RFC 3227

D. ISO/IEC 27035

Correct Answer: A. NIST SP 800-86

Question 2

A responder captures active network connections and memory before collecting a disk image. Which principle primarily explains this order?

A. Least privilege

B. Order of volatility

C. Defence in depth

D. Separation of duties

Correct Answer: B. Order of volatility

Question 3

Which statement best describes MITRE ATT&CK?

A. A legal standard for evidence admissibility

B. A hardware acquisition procedure

C. A knowledge base of adversary tactics and techniques

D. A replacement for incident response governance

Correct Answer: C. A knowledge base of adversary tactics and techniques

Question 4

Under a lifecycle model, disabling a compromised account to stop ongoing misuse is primarily an example of:

A. Preparation

B. Containment

C. Lessons learned

D. Forensic reporting

Correct Answer: B. Containment

Question 5

Which activity most clearly belongs to eradication rather than containment?

A. Blocking an attacker’s IP address temporarily

B. Isolating a workstation from the network

C. Removing persistence and patching the exploited weakness

D. Prioritizing the incident for executive review

Correct Answer: C. Removing persistence and patching the exploited weakness

Question 6

What is the principal governance emphasis of ISO/IEC 27035 in comparison with a narrowly technical response procedure?

A. It excludes post-incident improvement

B. It integrates incident management with organizational responsibilities and continual improvement

C. It provides only malware reverse-engineering instructions

D. It replaces the need for incident classification

Correct Answer: B. It integrates incident management with organizational responsibilities and continual improvement

Question 7

An ATT&CK technique mapping should be treated primarily as:

A. A confirmed identification of the attacker

B. A behavioural interpretation supported by evidence

C. A substitute for collecting logs

D. A legal conclusion about responsibility

Correct Answer: B. A behavioural interpretation supported by evidence

Question 8

Which report practice is most forensically defensible?

A. Presenting assumptions as established facts

B. Reporting only successful findings

C. Distinguishing facts, interpretations, limitations, and confidence

D. Deleting contradictory evidence from the case file

Correct Answer: C. Distinguishing facts, interpretations, limitations, and confidence

Question 9

A cloud investigation may fail even when the response team is technically capable if the organization has not:

A. Used a single framework exclusively

B. Configured adequate log retention and access to cloud audit records

C. Mapped every alert to attribution

D. Avoided all automated actions

Correct Answer: B. Configured adequate log retention and access to cloud audit records

Question 10

What is the best reason to integrate several DFIR frameworks rather than select one as universally sufficient?

A. Each framework addresses different management, forensic, preservation, or behavioural questions

B. Using several frameworks guarantees attribution

C. Frameworks eliminate the need for professional judgment

D. Multiple frameworks make evidence collection unnecessary

Correct Answer: A. Each framework addresses different management, forensic, preservation, or behavioural questions