Most applications ship with features and permissions that a given organisation never uses, and every one of them is a setting an attacker can switch on, abuse or quietly change. MITRE D3FEND names the countermeasure Application Configuration Hardening (D3-ACH) and defines it as "Modifying an application's configuration to reduce its attack surface." It sits under the Harden tactic as a child of Application Hardening, and has one child of its own, Disable Remote Access (D3-DRA). This card explains what D3-ACH covers, the ATT&CK techniques D3FEND relates to it, where the settings live, how to roll out and verify a hardened configuration, and where it stops. It is written for application owners, platform engineers and the teams that run configuration baselines. Where vendor settings are named as examples, vendors are listed alphabetically; the order is not a ranking.
Key takeaways
- Two levers. D3FEND's article names them: limit the permissions an application has, and disable application features that are vulnerable or unused.
- Environment counts too. D3FEND says hardening means analysing the environment the application runs in, not only the application, so service accounts, file permissions and network exposure are in scope.
- The ATT&CK links are about configuration tampering. D3FEND relates D3-ACH to techniques that modify application configuration: email forwarding rules, email hiding rules, Windows event log settings and command history settings.
- Start from a published baseline. D3FEND's own references are DISA STIGs; CIS Benchmarks and vendor security baselines serve the same purpose. Tailor them, do not invent settings from scratch.
- Hardening without drift detection decays. A setting applied once and never checked can be undone by an attacker, an upgrade or an administrator, so verification is part of the control.
D3-ACH at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ACH (d3f:ApplicationConfigurationHardening) |
| Tactic | Harden |
| Parent technique | Application Hardening |
| Child technique | Disable Remote Access (D3-DRA) |
| Digital artefact | Application Configuration (D3FEND relation: hardens; its child D3-DRA configures it). D3FEND defines it as "Information used to configure the parameters and initial settings for an application"; sub-types include Application Configuration File and Application Configuration Database Record |
| D3FEND references | Red Hat Enterprise Linux 8 STIG; Windows 10 STIG |
| Typical tooling | Configuration management and policy tools, SaaS and cloud posture tools, benchmark scanners |
What it hardens
The D3FEND artefact is broad: any information that sets an application's parameters, whether it lives in a file, a database record, the Windows registry or a SaaS admin console. In practice hardening work falls into five groups.
| Setting group | Examples (illustrative) | What it removes |
|---|---|---|
| Features and modules | Unused protocols, legacy authentication, scripting engines, sample apps, admin consoles on public interfaces | Code paths an attacker can reach |
| Permissions and identities | Service account rights, file and directory permissions, database grants, API scopes | What a compromised application can do |
| Remote and external access | Remote administration, external sharing, automatic external forwarding (the D3-DRA child covers remote access) | Paths for access and data to leave |
| Logging and audit | Audit logging on, retention, protection of log settings, command history | The attacker's ability to hide |
| Cryptography and session | TLS versions and ciphers, session timeouts, cookie flags | Downgrade and session abuse |
Where identity fits
The "limit the permissions" half of D3-ACH is largely about non-human identities: the service account an application runs as, the database login in its connection string and the API keys in its configuration file. Running an application under a dedicated low-privilege identity and keeping secrets out of plain-text configuration files are hardening settings in their own right; policy wording is in the Secure Configuration and Hardening Policy Template and the wider configuration practice in the NIST SP 800-128 Security-Focused Configuration Management Guide.
ATT&CK techniques D3FEND relates to D3-ACH
Relationship type: inferred only. D3FEND relates these techniques to D3-ACH because they modify, or may modify, Application Configuration, the artefact D3-ACH hardens. D3FEND labels such relations "inferred, experimental" (D3FEND 1.6.0, checked November 2026). Two of the techniques D3FEND lists are under IDs that ATT&CK v20 has revoked; the table shows their v20 successors. D3FEND also relates the artefact to four SPARTA space-segment techniques, which are outside the scope of this page.
| ATT&CK ID | Technique | Relation via artefact | Hardening setting that answers it |
|---|---|---|---|
| T1114.003 | Email Forwarding Rule | modifies Application Configuration | Block automatic external forwarding at tenant level; restrict by remote domain where some forwarding is needed |
| T1564.008 | Email Hiding Rules | modifies Application Configuration | Audit inbox rule creation; restrict rule actions that delete or move mail to obscure folders where the platform allows |
| T1685.001 | Disable or Modify Windows Event Log (v20 successor of the revoked Disable Windows Event Logging ID D3FEND lists) | may-modify Application Configuration | Enforce audit policy and log settings centrally so local changes are overwritten and alerted |
| T1690 | Prevent Command History Logging (v20 successor of the revoked Impair Command History Logging ID D3FEND lists) | Listed on the D3FEND site | Enforce shell history settings and forward command logging off the host |
The attacks themselves are covered in T1114 Email Collection Defensive Guide, MITRE ATT&CK T1564.008 Hide Artifacts and MITRE ATT&CK T1690 Prevent Command History Logging.
Worked examples from vendor documentation
- Google Workspace, automatic forwarding: in the Admin console under Apps, Google Workspace, Gmail, End User Access, clear "Allow users to automatically forward incoming email". It can be set per organisational unit and needs the Gmail Settings administrator privilege.
- Microsoft 365, automatic forwarding: in the outbound spam filter policy, set Automatic forwarding rules to "Off - Forwarding is disabled". Microsoft recommends choosing On or Off explicitly rather than leaving "Automatic - System-controlled", because its behaviour differs between organisations. When off, existing external forwarding inbox rules and mailbox forwarding stop working and senders get NDR 5.7.520. Where some forwarding is needed, Microsoft documents setting the policy On and blocking with remote domains or mail flow rules, since a block normally wins.
- PowerShell, command history: PSReadLine's
HistorySaveStyledefaults toSaveIncrementallyand writes toConsoleHost_history.txtunder the user's AppData on Windows. An attacker settingSaveNothingis exactly the T1690 behaviour, so history settings belong in the hardened baseline and command logging should also be collected centrally. PSReadLine'sAddToHistoryHandlerhas no default filter, so commands containing secrets are saved unless a handler is set.
Where it is implemented
| Implementation class | Covers | Notes |
|---|---|---|
| Published baselines | DISA STIGs, CIS Benchmarks, vendor security baselines | CIS describes its Benchmarks as consensus-based configuration recommendations, with Build Kits to apply them and CIS-CAT Pro to assess conformance; NIST's National Checklist Program repository indexes checklists by product and vendor |
| Configuration management and policy tools | Servers, endpoints, middleware | Group Policy, MDM profiles and desired-state tools apply settings and overwrite local changes |
| Infrastructure and configuration as code | Cloud services, containers, application config files | Settings reviewed in pull requests and tested before deployment |
| SaaS and cloud posture management | Tenant settings in SaaS and cloud platforms | Continuous comparison of live settings to a baseline |
| Benchmark scanners | Hosts and applications | SCAP-based scanners and benchmark tools report deviations |
Baseline sources are compared in the CIS Benchmarks Guide, the DISA STIG Guide and the Microsoft Security Baselines and Security Compliance Toolkit Guide.
Implementation steps
- Inventory applications and their configuration stores. For each application record where its settings live (files, registry, database, admin console) and who can change them.
- Choose a baseline per application. Use a STIG, CIS Benchmark or vendor baseline where one exists; for in-house applications write one from the vendor's security documentation. Record every deviation with a reason in a hardening exceptions register.
- Prioritise settings that map to observed attacks. External forwarding, audit logging and remote administration settings come first because attackers change them to collect data and hide.
- Test in audit or report-only mode. Run the baseline as a scan first and review what would change. Apply to a pilot group, then widen in rings.
- Enforce centrally. Deliver settings through policy or configuration as code, so local changes are overwritten and the source of truth is versioned.
- Plan rollback. Keep the previous configuration version so a setting that breaks a business process can be reverted for the affected group only, with an exception recorded rather than a fleet-wide rollback.
- Alert on change. Forward configuration change events for high-value settings (forwarding, logging, remote access) to the SIEM.
How to verify it works
- Scan against the baseline: run benchmark or posture scans on a schedule and track deviations per application.
- Test the control, not only the setting: for forwarding, create an external forwarding rule in a test mailbox and confirm the message is blocked; for logging, confirm a test event reaches the SIEM.
- Tamper test: change a hardened setting on a test host or tenant and confirm both that the change raises an alert and that enforcement reverts it.
- Review exceptions: confirm each exception still has an owner and an end date.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Applications with a named baseline | All internet-facing and business-critical applications | Coverage of the attack surface |
| Baseline conformance rate | Rising, with each failure explained | Shows drift and exceptions |
| Mean time to revert an unauthorised setting change | Hours, not days | Measures enforcement and alerting |
| Expired hardening exceptions | Zero | Exceptions are where weak settings hide |
| Mailboxes with active external forwarding outside the approved list | Zero | Direct check on T1114.003 |
Drift handling is covered in the Configuration Drift and Baseline Enforcement Guide, and a forwarding audit in How to Audit Mailbox Forwarding and Inbox Rules.
Limits, bypasses and failure patterns
- Settings that sit outside the baseline: a benchmark covers the settings its authors chose; a feature added in a later release can arrive enabled and unassessed. Review the baseline at each major upgrade.
- Admin rights defeat hardening: an attacker with application admin rights can change any setting. Hardening has to be paired with privileged access control and change alerting.
- Silent default behaviour: settings left on "automatic" or "system-controlled" can behave differently over time, as Microsoft notes for its forwarding control. Set security-relevant values explicitly.
- Configuration files that hold secrets: a hardened file with a plain-text database password is still a credential store. Move secrets to a secrets manager and restrict read access to the file.
- Exceptions that never close: one temporary exception per application quickly becomes the real baseline. Track them in a register such as the Hardening Exceptions and Compensating Controls Template.
- Hardening that breaks a process without warning: blocking forwarding without notice leads to emergency rollbacks. Communicate and pilot first.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-6 Configuration Settings | Establish and enforce secure configuration settings |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality | Disable unneeded functions, ports, protocols and services |
| NIST CSF 2.0 | PR.PS-01 | Configuration management practices are established and applied |
| CIS Controls v8.1 | Control 4 Secure Configuration of Enterprise Assets and Software | See CIS Control 4 Secure Configuration of Enterprise Assets and Software |
| ISO/IEC 27001:2022 | A.8.9 Configuration management | Documented, implemented, monitored and reviewed configurations |
| MITRE ATT&CK mitigations | M1054 Software Configuration; M1042 Disable or Remove Feature or Program | See M1054 Software Configuration and M1042 Disable or Remove Feature or Program |
Related countermeasures
- Disable Remote Access (D3-DRA): the child technique for one specific hardening setting; see D3-DRA Disable Remote Access.
- Other Application Hardening children: compile-time and runtime protections such as D3-SFCV Stack Frame Canary Validation and D3-PAN Pointer Authentication, which harden code rather than settings.
- The wider framework: see the MITRE D3FEND Guide.
Practitioner checklist
- Record each application's configuration stores and who can change them.
- Assign a STIG, CIS Benchmark or vendor baseline to every critical application.
- Disable automatic external email forwarding, with explicit exceptions only.
- Enforce audit logging and command history settings centrally and alert on change.
- Run each application under a dedicated low-privilege identity and keep secrets out of config files.
- Test new baselines in report-only mode and roll out in rings.
- Scan for drift on a schedule and run a tamper test each quarter.
- Keep an exceptions register with owners and end dates.
Standards and references
- MITRE D3FEND: Application Configuration Hardening (D3-ACH)
- NIST: National Checklist Program
- CIS: CIS Benchmarks
- Google Workspace Admin Help: Let users automatically forward their own Gmail emails
- Microsoft Learn: Control automatic external email forwarding
- Microsoft Learn: Set-PSReadLineOption
Related NHI Mgmt Group resources: CIS Benchmarks Guide · Configuration Drift and Baseline Enforcement Guide · M1054 Software Configuration · Secure Configuration and Hardening Policy Template · MITRE D3FEND Guide