A.5.15 Organizational
Access control
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 (30)
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-2mostlycovers — A.5.15's broad mandate to ensure authorized access and prevent unauthorized access accounts for the bulk of ac-2's account-type, user, group/role, and privilege specification requirements, but leaves a residual of procedural elements (assigning dedicated account managers, formal approval workflows) uncovered.
- AC-24mostlycovers — A.5.15's broad mandate to ensure authorized access and prevent unauthorized access accounts for the core of AC-24's requirement to make and apply access control decisions on every request, but leaves a residual on the specific 'prior to enforcement' sequencing and any organization-defined parameters not explicitly required by the ISO control.
- AC-3mostlycovers — ISO A.5.15 establishes the overarching access control policy and rules that enforce who may access what, directly fulfilling the core intent of AC-3.
- AC-6mostlyaligns with — The control explicitly requires restricting privileged access and applying the need-to-know principle, which aligns with the least-privilege objective of AC-6.
- AC-6mostlycovers — A.5.15's broad mandate to ensure authorized access and prevent unauthorized access accounts for the bulk of AC-6's least-privilege requirement, but leaves a real residual: AC-6 explicitly requires the finer-grained 'only those accesses necessary for assigned tasks' (need-to-know / minimal rights), which A.5.15 does not itself mandate or detail.
- AC-16partialaligns with — Consistency between access rights and information classification is mandated, reflecting the security-attribute usage that AC-16 governs.
- AC-2partialaligns with — A.5.15 addresses the authorization and ongoing management of access rights, which overlaps with the account provisioning and rights-management aspects of AC-2.
- AC-24partialaligns with — The guidance requires formal authorization of access requests and segregation of access-control functions, which supports the access-decision process addressed by AC-24.
- AC-5partialaligns with — Segregation of duties is listed as a required consideration when defining access control rules, matching the separation objective of AC-5.
- AC-5partialcovers — A.5.15's broad mandate for authorized access and preventing unauthorized access addresses only a slice of ac-5; it does not itself require identifying/documenting the specific duties or defining access authorizations explicitly to enforce separation of duties.
Aligned NIST CSF 2.0 outcomes (17)
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)
- PR.AA-05fullcovers — The ISO control establishes and enforces policy-based access permissions, entitlements, and authorizations while incorporating the need-to-know principle, segregation of duties, and formal authorization processes.
- PR.AA-01mostlyaligns with — Both require systematic management of identities and credentials for users, services, and hardware, including role-based assignment and lifecycle handling of access rights.
- PR.AA-06mostlyaligns with — The control explicitly integrates physical access requirements with logical access control, ensuring physical entry controls support the overall access policy.
- GV.PO-01partialaligns with — The ISO control requires a topic-specific access control policy derived from organizational context, business requirements, and legal obligations.
- ID.AM-05partialaligns with — Access rights are defined and mapped according to asset classification, criticality, and business impact, aligning with the CSF outcome of prioritizing assets for protection.
- GV.PO-01implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. 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.AM-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.AA-01implements — A.5.15's operational mechanisms for enforcing authorized access directly give effect to the identity/credential management outcome named in PR.AA-01 within the access-control domain (though PR.AA-01 does not cite A.5.15 by name)
- PR.AA-06implements — A.5.15's mandate to prevent unauthorized access to assets directly operationalizes physical-access enforcement as one core means within its broad access-control domain (the PR.AA-06 outcome names physical access to assets as the end, and A.5.15 supplies the technical mechanism that achieves it).
Related OWASP ASVS 5.0 requirements (14)
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)
- V8.2.1fullcovers — The ISO control’s mandate to implement access rights and restrictions directly implements the ASVS requirement that function-level access be restricted to entities with explicit permissions.
- V8.2.2fullcovers — ISO’s requirement to map access rights to specific information assets aligns with the ASVS rule that data-specific access must be limited to consumers with explicit permissions for those items.
- V8.1.1mostlyaligns with — Both require documented rules that map consumer permissions to function-level and data-specific access restrictions.
- V8.3.1mostlyaligns with — ISO’s emphasis on formal authorization, segregation of duties, and enforcement at a trusted layer mirrors the ASVS requirement that authorization decisions be enforced by a trusted service rather than an untrusted consumer.
- V8.2.3partialaligns with — The ISO guidance on consistency between access rights and information classification supports the ASVS objective of restricting field-level access based on explicit permissions.
- V8.3.3partialaligns with — The ISO principle that access is granted to the originating entity (user, service, or device) aligns with the ASVS rule that object access must be based on the originating subject’s permissions, not any intermediary.
- V8.4.1partialaligns with — ISO’s requirement to consider segregation of duties and need-to-know supports the ASVS objective of preventing cross-tenant operations in multi-tenant environments.
Related weaknesses / CWE (106)
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).
CWE-1220←P →PCWE-1230←P →PCWE-1268←P →PCWE-1323←P →PCWE-1334←P →PCWE-15←P →PCWE-202←P →MCWE-213←P →PCWE-219←P →PCWE-250→PCWE-266←P →PCWE-267←P →PCWE-268←P →PCWE-269→PCWE-270←P →PCWE-274←P →PCWE-278←P →PCWE-280←P →PCWE-281←PCWE-282←PCWE-283←P →PCWE-284→FCWE-285→PCWE-286←P →PCWE-288←P →PCWE-289←P →PCWE-290←P →PCWE-291←P →PCWE-302←PCWE-308←P →PCWE-309←PCWE-384←PCWE-402←P →MCWE-408←P →PCWE-424←P →PCWE-425←P →PCWE-441←P →PCWE-527←P →PCWE-528←P →PCWE-529←P →PCWE-530←P →PCWE-540←P →PCWE-566→PCWE-612←P →PCWE-638←P →PCWE-639←P →PCWE-642←P →PCWE-645←PCWE-653←PCWE-654←P →PCWE-669←PCWE-671←PCWE-673←PCWE-708←P →PCWE-732→MCWE-837←PCWE-842←P →PCWE-862→PCWE-863→PCWE-921←P →MCWE-939→P
Why these map — AI rationale (under review)
- CWE-282nonemitigates — Access control policies can enforce correct ownership assignment and verification for objects.
- CWE-653nonemitigates — Access control policies establish the boundaries that isolation must enforce.
- CWE-669nonemitigates — Access-control policies limit unintended control over transferred resources.
- CWE-673nonemitigates — Access control policies and enforcement directly limit who can define or modify control spheres.
- CWE-1220prevents — Establishes the overarching access-control policy whose granularity directly determines whether the weakness exists.
- CWE-1230mitigates — Access-control rules can be extended to metadata objects, though the control is not metadata-specific.
- CWE-1268prevents — Defines the overarching access-control policy that should enforce consistent privileges between control and data agents.
- CWE-1323prevents — Access-control policies limit who can read or move trace buffers.
- CWE-1334prevents — Access control limits who can reach redundant hardware blocks, reducing the chance of unauthorized error injection.
- CWE-15prevents — Access control policies underpin the technical restrictions on configuration changes.
- CWE-202prevents — Access control limits who can run queries that could expose sensitive information via inference.
- CWE-213prevents — Access control can limit exposure to actors whose policies differ from the developer’s.
- CWE-219mitigates — Access-control policy defines who may reach files under the web root.
- CWE-250prevents — The requirement to restrict privileged access and apply segregation of duties limits the number of processes or accounts that must run with elevated rights, lowering the impact of unnecessary privilege assignments.
- CWE-266prevents — Access control policy directly prevents incorrect privilege assignment by defining who may receive which rights.
- CWE-267mitigates — Access control policy can limit unsafe privilege use but does not define safe actions for each privilege.
- CWE-268prevents — Access control policies can limit the combination of privileges that enable unsafe actions.
- CWE-269prevents — Explicit restrictions on privileged access and segregation of duties limit the scope of privileges that can be assigned, reducing the chance that excessive or unnecessary privileges are granted to entities.
- CWE-270prevents — Access-control policy defines privilege boundaries but does not guarantee correct switching logic.
- CWE-274prevents — Access control policy defines privilege boundaries but does not guarantee correct runtime handling when privileges prove insufficient.
- CWE-278prevents — Access control policies can require explicit permission review on object creation or copy, reducing inherited insecure permissions.
- CWE-280prevents — Defines access-control policy that should prevent insufficient-privilege situations.
- CWE-283prevents — Access control policies can require ownership verification before granting access to critical resources.
- CWE-284prevents — Defining and enforcing explicit access rights and restrictions for each entity directly stops the assignment of permissions that exceed what is required, eliminating the root condition that allows improper access control.
- CWE-285prevents — Mapping access rights to information classification and business requirements forces correct enforcement of authorization decisions, blocking the incorrect authorization weakness at the policy and implementation stage.
- CWE-286prevents — Access control policies rely on accurate user management but do not themselves define user lifecycle processes.
- CWE-288prevents — Access control policy directly addresses alternate authentication paths by requiring all channels to enforce authentication.
- CWE-289prevents — Access-control policy can mandate canonical-name checks but does not prescribe the technical implementation.
- CWE-290prevents — Access control policy reduces spoofing opportunities but does not prescribe authentication mechanisms.
- CWE-291prevents — Access-control policy can mandate stronger authentication than IP address alone.
- CWE-308prevents — Access control policy can mandate multi-factor authentication but does not prescribe the technical implementation.
- CWE-402prevents — Access-control mechanisms limit who can receive resources that should remain internal.
- CWE-408prevents — Access control policies that enforce authentication before resource-intensive operations directly prevent early amplification.
- CWE-424prevents — Access control policy directly requires protection of all entry points to restricted functionality.
- CWE-425prevents — Access control policy directly requires authorization checks on all resources, preventing forced browsing.
- CWE-441prevents — Access-control rules can limit which upstream identities may cause the product to act on their behalf, reducing confused-deputy risk.
- CWE-527prevents — Access control policies directly prevent unauthorized actors from reaching version-control repositories.
- CWE-528prevents — Access-control policies can restrict who may read core-dump files, yet the control is broader than this specific weakness.
- CWE-529prevents — Access control policy directly requires restricting ACL files to the intended control sphere.
- CWE-530prevents — Access control directly limits who can reach backup files, though it does not address how backups are created or stored.
- CWE-540prevents — Access control limits who can view or retrieve source code that may contain secrets.
- CWE-566prevents — Access-control policy sets the governance expectation that all data access must be authorized, indirectly supporting prevention of CWE-566.
- CWE-612prevents — Access control policies directly limit who can query or view the index.
- CWE-638prevents — Access control policy directly requires checks on every access, preventing stale privileges.
- CWE-639prevents — Access control policy directly requires enforcement of authorization rules that prevent unauthorized access via manipulated keys.
- CWE-642prevents — Access control policies directly limit who can read or modify security-critical state data.
- CWE-654prevents — Access control policy can mandate multi-factor checks, but does not guarantee implementation.
- CWE-708prevents — Access-control policy can mandate correct ownership assignment, but does not prescribe how ownership is technically enforced.
- CWE-732prevents — By requiring owners to determine and document the exact permissions needed for each asset, the control reduces the likelihood that default or overly permissive file and resource permissions will be left in place.
- CWE-842prevents — Access control policy defines group membership rules but does not guarantee correct assignment.
- CWE-862prevents — Requiring formal authorization of every access request before rights are granted ensures that checks for required permissions are performed, preventing missing authorization checks from being introduced.
- CWE-863prevents — Requiring consistency between access rights and classification plus formal approval steps ensures that the authorization logic correctly distinguishes between entities that should and should not be granted access.
- CWE-921prevents — Access control policy directly requires protection of sensitive data wherever it is stored.
- CWE-939prevents — High-level access-control policy provides governance context but does not prescribe the technical authorization logic needed for URL-scheme handlers.
Mitigated MITRE ATT&CK techniques (813)
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←MT1001.003←MT1003←M →PT1003.001←M →PT1003.002←M →PT1003.003←M →PT1003.004←M →PT1003.005→PT1003.006→PT1003.007→PT1003.008→PT1005→PT1006←M →PT1008←MT1011←M →PT1011.001←MT1014←MT1020→PT1021→PT1021.001→PT1021.002←M →PT1021.003←P →PT1021.004←M →PT1021.005←M →PT1021.006→PT1021.007→PT1021.008→PT1027.001←MT1027.002←MT1027.005←MT1027.006←MT1027.007←MT1027.008←MT1027.009←MT1027.010←MT1027.011←MT1027.014←MT1027.016←MT1027.017←MT1027.018←MT1030←MT1036←MT1036.002←MT1036.003←MT1036.004←MT1036.005←MT1036.006←MT1036.007←MT1036.008←MT1036.009←MT1036.010←MT1036.011←MT1036.012←MT1037→PT1037.001→PT1037.002→PT1037.003→PT1037.004→PT1039←M →PT1040←M →PT1046→PT1047←M →PT1048←M →PT1049→PT1052←M →PT1052.001←M →PT1053→PT1053.002←M →PT1053.003→PT1053.005←M →PT1053.006→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←MT1056←MT1056.002←MT1056.003←M →PT1056.004←PT1057→PT1059←MT1059.001→PT1059.002→PT1059.003→PT1059.007→PT1059.008←M →PT1059.009←M →PT1059.012→PT1059.013←M →PT1068←M →PT1069→PT1069.001→PT1069.002→PT1069.003→PT1070←MT1070.003←MT1070.006←MT1070.010←MT1071←MT1071.001←MT1071.002←MT1071.003←MT1071.004←MT1071.005←MT1072←M →PT1074.002←PT1078→MT1078.001→PT1078.002→MT1078.003→PT1078.004→PT1080→PT1083→PT1087→PT1087.001→PT1087.002→PT1087.003→PT1087.004→PT1090←MT1090.001←MT1090.002←MT1090.003←MT1090.004←MT1091←M →PT1095←MT1098→PT1098.001←M →PT1098.002→PT1098.003→PT1098.004←M →PT1098.005→PT1098.006←M →PT1098.007→PT1102←MT1102.001←MT1102.002←MT1102.003←MT1110→PT1110.001→MT1110.002→MT1110.003→MT1110.004→MT1111←M →PT1112←P →PT1114→PT1114.001→PT1114.002←M →PT1114.003→PT1119→PT1127←MT1127.001←MT1127.002←M →PT1127.003←MT1132.001←PT1132.002←PT1133→PT1134→PT1134.001→PT1134.002→PT1134.003←M →PT1134.004←MT1134.005←MT1135→PT1136←P →PT1136.001←M →PT1136.002←M →PT1136.003←M →PT1137→PT1137.001→PT1137.002→PT1137.003→PT1137.004→PT1137.005→PT1137.006→PT1176←M →PT1176.001←P →PT1185←M →PT1187→PT1189←MT1190←M →PT1199←M →PT1200←M →PT1202←M →PT1203←PT1204←PT1204.001←MT1204.002←M →PT1204.003←MT1204.004←MT1204.005←MT1205←MT1205.001←MT1207←M →PT1210←M →PT1211←MT1212←MT1213→PT1213.001→PT1213.002←M →PT1213.003←M →PT1213.004→PT1213.005←M →PT1213.006→PT1216←MT1216.001←MT1216.002←MT1218←MT1218.002←M →PT1218.003←M →PT1218.004←M →PT1218.005←M →PT1218.007←MT1218.008←M →PT1218.009←MT1218.010←M →PT1218.011←MT1218.012←M →PT1218.013←MT1218.014→PT1219←M →PT1219.001←MT1219.002←M →PT1219.003←M →PT1220←MT1221←PT1222←M →PT1222.001←M →PT1222.002←M →PT1480.001←MT1484←M →PT1484.001→PT1484.002←M →PT1485.001→PT1489←PT1496.004→PT1497←MT1497.001←MT1497.002←PT1499←PT1505.001→PT1505.003←M →PT1505.005←MT1525→PT1526→PT1528←M →PT1529←PT1530→PT1531←MT1534←M →PT1535←MT1537←M →PT1538→PT1539→PT1542←MT1542.001←PT1542.002←MT1542.003←MT1542.005←MT1543.001→PT1543.002→PT1543.003←M →PT1543.004→PT1543.005→PT1546→PT1546.002→PT1546.003→PT1546.004→PT1546.008←M →PT1546.011←P →PT1546.012←P →PT1546.013→PT1546.014→PT1546.016→PT1546.017→PT1547→PT1547.001←M →PT1547.003→PT1547.004→PT1547.006→PT1547.007→PT1547.009→PT1547.010→PT1547.012→PT1547.013→PT1547.014→PT1547.015→PT1548→PT1548.001←M →PT1548.002←M →PT1548.003←M →PT1548.004←M →PT1548.005←M →PT1548.006←M →PT1550→PT1550.001←F →PT1550.002←F →PT1550.003→PT1550.004←F →PT1552←P →PT1552.001→PT1552.004→PT1552.005←M →PT1552.006←M →PT1552.007→PT1552.008←M →PT1553←MT1553.001←MT1553.002←PT1553.003←M →PT1553.004←MT1553.005←MT1553.006←M →PT1554←PT1555←M →PT1555.001→PT1555.003→PT1555.004→PT1555.005→PT1555.006→PT1556←M →PT1556.001←MT1556.002←PT1556.003←M →PT1556.004←MT1556.005←P →PT1556.006→PT1556.007←M →PT1556.008←M →PT1556.009→PT1557←M →PT1557.001←M →PT1557.002←MT1557.003←MT1557.004←M →PT1558←M →PT1558.001←M →PT1558.002←M →PT1558.003→PT1558.004→PT1558.005→PT1559.002→PT1559.003→PT1561←PT1561.002→MT1563→PT1563.001←M →PT1563.002←M →PT1564←MT1564.001←MT1564.004←MT1564.008→PT1565→PT1565.001→PT1566→PT1566.002→PT1566.003←M →PT1566.004→PT1567.001→PT1567.002→PT1567.003→PT1567.004→PT1568←MT1568.002←MT1568.003←MT1569→PT1569.002→PT1569.003→PT1570←P →PT1571←MT1572←M →PT1574←MT1574.001←M →PT1574.004←MT1574.005→PT1574.006←M →PT1574.007→PT1574.008←M →PT1574.009→PT1574.010←M →PT1574.011←P →PT1574.012→PT1574.013←MT1578←M →PT1578.001←MT1578.002←MT1578.003←MT1578.004←MT1578.005←M →PT1580→PT1583.007←MT1584←MT1584.006←MT1584.007←PT1584.008←MT1585←MT1586←M →PT1586.002←MT1586.003→PT1587.001←MT1589.001←P →PT1590.003←MT1595.003→PT1598.001→PT1598.003←MT1599←M →PT1599.001←MT1600←PT1600.001←PT1601←PT1601.001←M →PT1601.002←MT1602←M →PT1602.001→PT1602.002→PT1606←M →PT1606.001←F →PT1606.002←M →PT1609←M →PT1610←P →PT1611←M →PT1612←PT1619→PT1620←MT1621←M →PT1622←PT1647←MT1648→PT1649←M →PT1650←MT1651→PT1653←PT1654→PT1657→PT1659←MT1665←PT1666←M →PT1668←PT1669←M →PT1671←M →PT1675→PT1677→PT1678←MT1679←PT1684←M →PT1684.001←PT1684.002←MT1685←MT1685.001←M →PT1685.002←M →PT1685.003←MT1685.004←MT1685.005←MT1685.006←MT1686←FT1686.001←M →PT1686.002←M →PT1686.003←MT1687←MT1688←MT1689←MT1690←M
Why these map — AI rationale (under review)
- T1003prevents — A.5.15's policy-driven determination and enforcement of access rights, need-to-know, privileged restrictions, segregation, and logging directly constrain many credential-dumping vectors (especially those relying on unauthorized logical or privileged access to memory, caches, or structures), but physical, dynamic, and post-compromise techniques remain outside its defined scope.
- T1003.001prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, segregation of duties, and formal authorization of rights directly constrain who can reach LSASS (a privileged SYSTEM process) and its credential material, preventing the administrative/SYSTEM-level access the technique requires in most cases; it does not reach in-memory dumping by already-compromised code executing as SYSTEM or SSP modifications.
- T1003.002prevents — A.5.15's policy, requirements, role-based rules, need-to-know, privileged-access restrictions and logging directly constrain who can reach SYSTEM-level access or the SAM database, stopping the technique for the bulk of non-privileged entities while leaving a bounded remainder (legitimate SYSTEM processes, misconfigured privileged accounts, and dynamic-access edge cases).
- T1003.003prevents — A.5.15 requires determining access needs, defining/enforcing topic-specific access control policy and rules (including need-to-know, privileged restrictions, segregation, formal authorization, and consistency with classification), which constrains who can reach the NTDS file or its backups on domain controllers and limits the technique's success for unauthorized entities.
- T1003.004prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and consistent access rights directly constrain the SYSTEM-level privilege and credential-dumping path that T1003.004 relies on; this is a genuine but minority slice of the technique (the remainder is post-compromise execution that policy alone does not stop).
- T1003.005prevents — A.5.15's policy, requirements, and rules for determining, restricting, and formally authorizing access (including need-to-know, privileged restrictions, segregation, logging, and consistency with classification) can prevent unauthorized entities from reaching the cached credential stores, but this is only a slice of the technique which also relies on already-elevated SYSTEM/sudo access that the control does not itself block.
- T1003.006prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy, mapping rights to entities/roles, considering need-to-know, privileged restrictions, segregation, formal authorization, and consistency with classification — which directly constrains who can legitimately replicate from a DC and thereby prevents the DCSync technique from being available to unauthorized entities; it is only partial because the control is governance-oriented (policy and requirements) rather than a technical enforcement mechanism that stops a privileged admin from actually invoking the API.
- T1003.007prevents — A.5.15's topic-specific policy, entity access determination, need-to-know, privileged restrictions, segregation, and rule mapping (including consistency with classification and perimeter needs) can constrain who may reach /proc entries that expose other processes' credential-bearing memory, but leaves self-access, browser-context, and unaddressed dynamic/kernel-interface cases untouched.
- T1003.008prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, privileged restrictions, formal authorization, and consistent rights mapping directly constrain who can reach /etc/shadow (readable only by root by default), preventing the technique for non-authorized entities; partial because it is governance that does not itself enforce runtime checks or close all technical paths (e.g. root compromise, misconfigurations).
- T1005prevents — A.5.15's policy-driven determination and enforcement of who gets which type of access (including need-to-know, classification, privileged restrictions, and consistent rights mapping) directly stops many unauthorized local-file reads that constitute T1005; it does not reach every local collection vector (e.g., memory scraping inside an already-authorized process or unclassified data).
- T1006prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access types, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and mapping of access rights (including consistency with classification and perimeter needs) directly constrain the ability of unauthorized entities to obtain the direct volume access rights that enable T1006, though it does not address all technical bypass vectors or dynamic elements in full.
- T1011prevents — A.5.15's policy-driven access control rules, entity-specific rights, need-to-know, segregation, and consistency with classification/perimeter/dynamic factors can prevent unauthorized use of alternate network mediums (e.g. WiFi, Bluetooth, cellular) for exfiltration where access is the gating factor, but this is only a minority slice of the technique given its reliance on proximity, physical access, and alternate-medium defenses outside core logical access enforcement.
- T1020prevents — A.5.15's policy-driven determination and enforcement of who may access what (need-to-know, classification, roles, restrictions on privileged and distributed connections) directly constrains the sensitive data that can be collected and thus automated-exfiltrated, but leaves the post-compromise automation itself and many lateral paths untouched.
- T1021prevents — A.5.15 requires a topic-specific access control policy, determination of who needs what access (including need-to-know, privileged restrictions, segregation), formal authorization, and consistent rule enforcement that directly constrains use of valid accounts for unauthorized remote logins; however, it is governance/planning that does not itself implement or enforce the technical mechanisms (those live in 5.16/5.18 and 8.x references), leaving a large remainder.
- T1021.001prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider entity access needs, privileged restrictions, need-to-know, formal authorization, logging, and consistency with classification/perimeter — which directly constrains when and which accounts may legitimately use RDP, thereby stopping many (but not all) unauthorized RDP logons that rely on valid accounts with overly broad rights.
- T1021.002prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider network shares, distributed connections, need-to-know, privileged-access restrictions, and consistency with classification/perimeter needs; this stops many (but not all) unauthorized SMB/admin-share uses of valid accounts, especially those relying on misconfigured or overly permissive shares.
- T1021.003prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific access control policy (including restrictions on privileged access, need-to-know, segregation, formal authorization, and consistency with classification/perimeter), and implementing mapped access rights/rules for entities; this directly constrains the valid-account + DCOM lateral movement path at the policy and rights-assignment layer, but leaves a bounded remainder (e.g., already-granted admin rights, dynamic factors, or mis-mapped COM ACLs that the control does not itself harden).
- T1021.004prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider entity access needs, need-to-know, privileged restrictions, segregation, formal authorization, and consistency with classification — directly constraining which valid accounts can legitimately authenticate via SSH, so the technique cannot run for unauthorized entities; partial because it is governance/policy that does not itself implement or enforce the technical mechanisms (e.g. keypair files, daemon config, or runtime auth checks) referenced in the technique.
- T1021.005prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy, mapping rights to entities (including network services), considering all connection types in distributed environments, and consistency with classification/perimeter needs, which constrains unauthorized VNC use via valid accounts or weak configs; it does not guarantee enforcement of those rules or address brute-force/memory exploits in VNC implementations themselves.
- T1021.006prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider remote access, network services, need-to-know, privileged restrictions, and consistency with classification, which directly stops many (but not all) valid-account WinRM abuse paths.
- T1021.007prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization, need-to-know, segregation, and consistent rule enforcement that directly constrains which synchronized/federated accounts can legitimately reach cloud services, preventing the adversary technique from succeeding when followed; partial because the control is governance-oriented, stops short of mandating technical enforcement mechanisms (e.g. MFA, token validation, session controls) that live in referenced clauses, and leaves residual paths such as stolen tokens or misconfigured federation.
- T1021.008prevents — A.5.15's policy, requirements, rules, and role-based mapping for determining and enforcing authorized access (including privileged, need-to-know, segregation, and consistency with classification) directly constrain the abuse of valid accounts for direct cloud VM console logins, but leave real residual via default-privileged cloud-native methods, dynamic factors, physical perimeter gaps, and incomplete enforcement on all connection types.
- T1037prevents — A.5.15's policy, requirements, and rules for determining, authorizing, restricting, and managing access rights (including privileged access, need-to-know, segregation, and consistency with classification) can stop unauthorized entities from configuring or applying malicious boot/logon scripts, but this is only a slice of the technique (e.g., does not block local admin use of permitted scripts or all persistence paths).
- T1037.001prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, privileged restrictions, segregation, formal authorization, and consistent rights mapping directly constrain who can legitimately modify HKCU logon-script registry values or assign such scripts, preventing the technique for the bulk of unauthorized cases while leaving a bounded remainder (e.g., already-authorized local admin or misconfigured legitimate scripts).
- T1037.002prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, formal authorization of requests, and consistent mapping of rights (including to system resources like plists), which constrains the admin-level modification needed for a malicious LoginHook but does not eliminate it when admin rights are already present or policy is bypassed.
- T1037.003prevents — A.5.15's policy, requirements, rules, and restrictions on access rights (including privileged access, need-to-know, segregation, formal authorization, and consistency with classification) can constrain who may assign or modify network logon scripts in AD/GPO, thereby preventing the technique from being available to the adversary in many configurations.
- T1037.004prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, formal authorization of changes, and consistent rules that limit entities (including processes) to only authorized assets; this constrains the root-level modification of RC scripts on many Unix-like systems but leaves real residual on lightweight/default-root platforms (ESXi, embedded), deprecated mechanisms, and cases where the policy is not enforced at the file-permission or boot-script level.
- T1039prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, and consistency with classification directly constrain which entities can reach network shares, preventing the technique from succeeding on properly segmented/classified shares; it is only partial because the control is governance-oriented, does not itself enforce runtime access decisions (those live in 5.16/8.x), and leaves residual paths such as already-compromised legitimate sessions or misclassified shares.
- T1040prevents — A.5.15's policy-driven access control rules (need-to-know, restrictions on privileged access, segregation, formal authorization, and consistency with classification/perimeter) can prevent sniffing of sensitive data by limiting who is authorized to access network segments or promiscuous-mode interfaces, but this is only a minority slice against the full technique (especially passive capture, unencrypted protocols, cloud mirroring, and network-device CLI methods).
- T1046prevents — A.5.15's policy-driven access control rules (need-to-know, restrictions on privileged access, consistency with classification and perimeter needs, limiting connections to authorized assets) can block many discovery vectors when enforced at network/service boundaries, but leaves open-ended slices such as local Bonjour/mDNS, unmonitored cloud APIs, and scans from already-authorized footholds.
- T1047prevents — A.5.15 requires a topic-specific access control policy, entity-specific rights mapping, need-to-know, privileged-access restrictions, and consistency checks that can constrain WMI abuse for remote/local access and execution on Windows, but leaves many legitimate WMI/programmatic uses (local admins, scripts, management tools) intact and does not reach the technique's full surface.
- T1048prevents — A.5.15's policy-driven determination of authorized access, need-to-know, role-based rules, and restrictions on entities (including network services) can block many unauthorized exfiltration channels when enforced, but leaves open slices such as approved SaaS/IaaS web consoles, dynamic access factors, and legitimate protocols that adversaries can still abuse.
- T1049prevents — A.5.15's policy-driven access control rules (need-to-know, least-privilege restrictions, role-based mapping, and consistency with classification/perimeter) can prevent an adversary from ever gaining the authorized access required to run discovery commands like netstat/lsof on the target system; this is only a slice of the technique because the control is silent on post-compromise execution once access is obtained and does not reach all listed platforms or dynamic/cloud scenarios.
- T1052prevents — A.5.15's policy, requirements, and rules on access control (including physical access, need-to-know, restrictions on privileged access, and consistency with physical perimeter security) can prevent unauthorized entities from using removable media for exfiltration in many cases, but this is only a slice: the control is governance-oriented, does not itself enforce technical blocks (e.g. USB port disabling or device whitelisting live in 7.x and 8.x), and leaves air-gapped user-introduced media as a bounded remainder.
- T1052.001prevents — A.5.15's policy, requirements, and rules for determining authorized access (including physical, need-to-know, and perimeter controls) directly constrain when and how entities may use USB devices for data movement, stopping the technique in many air-gapped/user-introduced cases; it does not reach all technical vectors or enforcement gaps.
- T1053prevents — A.5.15's policy, requirements, and rules for determining/assigning access rights (incl. least-privilege, need-to-know, privileged restrictions, and formal authorization) can stop unauthorized entities from creating or scheduling tasks under elevated contexts, but this is only one slice of the technique (remote auth, persistence via startup tasks, and masking under trusted processes remain reachable).
- T1053.002prevents — A.5.15 requires a topic-specific access control policy, determination of which entities get which access (including privileged/restricted use of tools like at), formal authorization of requests, management of rights, and consistency with classification/need-to-know, which can prevent unauthorized users from being able to invoke at; this is only a minority slice of the technique because the control is governance/planning-oriented, does not itself enforce technical restrictions on at (or at.allow/at.deny), and leaves most of the abuse surface (admin/superuser use, sudo, WMI) untouched.
- T1053.003prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and formal authorization directly constrain who may create or modify crontab entries (the root technique), but the control is silent on enforcement mechanisms, cron daemon behavior, and residual vectors such as legitimate-but-abused scheduled tasks or non-human entities, leaving a genuine minority slice unaddressed.
- T1053.005prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, restrictions on privileged access, segregation of duties, formal authorization of requests, and consistent mapping of access rights directly constrain abuse of the Task Scheduler for unauthorized/persistent execution under elevated contexts (e.g. SYSTEM), but leave open the remainder of technique variants that use already-authorized accounts, hidden tasks via registry manipulation, or non-privileged persistence.
- T1053.006prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, and formal authorization requirements can constrain who may create or activate privileged systemd timers (especially in /etc or via systemctl), but do not stop the technique outright for user-level timers, misconfigurations, or already-authorized entities.
- T1056.003prevents — A.5.15's policy-driven access control rules, need-to-know, privileged restrictions, and entity mapping can prevent unauthorized installation of credential-capturing code on portals when the adversary lacks admin rights, but the technique explicitly allows post-compromise use of legitimate administrative access that the control does not block.
- T1057prevents — A.5.15's policy-driven access control rules (need-to-know, least privilege via roles, segregation, formal authorization, logging) can prevent unauthorized entities from running process-enumeration commands on many platforms, but this is only a minority slice of the technique because the control is silent on technical enforcement mechanisms, does not reach admin/elevated sessions that legitimately see all processes, and leaves the bulk of discovery vectors (ps, /proc, Tasklist, native APIs) intact for authorized contexts.
- T1059.001prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and consistency with classification can prevent many (but not all) unauthorized uses of PowerShell by non-privileged or unapproved entities; the technique's in-memory/.NET-assembly execution paths and admin-permitted remote use remain reachable under the control's own carve-outs.
- T1059.002prevents — A.5.15's policy-driven access control rules, entity/role mapping, need-to-know, privileged restrictions, and consistency with classification can prevent unauthorized AppleScript execution against protected assets when the script would require crossing an access boundary, but leaves many execution vectors (local scripts, already-authorized apps, non-access-control abuses) untouched.
- T1059.003prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and segregation of duties can prevent many unauthorized invocations or permission escalations needed to abuse cmd.exe, but the control is silent on interpreter removal, whitelisting, or blocking legitimate-but-abused shells, leaving a large residual slice of the technique reachable under authorized access.
- T1059.007prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, and consistency rules for classification/perimeter can constrain which entities are authorized to invoke JS interpreters or run JS-based payloads, preventing the technique where it would require unauthorized access; this is only a slice of the class because the control is governance-oriented, does not reach JS execution inside already-authorized processes or browsers, and leaves technical enforcement to referenced controls such as 8.2/8.26.
- T1059.008prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that map rights/restrictions (including privilege limits, need-to-know, role-based groups, and consistency with classification) to entities; this directly constrains which users can reach and run privileged CLI commands on network devices, preventing the technique for the bulk of intended access paths, but leaves a remainder for misconfigured or bypassed enforcement on distributed/remote connections.
- T1059.009prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules (including need-to-know, least-privilege restrictions on privileged access, formal authorization, role-based mapping, and consistency with classification) that directly constrain which entities may invoke cloud APIs; this stops the technique when the adversary lacks proper permissions, but leaves a bounded remainder when valid credentials or dynamic factors are already compromised.
- T1059.012prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, formal authorization, and consistent rules that limit entities (including services) to only authorized assets and connections; this constrains abuse of hypervisor CLIs by unauthorized or over-privileged entities but leaves the legitimate administrator path and dynamic factors unaddressed.
- T1059.013prevents — A.5.15's policy-driven determination of who needs what access (including restrictions on privileged use, segregation of duties, need-to-know, formal authorization, and role-based mapping) can stop unauthorized entities from reaching the Docker/K8s CLI or API surfaces that enable T1059.013, but leaves a bounded remainder where legitimate container admins or misconfigured services retain the rights that adversaries then abuse.
- T1068prevents — A.5.15's policy, requirements, rules, and role-based mapping for determining and enforcing authorized access (including restrictions, least-privilege-like segregation, and consistency with classification) directly constrain the permission-level constructs that T1068 must circumvent, so the technique cannot succeed where those rules are fully applied; it is only partial because the control is governance-oriented, stops short of mandating specific technical enforcement mechanisms or vulnerability fixes, and leaves exploitable bugs in higher-privileged components as a named remainder.
- T1069prevents — A.5.15's policy, requirements, and rules for determining, restricting, and formally authorizing access (incl. least-privilege, need-to-know, segregation, and role-based mapping) directly constrain which permission groups exist and which entities can hold elevated membership, so the reconnaissance technique cannot run against the bulk of the environment it targets; residual coverage gaps on discovery methods and on already-granted groups keep it from mostly.
- T1069.001prevents — A.5.15 requires defining and enforcing an access control policy plus rules that explicitly consider restrictions to privileged access, segregation of duties, need-to-know, and consistency with classification, which constrains the value and success of discovering local groups/permissions by limiting what elevated or useful group memberships an adversary can actually leverage.
- T1069.002prevents — A.5.15 requires a topic-specific access control policy that explicitly considers determining which entities require which access, restrictions to privileged access, segregation of duties, need-to-know, and formal authorization of rights; this constrains the value and actionability of the discovered domain group/permission data and can prevent the technique from yielding usable elevated-access information, but does not stop the enumeration commands themselves.
- T1069.003prevents — A.5.15's policy, requirements, role-based rules, need-to-know, segregation, and formal authorization of access rights directly constrain which entities can legitimately query or enumerate cloud groups/ACLs/permissions, preventing the technique from succeeding for unauthorized callers; this is a minority slice of the class because the control is governance-oriented, leaves technical enforcement to referenced controls (5.16/5.18/8.2), and assumes prior authenticated access.
- T1072prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, need-to-know, segregation of duties, privileged-access restrictions, formal authorization, and rule implementation directly constrain who can access enterprise deployment tools and with what rights, stopping the technique for properly-scoped accounts; it leaves the administrative-account and direct-credential vectors (explicit in the T1072 prose) as a bounded remainder.
- T1078prevents — Formal authorization, role-based assignment, and periodic review of access rights directly constrain an adversary's ability to leverage stolen or guessed credentials by ensuring only explicitly approved entities retain access.
- T1078.001prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged accounts, formal authorization, and consistent rules that limit entities (including defaults) to only authorized access; this constrains abuse of unchanged defaults but does not mandate changing or disabling them, leaving a substantial remainder (e.g., factory defaults on appliances, post-integration accounts like vpxuser, or keys) unaddressed at the source.
- T1078.002prevents — Mapping access rights to verified roles and enforcing need-to-know limits the scope of any compromised domain account.
- T1078.003prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider determining required access per entity, restrictions on privileged accounts, segregation of duties, formal authorization, need-to-know, and consistency with classification — directly constraining how and whether local accounts can be created, assigned, or abused for initial access/privilege escalation.
- T1078.004prevents — A.5.15 requires defining, communicating, and implementing topic-specific access control policies, rules, role-based restrictions, need-to-know, segregation, formal authorization, and consistency with classification/perimeter needs, which directly constrains many abuse vectors for valid cloud accounts (e.g., over-privileged roles, misconfigured assumptions, unauthorized pivots); however, it is silent on credential strength, MFA, brute-force resistance, phishing defenses, and technical enforcement mechanisms that live in other clauses, leaving a large residual slice of the technique.
- T1080prevents — A.5.15's policy, requirements, and rules for determining authorized access (including need-to-know, segregation, restrictions on privileged access, and consistency with classification) directly constrain which entities can write to or modify shared storage, thereby stopping most tainting of shared content before it occurs; the remainder is the technical enforcement slice left to 5.16/5.18 and 8.x controls.
- T1083prevents — A.5.15's policy-driven definition and enforcement of access rights (including need-to-know, least privilege via roles, consistency with classification, and restrictions on privileged access) directly stops unauthorized entities from reaching the files/directories the T1083 enumeration depends on, but leaves the technique executable against any objects the authorized entity can legitimately see.
- T1087prevents — A.5.15's policy-driven definition of access control rules, need-to-know, role-based restrictions, and consistency with classification can constrain which accounts are visible or enumerable by unauthorized entities, but leaves many discovery vectors (built-in commands, file searches, cloud APIs, misconfigurations) untouched.
- T1087.001prevents — A.5.15's policy-driven determination and enforcement of access rights (including need-to-know, segregation, logging, and restrictions on privileged/system entities) can prevent many forms of unauthorized local account enumeration, but leaves residual paths such as unmonitored physical access, misconfigured defaults, or non-policy-compliant technical implementations.
- T1087.002prevents — A.5.15's policy-driven access control rules, need-to-know, role-based restrictions, and consistency with classification can prevent unauthorized enumeration of domain accounts in many cases, but the control is governance-oriented, leaves technical enforcement to other clauses (e.g. 8.2/8.3/8.15), and does not reach all discovery vectors or platforms.
- T1087.003prevents — A.5.15's policy, requirements, and rules for determining authorized access (including need-to-know, segregation, privileged restrictions, and formal authorization) directly constrain which authenticated entities can invoke commands like Get-GlobalAddressList or browse directories, preventing the technique for unauthorized callers; partial because it stops at policy/rules and defers enforcement to referenced controls (5.16/5.18/8.2/etc.) while the technique can still run for any entity already granted the access.
- T1087.004prevents — A.5.15's policy, requirements, rules, need-to-know, segregation, formal authorization and role-based restrictions on privileged access directly constrain which authenticated entities can invoke discovery commands like az ad user list or aws iam list-users, preventing the technique for the bulk of accounts while leaving a named remainder (e.g. over-permissioned service accounts or dynamic-access exceptions).
- T1091prevents — A.5.15's policy-driven determination of access requirements, need-to-know, restrictions on privileged access, and rules for authorized entities (including physical and dynamic controls) can prevent unauthorized execution from removable media in some scenarios, but leaves open vectors like firmware modification, social engineering, and air-gapped lateral movement that the control does not reach.
- T1098prevents — Segregation of access request, authorization, and administration functions makes it harder for an adversary to silently create or modify accounts without detection.
- T1098.001prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, restrictions on privileged access, formal authorization of requests, management of access rights, and consistency with classification directly constrain the ability of an adversary (or compromised account) to add unauthorized credentials, but this is governance/planning that does not itself enforce technical checks at the point of API calls or key creation.
- T1098.002prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization, management of rights, need-to-know, segregation, and consistent mapping of rights to classification and perimeter needs; this directly constrains the unauthorized granting of mailbox/folder delegate permissions that T1098.002 relies on, but leaves residual gaps in dynamic, distributed, or post-compromise enforcement where the adversary already holds a privileged account.
- T1098.003prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, segregation of duties, formal authorization of requests, and consistent mapping of rights to classification/perimeter needs; this directly constrains the addition of unauthorized extra roles/permissions (including to adversary-controlled accounts) in a manner that matches the technique's core act, but leaves real residual because the control is governance-oriented, does not itself enforce runtime authorization checks or prevent a sufficiently privileged compromised account from succeeding, and defers technical enforcement to other clauses (e.g. 5.16, 5.18, 8.2).
- T1098.004prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization, management of rights, need-to-know, segregation, and consistent rules that limit entities (including services) to only authorized information/assets; this directly constrains the addition of unauthorized SSH keys to authorized_keys files in most cases, but leaves residual gaps such as dynamic/cloud API modifications, privileged-role exceptions, and physical/config-layer bypasses named in the control's own cross-references.
- T1098.005prevents — A.5.15 requires determining access requirements, defining/enforcing a topic-specific access control policy (including restrictions on privileged access, formal authorization of requests, management of rights, need-to-know, and consistency with classification), which directly constrains unauthorized device registration to bypass MFA/conditional access when the policy and rules are applied to MFA/device management systems.
- T1098.006prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, segregation of duties, formal authorization of requests, and consistent mapping of rights to classification and need-to-know, which directly constrains the ability of an adversary (or compromised account) to unilaterally add roles/permissions or modify ABAC policies in a container cluster.
- T1098.007prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider restrictions to privileged access, segregation of duties, need-to-know, formal authorization of changes, and consistency with classification; this directly constrains the addition of accounts to high-privilege groups such as Administrators, sudoers or RDP users, but leaves residual paths (e.g., dynamic factors, unmanaged machine accounts, or policy gaps in distributed environments) unaddressed.
- T1110prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules (including restrictions on privileged access, need-to-know, formal authorization, segregation, and consistency with classification) that can stop many brute-force paths to unauthorized accounts, but leaves the dominant technical mechanisms (strong passwords, MFA, lockouts, rate limiting) to other controls and does not reach offline hash cracking.
- T1110.001detects — A.5.15 explicitly requires logging of access control events (see 8.15) and consideration of dynamic access control factors, which surfaces password-guessing attempts as anomalous login failures; this is only a slice of the full technique surface because the clause itself does not mandate the depth, scope, or real-time monitoring of those logs.
- T1110.001prevents — A.5.15 requires a topic-specific access control policy that explicitly considers restrictions to privileged access, segregation of duties, formal authorization, management of access rights, need-to-know, and consistent enforcement of access rights (including in distributed environments and against all connection types); this directly constrains the success of unauthenticated password guessing against managed accounts and services, matching the A.8.5 anchor's logic and extent for the same technique.
- T1110.002prevents — A.5.15's topic-specific policy, requirements for determining authorized entities, restrictions on privileged access, segregation of duties, formal authorization, need-to-know, and consistent mapping of access rights directly constrain when and how cracked credentials can be used for login, preventing the technique's success in most cases (per A.8.5 anchor); residual exists for exempted accounts, legacy paths, or mis-mapped rights.
- T1110.003prevents — A.5.15 requires a topic-specific access control policy, determination of which entities get which access (incl. need-to-know, privileged restrictions, segregation), formal authorization, consistent rights mapping, and consideration of all connection types so entities only reach authorized assets/services; this directly stops password spraying from succeeding against managed accounts/services (as in the A.8.5 anchor), with a bounded remainder for exempted/legacy identities or dynamic factors not fully covered by the policy layer.
- T1110.004prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, formal authorization, management of access rights, and rules that map rights consistently with classification and only to authorized connections directly constrain credential-stuffing success by enforcing that only valid, authorized credentials work, though the control is silent on password strength, reuse enforcement, MFA, or lockout mechanics that would close the remainder.
- T1111prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, formal authorization, and consistency with classification directly constrain many MFA-interception vectors (e.g., by limiting who can obtain tokens or out-of-band codes), but leave residual paths such as keyloggers on already-authorized endpoints and service-provider compromises untouched.
- T1112prevents — A.5.15 requires defining and enforcing access control rules (including account permissions, need-to-know, privileged access restrictions, and consistency with classification) that directly constrain which entities can reach and modify specific Registry keys, preventing the technique where access is the gating factor; this is only a slice of T1112 because the technique also succeeds via already-authorized accounts, remote services, or non-access-modification aspects such as obfuscation and defense impairment.
- T1114prevents — A.5.15's policy-driven determination and enforcement of who gets which access (need-to-know, classification-consistent rights, restrictions on privileged/distributed connections) directly stops many unauthorized email-collection paths at the authorization layer, but leaves a bounded remainder (e.g., client-side collection after legitimate mailbox access, or insider abuse of granted rights).
- T1114.001prevents — A.5.15's policy-driven determination and enforcement of access rights (need-to-know, classification consistency, restrictions on privileged access, logging) can prevent unauthorized local collection of email files when those files are treated as classified assets under the rules, but leaves open-ended remainder for unclassified email, mis-mapped rights, or post-compromise collection after legitimate user access.
- T1114.002prevents — A.5.15 requires a topic-specific access control policy, determination of who needs what access (including need-to-know and privileged restrictions), formal authorization, and consistent rule enforcement that can stop unauthorized credentialed access to email services; this reaches the technique's credential-leveraging core but leaves a bounded remainder for post-authentication collection, dynamic factors, externally exposed services, and implementation gaps referenced to other clauses.
- T1114.003prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, segregation of duties, formal authorization of requests, and mapping of access rights directly constrain who can create or modify email forwarding rules, preventing the technique for unauthorized actors in most cases; however, it is silent on technical enforcement (e.g., against valid-credential abuse, hidden MAPI rules, or admin transport rules), leaving a substantial residual slice.
- T1119prevents — A.5.15's policy-driven definition of access rights, need-to-know, segregation, and restrictions on privileged access (with mapping to entities and classification) can prevent unauthorized automated collection of data the adversary is not entitled to reach, but leaves the post-compromise case (adversary already inside with some foothold) and many discovery/ETL paths largely untouched.
- T1127.002prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, and consistency rules for classification/perimeter can constrain some abuse vectors (e.g. limiting who can install/run ClickOnce from untrusted shares or web origins), but the control is governance-oriented, does not reach technical enforcement of execution proxies or startup-folder placement, and leaves the dominant technique slice (limited-permission user execution via trusted DFSVC) untouched.
- T1133prevents — A.5.15 requires determining access requirements, defining/enforcing a topic-specific access control policy (including restrictions on privileged/remote access, need-to-know, formal authorization, consistency with classification/perimeter needs, and considering all connection types in distributed environments), which directly constrains many vectors of T1133 such as unauthenticated exposed services, improper remote gateway configs, and unauthorized use of VPN/Citrix/RDP/Tor services; it does not reach credential theft leading to valid accounts or all post-compromise persistence mechanics.
- T1134prevents — A.5.15's policy-driven requirements for access rules, least-privilege restrictions, segregation of duties, privileged-access limits and formal authorization of rights directly constrain many token-manipulation vectors (especially those relying on overly broad admin rights or missing need-to-know), but the control is silent on Windows token-implementation mechanics, runas/impersonation by standard users, and AD-field abuse, leaving a substantial remainder.
- T1134.001prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that map rights consistently to classification, need-to-know, least-privilege, and segregation, which can constrain the conditions under which a valid token exists to be stolen or the contexts in which an impersonated token can be used; however, it does not address the Windows token-duplication APIs or the runtime impersonation mechanics themselves.
- T1134.002prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that map rights consistently to classification, need-to-know, least-privilege, segregation of duties, and dynamic factors; this constrains many prerequisite conditions for T1134.002 (e.g., who may hold or duplicate tokens, privileged impersonation rights, and authorized process-creation contexts) but leaves residual paths such as already-compromised admin tokens or unmonitored dynamic escalations.
- T1134.003prevents — A.5.15's policy, requirements, rules, and role-based mapping for authorized access (including need-to-know, segregation, privileged restrictions, and formal authorization) directly constrain creation/impersonation of tokens to bypass controls, but only as governance that does not reach the Windows API-level execution of LogonUser/SetThreadToken.
- T1135prevents — A.5.15's policy, requirements, and rules for determining authorized access (incl. need-to-know, restrictions on privileged access, segregation, and mapping rights to entities) directly constrain which network shares can legitimately be enumerated or accessed, preventing the technique for unauthorized shares while leaving discovery of authorized ones intact.
- T1136prevents — A.5.15 requires a topic-specific access control policy, determination of who needs what access, restrictions on privileged accounts, formal authorization of requests, and consistent mapping of rights (including need-to-know and segregation), which directly constrains or blocks unauthorized account creation when followed; however, it is governance/planning that does not itself enforce technical creation-time checks, leaving a large remainder for post-policy implementation gaps.
- T1136.001prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy (incl. need-to-know, privileged restrictions, segregation, formal authorization, role-based rules), and mapping rights consistently with classification and perimeter needs; this constrains creation of unauthorized local accounts as a policy violation but leaves residual cases (e.g., privileged insiders, dynamic factors, or post-exploitation via exploited management consoles) unaddressed by the governance layer alone.
- T1136.002prevents — A.5.15 requires a topic-specific access control policy, requirements for determining who needs what access (incl. need-to-know, privileged restrictions, segregation of duties, formal authorization, and role-based rules), which directly constrains creation of unauthorized domain accounts; however, it is governance/planning that does not itself enforce technical creation restrictions, leaving a large remainder addressed by referenced controls such as 5.16/5.18 and 8.2.
- T1136.003prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy, formal authorization of requests, management of rights, need-to-know, segregation, and consistency with classification — all of which constrain creation of unauthorized cloud accounts; however, the control is governance-oriented, stops short of technical enforcement mechanisms, and leaves residual creation paths (e.g., via already-compromised privileged sessions or sanctioned exceptions).
- T1137prevents — A.5.15's policy, requirements, and rules for determining authorized access (including need-to-know, segregation, privileged restrictions, and consistency with classification) can constrain some Office persistence vectors when they cross authorization boundaries, but leaves the dominant code-level abuse mechanisms (macros, add-ins, rules, forms) untouched.
- T1137.001prevents — A.5.15's topic-specific policy, need-to-know, segregation of duties, privileged-access restrictions, formal authorization, and access-rights mapping can constrain who may modify Office templates or enable macros, preventing the technique in policy-enforced environments, but this is only a governance slice that leaves technical execution paths (e.g., local file writes, registry changes, search-order hijacks) unaddressed.
- T1137.002prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, formal authorization of requests, and mapping of access rights can constrain who may create or modify the Office Test registry keys (a privileged persistence vector), but does not stop an already-authorized user or process from doing so or address the underlying Office loading behavior.
- T1137.003prevents — A.5.15's topic-specific policy, need-to-know, segregation, formal authorization of access requests, and mapping of rights to entities (including services) can constrain which mailboxes or Outlook items allow form registration/execution, but leaves open many technical vectors once initial access exists and does not reach the code-execution persistence mechanism itself
- T1137.004prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, and consistency with classification directly constrain the unauthorized addition and execution of a malicious Outlook Home Page URL, but this is only one narrow slice of the many persistence vectors the control addresses.
- T1137.005prevents — A.5.15's topic-specific policy, need-to-know, segregation, formal authorization, and rule-mapping requirements constrain who can create or modify Outlook rules (a form of privileged access to mailbox behavior), lowering the chance the technique can be introduced post-compromise; this is a genuine but minority slice of the class, as most of the technique lives in client-side execution after rules are present.
- T1137.006prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, need-to-know, segregation, formal authorization, and consistent access rules (including for applications and dynamic controls) can constrain which add-ins are permitted to load at Office startup, preventing the persistence technique in many cases; however, it is governance-level and leaves technical enforcement, privileged add-in paths, and legacy Office behaviors as a substantial unaddressed slice.
- T1176prevents — A.5.15's policy-driven determination of access requirements, need-to-know, segregation, and rule mapping for entities (including services) constrains which extensions can legitimately be granted host-application permissions, preventing the abuse vector in a minority slice of cases; the bulk of the technique (social engineering, marketplace compromise, post-compromise install, and benign-extension abuse) sits outside this governance layer.
- T1176.001prevents — A.5.15's topic-specific policy, entity/access-right mapping, need-to-know, privileged-access restrictions, segregation, and consistency rules (including dynamic factors) can constrain which extensions are authorized and how they inherit permissions, stopping many installation vectors; however, it is a governance/planning control that does not itself enforce technical restrictions at browser, file, or app-store layers, leaving substantial residual techniques (e.g., post-compromise file modification, social engineering).
- T1185prevents — A.5.15's policy, requirements, rules, and role-based mapping for authorized access (including need-to-know, segregation, privileged restrictions, and consistency with classification) directly constrain the unauthorized inheritance and use of sessions/certificates/permissions that enable T1185 pivoting, but leave open browser vulnerabilities, injection vectors, and dynamic factors not covered by the control's governance focus.
- T1187detects — A.5.15 requires logging of access control events (explicitly referencing 8.15) and topic-specific policy that can drive monitoring of anomalous access/authentication, which surfaces some forced-authentication attempts (e.g. unexpected external SMB/WebDAV), but the control is governance-oriented and does not mandate the specific detection mechanisms or coverage needed to catch all variants of this technique.
- T1187prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access types, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and consistent access rights (including in distributed environments) directly constrain the unauthorized forced-authentication paths that enable T1187, but leave residual gaps such as unaddressed client-side automatic behaviors, physical perimeter support, and dynamic factors.
- T1190prevents — A.5.15's policy-driven determination of access requirements, need-to-know, segregation, formal authorization, and mapping of rights can prevent exploitation paths that rely on weak/misconfigured IAM or overly permissive access to public-facing apps, but leaves the dominant software-bug and many misconfiguration slices (e.g. unpatched web vulns, exposed services) untouched.
- T1199prevents — A.5.15's policy, requirements, rules, and restrictions on access (including third-party, need-to-know, privileged, segregation, and dynamic factors) directly constrain the granting and scoping of the trusted relationships that T1199 abuses, but do not guarantee enforcement or elimination of all such access paths (e.g., legacy delegations or incomplete perimeter controls).
- T1200prevents — A.5.15 requires determining access needs, defining/implementing access control rules (including physical perimeter consistency, restrictions on connections/network services, and privileged access), and formal authorization, which can prevent many hardware additions from being usable for unauthorized access; however, it does not stop the physical introduction itself (that is explicitly assigned to the PE family).
- T1202prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and consistency checks can constrain which entities may invoke bypass utilities or execute via them, preventing the technique in many cases, but this is governance rather than a technical enforcement that stops all indirect command execution paths (e.g. WSL components or ssh.exe options).
- T1204.002prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, and consistency rules for classification/perimeter can constrain which users are authorized (and thus able) to open files in many scenarios, but the control is silent on execution controls, file-type restrictions, or technical enforcement that would stop a user from opening a malicious file they are already authorized to access.
- T1207prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, restrictions on privileged access, segregation of duties, formal authorization of requests, and consistent access rights directly constrain the Administrator/KRBTGT privileges and object-creation steps needed to register a rogue DC, but the control is governance-oriented and leaves technical enforcement (e.g. schema protections, replication monitoring) to referenced controls.
- T1210prevents — A.5.15's policy-driven determination and enforcement of authorized access rights (including need-to-know, segregation, privileged restrictions, and consistency with classification/perimeter rules) directly constrains which entities can reach remote services, thereby preventing many exploitation opportunities for unauthorized lateral movement; it leaves residual gaps in patch-level vulnerability presence and in dynamic/runtime enforcement of those rules.
- T1213prevents — A.5.15's topic-specific policy, requirements analysis, need-to-know, role-based rules, and consistency checks with classification/perimeter directly constrain overly-broad or public repository access that the technique exploits, but the control is governance-oriented and does not itself implement or enforce the technical access rules (those live in 5.16/5.18 and 8.x references).
- T1213.001prevents — A.5.15 requires defining and enforcing topic-specific access control policies, rules, and rights (including need-to-know, classification consistency, and restrictions on privileged or unauthorized entities) that directly stop adversaries from gaining the repository access needed to mine Confluence data; this is only partial because the control is governance-oriented, leaves implementation details (e.g. enforcement strength, MFA, or technical ACLs) to referenced clauses, and does not guarantee prevention in all distributed/SaaS configurations.
- T1213.002prevents — A.5.15 requires owners to define and enforce topic-specific access control policies (including need-to-know, classification-driven rights, privileged-access restrictions, and formal authorization) that directly stop unauthorized entities from reaching the SharePoint repository or the listed sensitive items it stores.
- T1213.003prevents — A.5.15's topic-specific policy, entity/access-right mapping, need-to-know, privileged-access restrictions, and consistency rules for classification and connections directly constrain unauthorized repository access (especially internal/private ones), but leave public SaaS repos, post-compromise credential abuse, and incomplete enforcement as open gaps.
- T1213.004prevents — A.5.15's policy, requirements, rules, and role-based mapping for authorized access (including need-to-know, segregation, logging, and consistency with classification) directly constrain who can reach CRM data, stopping the technique for properly scoped entities; partial because it is governance that does not itself enforce runtime checks or close all technical paths once initial access is obtained.
- T1213.005prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, and consistent rights mapping directly constrain which entities can reach messaging-app data, stopping the technique for properly scoped users/assets; partial because it is governance that does not itself enforce runtime technical controls on all connections or dynamic factors.
- T1213.006prevents — A.5.15's topic-specific policy, requirements for determining authorized entities, need-to-know, segregation, formal authorization, and rule implementation (including dynamic factors and consistency with classification) directly constrain which entities can reach database contents, stopping the technique for properly-scoped users; partial because it is governance that does not itself enforce at query or credential level and leaves residual paths (e.g., compromised legitimate accounts, misconfigurations outside the policy, or unclassified data stores).
- T1218.002prevents — A.5.15's policy-driven access control rules, entity-specific rights, need-to-know, privileged restrictions, and consistency with classification can prevent unauthorized proxy execution via control.exe for many registered or classified malicious CPL items, but leaves open delivery vectors like phishing, direct command-line abuse, and non-classified dynamic registration that the control does not address.
- T1218.003prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and consistency checks can constrain which entities are allowed to invoke CMSTP or supply its INF files, thereby preventing the technique in many configurations, but leaves open legitimate remote-access use of the signed binary plus dynamic factors and enforcement gaps.
- T1218.004prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and consistency with classification can constrain which entities are allowed to invoke InstallUtil (or supply the .NET binaries it acts on), but the control is silent on signed-trusted-utility proxy execution, application-control bypass via RunInstaller attributes, and the underlying code-execution technique itself.
- T1218.005prevents — A.5.15's policy-driven determination and enforcement of access rights (including restrictions, need-to-know, privileged access limits, and consistency with classification) can prevent mshta.exe abuse by denying unauthorized entities the rights needed to execute it or fetch remote HTA payloads, but leaves a bounded remainder where the technique runs under already-authorized rights or via unaddressed dynamic/execution factors.
- T1218.008prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, segregation, and dynamic rules directly constrain which entities (incl. signed binaries like odbcconf.exe) may execute or load DLLs, preventing the abuse in many configurations; residual exists for unscreened legacy/authorized use of the utility itself.
- T1218.010prevents — A.5.15 requires a topic-specific access control policy, determination of which entities get which access, restrictions on privileged access, formal authorization of requests, and consistent rules that limit entities (including services) to only authorized information/assets; this constrains the user-permission and bypass aspects of Regsvr32 abuse but leaves the signed-binary proxying, allow-list evasion, and COM/scriptlet execution slices untouched.
- T1218.012prevents — A.5.15's topic-specific policy, entity/role-based access rights, need-to-know, segregation, and consistency rules for authorized access can constrain which entities may invoke or register CLSIDs that verclsid.exe would proxy, but leaves the signed-native binary abuse vector itself untouched.
- T1218.014prevents — A.5.15's topic-specific policy, entity/role-based rules, need-to-know, privileged-access restrictions, segregation of duties, formal authorization, and consistency checks for access rights directly constrain which entities (including processes) may invoke signed binaries like mmc.exe or load .msc files, stopping the technique before it runs for the bulk of managed access decisions; residual remains for unmanaged or already-authorized administrative contexts.
- T1219prevents — A.5.15's policy, requirements, and rules for determining/ restricting authorized access (including need-to-know, privileged restrictions, segregation, formal authorization, and consistency with classification) can stop many unauthorized uses of remote access tools, but leaves open post-compromise abuse of already-permitted legitimate tools, EDR response features, and dynamic/ inherited sessions that match an entity's approved rights.
- T1219.002prevents — A.5.15 requires a topic-specific access control policy, determination of authorized entities/roles, need-to-know, restrictions on privileged/remote access, and consistent enforcement of rules across connections (including networks); this constrains legitimate desktop support/RMM tools from being available for unauthorized C2 use, but leaves open the common case where such software is explicitly authorized for legitimate support (as the technique itself notes).
- T1219.003prevents — A.5.15 requires determining access needs, defining/implementing access control rules (including for physical perimeter, network connections, and entities like devices), and consistency with physical security needs, which can prevent unauthorized installation/use of remote access hardware in some cases but leaves open post-compromise physical installation and policy allowances for legitimate tools.
- T1222prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that map rights consistently to classification, need-to-know, least privilege, and segregation — which directly constrains the ability of non-owners or non-privileged entities to modify ACLs/permissions on protected files or directories, preventing the technique for the bulk of cases that rely on unauthorized permission changes.
- T1222.001prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, segregation of duties, formal authorization of changes, and consistent mapping of rights to classification/perimeter needs; this constrains many avenues for an adversary to obtain the permissions needed to run icacls/takeown/etc. against protected objects, but leaves open vectors such as already-compromised privileged accounts, dynamic access-control gaps, and post-compromise local abuse that the control does not itself stop.
- T1222.002prevents — A.5.15's policy, requirements, rules, and role-based mapping for determining and enforcing authorized access (including restrictions, need-to-know, privileged limits, and consistency with classification) directly constrain the ability of unauthorized entities to successfully run chmod/chown against protected files, preventing the technique from achieving its goal in covered cases, but leaves a remainder for already-authorized or dynamic contexts where the adversary can still modify permissions.
- T1484prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, restrictions on privileged access, segregation of duties, formal authorization of changes, and consistency rules for access rights directly constrain the permissions and processes needed to modify domain/tenant policies (including GPOs, trusts, and federation settings), but only for the policy/governance slice; technical enforcement lives in referenced controls such as 5.16/5.18/8.2 and does not guarantee prevention of all abuse vectors once permissions exist.
- T1484.001prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization, management of rights, restrictions on privileged access, segregation of duties, and consistency with classification/perimeter needs; this directly constrains improper delegation or write access to GPOs that enables T1484.001, but leaves residual gaps (e.g., dynamic factors, enforcement consistency, and post-authorization technical enforcement live in referenced controls like 5.16/5.18/8.2).
- T1484.002prevents — A.5.15's policy, requirements, rules, and consistency checks for access control (including privileged access, need-to-know, segregation, formal authorization, and dynamic factors) directly constrain the configuration changes that enable T1484.002, but only for the subset of trust modifications that cross defined access boundaries rather than the full class of trust-object manipulation.
- T1485.001prevents — A.5.15 requires defining and enforcing an access control policy plus rules that explicitly consider restrictions to privileged access, segregation of duties, formal authorization, and consistency of rights with classification and business needs; this directly constrains the 'sufficient permissions' prerequisite for the PutLifecycleConfiguration action that triggers the technique, but leaves a bounded remainder (e.g., misconfigured roles, insider abuse of legitimately granted rights, or dynamic access-control factors not fully locked down).
- T1496.004prevents — A.5.15's policy, requirements, and rule-mapping for authorized access (including privileged, need-to-know, segregation, and dynamic factors) directly constrain illegitimate use or enabling of SaaS resources by unauthorized entities, but leaves open the post-compromise abuse slice once a legitimate credential or role is already hijacked.
- T1505.001prevents — A.5.15's policy, requirements, role-based rules, need-to-know, segregation, formal authorization and consistency checks on access rights can constrain which entities (including DB users/services) may create or invoke stored procedures, limiting the attack surface for malicious persistence, but does not reach the dominant technical slice of crafting/modifying the procedure code itself once authorized access exists.
- T1505.003prevents — A.5.15's policy, requirements, and rules for determining, authorizing, and restricting access (including to applications, networks, services, and privileged functions) directly constrain the placement and open accessibility of a web shell that grants unauthorized gateway access, but this is only a slice of the full technique (e.g., does not reach initial foothold vectors, client-side components, or all deployment paths).
- T1525prevents — A.5.15's topic-specific access control policy, entity/role-based rights mapping, need-to-know, privileged-access restrictions, and consistency rules for distributed/cloud environments constrain which entities can reach and modify image registries, thereby preventing the initial compromised-instance + list-and-implant sequence in many cases, but leaves residual paths (e.g., legitimate but overly broad developer or automation roles that can still push backdoored images).
- T1526prevents — A.5.15's policy-driven definition of access rights, need-to-know, segregation, and restrictions on privileged access (with explicit mapping to entities including services) can prevent an adversary who has initial access from being authorized to enumerate many cloud services, but leaves open techniques that use already-authorized identities or bypass the policy entirely.
- T1528prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, formal authorization, and consistent rules directly constrain many vectors for stealing or misusing application access tokens (OAuth registration, service-account grants, IMDS requests, CI/CD token use), but leave open social-engineering consent flows, post-compromise token extraction from already-authorized containers, and refresh-token reuse.
- T1530prevents — A.5.15 requires determining access needs, defining/communicating a topic-specific policy, implementing mapped access rights and restrictions (including need-to-know, least-privilege-like limits on privileged access, segregation, formal authorization, and consistency with classification), which directly constrains the misconfigurations and overly-broad/unauthenticated access that enable T1530; partial because it is governance-oriented, references other controls for enforcement (e.g. 5.16/5.18), and does not itself close all technical paths such as credential abuse or dynamic factors.
- T1534prevents — A.5.15's policy, requirements, and rules for determining, authorizing, restricting, and managing access (including need-to-know, privileged restrictions, segregation, logging, and dynamic factors) can constrain the initial account compromise vectors that enable the trusted-internal-account stage of T1534, but do not stop the subsequent spearphishing, impersonation, or credential-capture techniques once an account is already inside.
- T1537prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, formal authorization, and mapping of rights directly constrain the cloud-account sharing, SAS URI, and backup-transfer vectors that rely on improper access grants, but leaves residual paths (e.g., compromised legitimate high-privilege accounts or dynamic factors not fully enforced).
- T1538prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy, and implementing mapped access rights (including need-to-know, privileged restrictions, formal authorization, and consistency with classification), which directly constrains use of stolen credentials against the dashboard; partial because it addresses the policy/rights layer but leaves technical enforcement (e.g. MFA, session controls, or dashboard-specific RBAC) to referenced controls like 5.16/5.18/8.2.
- T1539prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and mapping of access rights directly constrain session-cookie theft vectors that rely on improper authorization or over-privileged access (e.g. malware stealing cookies from memory/disk, JS injection, or proxy phishing that yields unauthorized use), but leaves many technical theft methods (e.g. network sniffing, browser process injection, or post-theft use of a legitimately issued cookie) untouched.
- T1543.001prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, formal authorization, and consistent rights mapping can prevent unauthorized creation/modification of launch agents in many cases, but this is only a governance slice that does not technically block the filesystem writes or execution.
- T1543.002prevents — A.5.15 requires owners to define and enforce topic-specific access control policy plus rules that explicitly consider restrictions to privileged access, segregation of duties, formal authorization of requests, management of rights, and consistency with classification/perimeter needs; this constrains the creation or modification of systemd services (especially those altering User/Exec directives or placing symlinks) but leaves open slices such as dynamic generator-based creation and non-privileged user-level services that still achieve persistence.
- T1543.003prevents — A.5.15 requires a topic-specific access control policy, determination of which entities get which access (including to services/registry), formal authorization, need-to-know, segregation of duties, and consistent rules that limit entities (human or technical) to only authorized information/assets; this constrains the technique's creation/modification of services for unauthorized persistence/escalation on a minority slice (policy-driven authorization of service objects) but leaves the dominant technical execution paths (sc.exe, direct Registry/API writes, driver loading, hiding) untouched.
- T1543.004prevents — A.5.15's policy, requirements, and rules for determining authorized entities, need-to-know, privileged-access restrictions, formal authorization, and consistency with classification/perimeter directly constrain who can install or modify privileged Launch Daemons, but leave residual paths via poor configurations, masquerading, or already-elevated entities
- T1543.005prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, restrictions on privileged access, segregation of duties, formal authorization of requests, and mapping of access rights directly constrain who can legitimately create/modify container services or use commands like docker run/podman run/DaemonSets, preventing the technique for authorized entities in a policy-driven manner; however, it is governance-level only and leaves technical enforcement, dynamic factors, and misconfigurations as a large residual.
- T1546prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, segregation of duties, privileged restrictions, formal authorization, and consistent rights mapping constrain which entities can legitimately create/modify event triggers or be granted the higher-privilege accounts that proxy them, preventing the abuse vector for a genuine but minority slice of T1546 (the remainder is post-compromise technical modification of triggers that the governance-focused control does not reach).
- T1546.002prevents — A.5.15 requires a topic-specific access control policy that determines required access types, enforces restrictions/least-privilege, segregation of duties, formal authorization of rights, and consistency with classification and physical needs; this can block unauthorized registry writes or PE placement for malicious screensavers in many cases, but leaves open vectors such as already-authorized user sessions, insider abuse of legitimate rights, or dynamic access-control gaps that the control does not itself close.
- T1546.003prevents — A.5.15's policy-driven determination and enforcement of access rights, need-to-know, privileged restrictions, and segregation of duties can prevent unauthorized WMI subscriptions that require elevated or unintended access, but leaves many legitimate WMI uses and implementation gaps unaddressed.
- T1546.004prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, formal authorization, and consistency rules (including for distributed connections) constrain which entities may legitimately modify or source the shell config files, preventing the adversary from reaching the insertion point in the bulk of cases; it does not reach the technical enforcement that stops a privileged or already-authorized actor from writing the malicious commands.
- T1546.008prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy (including restrictions on privileged access, segregation of duties, formal authorization, need-to-know, and logging), and implementing mapped access rights/rules; this constrains the unauthenticated SYSTEM-level execution and binary/registry tampering at the login screen for a bounded slice of the technique but leaves residual paths (e.g., physical access, RDP, signed replacements, or IFEO workarounds) unaddressed by the policy layer alone.
- T1546.011prevents — A.5.15's policy-driven access control rules, role-based restrictions, privileged-access limits, need-to-know, and formal authorization can block unauthorized shim installation/registration (which requires admin rights) and limit abuse vectors, but does not reach the technique's core (shim database hooking, persistence via legitimate programs, or UAC bypasses that operate within authorized sessions).
- T1546.012prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization, management of rights, consistency with classification, and restrictions on privileged access; this constrains the IFEO Registry modifications that enable unauthorized persistence/privilege escalation but does not reach the full technique surface (e.g., silent-exit monitoring, GFlags usage, or post-login process-injection vectors).
- T1546.013prevents — A.5.15's policy, requirements, role-based rules, need-to-know, privileged-access restrictions and formal authorization directly constrain who can modify profile.ps1 files or the paths that load them, preventing the technique for the bulk of ordinary users while leaving a bounded remainder (e.g., administrators who legitimately edit their own profiles or systems where -NoProfile is not enforced).
- T1546.014prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider restrictions to privileged access, segregation of duties, formal authorization of access requests, management of access rights, and consistency with classification — which directly constrains who can write emond rules or the LaunchDaemon plist that enables the service, thereby preventing the abuse in a genuine but minority slice of the technique (the authorization surface) while leaving the code-execution and persistence mechanics themselves untouched.
- T1546.016prevents — A.5.15's policy, requirements, role-based rules, need-to-know, privileged-access restrictions and segregation of duties can constrain which entities (including installers) are authorized to run with elevated rights or modify installer content, but this is governance-level and leaves technical execution of postinstall/maintainer/.msi scripts as a large residual.
- T1546.017prevents — A.5.15 requires determining access requirements, defining and enforcing a topic-specific access control policy (including restrictions to privileged access, need-to-know, formal authorization of changes, and consistency with classification/perimeter needs), which directly constrains the root-level ability to add or modify udev rules in the cited directories; this prevents the technique for non-privileged actors and for privileged actors who must follow the enforced policy, but leaves a bounded remainder where authorized privileged users can still introduce malicious rules.
- T1547prevents — A.5.15's policy-driven determination and enforcement of access rights, restrictions, need-to-know, privileged-access limits, and consistency with classification can block many unauthorized autostart configurations that rely on improper rights or privilege escalation, but leaves kernel modifications, physical vectors, and many legitimate-but-abusable autostart mechanisms (e.g., designated directories) untouched.
- T1547.001prevents — A.5.15 requires a topic-specific access control policy that explicitly considers restrictions to privileged access, segregation of duties, formal authorization of access requests, management of access rights, and consistency with information classification; these directly constrain which entities (including malware) can write to the listed HKLM/HKCU run-key and startup-folder locations, but the control stops at policy-level requirements and does not itself enforce the technical restrictions.
- T1547.003prevents — A.5.15's policy, requirements, and rules for determining/ restricting access (including privileged, need-to-know, segregation, formal authorization, and consistency with classification) can constrain who may register time-provider DLLs, but this is only a minority slice of the technique's attack surface (admin-level registry abuse at boot).
- T1547.004prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization, management of rights, and consistency with classification/need-to-know, which constrains unauthorized registry modifications for Winlogon helpers when enforced; however, it is governance-level planning that does not itself implement technical enforcement against the specific abuse vectors.
- T1547.006prevents — A.5.15's policy, requirements, and rules for determining authorized entities, need-to-know, privileged-access restrictions, formal authorization, and consistent mapping of rights can constrain which subjects may load kernel modules/extensions, but this is only a minority slice of the technique (the authorization layer) while the dominant technical mechanisms (kernel-level loading, signing bypass, SIP disablement, rootkit hiding) sit outside its governance scope.
- T1547.007prevents — A.5.15 requires a topic-specific access control policy, determination of which entities require which access, formal authorization of requests, management of access rights, and consistency with classification and need-to-know, which constrains unauthorized plist modifications for persistence when enforced at the logical access layer; however, it is governance/planning that does not itself implement enforcement mechanisms and leaves technical bypasses (e.g., local admin, unmonitored paths) as a large residual.
- T1547.009prevents — A.5.15's policy-driven determination of access rights, need-to-know, segregation, formal authorization, and consistent mapping of rights to entities (including startup-folder and shortcut objects) constrains who can create/modify shortcuts that achieve unauthorized boot/login execution, but leaves many implementation gaps (e.g., enforcement strength, dynamic factors, physical/logical consistency) unaddressed.
- T1547.010prevents — A.5.15 requires determining access needs, defining/implementing access control rules (including restrictions on privileged access, consistency with classification, and formal authorization), which can prevent unauthorized writes to the registry key or loading of adversary DLLs via proper access rights; however, it is governance-level and does not itself enforce technical controls like ACLs on the specific registry path or spooler service.
- T1547.012prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, formal authorization of requests, and consistent mapping of rights (including to privileged operations like SeLoadDriverPrivilege and registry changes for print processors), which can prevent unauthorized installation of malicious print processors; however, it is governance-level and does not itself enforce technical restrictions at the point of execution.
- T1547.013prevents — A.5.15 requires determining access needs, defining/implementing access control rules (including restrictions and consistency with classification/perimeter), and managing rights for entities including in distributed environments; this can prevent unauthorized modification of system-wide autostart files in /etc/xdg/autostart but leaves user-level ~/.config/autostart writable by the user (and many other persistence vectors) untouched.
- T1547.014prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, formal authorization of requests, and consistent mapping of rights (including to classification and need-to-know), which can prevent unauthorized creation or abuse of Active Setup Registry keys for persistence when those keys are treated as privileged modifications; however, it is governance-oriented, leaves technical enforcement to referenced controls (e.g. 5.16/5.18/8.2), and does not reach all execution-context or masquerading aspects of the technique.
- T1547.015prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, formal authorization of requests, management of rights, and consistency with classification/need-to-know, which constrains unauthorized addition of login items for persistence/escalation on macOS; however, it is governance-level planning that does not itself enforce technical restrictions on AppleScript, Native API, or launchd mechanisms.
- T1548prevents — A.5.15's policy, requirements, and rules for determining/managing access rights, need-to-know, privileged restrictions, segregation, and formal authorization directly constrain elevation-control bypasses for many entity types; physical, dynamic, and some platform-specific technique slices remain outside its defined scope.
- T1548.001prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, segregation of duties, formal authorization of rights, and consistent mapping of rights to classification and needs; this constrains the setuid/setgid abuse vector for many (but not all) cases by limiting who may set or exploit such bits and which binaries may legitimately carry them.
- T1548.002prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, privilege restrictions, segregation, formal authorization, and consistent rights mapping directly constrain many UAC-bypass vectors that rely on improper privilege elevation or unauthorized admin-level access, but leave open the remainder of implementation-specific bypasses (auto-elevation, COM hijacks, injection into trusted processes) that still require technical enforcement controls.
- T1548.003prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, segregation of duties, formal authorization of requests, management of access rights, and consistent rules (including least-privilege mapping and dynamic factors), which directly constrains sudo/sudoers misconfigurations that enable unauthorized elevation; however, it is governance-level and leaves technical enforcement, sudo binary hardening, and runtime tty/caching behaviors to referenced controls such as 8.2/5.18.
- T1548.004prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, privileged restrictions, formal authorization, and consistency with classification directly constrain abuse of the deprecated API for unauthorized elevation, but leave open user-prompt social engineering, world-writable file modification, and legacy macOS compatibility as residual attack surface.
- T1548.005prevents — A.5.15 requires a topic-specific access control policy, determination of required access per entity, restrictions on privileged access, segregation of duties, formal authorization of requests, and consistent mapping of rights to classification and needs, which constrains misconfigurations that enable temporary elevation paths; however, it is governance/planning that does not itself enforce runtime checks, approval workflows, or technical JIT/impersonation safeguards.
- T1548.006prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, need-to-know, segregation of duties, formal authorization of access requests, and mapping of access rights directly constrain how TCC permissions should be granted and managed, preventing the technique in policy-conformant environments; however, it is governance only and does not technically enforce or close the macOS TCC database manipulation vectors.
- T1550prevents — A.5.15's policy, requirements, rules, and role-based mapping for authorized access (including restrictions, need-to-know, privileged limits, and consistency with classification) directly constrain use of stolen alternate auth material to move laterally, but leave open-ended gaps such as dynamic factors, physical perimeter support, logging, and technical enforcement details addressed only by cross-referenced controls.
- T1550.001prevents — A.5.15's policy, requirements, rules, and role-based mapping for determining and enforcing authorized access (including need-to-know, segregation, privileged restrictions, and consistency with classification) directly constrain the issuance and use of tokens that bypass normal auth, but leave residual gaps such as token theft after issuance, misconfigured OAuth grants, and dynamic/refresh-token abuse that the clause does not close.
- T1550.002prevents — A.5.15's policy, requirements, rules, and restrictions on access rights (including privileged access, need-to-know, segregation, formal authorization, and consistency with classification) directly constrain the unauthorized lateral authentication that PtH performs by bypassing normal access controls.
- T1550.003prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider restrictions to privileged access, segregation of duties, formal authorization, need-to-know, and consistency with classification; this constrains the legitimate paths by which a valid ticket could be issued or used, but the technique still succeeds against already-compromised credentials or golden/silver tickets that bypass normal authorization checks.
- T1550.004prevents — A.5.15 requires determining access requirements, defining and communicating a topic-specific access control policy, and implementing mapped access rights/restrictions (including need-to-know, privileged access limits, and consistency with classification), which constrains session-cookie reuse by enforcing authorization boundaries; however, it is silent on technical cookie protections (e.g., HttpOnly, SameSite, short lifetimes, or binding) that the technique directly exploits, leaving a large residual slice of the attack surface.
- T1552prevents — A.5.15's policy, requirements, need-to-know, classification-driven rules, privileged-access restrictions, and consistent rights mapping directly constrain where/which credentials may be stored or accessed, preventing many (but not all) insecure storage locations and search vectors on the technique's broad platform surface.
- T1552.001prevents — A.5.15's policy, requirements, need-to-know, segregation, formal authorization, and rule-mapping directly constrain where/who can place or access credential-storing files, preventing the insecure-storage condition for many (but not all) cases such as embedded passwords or misconfigured cloud/container files.
- T1552.004prevents — A.5.15's policy-driven requirements for access control rules, need-to-know, privileged-access restrictions, logging, and consistent rights mapping directly constrain where and how private keys can be stored and accessed, preventing the insecure-storage/search vector on a meaningful slice (especially for human-managed keys), but leave residual paths such as device-generated keys, network-device CLI export, and post-compromise filesystem access unaddressed.
- T1552.005prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, segregation, formal authorization, and rule implementation (including consistency with classification and considering all connection types in distributed environments) directly constrain who can reach the Instance Metadata API and what credentials it can expose, but this is governance/planning that does not itself block the on-instance query, SSRF vector, or unauthenticated localhost access.
- T1552.006prevents — A.5.15's policy-driven determination of access requirements, need-to-know, privileged-access restrictions, and consistent mapping of rights to classification and distributed connections constrains who can reach SYSVOL/GPP XML files and therefore prevents the technique for many (but not all) entities and environments.
- T1552.007prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that limit entities (users, services, roles) to authorized access only, which directly stops unauthorized API calls that would allow credential gathering via Docker/Kubernetes APIs; partial because the clause is governance-oriented (policy, requirements, mapping) rather than a concrete enforcement mechanism and leaves implementation details (e.g. exact API hardening) to referenced controls like 8.2/8.3.
- T1552.008prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, segregation, formal authorization, and rule implementation (including dynamic factors and consistency with classification) directly constrain sharing of credentials in chat services and limit unauthorized collection paths, but this is a minority slice of the technique (which also covers direct endpoint/server/portal access and compromised integrations after credentials are already shared).
- T1553.003prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, restrictions on privileged access, segregation of duties, formal authorization, and consistent access rights (including to system components like registry/DLLs) directly constrain the hijack vectors when enforced, but the control is governance-oriented and leaves technical enforcement to referenced controls (e.g. 5.16, 5.18, 8.2) with many residual paths (e.g. DLL search order, unmanaged components).
- T1553.006prevents — A.5.15 requires a topic-specific access control policy that explicitly considers restrictions to privileged access, segregation of duties, formal authorization of access requests, and management of access rights; these directly constrain the elevated-privilege actions (registry edits, bcdedit, csrutil, kernel memory changes) used to modify code-signing policy, but the control stops at policy definition and does not itself enforce the technical mechanisms that stop the technique from succeeding.
- T1555prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, and consistent enforcement of rights directly constrain many common password-store locations and prevent the technique from succeeding when those stores fall under the defined access model; it does not reach every possible store (e.g., unclassified application-specific or dynamic/credential-manager internals) so the coverage is a genuine but bounded slice.
- T1555.001prevents — A.5.15 requires defining and enforcing topic-specific access control policies, rules, and rights (including need-to-know, segregation, privileged restrictions, and consistency with classification) that can prevent unauthorized entities from accessing Keychain-stored credentials when properly mapped and implemented, but leaves many residual paths (e.g., once an adversary has user-level access, physical access, or can bypass via the default login password).
- T1555.003prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, restrictions on privileged access, formal authorization, and consistency with classification directly constrain which entities can legitimately reach browser-stored credential files, thereby preventing the technique for unauthorized entities while leaving the method available to those with sanctioned access.
- T1555.004prevents — A.5.15 requires a topic-specific access control policy, determination of who needs what access (including need-to-know and privileged restrictions), formal authorization, and consistent rules that limit entities to only authorized information/assets; this constrains the Credential Manager access paths an adversary can exploit under normal conditions but leaves residual gaps (e.g., physical access, misconfigured roles, or post-compromise API/file reads).
- T1555.005prevents — A.5.15's policy, requirements, and rules for determining, authorizing, restricting, and managing access rights (including need-to-know, privileged restrictions, segregation, logging, and consistency with classification) directly constrain the conditions under which a password manager's master password or stored credentials can be legitimately accessed or unlocked, thereby preventing many but not all adversary paths such as unauthorized extraction or brute-force against the master password.
- T1555.006prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy, mapping rights consistently with classification and need-to-know, restricting privileged access, and considering dynamic factors, which directly constrains the 'sufficient privileges' prerequisite for T1555.006; partial because the control is governance-oriented, leaves technical enforcement (e.g. least-privilege IAM, MFA on secrets retrieval) to referenced controls like 8.2/5.18, and does not eliminate all paths such as service compromises or misconfigurations.
- T1556prevents — A.5.15's policy, requirements, rules, and role-based mapping for authorized access (including need-to-know, privileged restrictions, segregation, formal authorization, and consistency with classification) directly constrain or block many forms of authentication-process tampering that would enable unwarranted access, but this is only a minority slice of T1556 because the control is governance-oriented, silent on technical enforcement against runtime modification of LSASS/PAM/etc., and leaves most implementation details to referenced lower controls.
- T1556.003prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, privileged restrictions, segregation, formal authorization, and rule implementation (including consistency with classification and dynamic factors) constrain many vectors for unauthorized PAM modification or backdooring, but leave open technical implementation gaps, physical vectors, and post-policy enforcement on running binaries.
- T1556.005prevents — A.5.15 requires a topic-specific access control policy that explicitly considers restrictions to privileged access, segregation of duties, formal authorization of access requests, management of access rights, and consistency with information classification; this directly constrains the adversary technique of (ab)using policy mechanisms such as FGPP or Set-ADUser to enable reversible encryption, but leaves a bounded remainder for legacy-software exceptions, physical access, and non-policy vectors that the clause itself delegates elsewhere.
- T1556.006prevents — A.5.15's topic-specific policy, requirements for determining access needs, restrictions on privileged access, segregation of duties, formal authorization, and consistent access rights directly constrain the ability to disable or modify MFA (a privileged configuration change), but only for the policy/governance slice; it does not reach technical enforcement mechanisms that stop the technique once an adversary has initial access.
- T1556.007prevents — A.5.15 requires determining access requirements, a topic-specific policy, formal authorization, management of rights, segregation of duties/privileged access, and consistency with classification — which constrains who may legitimately modify hybrid auth processes or grant the initial privileged access used in the technique, but does not stop an already-privileged adversary from patching PTA/AD FS agents or registering a rogue one.
- T1556.008prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, restrictions on privileged access, formal authorization of requests, and management of access rights (including via roles) can prevent unauthorized registration of a malicious network provider DLL as a credential manager, but this is only a minority slice of the technique's full attack surface (e.g., does not reach the core credential-capture mechanism, DLL loading, or physical/logon-process aspects).
- T1556.009prevents — A.5.15's topic-specific policy, requirements determination, and rule implementation for access control (including restrictions, need-to-know, privileged access, dynamic factors, and consistency with classification) directly constrain or prohibit the modification of conditional access policies that would enable unauthorized persistent access.
- T1557prevents — A.5.15's policy-driven access control rules, entity mapping, need-to-know, segregation, and consistency with classification/perimeter requirements constrain many AiTM vectors (e.g. unauthorized network access, improper credential interception, or protocol abuse for positioning), but leave residual paths such as ARP/DNS poisoning on unsegmented networks, downgrade attacks, or physical-layer MITM that the control does not directly prevent.
- T1557.001prevents — A.5.15's topic-specific access control policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and consistent rules (including in distributed environments and dynamic factors) can prevent the unauthorized relay or use of captured NTLM credentials, but does not address the core name-resolution spoofing/poisoning that enables the technique on local networks.
- T1557.004prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, segregation, formal authorization, and consistency with classification/perimeter needs constrain which networks/devices users and systems are permitted to connect to, preventing the technique in managed/enterprise settings but leaving public/unmanaged Wi-Fi and client-side PNL behavior largely untouched.
- T1558prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, segregation, privileged restrictions, and consistent rights directly constrain the unauthorized ticket theft/forgery that enables Pass-the-Ticket, but leave residual gaps in technical enforcement, dynamic factors, and Kerberos-specific credential protections addressed elsewhere.
- T1558.001prevents — A.5.15's policy, requirements, and rules for determining, authorizing, restricting, and managing access rights (incl. privileged, need-to-know, segregation) directly constrain the ability to obtain KRBTGT hash or use a forged golden ticket for unauthorized resource access, but this is only a slice of the technique's full attack chain (credential dumping prerequisite, KDC interaction, and domain controller compromise remain unaddressed by this governance clause).
- T1558.002prevents — A.5.15's policy, requirements, and rules for determining, authorizing, restricting, and managing access rights (incl. need-to-know, privileged access, segregation, logging) directly constrain silver-ticket forgery and use by limiting who can legitimately obtain or employ service-account hashes for that resource.
- T1558.003prevents — A.5.15's policy-driven access control rules, need-to-know, privileged-access restrictions, segregation of duties, and formal authorization of rights can constrain which accounts receive SPNs and which service accounts are granted the TGTs needed to request TGS tickets, thereby preventing the technique for a slice of accounts and services; it does not reach the RC4-weakness, network sniffing, or brute-force steps themselves.
- T1558.004prevents — A.5.15's policy, requirements, and rules for access control (including restrictions on privileged access, need-to-know, segregation, formal authorization, and consistency with classification) can require/enforce Kerberos pre-authentication as a condition of account access, preventing the AS-REP roast technique from succeeding; this is only a slice of the control's broad governance focus rather than a direct technical mandate.
- T1558.005prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and consistent mapping of rights (including to classification and physical needs) directly constrain the conditions under which ccache files can be created, stored, or accessed by unauthorized entities, preventing the technique from succeeding in many configurations; it does not reach all dynamic, memory-resident, or post-authentication collection vectors on Linux/macOS.
- T1559.002prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, and dynamic-access considerations can constrain DDE usage and poisoning vectors in authorized contexts, but this is a minority slice of the technique (phishing delivery, registry-enabled Office abuse, remote DCOM invocation) that lives outside access-control policy.
- T1559.003prevents — A.5.15 requires determining access needs, defining/implementing topic-specific access control rules and rights (including restrictions, need-to-know, segregation, privileged access limits, formal authorization, and consistency with classification), which directly constrains improper XPC client validation and input sanitization that enable the technique on macOS.
- T1561.002recovers — A.5.15 requires determining access requirements, defining/implementing access control rules (including for physical, network, and privileged access), and considering backups implicitly via related controls like 8.13; this enables recovery of wiped boot structures from authorized backups after the technique runs, matching the recovers verb with a named remainder for unbacked-up or propagation-impacted systems.
- T1563prevents — A.5.15's policy, requirements, and rules for determining, authorizing, restricting, and managing access rights (including need-to-know, privileged restrictions, segregation, logging, and consistency with classification) directly constrain session hijacking vectors that rely on improper or overly permissive access grants to remote services, but leave residual gaps such as hijacking of already-authorized sessions via technical means like token theft or MITM that the governance-focused control does not itself close.
- T1563.001prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, privileged restrictions, segregation, formal authorization, and mapping of rights (including to network services) directly constrain the conditions under which an SSH session can legitimately exist and be hijackable, but leave open residual vectors such as runtime agent/socket compromise after initial authorized access.
- T1563.002prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, privileged restrictions, formal authorization, logging, and consistency with classification/perimeter directly constrain who can legitimately connect to or use RDP sessions, preventing the technique from succeeding in most cases; however, it is governance-level and leaves technical enforcement (e.g., session isolation, tscon.exe protections) to other controls.
- T1564.008prevents — A.5.15 requires a topic-specific access control policy, determination of who needs what access (including need-to-know and restrictions on privileged access), formal authorization of requests, and consistent mapping of rights to classification and connections; this constrains who can create or modify inbox/transport rules that hide emails, but does not stop a legitimately authorized (or already-compromised) user from abusing that permission.
- T1565prevents — A.5.15's policy-driven access control rules (need-to-know, segregation of duties, formal authorization, role-based restrictions, and consistency with classification) prevent unauthorized entities from reaching the data or applications an adversary would need to manipulate, but do not stop authorized users or processes that have already been granted access from performing the manipulation.
- T1565.001prevents — A.5.15's access control policy, rules, need-to-know, role-based restrictions, and consistency with classification directly constrain which authorized entities can reach or alter stored data, preventing the technique for the bulk of cases where manipulation requires unauthorized access; it leaves a remainder for authorized insiders or post-compromise scenarios where access is already legitimate.
- T1566prevents — A.5.15's policy-driven requirements for determining authorized entities, need-to-know, segregation, formal authorization, and consistent access rights (including to networks/services) constrain some delivery vectors and post-compromise access granted via phishing, but do not stop the social-engineering delivery or initial credential-harvesting/execution techniques themselves.
- T1566.002prevents — A.5.15 requires a topic-specific access control policy, requirements for determining authorized entities/roles, restrictions on privileged access, formal authorization, and consistent rules that can constrain OAuth consent flows, device authorization, and some token-stealing vectors, but leaves the social-engineering delivery, user execution, and most phishing tactics untouched.
- T1566.003prevents — A.5.15's topic-specific access control policy, need-to-know, segregation, formal authorization, and rules for entity access (including in distributed environments) can constrain which third-party services and connections employees are authorized to use, thereby preventing some vectors of spearphishing-via-service from succeeding; this is only a slice of the social-engineering technique itself.
- T1566.004prevents — A.5.15's topic-specific access control policy, need-to-know, segregation of duties, formal authorization, privileged access restrictions, and logging requirements can constrain some social-engineering outcomes that result in unauthorized access grants, but do not stop the voice call, user manipulation, or credential divulgence themselves.
- T1567.001prevents — A.5.15's topic-specific policy, entity/access-right mapping, need-to-know, privileged-access restrictions, and consistency rules can prevent unauthorized exfiltration to a code repo when the data owner classifies it and the policy explicitly denies that channel or role; this is only a minority slice of the technique because the control is governance/planning and does not itself enforce runtime network or API-level blocks on already-authorized entities.
- T1567.002prevents — A.5.15's policy-driven determination and enforcement of who gets which access (including need-to-know, privileged restrictions, logging, and dynamic rules) directly constrains unauthorized outbound data flows to cloud storage when those flows violate the defined access rights, but leaves open many residual cases (e.g., authorized users abusing legitimate cloud-service access, mis-mapped rules, or insider exfil).
- T1567.003prevents — A.5.15's topic-specific access control policy, entity/access mapping, need-to-know, restrictions on privileged access, and rules considering all connection types in distributed environments can constrain which entities are authorized to reach external text storage sites, thereby preventing the exfiltration technique from succeeding in many cases; however, it does not block all outbound channels or remove the adversary's ability to use permitted connections or alternate methods.
- T1567.004prevents — A.5.15's policy-driven access control rules, need-to-know, role-based restrictions, and consistency with classification can block unauthorized entities (including adversary-controlled ones) from the SaaS/webhook channels used in this technique, but this is only a slice: the control does not reach manual direct posts from already-compromised victim systems, dynamic factors, or all distributed connections, and leaves the dominant exfiltration-via-legitimate-SaaS-link vector mostly untouched.
- T1569prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and consistency with classification can prevent many unauthorized service interactions or creations, but the control is governance-oriented, silent on technical enforcement of service-specific rights, boot-time daemons, and remote service abuse vectors, leaving a large remainder.
- T1569.002prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged-access restrictions, segregation of duties, and formal authorization directly constrain who may legitimately invoke the service control manager or create/modify services, thereby stopping many (but not all) abuse paths for T1569.002.
- T1569.003prevents — A.5.15's policy, requirements, role-based rules, need-to-know, privileged-access restrictions and segregation of duties can constrain which entities are authorized to invoke systemctl (or start/enable services), preventing the technique for many users and roles; this is a genuine but minority slice of the Linux technique space whose dominant vectors (compromised root/admin shells, existing service accounts, or post-compromise local execution) remain untouched by the governance layer alone.
- T1570prevents — A.5.15's policy-driven access control rules, need-to-know, role-based restrictions, and consistency with classification can block many unauthorized file-copy paths (e.g. SMB shares, RDP, scp/sftp to non-authorized systems), but native tools, already-authenticated sessions, and dynamic/web-service transfers remain possible under the same rules.
- T1572prevents — A.5.15 requires a topic-specific access control policy, rules, and rights mapping that explicitly consider network connections, distributed environments, and authorized-only access to network services, which constrains many tunneling vectors that bypass filters or reach unauthorized destinations; it does not reach all protocol-tunneling implementations (e.g. those inside already-authorized encrypted channels or using permitted services).
- T1574.001prevents — A.5.15's policy-driven determination and enforcement of authorized access (including need-to-know, privilege restrictions, segregation, and consistent rights mapping) constrains many DLL abuse vectors that rely on unauthorized placement, substitution, or elevated execution, but leaves open attack variants that succeed under already-authorized processes or legitimate search paths.
- T1574.005prevents — A.5.15 requires defining and enforcing topic-specific access control policy plus rules that explicitly consider physical perimeter needs, information classification consistency, restrictions on privileged access, and limiting entities (including services) to only authorized assets and connections; this directly constrains the weak directory/binary permissions that enable the hijack, but leaves a bounded remainder for installer-created %TEMP% subdirectories and dynamic factors that the control treats only at the policy level rather than mandating hardened defaults.
- T1574.006prevents — A.5.15 requires a topic-specific access control policy that determines required access types, enforces need-to-know, restricts privileged access, segregates duties, formalizes authorization, manages rights, and considers dynamic factors and all connection types; this constrains many (but not all) environment-variable and library-precedence vectors that produce unauthorized code execution or privilege escalation.
- T1574.007prevents — A.5.15's policy-driven access control rules, need-to-know, privileged-access restrictions, and consistency requirements for distributed environments constrain who can modify PATH/$PATH or place binaries in searched directories, preventing the technique for many authorized entities but leaving slices (e.g., unmonitored user-level modifications, dynamic factors, or legacy paths) unaddressed.
- T1574.008prevents — A.5.15's policy-driven access control rules, need-to-know, least-privilege restrictions, role-based mapping, and consistency with classification/perimeter requirements can constrain where and how untrusted entities place files that would hijack a search order, but this is only a minority slice of the technique (which primarily exploits missing full paths in legitimate program calls rather than access rights themselves).
- T1574.009prevents — A.5.15's policy-driven determination of access requirements, need-to-know, segregation of duties, privileged-access restrictions, and explicit mapping of rights to entities (including services) constrains where and how unquoted service/shortcut paths can be legitimately configured, preventing many privilege-escalation and persistence instances of the technique; it leaves a remainder of developer/admin misconfigurations that still satisfy the policy.
- T1574.010prevents — A.5.15 requires determining access needs, defining/implementing access control rules (including consistency with classification, restrictions on privileged access, and need-to-know), and mapping rights to entities, which directly prevents improper file/service permissions that enable binary hijacking; however, it is governance-oriented, references technical details to other clauses, and does not itself enforce OS-level ACLs on binaries/directories.
- T1574.011prevents — A.5.15 requires determining access needs, defining and communicating a topic-specific access control policy, and implementing rules via rights/restrictions (including consistency with classification, need-to-know, privileged restrictions, and all connection types), which directly constrains improper Registry permissions for services and thereby stops the hijacking technique from being available to unauthorized entities; however, it is a governance-level control that does not itself enforce technical ACLs on HKLM\SYSTEM\CurrentControlSet\Services keys.
- T1574.012prevents — A.5.15's policy-driven determination and enforcement of authorized access rights (including restrictions on privileged access, need-to-know, and entity-level mapping) can block unauthorized setting or abuse of COR_PROFILER for DLL hijacking/persistence in many cases, but leaves open in-memory/process-scope abuse, dynamic factors, and non-policy technical bypasses as a substantial remainder.
- T1578prevents — A.5.15's policy, requirements, rules, and role-based mapping for authorized access (including restrictions, need-to-know, privileged access, segregation, and consistency with classification) directly constrain the adversary permissions and actions needed to modify cloud compute infrastructure, but this is only a slice of the technique (e.g., does not reach all dynamic, distributed, or post-breach evasion vectors).
- T1578.005prevents — A.5.15 requires defining and enforcing an access control policy plus rules that explicitly cover restrictions to privileged access, formal authorization of requests, management of rights, segregation of duties, and consistency with classification and business needs; this directly constrains the authorization step for modifying tenant-wide policies, quotas, or compute settings (the core of the technique), but leaves open post-compromise abuse by already-authorized privileged entities and does not reach the full set of configuration-modification vectors.
- T1580prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access types, need-to-know, restrictions on privileged access, segregation of duties, formal authorization, and mapping of rights (including consistency with classification and dynamic controls) directly constrain which authenticated entities can invoke discovery APIs/CLIs against IaaS resources, preventing the technique for unauthorized callers; it is only partial because the control is governance-oriented, assumes prior authentication, and does not itself enforce technical checks at the API boundary (those live in referenced controls like 8.2/5.18).
- T1586prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, restrictions on privileged access, segregation of duties, formal authorization, need-to-know, logging, and consistent rules directly constrain many credential-compromise vectors (e.g. insider sales, weak reuse, unauthorized escalation) but leave social-engineering, phishing-for-credentials, and external brute-force/purchase methods untouched.
- T1586.003prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/roles, need-to-know, segregation of duties/privileges, formal authorization, and consistent access rules directly constrain the acquisition and use of compromised cloud accounts as infrastructure or exfiltration resources, but do not address upstream credential compromise vectors (phishing, spraying, token theft) that enable the technique.
- T1589.001prevents — A.5.15's topic-specific access control policy, need-to-know, segregation of duties, privileged-access restrictions, formal authorization, and consistent rights mapping (including to classification and perimeter needs) constrain what credentials an organization issues or exposes internally, thereby preventing some gathering vectors such as overly broad account proliferation or leaks from misconfigured internal resources; they do not stop external elicitation, phishing, dark-web purchase, or compromise of third-party sites.
- T1595.003prevents — A.5.15's policy-driven access control rules, need-to-know, restrictions on privileged access, and consistency requirements for distributed environments can block many unauthorized discovery paths (e.g. hidden portals, private buckets) once rules are enforced, but the control is governance-oriented, silent on technical enforcement depth against reconnaissance wordlist scanning itself, and leaves open paths such as public content or pre-auth probes.
- T1598.001prevents — A.5.15's topic-specific access control policy, need-to-know, segregation, formal authorization, and rules for entity access rights (including in distributed environments and third-party services) constrain what information can be legitimately requested or shared, reducing the success window of spearphishing lures that rely on eliciting credentials or sensitive data.
- T1599prevents — A.5.15's policy, requirements, and rules for access control (including restrictions to privileged access, segregation of duties, formal authorization, and consistency with perimeter needs) constrain how boundary devices are administered and who can reconfigure them, preventing the initial compromise or rights escalation needed for T1599 in a slice of cases, but do not reach device hardening, network-level enforcement, or the post-compromise reconfiguration itself.
- T1601.001prevents — A.5.15's policy, requirements, role-based rules, need-to-know, privileged-access restrictions, formal authorization, and logging directly constrain the administrative-level or boot-loader access required for both storage and in-memory patching on network devices, but leave open vectors such as physical console, already-compromised bootloaders (ROMMONkit), or insider misuse that the clause does not itself close.
- T1602prevents — A.5.15's policy-driven determination and enforcement of access rights, need-to-know, segregation, logging, and restrictions on privileged/distributed access directly constrains unauthorized collection from configuration repositories (a form of sensitive asset access), but leaves residual exposure via unaddressed vectors like protocol weaknesses, misconfigurations, or physical paths not fully covered by the control's governance focus.
- T1602.001prevents — A.5.15's policy-driven determination of access requirements, need-to-know, restrictions on privileged access, formal authorization, and mapping of rights (including to network services) can prevent unauthorized SNMP queries to the MIB when those rules are enforced at the device or network layer; however, it is only a governance layer that does not itself implement the technical enforcement mechanisms (e.g. SNMP community strings, ACLs, or v3 auth).
- T1602.002prevents — A.5.15's policy, requirements, and rules for determining, authorizing, and restricting access (including need-to-know, privileged restrictions, logging, and consistency with classification) directly constrain the SNMP/SMI queries and config-file reads that enable T1602.002, but leave a bounded remainder for misconfigurations, dynamic factors, physical paths, and unmanaged network services.
- T1606prevents — A.5.15's policy, requirements, rules, and role-based mapping for determining and enforcing authorized access (including need-to-know, segregation, privileged restrictions, and consistency with classification) constrain many vectors for forging web credentials from secrets or APIs, but leave open slices such as legitimate-but-abused AssumeRole calls or dynamic factors that the control only directs to consider.
- T1606.001prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, need-to-know, restrictions on privileged access, formal authorization, and consistent mapping of rights (including to classification and dynamic factors) constrain the conditions under which a forged cookie could be treated as valid, but do not reach the cryptographic generation or secret-value protection steps that enable the forgery itself.
- T1606.002prevents — A.5.15 requires determining access needs, defining/enforcing a topic-specific policy, formal authorization, role-based rules, need-to-know, segregation, and consistency with classification/privileges; this directly constrains the permission-claim and lifetime aspects of forged SAML tokens used for unauthorized access, but leaves the upstream certificate-compromise and federation-trust attacks (T1552.004) untouched.
- T1609prevents — A.5.15 requires determining access needs, defining/enforcing topic-specific access control policy and rules (including restrictions on privileged access, segregation of duties, formal authorization, role-based mapping, and consistency with classification), which directly constrains the 'sufficient permissions' required for an adversary to abuse container admin services or exec commands; however, it is silent on container-specific mechanisms, dynamic access factors, and enforcement depth, leaving a substantial remainder unaddressed.
- T1610prevents — A.5.15's policy-driven access control rules, role-based restrictions, privileged-access limits, need-to-know, and consistency with classification/perimeter requirements can block unauthorized container deployment via APIs or dashboards when those actions require elevated or unapproved access, but this is only a slice of the technique (e.g., does not stop all image-based or workload-driven deployments once initial access exists).
- T1611prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, segregation, privileged restrictions, and consistency with classification/perimeter directly constrain many configuration-driven escape vectors (privileged containers, bind mounts, socket exposure, over-broad rights) before they are instantiated, but does not reach kernel exploits, unshare/keyctl abuse, or VM hypervisor vulnerabilities that live outside policy-level access control.
- T1619prevents — A.5.15 requires defining and enforcing topic-specific access control policies, rules, and rights (including need-to-know, least privilege, formal authorization, and consistency with classification) that can prevent unauthorized API calls to enumerate cloud storage objects when properly mapped to IaaS identities and resources.
- T1621prevents — A.5.15 requires a topic-specific access control policy that explicitly considers restrictions to privileged access, segregation of duties, formal authorization of access requests, management of access rights, and consistency with information classification and dynamic factors; this constrains the credential+push-generation path in T1621 for many enterprise configurations, but leaves a bounded remainder (e.g., legacy/self-service password reset flows, MFA fatigue via repeated attempts, and non-policy-enforced MFA exemptions) unreached by the governance clause itself.
- T1648prevents — A.5.15's topic-specific policy, entity/access-right mapping, need-to-know, privileged-access restrictions, segregation of duties, formal authorization and dynamic-access considerations directly constrain which identities can create/invoke serverless functions or grant them IAM roles, preventing the abuse in a meaningful but incomplete slice (e.g., misconfigurations or insider abuse of legitimate roles remain possible).
- T1649prevents — A.5.15 requires a topic-specific access control policy, determination of who needs what access (including to certificates as authentication material), restrictions on privileged access, formal authorization of requests, management of access rights, and consistency with classification and perimeter needs; this constrains enrollment rights, certificate issuance, and privileged access to CAs/private keys that enable forging/stealing, but leaves technical theft vectors (crypto APIs, registry extraction, misconfigurations) and physical access largely to other controls.
- T1651prevents — A.5.15's policy, requirements, role-based rules, need-to-know, privileged-access restrictions, and formal authorization directly constrain which entities (including cloud admins and delegated accounts) can legitimately invoke management services like RunCommand, preventing the technique for properly governed identities while leaving the post-compromise abuse path and dynamic/perimeter gaps as a bounded remainder.
- T1654prevents — A.5.15's policy-driven access control rules, role-based restrictions, need-to-know, privileged-access limits and logging considerations directly constrain which entities can reach logs (especially centralized/SIEM and privileged ones), preventing the technique from succeeding for the bulk of enumerated targets, but leave a named remainder on local unprivileged host binaries (wevtutil, PowerShell, CollectGuestLogs.exe) that an already-compromised process can still invoke.
- T1657prevents — A.5.15's policy, requirements, and rules for determining, authorizing, and restricting access (including need-to-know, privileged access, segregation, formal requests, and consistency with classification) prevent the unauthorized-access slices of financial theft such as account compromise and unauthorized transfers, but leave social engineering, extortion/ransomware, impersonation, and non-access vectors untouched.
- T1666prevents — A.5.15 requires defining and enforcing topic-specific access control policies, rules, and rights (including restrictions on privileged access, segregation of duties, formal authorization, and consistency with classification) that directly constrain which entities can modify IaaS hierarchies, thereby stopping many but not all instances of T1666 (e.g., via compromised Global Administrator accounts or insider abuse of permitted APIs).
- T1669prevents — A.5.15 requires determining access requirements, a topic-specific policy, and rules that map rights/restrictions to entities (including network services), which constrains unauthorized Wi-Fi connections when enforced; however, it is governance-level planning that does not itself implement technical wireless authentication, encryption, or proximity controls.
- T1671prevents — A.5.15 requires defining and enforcing topic-specific access control policies, rules, and rights (including need-to-know, privileged restrictions, formal authorization, role-based mapping, and consistency with classification) that directly constrain unauthorized OAuth app consents, integrations, and persistent tokens; this stops many but not all instances because the control is governance-oriented, leaves technical enforcement to referenced controls (e.g. 5.16/5.18/8.2), and does not address all dynamic or post-consent bypass vectors.
- T1675prevents — A.5.15's topic-specific policy, entity/access mapping, need-to-know, privileged restrictions, segregation, and formal authorization directly constrain which entities (including ESXi hypervisor services) can legitimately invoke guest-execution APIs, preventing the abuse when those rules are enforced; residual because the control is governance-oriented and does not itself implement or enforce the technical boundary on the ESXi platform.
- T1677prevents — A.5.15's policy, requirements, and rules for determining authorized access, need-to-know, segregation, formal authorization, and consistent rights (including in distributed environments) constrain who can legitimately reach and modify CI/CD configuration, referenced files, and build inputs, thereby stopping many poisoning vectors before the technique can run; it leaves a large remainder around misconfigured triggers, trusted inputs, and self-hosted runners that still allow unauthorized injection.
- T1684prevents — A.5.15's topic-specific policy, need-to-know, segregation of duties, formal authorization, privileged-access restrictions and role-based rules directly constrain the 'user-authorized' slice of social engineering (e.g. limiting what an tricked help-desk or approver can grant), but do not stop the adversary from influencing the initial human action itself.
- T1685.001prevents — A.5.15 requires a topic-specific access control policy that explicitly considers logging (see 8.15) and formal authorization of access requests, which constrains who may legitimately reach auditpol.exe, registry keys, and service controls used by T1685.001; this prevents the technique for non-privileged actors but leaves the privileged-administrator slice (the technique's dominant case) untouched.
- T1685.002prevents — A.5.15's topic-specific policy, requirements for logging (explicitly referencing 8.15), formal authorization of access requests, management of access rights, and restrictions on privileged access directly constrain the permissions needed to disable/modify cloud logging, preventing the technique where those controls are enforced; partial because it is governance/policy that does not itself implement or enforce the technical restrictions on all platforms and entities.
- T1686.001prevents — A.5.15's topic-specific policy, requirements for determining authorized entities/access, restrictions on privileged access, segregation, formal authorization, and rule implementation (including consistency with classification and perimeter needs) directly constrain the permissions and processes an adversary would need to modify cloud firewall rules, but this is governance/planning that does not itself enforce technical boundary controls at runtime.
- T1686.002prevents — A.5.15 requires defining/implementing access control rules (including restrictions, consistency with classification/perimeter needs, and considering all connection types in distributed environments) that directly constrain the network-device ACL/firewall rule changes the technique performs once the adversary has obtained device access.
Prevented OWASP Web Top 10 (2025) risks (8)
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)
- A01mitigates — A.5.15's policy, requirements, and rule-mapping for access control (including need-to-know, privileged restrictions, formal authorization, and consistency with classification) can bound the blast radius or realization of some A01 failures (e.g., via role-based rules or segregation), but the clause itself is governance-level and does not enforce or implement the actual runtime authorization decisions that would limit a realized weakness.
- A01prevents — A.5.15's purpose and guidance directly address determining, defining, and implementing access control rules, policies, and rights to ensure authorized access (covering authorization decisions, need-to-know, privileged restrictions, formal requests, and role-based mapping), which prevents many Broken Access Control instances like missing checks, IDOR, and improper authorization, but leaves out non-authorization members such as path traversal and CSRF as in the AC-3 vs A01 anchor.
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.