Reconnecting a contained host too early hands the attacker back the foothold the isolation took away. D3-RNA Restore Network Access is the MITRE D3FEND countermeasure for the end of containment: D3FEND defines it as restoring an entity's access to a computer network, places it in the Restore tactic under Restore Access (D3-RA), and cites CISA's Cybersecurity Incident and Vulnerability Response Playbooks as its reference. D3FEND gives no implementation article for it, so this card is short and practical: what must be true before a host goes back on the network, how to reconnect in stages, how to verify the restore and what goes wrong. It is written for incident responders, network and endpoint engineers. Sibling techniques under Restore Access are Restore User Account Access (D3-RUAA) and Reissue Credential (D3-RIC).
Key takeaways
- D3-RNA reverses isolation. It is the deliberate return of network access to a host that was contained, quarantined, rebuilt or replaced during an incident.
- Restore only after eradication is proven. CISA's playbook places reconnection in recovery, after persistence has been ruled out and passwords reset, and asks for tightened perimeter rules and enhanced monitoring when systems come back.
- Restore in stages, not in one switch. Management and security tooling first, then dependencies, then users, with a rollback to isolation ready at each step.
- D3FEND's ATT&CK links are inferred from the Host artefact. Directly, three cloud techniques that create, delete or revert instances (T1578.002, T1578.003, T1578.004).
- Machine credentials on the host decide the risk. A reconnected host still holding old service account passwords, API keys or certificates reopens the path; reissue them first.
D3-RNA at a glance
| Field | D3-RNA Restore Network Access |
|---|---|
| D3FEND ID | D3-RNA |
| Tactic | Restore |
| Parent technique | Restore Access (D3-RA): "Restoring an entity's access to resources" |
| Siblings | Restore User Account Access (D3-RUAA), Reissue Credential (D3-RIC) |
| Digital artefact | Host (D3FEND: the technique "restores" a Host) |
| D3FEND reference | CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021) |
| Reverses | Isolate-tactic actions such as network isolation of a host, EDR network containment, quarantine VLANs and disabled switch ports or cloud security group lockdowns |
| Main risk | Reconnecting before persistence and credentials are dealt with |
What CISA's playbook says about reconnecting
D3FEND's single reference for D3-RNA is CISA's federal incident response playbook. Its sequence sets the conditions for this technique:
- Containment: isolate affected systems and network segments from each other and from unaffected systems, and change administrator passwords, rotate keys and revoke privileged access where compromise is suspected.
- Eradication: account for all persistent access paths before eradication, reset passwords on compromised accounts, and allow time to confirm no persistence remains, since adversaries often use more than one mechanism. The playbook calls this "often an iterative process".
- Recovery: reconnect rebuilt or new systems to networks, tighten perimeter security such as firewall rulesets and zero trust access rules, test systems including their security controls, and monitor with "enhanced vigilance". It suggests an independent test or review to confirm normal operations.
D3-RNA is therefore a recovery step with entry criteria, not a toggle. For the wider sequence see the Incident Scoping and Containment Strategy Guide and the Ransomware Response and Recovery Guide.
ATT&CK techniques D3FEND relates to D3-RNA
Relationship type: inferred only. D3FEND relates D3-RNA to ATT&CK because both act on the Host artefact, and states that these mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026). Restoring access does not stop these techniques; the relation means they act on the same object, so they belong in the pre-restore checks.
| ATT&CK ID | Technique | D3FEND relation | Why it matters before reconnecting (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1578.002 | Create Cloud Instance | Creates Host | Confirm that no attacker-created instances are about to be reattached to production networks with the legitimate ones |
| T1578.003 | Delete Cloud Instance | Deletes Host | Instances deleted to remove evidence change what you are restoring; rebuild from known-good images rather than guessing |
| T1578.004 | Revert Cloud Instance | Modifies Host | A reverted instance may not be the clean state you think it is; verify the snapshot's provenance and date before reconnecting |
The D3FEND page also lists T1505.002 Transport Agent, T1505.003 Web Shell and T1114.002 Remote Email Collection, which it relates through sub-types of Host such as servers. These are practical pre-restore checks for mail and web servers: hunt for web shells and unauthorised transport agents before the server goes back online. All IDs were checked against ATT&CK v20. See MITRE ATT&CK T1578 Modify Cloud Compute Infrastructure.
Where it is implemented
| Isolation mechanism | How access is restored | Staged option | Evidence to keep |
|---|---|---|---|
| EDR network containment | Release from containment in the EDR console or API | Keep the host contained while scanning and collecting through the agent, where the tool supports it | Who released, when, and the scan result that justified it |
| Quarantine VLAN or NAC posture | Move the port or device back to its production VLAN or role | Remediation VLAN with access only to patching and management services | NAC decision logs and posture result |
| Switch port or wireless disablement | Re-enable the port or client | Re-enable with an ACL limiting destinations | Change ticket and configuration diff |
| Cloud security group or network ACL lockdown | Reattach the production security groups or remove the deny rules | Allow only the load balancer or bastion first | Cloud control-plane log of the change |
| Host firewall isolation | Remove the isolation rule set | Allow outbound to management and logging only | Firewall policy change record |
| Rebuilt or replacement host | Join a new host built from a known-good image | Build in an isolated staging segment, then promote | Image version and build record |
Product categories are examples, not recommendations. Restoration should use the same tool that isolated the host, so the containment and release are recorded in one place.
Where identity fits
Hosts carry machine identities: computer accounts, service account passwords in service configurations, API keys and tokens in files and environment variables, client certificates and cloud instance roles. If the attacker read any of these while the host was compromised, reconnecting the host, or a rebuilt one restored from backup with the same secrets, lets the attacker use them again from anywhere. Before restore, reissue the credentials the host held and confirm dependants have the new ones. See D3-CR Credential Revocation, D3-CRO Credential Rotation and Recovering IAM and PAM After Ransomware or Domain Compromise.
Implementation steps
- Define restore criteria before the incident. Write down who may approve reconnection, the evidence required (scan clean, persistence hunt complete, credentials reissued, patches applied) and how long the host stays under enhanced monitoring.
- Preserve evidence first. Capture memory, disk and logs needed for the investigation before rebuilding or reconnecting; once a host is back in service its state changes quickly.
- Rebuild or clean, then check. Prefer a rebuild from a known-good image for servers with confirmed compromise; run the persistence hunt (scheduled tasks, services, startup items, web shells, transport agents) on anything cleaned in place.
- Reissue host credentials. Reset the computer account, rotate service account passwords and keys stored on the host, and replace certificates whose private keys were on it.
- Reconnect in stages. Stage 1, management, EDR and logging only. Stage 2, required dependencies such as directory, DNS and databases. Stage 3, user or internet traffic. Hold each stage long enough to see normal and abnormal behaviour (the period is a local decision).
- Tighten the rules on the way back. Apply the firewall and access rule improvements identified during the incident at reconnection, as CISA's playbook recommends, rather than restoring the old rule set.
- Keep rollback ready. The rollback is re-isolation through the same tool. Make sure responders can isolate the host again in minutes if indicators return.
How to verify the restore
- Telemetry check: before user traffic is allowed, confirm the EDR agent is healthy and the host's logs are reaching the SIEM.
- Destination check: compare the host's outbound connections in the first hours with its pre-incident baseline; any new external destination needs an explanation.
- Credential check: confirm old credentials for the host's service accounts and keys fail, and that authentication events show only the new ones.
- Function check: confirm applications work as expected, as CISA's recovery phase requires, so pressure to bypass controls does not build.
- Independent review: for significant incidents, have someone outside the response team confirm the restore criteria were met.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Restores with all documented criteria met before reconnection | Discipline of the restore process | 100% |
| Hosts re-isolated within 30 days of restore | Restores done too early or eradication incomplete | Falling |
| Restored hosts with credentials reissued before reconnection | Machine identity hygiene | 100% |
| Time from approval to full restore by stage | Recovery speed without skipping stages | Stable or falling |
| Restored hosts reporting to EDR and SIEM before stage 2 | Visibility before exposure | 100% |
Limits and failure patterns
- Business pressure skips stages: the host goes straight from isolated to fully connected because a service is down. Agree stage criteria in advance so they are not negotiated during the outage.
- Restoring from an infected backup: the image or snapshot predates eradication but not the intrusion. Check the backup date against the earliest known attacker activity.
- Credentials left unchanged: the host is clean but the keys it held are with the attacker. Reissue before reconnecting.
- Restoring the old rules: the firewall or security group that allowed the intrusion is reapplied unchanged.
- Losing the isolation record: restores made outside the containment tool leave no trail of who reconnected what and why.
- Reconnecting one host while siblings remain compromised: scoping was incomplete and the restored host is reinfected over the network.
Framework mapping
| Framework | Reference | Relationship to D3-RNA |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Containment, eradication and recovery as a sequence |
| NIST SP 800-53 Rev 5 | CP-10 System Recovery and Reconstitution | Returning systems to a known state |
| NIST CSF 2.0 | Recover function (RC) | Restoring assets and operations after an incident |
| NIST SP 800-61 Rev. 3 | Incident response as a CSF 2.0 Community Profile (April 2025) | Current NIST incident response recommendations |
D3FEND cites only the CISA playbook for D3-RNA; the NIST rows are NHI Mgmt Group's mapping by intent.
Practitioner checklist
- Document restore criteria and approvers in the incident response plan.
- Preserve evidence before rebuild or reconnection.
- Rebuild confirmed-compromised servers from known-good images.
- Hunt for persistence, including web shells and transport agents on servers.
- Reissue every credential, key and certificate the host held.
- Reconnect in stages: management and security tooling, dependencies, then users.
- Apply improved network rules at reconnection, not the old rule set.
- Keep re-isolation ready and monitor restored hosts against baseline.
Standards and references
- MITRE D3FEND: Restore Network Access (D3-RNA)
- MITRE D3FEND: Restore Access (D3-RA)
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks (D3FEND reference)
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1578 Modify Cloud Compute Infrastructure
Related NHI Mgmt Group resources: Incident Scoping and Containment Strategy Guide · Ransomware Response and Recovery Guide · D3-RUAA Restore User Account Access · MITRE D3FEND Guide