A.5.14 Organizational
Information transfer
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (27)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- AC-17mostlyaligns with — Both controls establish rules, authentication, and protective measures for information exchanged over external or remote connections.
- AC-21mostlyaligns with — Both controls require agreements and controls that govern how and with whom sensitive information may be shared or transferred.
- MP-5mostlyaligns with — Both controls mandate accountability, chain-of-custody, and protection measures when physical media containing information are transported.
- SC-8mostlyaligns with — Both controls require cryptographic and procedural safeguards to protect information confidentiality and integrity while it moves between systems or organizations.
- SC-8mostlycovers — A.5.14's broad requirement to secure all forms of information transfer (including confidentiality and integrity protections) accounts for the bulk of SC-8's transmission protection mandate, but leaves a residual on the target's explicit parameter-driven selection of exactly which properties (confidentiality, integrity, or both) must be protected for each transmission type.
- AU-10partialaligns with — Both controls emphasize non-repudiation and traceability to ensure accountability for information while it is in transit.
- CA-3partialaligns with — Both controls require formal agreements that define security responsibilities and protections when information is exchanged with external parties.
- MP-5partialcovers — A.5.14's broad requirements for securing all forms of information transfer (including policies, procedures, and controls for physical/digital media) address a slice of MP-5's specific media-transport protections, accountability, documentation, and authorization rules, but the bulk of MP-5's detailed, media-focused obligations sit outside A.5.14's general transfer scope.
- SC-7partialaligns with — Both controls apply boundary and flow protections to prevent unauthorized interception or misrouting of information leaving organizational control.
- SC-7partialcovers — A.5.14's broad requirement to secure all information transfers (internal and external) is only partially accounted for by SC-7's narrower focus on boundary monitoring, subnetwork separation, and managed external interfaces; many transfer protections (e.g., encryption, labeling, agreements) sit outside SC-7.
- AC-17covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- AU-10covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- CA-3implements — CA-3 directly operationalizes the information-transfer security requirements that A.5.14 names as its core purpose, including approval, documented interface/security responsibilities, and ongoing review.
Aligned NIST CSF 2.0 outcomes (22)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- GV.SC-05mostlyaligns with — Mandating transfer agreements with third parties that define responsibilities, liabilities, and protection measures fulfills the CSF outcome of integrating cybersecurity requirements into supplier and partner contracts.
- PR.DS-02mostlycovers — The ISO control's rules and agreements for protecting information during electronic, physical, and verbal transfer directly implement the CSF outcome of safeguarding data-in-transit confidentiality, integrity, and availability.
- PR.IR-01mostlyaligns with — By requiring controls against interception, misrouting, and unauthorized access during transfer, the ISO guidance achieves the CSF outcome of protecting networks and environments from unauthorized logical access and usage.
- ID.RA-07partialaligns with — By requiring consideration of legal, regulatory, and contractual obligations when transferring information, the ISO control aligns with the CSF outcome of assessing and recording risk impacts from changes and exceptions.
- PR.AA-05partialaligns with — The control's requirement for recipient authentication and access controls commensurate with information classification supports the CSF outcome of defining, managing, and enforcing access permissions and authorizations.
- PR.PS-04partialaligns with — The control's emphasis on traceability, non-repudiation, and chain-of-custody records during transfer supports the CSF outcome of generating and making log records available for continuous monitoring.
- GV.SC-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- ID.RA-07implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.AA-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.IR-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.PS-04implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Related OWASP ASVS 5.0 requirements (12)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V12.2.1mostlyaligns with — The ISO requirement for protecting electronic information transfers over public networks with stronger authentication and encryption directly supports the ASVS mandate that TLS must be used for all external-facing HTTP services without fallback to insecure protocols.
- V12.3.1mostlyaligns with — Mandating encrypted protocols such as TLS for all inbound and outbound connections between application components mirrors the ISO expectation that cryptographic controls protect information in transit between the organization and third parties.
- V13.2.4partialaligns with — The ISO rule requiring an allowlist of approved external services for information transfer aligns with the ASVS requirement that the application only communicates with explicitly permitted external resources or systems.
- V13.2.5partialaligns with — ISO guidance that servers must be configured with an allowlist of destinations they may send requests to corresponds to the ASVS control that restricts the web or application server to an approved list of outbound targets.
- V14.2.3partialaligns with — The ISO prohibition on sending sensitive information to untrusted external parties or services aligns with the ASVS requirement that sensitive data must not be transmitted to untrusted third parties such as trackers.
- V4.1.4partialaligns with — ISO rules that restrict electronic communication facilities and prevent automatic forwarding of messages map to the ASVS requirement that only explicitly supported HTTP methods may be used by the application.
Related weaknesses / CWE (26)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- CWE-1230nonemitigates — Transfer policies can require stripping or protecting metadata, but coverage is indirect.
- CWE-669nonemitigates — Information-transfer rules can prevent improper resource hand-off between spheres.
- CWE-1323prevents — Rules for secure transfer reduce exposure when trace data leaves the SoC.
- CWE-200prevents — Requiring encryption, access controls, and recipient authentication for transfers directly reduces the chance that sensitive data reaches an unauthorized observer.
- CWE-201mitigates — Information-transfer rules directly govern what data may be sent to external parties.
- CWE-212prevents — Information-transfer rules can require sanitization of sensitive content before sharing.
- CWE-213mitigates — Transfer rules can enforce consistent protection when data crosses stakeholder boundaries.
- CWE-300prevents — Information transfer policies address secure exchange but are high-level and not technical.
- CWE-311prevents — Explicit rules requiring encryption for sensitive information in transit eliminate the weakness of sending data without cryptographic protection.
- CWE-319prevents — Mandating cryptographic protection and stronger authentication on public networks stops the transmission of plaintext sensitive information.
- CWE-359mitigates — Labeling, chain-of-custody, and access-control requirements limit the exposure of private personal information during any transfer method.
- CWE-402mitigates — Information-transfer rules can prevent unintended disclosure of private resources outside the product.
- CWE-5prevents — Requires secure transfer procedures that would mandate encryption for sensitive data in transit.
- CWE-523prevents — Requires secure information transfer, which can include protecting credentials in transit.
- CWE-924prevents — Requires secure information transfer procedures that can include integrity checks.
Mitigated MITRE ATT&CK techniques (496)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
T1001←MT1001.001←MT1001.002←M →PT1001.003←P →PT1006←MT1008←M →PT1011←M →PT1011.001←M →PT1020←M →PT1020.001→PT1021←M →PT1021.004→PT1027←M →PT1027.001←MT1027.002←MT1027.003←MT1027.006←MT1027.008←MT1027.009←MT1027.010←MT1027.011←PT1027.014←MT1027.015←MT1027.016←MT1027.017←M →PT1027.018←MT1029←MT1030←MT1036←MT1036.002←MT1036.003←MT1036.005←MT1036.007←M →PT1036.008←M →PT1036.009←MT1036.012←MT1040→MT1041←M →PT1048←M →PT1048.001←M →PT1048.002←M →PT1048.003←M →PT1052←M →MT1052.001←M →PT1055←MT1055.001←MT1055.002←MT1055.003←MT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1070←MT1070.008←MT1071←M →PT1071.001←M →PT1071.002←M →PT1071.003←M →PT1071.004←M →PT1071.005←M →PT1078←PT1078.004←MT1080←P →PT1090←MT1090.001←MT1090.002←M →PT1090.003←MT1090.004←MT1091←M →PT1092←M →PT1095←MT1098.002←MT1098.005←MT1102←M →PT1102.001←M →PT1102.002←M →PT1102.003←M →PT1104←MT1105←M →PT1110→PT1110.001→MT1110.003→PT1110.004→PT1111←M →PT1114←M →PT1114.001→PT1114.002→PT1114.003→PT1123→PT1127←MT1132←PT1132.001←MT1132.002←MT1133←M →PT1134←MT1137.001→PT1137.005→PT1185←M →PT1187→PT1189→PT1195←M →PT1199←M →PT1200←MT1202←PT1204←M →PT1204.001←M →PT1204.002←M →PT1204.004←PT1205←P →PT1205.001←PT1207←MT1211←PT1213→PT1213.003→PT1213.005←M →PT1216←MT1218←MT1218.005←M →PT1218.007←MT1218.010←MT1218.011←PT1218.013←MT1219←M →PT1219.002→PT1219.003←MT1221←MT1222.001←MT1222.002←MT1480.001←MT1484←MT1484.002←MT1485←P →MT1486→MT1496.002→PT1496.003←P →PT1496.004←PT1498←P →PT1498.001←M →PT1498.002←P →PT1499←FT1499.001←P →PT1499.002←P →PT1499.003←PT1505.002←P →PT1528→PT1530←M →PT1534←M →PT1535←MT1537←M →PT1539←F →PT1542←MT1542.002←MT1548.006←MT1550←MT1550.001←FT1550.002←FT1550.003←FT1550.004←FT1552.001→PT1552.004→PT1552.008→PT1553.001←MT1553.002←PT1553.003←MT1553.004←MT1553.005←MT1553.006←MT1556←MT1556.005←PT1556.006←MT1556.007←MT1556.009←MT1557←M →PT1557.001←M →PT1557.002←M →PT1557.003←P →PT1557.004←M →PT1558.003→PT1560←MT1560.001←MT1561←P →MT1561.001→MT1561.002→MT1563→PT1563.001←MT1563.002→PT1564.001←MT1564.004←PT1565→PT1565.002→MT1566→PT1566.001→PT1566.002→PT1566.003→PT1566.004→PT1567→PT1567.001→PT1567.002→PT1567.003←M →PT1567.004←M →PT1568←MT1568.002←MT1568.003←MT1570←MT1571←MT1572←M →PT1573←MT1573.001←P →PT1574←PT1574.001←MT1574.013←PT1578←MT1578.001←MT1578.002←MT1578.003←MT1578.004←MT1578.005←PT1583.006←MT1583.007←MT1584←MT1584.001→PT1584.006←MT1584.007←MT1586.002←MT1586.003←MT1589→PT1589.001→PT1598←M →PT1598.001←M →PT1598.002←M →PT1598.003←M →PT1598.004←M →PT1599←MT1599.001←MT1600←MT1600.001←P →PT1600.002←PT1601.001←PT1601.002←MT1602.001→PT1602.002→PT1606←MT1606.001←FT1606.002←MT1608.005←MT1612←PT1620←MT1621←P →PT1647←PT1649→PT1653←PT1657→PT1659←M →PT1665←MT1666←PT1667←M →PT1669→PT1678←PT1684←M →PT1684.001←M →PT1684.002←M →PT1685←MT1685.002←MT1685.003←MT1685.004←MT1685.005←MT1685.006←MT1686←FT1686.001←MT1686.002←MT1686.003←MT1687←PT1688←MT1689←PT1690←M
Why these map — AI rationale (under review)
- T1001.002detects — A.5.14 mandates detection of malware in electronic transfers plus traceability/non-repudiation and anomaly-oriented rules that can surface hidden C2 payloads in transit; this reaches only a minority slice of steganography (malware-tied or overtly anomalous cases) while the dominant stealth technique evades those controls.
- T1001.002prevents — A.5.14 mandates rules/procedures/agreements (including crypto, malware detection, attachment protection, and restrictions on public services) that directly stop many forms of hidden C2 data in transit; partial because it does not reach all steganography variants (e.g., non-electronic or custom non-malware carriers) and relies on correct implementation of the listed controls.
- T1001.003detects — A.5.14 mandates detection of malware in electronic transfers plus controls for traceability/non-repudiation and anomaly-preventing rules that can surface impersonated protocol traffic as part of monitoring transfer integrity, but this is only a minority slice of the technique's full scope (e.g., no requirement for deep protocol inspection or C2-specific anomaly detection).
- T1001.003prevents — A.5.14 mandates rules, procedures, agreements, stronger authentication on public networks, cryptographic techniques, malware detection in electronic comms, and restrictions on transfer facilities that stop many impersonation techniques from succeeding in blending C2 traffic, but leaves open-ended residual cases such as subtle header/URI manipulation on approved internal services or non-electronic vectors.
- T1008detects — A.5.14 requires detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface anomalous fallback-channel use, but this is limited to monitored transfer paths and does not broadly instrument for alternate C2 channels across all platforms or non-transfer contexts.
- T1011detects — A.5.14 requires detection of malware in electronic communications plus controls for traceability/non-repudiation and incident responsibilities that can surface anomalous transfers, but this is limited to organization-defined electronic channels and does not broadly instrument alternative media like Bluetooth/RF used in T1011
- T1011prevents — A.5.14 mandates topic-specific policies, rules, procedures and agreements (including stronger authentication, malware detection, restrictions on public services, approved couriers, tamper-evident packaging, verbal disclaimers and room controls) that directly constrain or block many of the insecure alternate mediums and misroutings named in T1011, but leaves residual cases (e.g., insider-proximate Bluetooth/RF exfil on unmanaged devices or when policy exceptions are granted) unaddressed.
- T1011.001detects — A.5.14 requires detection of malware transmitted through electronic communications plus controls ensuring traceability/non-repudiation and incident responsibilities, which can surface Bluetooth exfiltration as anomalous transfer or malware but only for a minority slice (electronic rules; physical/verbal sections and most of the clause ignore Bluetooth entirely)
- T1011.001prevents — A.5.14's policy, rules, procedures and agreements on information transfer (including electronic channels, stronger authentication on public networks, malware protection, restrictions on external services, and explicit advice against sending critical info over insecure channels like Bluetooth-adjacent wireless) constrain or block the exfiltration technique in many enterprise settings, but Bluetooth is an optional, proximity-based channel outside primary routed networks and the control's electronic-transfer items do not mandate its disablement or universal prohibition.
- T1020detects — A.5.14 mandates detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface automated exfiltration events, but this is limited to policy-driven monitoring of approved transfer paths and does not broadly instrument or detect the automated processing or outbound transfer itself.
- T1020prevents — A.5.14's policy, rules, procedures and agreements on protecting information in transit (including electronic transfer controls against unauthorized access, malware, misrouting, and stronger authentication on public networks) directly stop many automated exfiltration paths from succeeding, but do not address the automated collection/processing step itself nor block all possible exfiltration channels or insider misuse.
- T1020.001detects — A.5.14 mandates rules/procedures for detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface anomalous mirroring or redirection, but this is a narrow slice of the technique's scope (device config abuse, cloud mirroring, ROMMONkit, etc.) with most of the class outside the control's view.
- T1020.001prevents — A.5.14 mandates rules/procedures/agreements (including crypto, access controls, and protections against interception/unauthorized access/misrouting) that can stop adversaries from successfully configuring or abusing mirroring for exfiltration on covered paths, but leaves gaps for on-device modifications, unmonitored verbal/physical vectors, and cloud configurations outside policy scope.
- T1021prevents — A.5.14's policy, rules, stronger authentication on public networks, malware detection in electronic comms, and restrictions on transfer facilities (e.g. preventing auto-forwarding or public use of IM/SMS/fax) constrain some vectors for obtaining/using valid creds over remote services like SSH/RDP, but leave the dominant credential-theft and legitimate-app-abuse paths untouched.
- T1021.004prevents — A.5.14's policy, agreements, stronger authentication on public networks, restrictions on facilities, and controls against unauthorized access/misrouting directly constrain many SSH login scenarios (especially external or misconfigured), but do not reach all internal/authorized-account uses or platform defaults on Linux/macOS/ESXi.
- T1027prevents — A.5.14 mandates rules, procedures, agreements, cryptographic techniques, malware detection, and restrictions on transfer methods that stop many forms of in-transit obfuscation (e.g. unprotected encrypted payloads, misrouted archives, or cleartext strings) from succeeding across electronic, physical, and verbal channels, but leaves residual cases such as on-system obfuscation before transit, user-deobfuscation of password-protected files, or command obfuscation that the control does not address.
- T1027.017prevents — A.5.14's policy, rules, procedures and agreements for protecting information in transit (including electronic transfer, malware detection in comms, stronger authentication on public nets, and controls against unauthorized modification/interception) directly constrain SVG smuggling when it occurs via email, file-sharing, or other transfer channels, but leave substantial remainder for in-browser, web-delivered, or non-transfer vectors of the technique.
- T1036.007prevents — A.5.14's rules on electronic transfer (preventing misrouting/wrong-address sends, stronger authentication on public nets, malware detection in attachments, acceptable-use policy for email/file-sharing, and labeling/handling of sensitive info) constrain the spearphishing-attachment vector that commonly delivers double-extension files, but do not stop an adversary from creating or naming the file itself nor block all delivery paths.
- T1036.008prevents — A.5.14 mandates rules/procedures for protecting information in transit (including electronic transfer) that explicitly include controls against unauthorized modification, misrouting, malware detection (8.7), input sanitization/validation, and stronger authentication on public networks; these directly stop many signature/extension masquerading tricks used during transfer, but leave residual cases such as polyglots, post-transfer storage, or non-enforced validation.
- T1040detects — A.5.14 requires rules, procedures and agreements that include detection of and protection against malware transmitted through electronic communications plus traceability/non-repudiation and incident responsibilities, which can surface some sniffing activity (especially when it enables malware or produces detectable incidents), but the control is silent on general passive network monitoring, promiscuous-mode detection, or traffic-mirroring discovery and does not mandate instrumentation that would catch the technique in most cases.
- T1040prevents — A.5.14 mandates cryptographic protection, stronger authentication on public networks, malware detection on electronic channels, and rules against insecure protocols/transfer methods that directly stop cleartext credential/config capture via sniffing on most covered vectors (electronic, verbal, physical), with bounded remainder for insider promiscuous-mode or cloud-mirroring cases where traffic is already inside a trusted boundary.
- T1041detects — A.5.14 requires detection of malware in electronic communications plus controls ensuring traceability/non-repudiation and incident responsibilities, which can surface anomalous exfiltration over C2 but does not mandate or guarantee broad detection of the encoded data transfer itself
- T1041prevents — A.5.14 mandates rules/procedures/agreements (including stronger authentication on public nets, malware detection in comms, restrictions on forwarding, and controls against interception/unauthorized access) that can stop an adversary from successfully encoding and exfiltrating data over a C2 channel, but leaves residual cases such as already-compromised C2 paths, internal networks, or non-electronic vectors.
- T1048detects — A.5.14 mandates detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface anomalous exfiltration, but does not require monitoring or detection of the alternate-protocol technique itself across all its forms (e.g. cloud console downloads, DNS, obfuscated channels).
- T1048prevents — A.5.14 mandates topic-specific policies, rules, procedures and agreements (including stronger authentication on public networks, malware detection on electronic channels, approved services, restrictions on forwarding/SMS/fax, and controls against misrouting/interception) that constrain many common vectors for T1048 exfiltration over alternate protocols; it does not reach all platform-specific utilities, cloud-console/API downloads, or fully eliminate the possibility of an adversary using an allowed channel with stolen credentials.
- T1048.001detects — A.5.14 mandates detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface anomalous exfiltration, but does not require monitoring or logging of the symmetric-encryption or protocol behaviors that actually distinguish this technique.
- T1048.001prevents — A.5.14 mandates policies, procedures, agreements, stronger authentication on public networks, malware detection, approved services, and controls (incl. cryptography per classification) that constrain or block many forms of unauthorized symmetric-encrypted exfiltration, but leaves residual paths such as insider-approved channels, misclassified data, or pre-agreed keys that an adversary can still exploit.
- T1048.002detects — A.5.14 requires detection of malware in electronic transfers plus controls ensuring traceability/non-repudiation and incident responsibilities, which can surface some exfiltration events over asymmetric protocols (e.g. via logs or anomalies), but does not mandate network monitoring or anomaly detection for the exfiltration technique itself.
- T1048.002prevents — A.5.14 mandates rules, procedures, agreements, stronger authentication on public networks, malware detection, approved services, and controls against unauthorized access/interception/misrouting for all information transfers (including electronic), which constrains many but not all asymmetric exfiltration paths (e.g., approved HTTPS to alternate locations or insider misuse of permitted channels remain possible).
- T1048.003detects — A.5.14 mandates detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface anomalous exfiltration, but does not require monitoring or anomaly detection for the unencrypted non-C2 protocol transfers or obfuscated data themselves
- T1048.003prevents — A.5.14 mandates topic-specific policy, rules, procedures and agreements that require cryptographic protection (8.24), stronger authentication on public networks, malware detection, restrictions on forwarding/external services, and explicit controls against interception/unauthorized access/misrouting for electronic transfers — directly stopping unencrypted exfiltration over HTTP/FTP/DNS/etc. in most cases, with a bounded remainder for internal or exempted flows.
- T1052detects — A.5.14 requires rules, procedures, agreements, logs, chain-of-custody, courier verification, tamper-evident packaging, and incident-liability clauses that surface unauthorized physical-media transfers or anomalies after the fact, but this is only a slice of the T1052 surface (e.g., no coverage of user-introduced devices inside air-gapped networks or post-exfiltration detection).
- T1052prevents — A.5.14 mandates rules/procedures/agreements (incl. physical media transfer section) that directly close the main vectors for adversary exfiltration via removable media by requiring authorized couriers, tamper-evident packaging, chain-of-custody logs, classification-driven controls, and restrictions on what/when media can leave.
- T1052.001detects — A.5.14 requires rules, procedures, agreements and logs for physical media transfers (including USB) that can surface unauthorized or anomalous exfiltration events after the fact, but this is only a slice of the technique's surface (e.g., no coverage of in-memory USB exfil, non-media USB hopping, or non-physical-transfer detection).
- T1052.001prevents — A.5.14's rules, procedures, agreements, and physical-media controls (packaging, authorized couriers, tamper-evident bags, logs, classification-driven protections) directly constrain or block many vectors for USB-based exfiltration of sensitive data, but do not stop an adversary from copying data to an unauthorized USB device that a user introduces or that bypasses the policy entirely.
- T1071prevents — A.5.14's policy, rules, agreements, stronger authentication on public networks, malware detection in electronic comms, restrictions on forwarding/external services, and controls against misrouting/interception directly constrain many common application-layer C2 protocols (web, email, DNS, file transfer) when used for exfil or command, but leave internal enclave protocols (SMB/SSH/RDP) and approved/encrypted channels largely untouched.
- T1071.001detects — A.5.14 mandates detection of malware in electronic communications plus traceability/non-repudiation and anomaly-oriented rules that can surface disguised C2 blending, but does not require or guarantee network monitoring, protocol anomaly detection, or traffic inspection that would reliably catch web-protocol C2.
- T1071.002detects — A.5.14 mandates rules/procedures for detection of malware in electronic transfers and for maintaining traceability/chain-of-custody and logs that can surface anomalous file-transfer activity, but does not require or address general detection of adversary use or concealment within common file-transfer protocols such as SMB/FTP/TFTP.
- T1071.002prevents — A.5.14 mandates rules, procedures, agreements, stronger authentication on public networks, malware detection, restrictions on forwarding/external services, and controls against interception/unauthorized access/misrouting for electronic transfers (including file-oriented ones like FTP/SMB), which stops many abuse vectors for blending C2 in file protocols; it leaves residual paths on internal networks, approved services, and non-electronic vectors.
- T1071.003detects — A.5.14 requires detection of malware in electronic communications plus rules on approved services, stronger authentication, and restrictions that can surface anomalous mail-protocol use, but does not mandate monitoring or anomaly detection for embedded C2 traffic itself
- T1071.003prevents — A.5.14's policy, rules, procedures and agreements for electronic transfer (including stronger authentication on public networks, malware detection in comms, restrictions on auto-forwarding/external services, and preventing misrouting) constrain or block many abuse vectors of SMTP/POP3/IMAP for C2, but do not eliminate the core technique of embedding commands in legitimate-looking mail-protocol traffic that blends with expected flows.
- T1071.004detects — A.5.14 mandates detection of malware in electronic communications plus controls ensuring traceability/non-repudiation and incident responsibilities, which can surface anomalous DNS tunneling as malware or an information security incident, but the clause's scope is limited to transfer rules rather than mandating broad network monitoring or specific DNS analysis.
- T1071.004prevents — A.5.14's policy, rules, procedures and agreements for electronic transfer (including stronger authentication on public networks, malware detection in comms, approved services only, and controls against unauthorized modification/interception) can prevent many forms of covert DNS tunneling or beaconing by restricting or securing the channels, but DNS is a core administrative protocol that cannot be wholly removed and many stealthy implementations still blend with legitimate traffic.
- T1071.005detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications plus controls for traceability/non-repudiation and anomalous transfer behaviors, which can surface pub/sub C2 blending in with expected traffic in some electronic scenarios but does not mandate general network monitoring or anomaly detection for protocol abuse.
- T1071.005prevents — A.5.14 mandates topic-specific policies, rules, procedures and agreements (including stronger authentication on public networks, malware detection on electronic comms, approved services, and controls against misrouting/interception) that can block or constrain many abuse vectors of pub/sub protocols for C2, but leaves open usage of internal/approved brokers, legacy protocols, and configurations where the traffic still blends as normal.
- T1080detects — A.5.14 requires rules/procedures for traceability, chain-of-custody logging, authorized-courier lists, transfer logs identifying content/protection/recipients/times, malware detection in electronic comms, and incident-contact identification; these surface anomalous or malicious tainting of shared content after the fact in some (but not all) transfer scenarios, leaving the majority of the technique (esp. internal repo/code-share binary infection and directory-share pivot) outside the clause's defined scope.
- T1080prevents — A.5.14's rules, procedures and agreements for protecting information in transit (including shared storage media, network drives, code repositories, electronic/file transfers and labeling/access controls) directly constrain the adversary's ability to taint shared content without detection or authorization, but only for a slice of the technique (e.g., does not reach all binary infection vectors, directory-share pivots using LNK/masquerading/hidden files, or non-transfer aspects of the attack chain).
- T1090.002detects — A.5.14 mandates detection of malware in electronic communications plus controls for traceability/non-repudiation and anomalous transfer behaviors (e.g. misrouting, unauthorized access), which can surface proxy-based C2 redirection in monitored channels but does not require or guarantee broad network anomaly detection of external proxies.
- T1091detects — A.5.14 requires detection of malware transmitted through electronic communications and traceability/non-repudiation/chain-of-custody for transfers including physical media, which surfaces some instances of the technique (e.g. malware on media or via USB) but does not mandate scanning of removable media itself or detection of firmware modification, misnamed files, or Autorun abuse.
- T1091prevents — A.5.14's rules/procedures for physical storage media transfer (packaging, tamper-evident controls, authorized couriers, logs, correct addressing) and verbal/electronic advisories reduce the chance of malware being successfully copied to or executed from removable media, but do not stop an adversary from modifying media/firmware or exploiting autorun on insertion.
- T1092detects — A.5.14 explicitly requires logging of physical media transfers (who, what, when, recipients) plus chain-of-custody and incident-liability rules that surface anomalous or unauthorized removable-media use after the fact; this is genuine but limited detection of the T1092 technique itself, not its prerequisites or full C2 payload.
- T1092prevents — A.5.14's rules, procedures, agreements, packaging, tamper-evident controls, authorized couriers, logs, and verbal-transfer reminders for physical storage media directly constrain the use of removable media as a C2 channel, but do not stop an already-compromised pair of hosts from exchanging commands via media.
- T1102detects — A.5.14 mandates detection of malware in electronic communications plus controls for traceability/non-repudiation and incident responsibilities that can surface anomalous or unauthorized use of web services for data relay, but does not require or address behavioral detection of legitimate-looking web service C2 traffic itself
- T1102.001detects — A.5.14's rules for electronic transfer (malware detection in comms, stronger auth on public nets, restrictions on forwarding/public services, and monitoring for misrouting/interception) surface anomalous use of web/social services as C2 resolvers in a minority slice of cases, but the control's scope is policy/procedure for authorized transfers rather than broad detection of covert adversary dead-drop patterns.
- T1102.002detects — A.5.14 mandates detection of malware in electronic communications plus rules for monitoring/approvals/restrictions on public services (social media, file sharing, cloud) and stronger authentication, which can surface anomalous bidirectional C2 use of those exact services as an information-transfer anomaly; it does not require general behavioral detection of the technique itself.
- T1102.002prevents — A.5.14's policy, rules, procedures and agreements on information transfer (including approval for external public services like social networking/file sharing, stronger authentication on public networks, restrictions on auto-forwarding, and controls against misrouting/interception) constrain or block many legitimate-looking bidirectional uses of web services for C2, but leave a bounded remainder where approved services, developer workflows, or insider actions still allow the technique.
- T1102.003detects — A.5.14 requires detection of malware in electronic communications plus rules for monitoring/approving use of external public services (social media, file sharing, cloud) and stronger authentication on public networks, which can surface anomalous or unauthorized C2 use of those exact services; this is a genuine but minority slice of the technique (most T1102.003 executions blend into expected traffic without triggering those specific controls).
- T1102.003prevents — A.5.14's policy, agreements, approval gates for external public services (incl. social/file-sharing), stronger auth on public nets, and restrictions on auto-forwarding/SMS/fax directly constrain the legitimate-web-service C2 channel described in T1102.003, but do not stop an already-compromised host from passively polling public sites that are already approved or required for business use.
- T1105prevents — A.5.14's policy, rules, procedures and agreements on protecting information in transit (including electronic transfer controls, stronger authentication on public networks, malware detection in comms, restrictions on public services, and approval requirements) constrain many of the described ingress methods and tools when used for sensitive/critical information, but leave the bulk of the technique (any-file ingress on compromised hosts via native utilities, C2 channels, web services, sync clients, or post-phish execution) untouched.
- T1110prevents — A.5.14 mandates stronger authentication on public networks, restrictions on electronic facilities, and policies that can include rate limiting or MFA-like measures, which prevent many online brute-force attempts; however, it is silent on offline attacks, account lockouts, or sufficient password strength, leaving the dominant brute-force surface (weak/default creds, offline cracking) untouched.
- T1110.001prevents — A.5.14 mandates stronger authentication on public networks, restrictions on electronic facilities, malware detection in comms, and policies that directly raise the bar on password guessing over exposed services (SSH, RDP, HTTP, etc.), though some vectors (e.g., internal networks, non-electronic guessing) remain outside its primary transit focus.
- T1110.003prevents — A.5.14 mandates stronger authentication on public networks, restrictions on electronic facilities, and policies that can block weak-password login paths or misrouted credential guesses, but leaves most internal spraying vectors, SSO/federated targets, and non-network transfer forms untouched.
- T1110.004prevents — A.5.14's policy, rules, stronger authentication on public networks, restrictions on forwarding/external services, and controls against misrouting/interception address credential exposure in transit and some authentication hardening that can blunt stuffing success on exposed services, but do not stop reuse of already-breached credentials or the core overlap technique itself.
- T1111prevents — A.5.14 mandates rules, procedures, agreements, stronger authentication on public networks, malware protection in electronic comms, and explicit warnings against sending critical info via SMS/instant messaging or using insecure channels, which directly blocks several named interception vectors in the T1111 description (SMS/out-of-band codes, insecure electronic transfer); it leaves hardware-token keylogging, seed compromise, and service-provider compromise untouched.
- T1114detects — A.5.14 requires detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities that can surface anomalous forwarding or collection, but does not mandate monitoring for the core collection technique itself
- T1114prevents — A.5.14's rules, procedures and agreements for electronic transfer (including stronger authentication, malware detection, preventing misdelivery, restrictions on forwarding, and advising against insecure channels) constrain several vectors for adversaries to collect or forward email, but do not stop all collection methods such as direct client/server compromise or exfiltration after legitimate access.
- T1114.001prevents — A.5.14's policy, rules, procedures and agreements on protecting information in transit (including electronic transfer safeguards against malware, misrouting, unauthorized access, and stronger authentication on public networks) constrain some vectors for local email file collection when the .ost/.pst data is subsequently transferred, but do not prevent the core local acquisition technique itself on a compromised endpoint.
- T1114.002detects — A.5.14 requires detection of malware in electronic communications plus rules/procedures that surface misdelivery, unauthorized access, and anomalous transfer events (including logs of media handoffs), which can flag some remote email collection activity but does not mandate monitoring of Exchange/Office 365 API or credentialed mailbox access itself.
- T1114.002prevents — A.5.14's policy, agreements, stronger authentication on public nets, access controls, and restrictions on email forwarding/misrouting directly constrain credentialed remote collection from external Exchange/Office 365 surfaces, but do not stop an already-authenticated insider or token-holder from querying mailboxes internally.
- T1114.003detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications plus rules/procedures for monitoring transfer incidents and maintaining traceability/chain-of-custody, which can surface anomalous forwarding rules or hidden inbox rules after they run; this is a genuine but minority slice of the technique (mostly creation and hiding of rules themselves, which the control does not instrument).
- T1114.003prevents — A.5.14's rules on electronic transfer (esp. d, e, f, g) and topic-specific policy on acceptable use of email facilities directly constrain or prohibit creation/use of unauthorized forwarding rules, but do not stop an adversary with valid credentials from creating hidden rules via MAPI or transport rules.
- T1123detects — A.5.14's rules, procedures and agreements for electronic/verbal transfer (malware detection in comms, advising against insecure channels, room controls, disclaimers) can surface anomalous audio-capture activity or policy violations when it occurs in the context of information transfer, but this is a narrow slice of the technique's scope (any peripheral/app-based capture, including non-transfer uses).
- T1123prevents — A.5.14's rules, procedures and reminders for verbal transfer (no confidential talk in public/insecure channels, screen participants, room sound-proofing, disclaimers) and its policy on protecting information in transit reduce the chance sensitive conversations occur in capturable settings, but do nothing to stop malware/scripts from using OS APIs to activate a microphone and record.
- T1133prevents — A.5.14's policy, rules, agreements, stronger authentication on public networks, malware protection, restrictions on forwarding/external services, and controls against interception/unauthorized access directly constrain many external remote service abuse vectors (VPNs, exposed APIs, weak auth), but leave open unauthenticated exposures, Tor hidden services, and post-compromise credential use as named gaps.
- T1137.001prevents — A.5.14's policy, rules and agreements on information transfer (including acceptable-use guidelines, macro-handling restrictions via external/public services, and controls on attachments/electronic comms) can constrain the macro-enabled template abuse when it involves transfer of the malicious template or shared/remote loading, but this is only a slice of the technique's core local-persistence vectors (Normal.dotm modification, registry hijack, search-order abuse) that do not require transfer.
- T1137.005detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications (including via email attachments and rules that could trigger on crafted messages), but this is scoped only to malware detection rather than broadly detecting the abuse of Outlook rules for persistence, with most of the technique (rule creation and loading) outside its explicit electronic-transfer focus.
- T1137.005prevents — A.5.14's policy, rules, procedures and agreements on information transfer (including electronic mail) require controls against misrouting, malware in attachments, approval for external services, stronger authentication on public networks, and restrictions on auto-forwarding, which constrain the delivery channel an adversary would use to trigger a malicious Outlook rule but do not stop rule creation or the persistence mechanism itself.
- T1185detects — A.5.14 mandates detection of malware transmitted through electronic communications (explicitly listed under electronic transfer rules) and broader controls for interception/unauthorized access during transfer, which surfaces some in-browser hijacking techniques (e.g. malware injection or anomalous proxying of sessions) but leaves the majority of the class (purely functional pivoting, permission inheritance without malware, non-transfer behaviors) unreached.
- T1187detects — A.5.14 requires detection of malware transmitted through electronic communications and controls to protect against interception/unauthorized access during transfer, which surfaces some forced-authentication attempts (e.g. via attachments or external links), but leaves the majority of technique variants (e.g. .LNK/.SCF files, EFSRPC, internal shares) outside its explicit scope.
- T1187prevents — A.5.14's rules on stronger authentication over public networks, restrictions on external services, malware protection in electronic comms, and controls against interception/unauthorized access during transfer address some vectors (e.g. external SMB/WebDAV forcing via attachments or public shares) but leave internal network forcing (e.g. EfsRpcOpenFileRaw, .LNK/.SCF on desktop, or trusted shares) untouched.
- T1189prevents — A.5.14's policy, rules, and controls on electronic transfer (malware detection/protection in comms, stronger auth on public nets, restrictions on external services/cloud/file-sharing, and warnings against risky messaging) constrain several delivery vectors for drive-by content such as malicious ads, compromised cloud buckets, and unsafe browsing, but do not stop core web compromises, XSS on legitimate sites, or client-side exploitation itself.
- T1195prevents — A.5.14's rules, agreements, cryptographic protections, tamper-evident packaging, courier vetting, and chain-of-custody requirements for physical/electronic transfer directly block shipment interdiction and infected removable-media vectors of T1195, but leave all upstream development-tool, source-code, update-mechanism, and open-source-dependency manipulations untouched.
- T1199prevents — A.5.14 mandates topic-specific policies, transfer agreements (incl. recipient authentication), stronger auth on public nets, access controls, crypto, and explicit rules for third-party transfers that directly constrain the unprotected or under-scrutinized trusted relationships and delegated-admin paths described in T1199; it leaves residual gaps such as already-compromised third-party accounts and non-transfer vectors.
- T1204prevents — A.5.14's policy, rules, procedures and agreements on secure transfer (including electronic, with malware detection, wrong-address prevention, stronger auth on public nets, restrictions on auto-forwarding/IM/SMS/fax, and verbal-transfer reminders against public/insecure channels) directly stop several social-engineering vectors that induce User Execution, such as malicious attachments/links delivered via email/IM/SMS/fax or misrouted transfers; they do not reach non-transfer vectors such as files already on a desktop/shared drive, browser JS, or vishing-driven manual execution.
- T1204.001prevents — A.5.14's policy, rules, agreements, and user reminders on information transfer (esp. electronic: avoid public services, stronger auth on public nets, no auto-forward, no SMS/IM with critical info, prevent mis-sending) constrain the social-engineering vector that delivers the malicious link, but do not stop all delivery paths, all user clicks, or the downstream execution.
- T1204.002prevents — A.5.14's policy, rules, procedures and agreements on protecting information in transit (including electronic attachments, malware detection in comms, preventing misdelivery, stronger auth on public nets, and advising against sending critical info via SMS/IM/fax) directly constrain delivery vectors for malicious files that rely on user opening (especially spearphishing attachments), but leave internal placement, non-transfer delivery, and user execution decisions largely untouched.
- T1205detects — A.5.14 mandates detection of malware in electronic communications plus controls for traceability/non-repudiation and incident responsibilities, which can surface anomalous signaling packets or malware using them, but the control is scoped to information-transfer policy and does not require general network monitoring or packet inspection for magic values/port-knocking.
- T1213prevents — A.5.14's policy, agreements, access controls, cryptographic protections, authentication, and transfer rules (electronic/physical/verbal) constrain improper exposure and external sharing of repository data, but do not address the core access-control misconfigurations that enable repository mining itself.
- T1213.003prevents — A.5.14's policy, agreements, access controls, encryption, authentication, and transfer rules for electronic channels (including SaaS code repos accessed via web/git) prevent many forms of unauthorized collection of sensitive code/credentials in transit or via misrouting, but do not stop an already-authenticated adversary with repository access from simply reading/downloading the stored data.
- T1213.005detects — A.5.14 requires detection of malware in electronic communications and traceability/non-repudiation controls that can surface anomalous transfers or incidents involving messaging apps, but does not mandate monitoring of chat content, exfiltration, or adversary mining behavior itself.
- T1213.005prevents — A.5.14's policy, rules, procedures and agreements on information transfer (including electronic messaging apps) directly constrain what sensitive data may be sent or stored in such channels, reducing the pool of mineable information and thereby preventing the technique from succeeding in many cases; it is only partial because the control is governance-oriented, does not reach all implementations or all data types, and cannot stop an adversary who already has access from reading what was posted.
- T1218.005detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications (explicitly including 8.7), which surfaces mshta.exe abuse when it delivers or executes malicious HTA/VBS/JS payloads over networks or email, but does not address local non-network abuse, inline scripts, or non-malware uses of the trusted binary.
- T1219detects — A.5.14 mandates detection of malware transmitted through electronic communications (8.7) and controls for traceability/non-repudiation/chain-of-custody plus incident responsibilities, which can surface some RAT abuse in transit or post-compromise but leaves the bulk of in-network interactive C2 sessions, persistence, and legitimate-tool abuse undetected as the control is scoped to transfer rules rather than host/network behavioral monitoring.
- T1219prevents — A.5.14's rules on electronic transfer (stronger auth on public nets, malware detection in comms, restrictions on forwarding/external services, approvals for cloud/file-sharing, and controls against interception/unauthorized access) constrain some post-compromise abuse of remote access tools over networks, but do not stop internal/trusted-host usage, built-in modules, or persistence mechanisms.
- T1219.002detects — A.5.14 requires detection of malware transmitted through electronic communications and controls to protect against interception/unauthorized access/misrouting, which can surface anomalous use of remote desktop tools on public networks or via attachments, but does not mandate behavioral monitoring of legitimate RMM software inside the environment
- T1485recovers — A.5.14 explicitly requires retention/disposal guidelines, backup-like reliability/availability measures for transfer services, and (via 8.13 cross-reference in related controls) recovery mechanisms that restore data destroyed in transit or by destruction events, though it does not guarantee recovery from all overwrite-based irrecoverable cases.
- T1486recovers — A.5.14 requires rules, procedures and agreements (including for physical media and electronic transfer) that explicitly address retention/disposal, reliability/availability of transfer services, chain-of-custody, incident liabilities for loss of media/data, and packaging/controls to protect against destruction or denial-of-service in transit; these enable post-ransomware recovery of the encrypted data via protected backups or restored transfers, matching the event-lane recovers anchor for T1486 while leaving a named remainder (e.g., data written after last backup or backups also encrypted).
- T1496.002detects — A.5.14 requires detection of malware transmitted via electronic communications (8.7) and controls for traceability/non-repudiation/chain-of-custody plus incident responsibilities, which can surface anomalous bandwidth consumption or proxyjacking/botnet activity in transit but does not mandate general network monitoring or anomaly detection for the full technique (e.g. local resource hijacking or scanning).
- T1496.003detects — A.5.14 explicitly requires detection of and protection against malware transmitted through electronic communications (plus traceability, incident responsibilities, and anomalous transfer patterns via logs and agreements), which surfaces SMS pumping as anomalous high-volume messaging abuse, but only as one narrow slice of its electronic-transfer guidance and without mandating coverage of SaaS/web-form pumping vectors.
- T1496.003prevents — A.5.14's rules, procedures and agreements for electronic/verbal transfer (including approval for external messaging services, restrictions on auto-forwarding/SMS use for critical info, stronger auth on public nets, and malware/DOS protections) constrain the abuse of victim messaging infrastructure to generate fraudulent SMS traffic, but do not stop the core technique of abusing public web forms/OTP fields that trigger backend services like Twilio.
- T1498detects — A.5.14 mandates detection of and protection against malware transmitted through electronic communications plus traceability/non-repudiation and incident responsibilities that can surface anomalous transfer patterns, but this is a narrow slice of the many ways Network DoS (flooding, spoofing, botnets) can be performed without involving malware in transit or detectable transfer-policy violations.
- T1498prevents — A.5.14 mandates rules, procedures, agreements and controls (including cryptographic techniques, stronger authentication on public networks, malware detection in electronic comms, and restrictions on transfer facilities) that directly constrain several vectors for launching or amplifying a network DoS (spoofing mitigation via authentication, malware in comms, misrouting, and public-service abuse), but leaves the dominant volumetric/botnet flooding slice untouched.
- T1498recovers — A.5.14 requires rules/procedures for reliability and availability of the transfer service plus retention/disposal guidelines that can enable post-DoS restoration of service continuity and business records, but the control is scoped to information transfer channels rather than general network availability or bandwidth exhaustion recovery.
- T1498.001detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications plus controls to protect transferred information from denial of service and ensure reliability/availability of the transfer service, which can surface some network flooding anomalies but does not mandate general network monitoring or traffic analysis to detect the technique itself.
- T1498.001prevents — A.5.14's rules, procedures and agreements for electronic transfer (including stronger authentication on public networks, malware detection in comms, restrictions on forwarding/external services, and controls against misrouting/DoS) constrain some vectors for an adversary to launch or amplify a direct network flood, but do not stop the core technique of sending high-volume traffic from botnets or controlled systems.
- T1498.001responds — A.5.14 requires rules/procedures for incident responsibilities, liabilities, and contacts during information transfer incidents (including DoS from flooding), enabling organizational response once the flood is underway, but this is only a minority slice of the full technique which centers on high-volume external botnet traffic generation.
- T1498.002detects — A.5.14 mandates detection of and protection against malware transmitted through electronic communications plus controls for traceability/non-repudiation and incident responsibilities, which can surface anomalous high-volume reflection traffic or related misuse of allowed transfer services, but this is only a minority slice of the technique's core (spoofed amplification via reflectors like DNS/NTP/memcache) and does not require or imply dedicated network monitoring for the DoS pattern itself.
- T1498.002prevents — A.5.14's policy, rules, agreements, stronger authentication on public networks, anti-misrouting, and cryptographic protections for transit directly constrain spoofed-packet reflection/amplification vectors when the organization's own systems or networks are involved in the attack path, but cannot prevent the technique when it leverages only external reflectors and third-party amplifiers.
- T1499.001detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications plus controls to protect transferred information from denial of service and ensure reliability/availability of transfer services, which can surface some network-level DoS indicators (e.g., anomalous floods), but does not mandate or address endpoint/OS-level monitoring for resource-exhaustion techniques like SYN/ACK floods.
- T1499.001prevents — A.5.14 mandates rules/procedures/agreements (including cryptographic techniques, stronger authentication on public networks, malware detection in electronic comms, and controls against misrouting/DoS) that can stop many network-borne OS-exhaustion floods before they reach the target, but leaves a bounded remainder for non-electronic vectors, local attacks, and cases where the flood evades the transfer protections.
- T1499.002prevents — A.5.14 mandates rules/procedures/agreements that include controls to protect information in transit against denial of service (explicitly listed in 5.14.a), stronger authentication on public networks, malware protection in electronic comms, and restrictions on services like public cloud/file sharing that could be abused for floods; this constrains some vectors of T1499.002 but leaves the bulk (raw volumetric HTTP floods, SSL renegotiation at scale, non-transfer-service exhaustion) untouched.
- T1505.002detects — A.5.14 mandates detection of and protection against malware transmitted through electronic communications (including attachments) plus traceability/non-repudiation and incident responsibilities, which can surface a malicious transport agent acting on in-transit email; this is only a slice of the persistence technique itself.
- T1528prevents — A.5.14's policy, agreements, cryptographic protections, stronger authentication on public networks, malware detection in electronic transfer, and restrictions on facilities directly stop many electronic and OAuth/social-engineering vectors for stealing tokens in transit or via mis-sent messages; they do not address container compromise, IMDS requests after VM takeover, or CI/CD pipeline breaches that steal tokens at rest or via local access.
- T1530detects — A.5.14 requires rules/procedures for detection of malware in electronic transfers, traceability/non-repudiation, incident responsibilities, and logs for physical media transfers, which can surface some T1530 access events (esp. via misconfigs or leaked creds) but does not mandate monitoring of cloud API access or storage itself.
- T1530prevents — A.5.14's policy, agreements, classification-driven controls (incl. crypto, access levels, authentication, misrouting prevention, and public-service approvals) directly stop many misconfiguration and credential-abuse paths that enable unauthenticated or overly-broad cloud-storage access, but leaves residual gaps such as insider misuse of valid credentials and incomplete enforcement on third-party SaaS configurations.
- T1534detects — A.5.14 requires detection of malware in electronic communications plus rules for monitoring/traceability/non-repudiation that can surface anomalous internal messages or attachments, but this is a minority slice of the multi-staged internal spearphishing technique (initial compromise, impersonation, chat-app abuse) whose dominant vectors sit outside the control's transfer-focused scope.
- T1534prevents — A.5.14's policy, rules, procedures and agreements on protecting information in transit (electronic, including email/chat/IM/attachments; verbal; physical) directly constrain the delivery vectors and content of internal spearphishing (e.g. malware detection, wrong-address prevention, stronger auth on public nets, no critical info in SMS/IM, disclaimers, approved services), but the technique's initial account compromise stage and impersonation of already-trusted internal identities sit outside its transit-focused scope.
- T1537detects — A.5.14 mandates detection of malware in electronic transfers, traceability/non-repudiation with logs and chain-of-custody, incident responsibilities, and contact identification, which can surface anomalous internal cloud-account transfers or backups when they trigger logging or incident processes, but the control is scoped to policy/rules for transfers (with detection limited to malware and post-facto incidents) and does not require monitoring of cloud APIs, sharing links, or internal transfers that blend as normal traffic.
- T1537prevents — A.5.14's policy, agreements, classification-driven controls (incl. crypto, access levels, authentication, malware detection, restrictions on public services, and transfer rules) constrain many electronic/cloud transfer vectors in the technique, but internal same-provider account transfers, API blending, and anonymous sharing links remain reachable without violating the clause.
- T1539detects — A.5.14 mandates detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities that can surface cookie-theft events, but the clause is scoped to transfer rules and does not require host/process/memory monitoring for local cookie theft vectors such as browser injection or in-memory scraping.
- T1539prevents — A.5.14 mandates rules, procedures, agreements, and controls (including encryption, stronger authentication on public networks, malware detection in electronic comms, restrictions on forwarding/sharing services, and protections against interception/unauthorized access) that stop many vectors for stealing session cookies in transit or via electronic means, but leaves local malware theft, JS injection, and post-auth browser memory attacks untouched.
- T1552.001prevents — A.5.14's policy, rules, agreements, cryptographic and access-control requirements for information in transit (including electronic files, attachments, storage media) directly constrain insecure credential storage and transfer practices that would otherwise enable the technique, but this is only a slice of the class (e.g., does not reach embedded credentials in source/binary, Group Policy Preferences, or local non-transit files).
- T1552.004prevents — A.5.14 mandates topic-specific policy, rules, procedures and agreements (including cryptographic techniques per classification, stronger authentication on public networks, and controls against interception/unauthorized access) that directly stop insecure storage and transit of private keys on many but not all vectors (e.g., local filesystem search on already-compromised hosts, device key export, or passphrase brute-force remain outside its primary transfer focus).
- T1552.008detects — A.5.14 explicitly requires detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities that surface credential-exposure events, but does not mandate monitoring of chat content, integration-tool abuse, or credential patterns themselves.
- T1552.008prevents — A.5.14's policy, rules, procedures and agreements (including stronger auth on public nets, restrictions on forwarding/auto-forward, malware detection in comms, and explicit advisories against sending critical info via chat/SMS/IM) directly constrain the insecure passing of credentials through chat services, but only for the subset of cases where users comply and the service is not already compromised; the technique's core (adversary collection from endpoint/server/portal or via compromised integrations) is not stopped.
- T1557detects — A.5.14 mandates detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities that can surface AiTM positioning or its effects (e.g. misrouting, interception), but the control is silent on detecting protocol abuses like ARP/DNS/LLMNR spoofing that establish the position itself.
- T1557prevents — A.5.14 mandates rules, procedures, agreements, cryptographic protections, stronger authentication on public networks, malware detection on electronic channels, and anti-misrouting measures that directly stop most protocol-abuse and downgrade vectors used to establish an AiTM position; the bounded remainder is local-link attacks (ARP/LLMNR) on unmanaged internal segments where the policy may not be enforced uniformly.
- T1557.001detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications (plus broader monitoring implied by incident responsibilities and traceability), which can surface some name-resolution-poisoning activity when it involves malicious tools or anomalous traffic, but the control is scoped to information-transfer policy and does not mandate network-level anomaly detection for LLMNR/NBT-NS/mDNS spoofing itself.
- T1557.001prevents — A.5.14's policy, rules, procedures and agreements for electronic transfer (including stronger authentication on public networks, malware protection, restrictions on forwarding, and controls against interception/unauthorized access) constrain or block some vectors for LLMNR/NBT-NS/mDNS spoofing and NTLM relay on local networks, but leave the dominant local-link poisoning technique itself (and many Windows defaults) untouched.
- T1557.002prevents — A.5.14 mandates cryptographic protection, stronger authentication on public networks, malware detection on electronic comms, and rules to protect transit from interception/unauthorized access; these stop ARP poisoning from succeeding in MITM on many (but not all) enterprise network segments, especially those using encryption or switched/segmented designs.
- T1557.003detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications plus controls to protect transferred information from interception/unauthorized access/misrouting, which can surface rogue DHCP activity or its effects in monitored electronic transfers, but the control is scoped to information transfer policy/procedures rather than mandating network-level monitoring of DHCP protocol exchanges themselves.
- T1557.004detects — A.5.14 mandates detection of malware in electronic communications plus rules for stronger authentication, restrictions on forwarding, and advising against insecure verbal/SMS transfers, which can surface some evil-twin indicators (e.g., anomalous captive portals or malware delivered post-connection) but does not require monitoring for rogue APs, probe-response spoofing, signal-strength attacks, or fake SSIDs themselves.
- T1557.004prevents — A.5.14's policy, rules, stronger authentication on public networks, malware protection in electronic comms, and user reminders against insecure channels (including public Wi-Fi) constrain the setup and success of evil twin deception in many enterprise/public scenarios, but do not stop an adversary from hosting a rogue AP or devices from connecting when signal strength or PNL spoofing succeeds.
- T1558.003prevents — A.5.14 mandates stronger authentication, cryptographic protection of sensitive data in transit, malware detection on electronic channels, and rules against insecure transfer methods, which can block network sniffing of TGS tickets or force better encryption that defeats RC4-based offline cracking; however, it does not address the core technique of requesting TGS tickets with a valid TGT from a DC or the underlying weak service account key derivation.
- T1561recovers — A.5.14 mandates rules, procedures and agreements for retention/disposal of business records plus physical media transfer packaging, courier controls, logs, and chain-of-custody that enable recovery of wiped or corrupted data from protected backups or alternate media after the T1561 event.
- T1561.001recovers — A.5.14 explicitly requires retention/disposal guidelines, backup-like reliability/availability of transfer services, and physical media packaging/protection that enable restoration of wiped storage contents after a destructive wipe event.
- T1561.002recovers — A.5.14 explicitly requires retention/disposal guidelines, backup/restore capabilities for transferred business records and media (including physical storage media and logs), plus reliability/availability measures that enable recovery of wiped boot structures or lost data after a destructive availability event.
- T1563prevents — A.5.14 mandates stronger authentication on public networks, anti-interception controls (incl. crypto), non-repudiation, session protections against hijacking-like risks, and rules against insecure channels, which prevent many session hijacking vectors but leave gaps for local or already-compromised sessions.
- T1563.002prevents — A.5.14's policy, rules, stronger authentication on public networks, malware protection, and controls against interception/unauthorized access in electronic transfers address a slice of RDP hijacking vectors (esp. over networks), but do not reach local hijacking with System privileges via tscon.exe or the core session-stealing mechanic.
- T1565detects — A.5.14 mandates traceability/non-repudiation, chain-of-custody logging, incident-liability rules, transfer logs, malware detection in electronic channels, and reminders about verbal leaks, all of which can surface data-manipulation attempts or their artifacts after the fact; this is limited to transit-related slices and does not address in-place manipulation inside applications or complex systems.
- T1565prevents — A.5.14's rules, procedures and agreements (esp. a, b, e, f, i under general; electronic and physical specifics) directly require controls that stop interception/modification/misrouting of data in transit, which prevents the adversary technique from succeeding against information while it is being transferred.
- T1565.002detects — A.5.14 explicitly requires traceability, non-repudiation, chain-of-custody, logging of transfers, incident responsibilities, and malware detection in electronic channels, which can surface some instances of in-transit manipulation after the fact, but this is limited to covered transfer types and does not broadly instrument for interception/modification across all mechanisms or platforms.
- T1565.002prevents — A.5.14 mandates rules/procedures/agreements (incl. crypto, access controls, integrity mechanisms, non-repudiation, and transit protections) that directly stop interception-and-alteration of data in electronic, physical, or verbal transit, reaching the bulk of T1565.002's network and media scenarios while leaving a bounded remainder for in-process manipulation between system processes.
- T1566detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications (plus traceability/non-repudiation and incident responsibilities), which surfaces some phishing payloads but does not address social engineering, spoofing, thread hijacking, or non-malware lures that dominate the technique.
- T1566prevents — A.5.14's policy, rules, procedures and agreements for electronic transfer (including stronger authentication on public nets, malware detection in comms, preventing misdelivery, restrictions on auto-forwarding/external services, and warnings against SMS/IM for critical info) directly constrain or block many delivery vectors and social-engineering lures of T1566 phishing, but leave open targeted spearphishing that evades these (e.g., via compromised accounts, thread hijacking, or non-email channels) and do not reach the human-acceptance step of the technique.
- T1566.001detects — A.5.14 explicitly requires detection of and protection against malware transmitted through electronic communications (including attachments), which surfaces the malicious payload in spearphishing emails, but does not address the social engineering, spoofed sender, or pre-execution delivery aspects of the technique.
- T1566.001prevents — A.5.14's rules on electronic transfer (malware detection in comms, attachment protection, preventing misdelivery, stronger auth on public nets, restrictions on auto-forwarding/external services, and warnings against sending critical info via SMS/IM/fax) directly constrain or block the delivery and success of malicious spearphishing attachments in many common cases, but leave open social-engineering lures, user execution, and non-email vectors.
- T1566.002detects — A.5.14 requires detection of malware transmitted through electronic communications (8.7) and controls to protect against misrouting, interception and unauthorized access in electronic transfer, which surfaces some spearphishing-link delivery vectors but leaves the social-engineering pretext, link obfuscation, consent-phishing and device-code variants largely unreached.
- T1566.002prevents — A.5.14's policy, rules, procedures and agreements for electronic transfer (including stronger authentication on public nets, malware detection in comms, preventing misdelivery, restrictions on auto-forwarding/external services, and warnings against sending critical info via SMS/IM) directly constrain or block several vectors of spearphishing-link delivery and success, but leave open social-engineering pretexts, obfuscated URLs, consent-phishing OAuth flows, and user execution after a link is clicked.
- T1566.003detects — A.5.14 requires detection of malware transmitted through electronic communications (8.7) and controls for traceability/non-repudiation/chain-of-custody plus incident responsibilities, which can surface spearphishing-via-service messages or payloads when they use monitored enterprise channels or trigger logging, but the technique's core (adversary rapport-building on external third-party services like social media or personal webmail) lies outside enterprise visibility and policy enforcement.
- T1566.003prevents — A.5.14's policy, rules, approvals, stronger authentication, restrictions on external services (e.g. social media, instant messaging, file sharing), and guidance against sending critical info via SMS/IM directly constrain or block the adversary's ability to deliver malicious links/attachments via third-party services, but do not stop social engineering rapport-building or all possible service vectors.
- T1566.004detects — A.5.14 explicitly requires detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities that can surface vishing-driven social engineering when it produces anomalous transfers or reported incidents, but the control's verbal-transfer guidance is only advisory reminders to users and does not mandate any technical or procedural detection of the voice call itself
- T1566.004prevents — A.5.14's verbal-transfer rules (reminders against confidential discussions on insecure channels, public places, voice messages, misdialling, plus disclaimers and room controls) directly constrain the social-engineering voice channel that T1566.004 relies on, but only address part of the technique (the vishing conversation itself) while leaving the preceding electronic lures, urgency/impersonation setup, and downstream user execution/MFA bypass untouched.
- T1567detects — A.5.14 requires detection of malware in electronic transfers plus controls for traceability/non-repudiation, incident responsibilities, and anomalous transfer practices (e.g. wrong-address sending, unapproved public services, SMS/fax risks), which can surface some T1567 exfiltration events but leaves the bulk of stealthy, encrypted, legitimate-looking web-service data exfil (especially non-malware) outside its defined scope.
- T1567prevents — A.5.14's policy/rules on electronic transfer (esp. approval for external public services like cloud/file-sharing, stronger auth on public nets, malware detection, and controls against misrouting/interception) constrain many common T1567 vectors but leave open-ended remainder for approved/necessary web services already permitted by firewall rules.
- T1567.001detects — A.5.14 requires detection of malware in electronic communications plus controls for traceability/non-repudiation, incident responsibilities, and logging of transfers, which can surface anomalous exfiltration to a code repo API as an incident or via logs, but this is only a minority slice of the technique (no mandated network monitoring, anomaly detection on API calls, or data-loss prevention).
- T1567.001prevents — A.5.14's policy, agreements, stronger authentication on public networks, restrictions on external services (e.g. file sharing/cloud), malware detection, and controls against misrouting/interception directly constrain or block many paths for exfiltrating data to a public code repo via its HTTPS API, but do not eliminate all cases (e.g. approved internal repos, sanctioned cloud use, or covert use of popular services already in the environment).
- T1567.002detects — A.5.14 requires detection of malware in electronic communications plus rules on approved external services (including cloud storage) and stronger authentication, which can surface anomalous or unapproved exfiltration to cloud storage as an incident or policy violation, but this is only a minority slice of the technique (no broad network/behavioral detection of data exfiltration itself).
- T1567.002prevents — A.5.14 mandates topic-specific policy, rules, procedures and agreements (including approvals before using external cloud storage/file sharing, stronger authentication on public networks, and controls against unauthorized transfer) that directly constrain the adversary technique of exfiltrating data to cloud storage services.
- T1567.003detects — A.5.14 requires detection of malware in electronic communications plus rules/procedures for monitoring transfer services, traceability, and anomalous use of public services like file sharing or cloud storage, which can surface some exfiltration to text sites but leaves most stealthy or encrypted uses of pastebin-like services outside its mandated scope.
- T1567.003prevents — A.5.14's policy, rules, agreements, and controls (esp. approval for public file-sharing/cloud services, stronger auth on public nets, malware detection, non-repudiation, and restrictions on auto-forwarding/SMS/IM) directly constrain or block many paths for exfiltrating to public text storage sites like Pastebin; partial because the control is governance-oriented, does not reach all implementations or all adversary workarounds (e.g., encrypted payloads, approved internal services, or non-public instances), and leaves a bounded remainder.
- T1567.004detects — A.5.14 mandates detection of malware in electronic transfers plus traceability/non-repudiation and incident responsibilities that can surface webhook exfiltration when it uses monitored channels or triggers an observable incident, but the control is silent on behavioral network monitoring or anomaly detection for blended HTTPS webhook posts themselves
- T1567.004prevents — A.5.14's policy, rules, procedures and agreements on information transfer (including electronic channels, stronger authentication on public networks, restrictions on external services like file sharing/cloud, malware detection in comms, and controls against misrouting/unauthorized access) constrain or block many webhook-based exfiltration paths, but leave real residual slices such as adversary-controlled SaaS links, manual HTTPS posts that blend with normal traffic, and insider-approved transfers.
- T1572detects — A.5.14 mandates detection of malware in electronic communications plus controls ensuring traceability/non-repudiation and protection from interception/unauthorized access, which can surface anomalous tunneling (e.g. via DoH, SSH, or unexpected encapsulation) in monitored transfers, but the clause is scoped to policy-level rules for authorized transfers rather than mandating broad network monitoring or anomaly detection for tunneling techniques themselves.
- T1572prevents — A.5.14 mandates rules, procedures, agreements, stronger authentication on public networks, malware detection in electronic comms, and controls against interception/unauthorized access/modification for all transfer methods (including electronic), which directly stops many tunneling techniques that rely on blending, weak auth, or unmonitored encapsulation; it leaves residual cases such as authorized-but-abused tunnels, internal non-public-network tunneling, or non-transfer-protocol uses.
- T1573.001prevents — A.5.14 mandates use of cryptographic techniques (incl. symmetric) with classification-driven strength, stronger auth on public nets, and malware/forwarding protections that stop many symmetric-C2 concealment cases, but leaves residual where weak algorithms, key management, or non-electronic vectors are used.
- T1584.001prevents — A.5.14's policy, agreements, stronger authentication on public networks, access controls, non-repudiation, and incident-liability rules constrain several hijacking vectors (e.g. renewal gaps, help-desk social engineering, email-owner compromise, unauthorized subdomain creation) but leave residual paths such as direct cloud-provider compromise or dormant DNS entries unaddressed.
- T1589prevents — A.5.14's policy, rules, procedures and agreements on protecting information in transit (including electronic, physical and verbal channels) with controls against interception/unauthorized access, stronger authentication on public networks, anti-malware, non-repudiation, and reminders against disclosing sensitive info verbally or via insecure channels directly constrain several gathering vectors such as phishing for information, social media exposure, and verbal elicitation, but leave active scanning, search of victim-owned sites, and many public leaks untouched.
- T1589.001prevents — A.5.14's policy, rules, agreements, and controls on secure transfer (esp. electronic: malware detection, stronger auth on public nets, no SMS/IM for critical info, no auto-forward, approved services only) prevent some credential-gathering vectors such as interception of in-transit MFA/OTP, leaked creds via mis-sent messages, or public exposure of auth tokens, but leave the bulk of the technique (phishing elicitation, breach dumps, dark-web purchase, compromised-site cookie theft, infostealer logs) untouched.
- T1598detects — A.5.14 requires rules, procedures and agreements that include detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities, which can surface some phishing-for-information attempts (especially those involving malware or detectable anomalies), but the control is silent on detecting the core social-engineering elicitation, spoofing, or callback variants that dominate the technique.
- T1598prevents — A.5.14's policy, rules, procedures and agreements for electronic/verbal transfer (e.g. stronger authentication on public nets, no critical info via SMS/IM/fax, disclaimers, approved services, anti-misdelivery) directly constrain the social-engineering delivery and recipient behavior that enable T1598 phishing messages to succeed in eliciting info, but leave open adversary spoofing, evasive techniques, and non-compliant human actions as a substantial remainder.
- T1598.001prevents — A.5.14's policy, rules, approvals, stronger authentication on public nets, restrictions on external services (incl. social/file-sharing/IM), and explicit guidance against sending/receiving critical info via SMS/IM or insecure channels directly constrain the third-party service vectors and social-engineering lures used in T1598.001; residual slice remains because the control cannot stop an adversary from creating accounts and sending the initial message from outside the organization.
- T1598.002detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications (including attachments) plus controls to prevent misdelivery and ensure traceability, which surfaces some spearphishing attachment lures but leaves the social-engineering, reconnaissance-driven, and non-malware variants (e.g. HTML smuggling for credential harvest) outside its defined scope.
- T1598.002prevents — A.5.14 mandates rules, procedures, agreements, training/advisories, stronger authentication, malware detection, attachment protections, and restrictions on public services/forwarding/SMS/fax that directly constrain or block many delivery vectors and social-engineering lures for spearphishing attachments, but cannot stop all reconnaissance-crafted lures or every possible external delivery path.
- T1598.003detects — A.5.14 explicitly requires detection of malware transmitted through electronic communications (8.7) and controls to protect against misrouting/wrong-address delivery of messages containing links, both of which surface indicators of spearphishing-link lures; this is a genuine but minority slice of the full technique (social engineering text, QR codes, tracking pixels, BitB, proxy kits, and post-click credential harvesting remain out of scope).
- T1598.003prevents — A.5.14's policy, rules, procedures and agreements for electronic information transfer (including stronger authentication on public networks, malware detection in comms, restrictions on external services, anti-misdelivery measures, and explicit advisories against sending critical info via SMS/IM/fax) directly constrain or block many delivery vectors and social-engineering lures used by T1598.003, but leave open targeted email, QR codes on mobile, and adversary-in-the-middle kits that bypass those exact controls.
- T1598.004prevents — A.5.14 explicitly requires reminding personnel not to discuss confidential information over insecure channels (including phone calls that can be overheard) and to begin sensitive conversations with a classification disclaimer, which directly constrains the vishing technique from succeeding when the target follows the rules; this is only a slice because the control is awareness-based, does not stop the adversary from initiating the call or spoofing, and cannot reach victims who ignore the reminders.
- T1600.001prevents — A.5.14 mandates stronger authentication, cryptographic techniques, and controls against interception/modification of information in transit (including on networks), which directly counters weakening of ciphers on network devices; however, it is silent on device configuration integrity, firmware modification paths (T1601), and CLI-based parameter changes that enable the reduction.
- T1602.001prevents — A.5.14's policy, agreements, access controls, cryptographic protections, stronger authentication on public networks, and restrictions on electronic facilities can stop unauthorized SNMP queries that expose MIB data, but only for a minority slice (e.g. public/untrusted paths or misconfigured transfers); most SNMP MIB access occurs on managed internal networks where the control's transfer-focused rules do not reach the dominant technique.
- T1602.002detects — A.5.14 requires detection of malware in electronic transfers and traceability/non-repudiation controls that can surface anomalous transfers or access, but does not mandate monitoring for configuration dump techniques via management protocols like SNMP on network devices.
- T1602.002prevents — A.5.14's policy, agreements, access controls, cryptographic protections, authentication, and restrictions on electronic transfer facilities (including stronger auth on public networks and malware detection) prevent many forms of unauthorized network config access or exfiltration, but leave gaps for in-device access, misconfigured SNMP, or non-electronic vectors on network devices.
- T1621detects — A.5.14 requires detection of malware in electronic communications plus controls for traceability/non-repudiation, incident responsibilities, and advising on insecure channels, which can surface anomalous MFA push/SMS/call floods as potential incidents or misuse, but this is only a minority slice of the technique's core (credentialed login abuse and user fatigue) with no mandated monitoring of auth requests themselves.
- T1649prevents — A.5.14's rules on protecting information in transit (including crypto, access controls, non-repudiation, and secure transfer agreements) prevent some certificate theft vectors during electronic or physical transit but do not address forging, enrollment abuse, CA key compromise, or most post-compromise certificate use.
- T1657prevents — A.5.14's rules, procedures, agreements, authentication, labeling, malware detection, approval gates, restrictions on public services, and verbal-transfer reminders directly block or reduce success of BEC/social-engineering paths, misrouted transfers, and some ransomware-leak extortion vectors that rely on insecure information transfer, but do not address technical theft, bank hacking, cryptocurrency exploits, or post-compromise unauthorized transfers.
- T1659detects — A.5.14 mandates detection of and protection against malware transmitted through electronic communications plus traceability/non-repudiation and incident responsibilities that can surface anomalous transfers, but this is scoped only to organization-managed transfer policies, agreements and facilities and does not address upstream ISP-level or external channel compromises that enable the technique.
- T1659prevents — A.5.14 mandates rules, procedures, agreements, cryptographic protections, malware detection, stronger authentication on public networks, and restrictions on electronic transfer channels that directly constrain or block many forms of upstream/online traffic manipulation and content injection (especially ISP-level or man-on-the-side), but leaves open-ended residual paths such as lawful-interception compromises, certain side-channel races, and non-electronic vectors.
- T1667detects — A.5.14 requires detection of and protection against malware transmitted through electronic communications (plus traceability/non-repudiation and incident responsibilities), which can surface anomalous flooding patterns or the resulting inbox disruption as an incident, but does not mandate monitoring for volume-based email bombing itself.
- T1667prevents — A.5.14's rules on electronic transfer (esp. approval for public services, stronger auth on public nets, restrictions on auto-forwarding, malware detection in comms, and advising against insecure channels) constrain some signup-bombing and mass-mailing vectors but leave the dominant technique (automated bot registrations to unvalidated public lists) mostly untouched.
- T1669prevents — A.5.14 mandates topic-specific policy, rules, procedures and agreements (including stronger authentication on public networks, restrictions on facilities, malware protection, and controls against interception/unauthorized access) that directly constrain open or weakly secured Wi-Fi as an initial-access vector; it does not reach all adversary paths such as credential theft via Valid Accounts or dual-homed bridging.
- T1684detects — A.5.14's rules, procedures and reminders for electronic/verbal transfer (e.g. malware detection in comms, advising against SMS/fax/public conversations, approval for external services) surface some social-engineering indicators in transit channels, but the control's scope is limited to transfer mechanics and does not address the broader trust-building, urgency, or narrative patterns that define T1684.
- T1684prevents — A.5.14's rules, procedures, agreements, training reminders and controls (e.g. no confidential talk in public/insecure channels, disclaimers, stronger auth on public nets, approved services, malware detection on electronic transfer) directly constrain several social-engineering vectors (voice, email, SMS, fax, public conversations) that T1684 relies on, but leave large slices (e.g. help-desk impersonation, SaaS consent phishing, scare-tactic narratives inside approved channels, AI voice) untouched.
- T1684.001detects — A.5.14 mandates rules, procedures, agreements, and training to detect misrouting, unauthorized access, spoofed senders (via stronger authentication, contacts, chain-of-custody, and disclaimers), and anomalous transfers across electronic/physical/verbal channels, but only surfaces a slice of impersonation campaigns that manifest in those transfers rather than the full social-engineering technique.
- T1684.001prevents — A.5.14's policy, rules, procedures and agreements on information transfer (including electronic comms, authentication, approvals for external services, anti-misdelivery, and verbal-transfer reminders) directly constrain or block many impersonation vectors that rely on spoofed senders, unvetted channels, or social-engineering lures in transit, but leave open reconnaissance-driven domain acquisition, compromised-account reuse, and non-transfer social vectors.
- T1684.002detects — A.5.14 mandates detection of malware in electronic communications plus traceability/non-repudiation and incident responsibilities that can surface spoofed emails after delivery, but the control is silent on DMARC/SPF/DKIM monitoring or header-authentication failure detection and does not require instrumentation that would catch the technique in flight.
- T1684.002prevents — A.5.14 mandates topic-specific policies, stronger authentication on public networks, controls against misrouting/wrong addresses, malware detection in electronic comms, and agreements that can enforce DMARC/SPF/DKIM-like measures, which directly stop many email-header spoofing vectors; it leaves gaps for internal Direct Send abuse, weak p=none policies, and non-enforced implementations.
Prevented OWASP Web Top 10 (2025) risks (9)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- A04mitigates — A.5.14 requires cryptographic techniques (see 8.24) plus stronger authentication on public networks and other protections that bound the realized consequence of weak/misused crypto for data in transit, but does not address at-rest exposure, algorithm selection, key management, or correct implementation of the cryptography itself.
- A04prevents — A.5.14 mandates topic-specific policies, rules, procedures and agreements that require cryptographic techniques (see 8.24), stronger authentication on public networks, and protections against interception/misrouting for information in transit, directly addressing the 'in transit' slice of A04:2025; it does not address at-rest exposure, weak/misused crypto implementation details, or algorithm selection.
- A05mitigates — A.5.14's electronic-transfer rules (malware detection in 8.7, stronger auth on public nets, restrictions on forwarding/SMS/fax, and controls against misrouting) bound the consequence of some injection vectors (esp. outbound C2/exfil or SSRF-like cases) but do not address the core neutralization failure at the interpreter boundary for dominant members like SQLi, XSS, or command injection.
- A08mitigates — A.5.14's rules for protecting information in transit (esp. electronic: malware detection, attachment protection, correct addressing, stronger auth on public nets, restrictions on forwarding/SMS/fax) bound the consequences of integrity failures such as unsigned updates or CI/CD path tampering during transfer, but do not address the core weakness of trusting code/data without verification (e.g. insecure deserialization, missing signatures on updates).
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.