Cyber Resilience

← ISO 27001 Annex A

A.5.8 Organizational

Information security in project management

AttributesPreventive C·I·A Identify Protect Governance Governance and Ecosystem Protection

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 (15)

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).

CM-3→P PL-2→P RA-3←M →P PM-9gov RA-2gov SA-17gov SA-3gov SA-4gov

Why these map — AI rationale (under review)

SA-3mostlyaligns with — Both controls embed security risk assessment, requirements definition, and treatment activities into the project or system-development life cycle so that security is addressed from initiation through delivery.
CM-3partialaligns with — Both ensure that security-related changes and risk-treatment progress are reviewed and approved at defined project or configuration-control gates.
PL-2partialaligns with — Both require that security and privacy requirements—including risk treatment and compliance obligations—are documented and reviewed as part of project or system planning artifacts.
RA-2partialaligns with — Both mandate early and recurring categorization of information assets and assessment of security risks within the context of projects or system initiatives.
RA-3partialaligns with — Both require that project or system risks be formally assessed and treated, with periodic re-evaluation throughout the life cycle.
RA-2implements — 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.
SA-3implements — A.5.8 requires information security to be integrated into project management across the full project life cycle; SA-3 operationalizes that exact outcome by mandating an SDLC process that incorporates security and privacy considerations throughout development and acquisition.

Aligned NIST CSF 2.0 outcomes (20)

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).

GV.PO-01gov GV.RM-03gov GV.RR-02gov GV.SC-03gov GV.SC-05gov ID.RA-04gov ID.RA-05gov ID.RA-06gov

Why these map — AI rationale (under review)

GV.RM-03mostlyaligns with — Embedding information security risk management into every project ensures cybersecurity risk activities are part of enterprise risk management processes.
ID.RA-05mostlyaligns with — The control requires early and ongoing assessment of information security risks within projects so that risk responses can be prioritized and planned.
ID.RA-06mostlyaligns with — Project governance must select, prioritize, and track information security risk-treatment actions throughout the project life cycle.
GV.RR-02partialaligns with — The control mandates that project-specific roles, responsibilities, and authorities for information security are defined and allocated.
GV.SC-05partialaligns with — Security requirements for third parties and suppliers are explicitly captured in project contracts and agreements.
ID.RA-04partialaligns with — Projects must identify potential impacts and likelihoods of threats exploiting vulnerabilities when determining information security requirements.
GV.RM-03implements — 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.
GV.RR-02implements — 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.
GV.SC-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-04implements — 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.RA-05implements — A.5.8 requires addressing information security risks (including threats/vulnerabilities/likelihoods/impacts) throughout the project life cycle, which directly operationalizes the risk-understanding and prioritization outcome named in ID.RA-05 within the project-management domain
ID.RA-06implements — A.5.8 requires addressing information security risks (including choosing/planning/tracking responses) throughout the project life cycle, which directly operationalizes the risk-response activities named in ID.RA-06 within the project-management domain

Related OWASP ASVS 5.0 requirements (13)

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).

V11.1.1←M V13.1.1←P V13.1.4→P V14.1.1←M V15.1.1←M →P V2.1.1→P V2.1.3←P →P V6.1.1←M V6.1.3→P V8.1.1←M →P

Why these map — AI rationale (under review)

V13.1.4partialaligns with — The ISO control's call for determining and scheduling rotation of critical project secrets aligns with the ASVS requirement to document the secrets essential to application security and their rotation schedule.
V15.1.1partialaligns with — The ISO control's mandate to assess and treat information security risks early and throughout the project lifecycle directly supports the ASVS requirement for documented, risk-based remediation timelines for vulnerable third-party components.
V2.1.1partialaligns with — Requiring information security requirements to be defined at the earliest project stages aligns with the ASVS need for documented input validation rules that specify how data items must be checked against expected formats and business constraints.
V2.1.3partialaligns with — The ISO guidance to derive business-process requirements such as transaction logging, monitoring, and non-repudiation maps to the ASVS expectation that business-logic limits and validations are explicitly documented for both per-user and global contexts.
V6.1.3partialaligns with — Specifying authentication requirements derived from the required level of identity assurance in project security requirements matches the ASVS need to document all authentication pathways together with their security controls.
V8.1.1partialaligns with — Defining access-provisioning and authorization processes for customers, privileged users, and external suppliers in project requirements corresponds to the ASVS requirement that authorization documentation specify function-level and data-specific access rules based on consumer permissions.

Related weaknesses / CWE (12)

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-1059←P CWE-1068←P →P CWE-284→P CWE-285→P CWE-306→P CWE-435←P →P CWE-657←P →P CWE-732→P CWE-862→P

Why these map — AI rationale (under review)

CWE-1068prevents — Project-level design-to-implementation traceability directly reduces divergence between documented design and delivered code.
CWE-284prevents — Embedding security requirements and risk treatment into project governance forces explicit definition of access rules and roles before code or configuration is created, reducing the chance that access-control decisions are omitted or left to default.
CWE-285prevents — Requiring authorization processes and privilege assignments to be specified during project initiation prevents downstream components from receiving overly broad or incorrect rights that would allow unauthorized actions.
CWE-306prevents — Mandating authentication requirements for critical functions at the requirements-gathering stage ensures that essential operations are not left unprotected by missing login or verification mechanisms.
CWE-435prevents — Project-level integration planning can surface interaction issues between components.
CWE-657prevents — Embedding security in project management helps enforce secure design principles from the outset.
CWE-732prevents — Project-level security requirements derived from policy and threat modelling drive the assignment of correct file, resource and configuration permissions rather than leaving them at insecure defaults.
CWE-862prevents — Defining authorization responsibilities and reviewing risk-treatment progress throughout the project lifecycle catches missing authorization checks before the system is deployed.

Mitigated MITRE ATT&CK techniques (490)

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←M T1001.001←M T1001.002←M →P T1001.003←M T1003.003→P T1003.006→P T1003.008→P T1005→P T1006←M T1011←M T1014←M T1020→P T1021→P T1021.004→P T1021.007→P T1021.008→P T1027.001←M T1027.002←M T1027.003→P T1027.006←M T1027.008←M T1027.009←M →P T1027.010←M →P T1027.011←M T1027.014←M T1027.016←M T1027.017→P T1027.018←M →P T1030←M T1036←M →P T1036.002→P T1036.003←M T1036.004→P T1036.005←M T1036.008←M →P T1036.009←M T1036.010→P T1036.012←M T1037→P T1037.001→P T1037.003→P T1040→P T1041→P T1048→P T1048.001→P T1048.003→P T1052→P T1052.001→P T1053.007→P T1055←M T1055.001←M T1055.002←M T1055.003←M T1055.004←M T1055.005←M T1055.008←M T1055.009←M T1055.011←M T1055.012←M T1055.013←M T1055.014←M T1055.015←M T1056.002→P T1056.003→P T1059→P T1059.005→P T1059.007→P T1059.008→P T1059.009→P T1059.013→P T1068←M →P T1069.003→P T1070←M T1070.010←M T1071←M T1071.001←M T1071.004←M T1071.005←M T1072→P T1078→P T1078.001→P T1078.002→P T1078.003→P T1078.004→P T1080→P T1087.004→P T1090←M T1090.002←M T1090.003←M T1090.004←M T1092→P T1095←M T1098→P T1098.001→P T1098.002→P T1098.003→P T1098.004→P T1098.005←M →P T1098.006→P T1098.007→P T1102←M T1102.002→P T1102.003←M →P T1104→P T1110→P T1110.001→P T1110.002→P T1110.003→P T1110.004→P T1111←M →P T1114.001→P T1114.002→P T1114.003→P T1127←M →P T1127.001←M →P T1127.002→P T1127.003←P →P T1132.001←M T1132.002←M T1133←M →P T1134←M T1134.001←M T1134.004←M T1136→P T1136.001→P T1136.002→P T1136.003→P T1137→P T1137.001→P T1137.002→P T1137.003→P T1137.004→P T1137.005→P T1137.006→P T1176→P T1176.001→P T1176.002→P T1185←M →P T1187→P T1189→P T1190→P T1195→P T1195.001→P T1195.002←P →P T1195.003→P T1199→P T1202←M T1203→P T1204→P T1204.001→P T1204.002→P T1204.003→P T1204.004←M T1204.005→P T1207←M →P T1210→P T1211←M →P T1212→P T1213→P T1213.001→P T1213.002→P T1213.003→P T1213.004→P T1213.005→P T1213.006→P T1216←M T1218←M T1218.005←M →P T1218.007←M T1218.008←M T1218.010←M T1218.011←M T1218.012←M T1218.013←M T1218.015→P T1219.001→P T1219.003←M T1221←P →P T1222←M T1222.001←P T1222.002←M T1480.001←M T1484←M →P T1484.001→P T1484.002←M →P T1485→P T1486→P T1491→P T1491.001→P T1491.002→P T1495→P T1496→P T1496.001→P T1496.002→P T1496.003→P T1496.004→P T1497←P T1497.002←M T1498→P T1499←P →P T1499.002→P T1499.003→P T1499.004→P T1505→P T1505.001→P T1505.002→P T1505.003→P T1505.004→P T1525→P T1528→P T1530→P T1534→P T1535←M T1537←M →P T1538→P T1539←F →P T1542←M T1542.002←M →P T1542.004→P T1542.005→P T1543.002→P T1543.003→P T1543.005→P T1546→P T1546.001→P T1546.004→P T1546.007→P T1546.008→P T1546.013→P T1546.015→P T1546.016→P T1547.001→P T1547.006→P T1547.007→P T1547.012→P T1548→P T1548.001→P T1548.002←M T1548.003→P T1548.005→P T1548.006→P T1550←F →P T1550.001←F →P T1550.002←F T1550.003←F →P T1550.004←F →P T1552→P T1552.001→P T1552.004→P T1552.005→P T1552.006→P T1552.007→P T1552.008→P T1553.001←F T1553.002←P T1553.003←M →P T1553.004←M →P T1553.005←M T1553.006←M →P T1554→P T1555.006→P T1556←M →P T1556.003→P T1556.005←P →P T1556.006←P →P T1556.007←M →P T1556.008→P T1556.009←M →P T1557→P T1557.001→P T1557.003→P T1558→P T1558.001→P T1558.002→P T1558.004→P T1559.002→P T1559.003→P T1561.002→M T1563→P T1563.001→P T1564←M T1564.001←M T1564.004←M T1564.006→P T1565→P T1565.001→P T1565.002→P T1565.003→P T1566→P T1566.001→P T1566.002→P T1566.003←M →P T1566.004→P T1567→P T1567.001→P T1567.002→P T1567.003→P T1567.004→P T1568←M T1571←M T1572←M →P T1574←P →P T1574.001←M →P T1574.005→P T1574.007→P T1574.008→P T1574.009→P T1574.010→P T1574.011→P T1574.012→P T1574.013←P T1578←M T1578.001←M T1578.002←M →P T1578.003←M T1578.004←M T1578.005←M →P T1580→P T1583.001→P T1584→P T1584.001→P T1586→P T1586.003→P T1587.001→P T1587.004→P T1588.005→P T1589→P T1589.001→P T1589.003→P T1590.003→P T1591.002→P T1593.003→P T1598→P T1598.001→P T1598.002→P T1598.003→P T1598.004→P T1599←M →P T1599.001←M T1600←P →P T1600.001→P T1601→P T1601.001←P →P T1601.002←P T1602→P T1602.001→P T1602.002→P T1606←M →P T1606.001←F →P T1606.002←M →P T1608.004→P T1608.005→P T1609→P T1610←P →P T1611→P T1612←P →P T1620←M T1621←M →P T1622←P T1647←P T1648→P T1649→P T1650→P T1653←P T1657→P T1665←P T1666←M →P T1671→P T1675→P T1677←P →P T1678←P T1684→P T1684.001→P T1684.002←M →P T1685←M T1685.001→P T1685.002←M →P T1685.003←M T1685.004←M T1685.005←M T1686←F T1686.001←M →P T1686.002→P T1686.003←M T1687←P →P T1688←M T1689←M →P T1690←P

Why these map — AI rationale (under review)

T1001.002prevents — A.5.8 mandates early/periodic risk assessment, threat modelling, requirements derivation (including for comms security and C2-like channels), and treatment throughout the project life cycle; this can prevent steganography from being designed into project deliverables or C2 mechanisms, but only for first-party/custom projects and leaves adversary use of off-the-shelf or post-delivery stego untouched.
T1003.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. access control, authentication, logging, compliance), and treatment review across any project type; this can prevent insecure designs or implementations that would allow NTDS.dit extraction (e.g. via poor backup protection, weak authz, or unmonitored access), but leaves many post-deployment runtime paths (e.g. compromised admin, unpatched DC, or operational misconfigs) untouched.
T1003.006prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authz, access provisioning, compliance, and threat modeling), and governance review that can prevent DCSync-enabling misconfigurations (e.g., excessive DC privileges or weak replication controls) from being designed into the environment; it does not reach runtime technique execution or existing deployments.
T1003.008prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including requirements for authentication, access control, credential protection and third-party assurance, which can stop the credential-dumping technique from being introduced into delivered systems or project environments; it does not reach runtime protection of already-deployed /etc/shadow files on Linux hosts.
T1005prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including information security requirements (classification, protection needs for CIA, access controls, logging, third-party assurance, etc.) that can drive design choices preventing sensitive data from being left accessible on local systems in delivered products/services.
T1020prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including data classification, protection needs for confidentiality/integrity/availability, access controls, logging/monitoring, and compliance) across all project types, which directly constrains design choices that would otherwise allow automated exfiltration paths; this is a genuine but minority slice because the control is governance/process-oriented and does not itself implement or enforce the resulting technical barriers.
T1021prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, access control, third-party clauses, and compliance), and governance review that can prevent insecure-by-default remote service configurations or weak credential handling in delivered systems, but leaves residual paths such as post-deployment credential compromise, insider abuse of valid accounts, and non-project-managed services.
T1021.004prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, access control, third-party clauses), and integration into the full project life cycle; this prevents many SSH misuse vectors (e.g., weak defaults, poor key management, unvetted accounts) from being present in delivered systems, but leaves residual paths such as runtime credential compromise or post-deployment configuration changes.
T1021.007prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of requirements (authentication, access provisioning/authorization, third-party assurance, compliance) that directly address federation, valid-account misuse, and cloud-service access risks in any project, but does not itself enforce mechanisms that stop the technique from running.
T1021.008prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (authentication, access provisioning, authorization, privileged users, third-party contracts) throughout the project life cycle, which can prevent insecure-by-default direct VM connection methods from being introduced; it does not guarantee removal of all such access vectors once present or cover every implementation detail.
T1027.003prevents — Integrating security risk assessment, requirements (incl. application security, threat modelling, logging/monitoring interfaces, and compliance), and periodic reviews into the project life cycle can prevent steganography from being designed into custom deliverables or malware, but leaves a bounded remainder for adversary use of off-the-shelf tools or third-party components on Linux/macOS/Windows platforms.
T1027.009prevents — integrating security risk assessment, requirements derivation (including threat modelling), and reviews into the project life cycle can prevent developers from introducing embedded-payload techniques in delivered code or products, but the control is silent on enforcement depth, testing rigour, and non-development projects so only a slice of the technique is reached
T1027.010prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and integration into the full project life cycle for any project type; this can surface and block common obfuscation patterns in delivered code or scripts before deployment, but does not guarantee detection or removal of every manual or tool-assisted obfuscation technique an adversary might introduce post-delivery or at runtime.
T1027.017prevents — A.5.8 mandates early and periodic information security risk assessment/treatment plus explicit derivation of requirements (threat modelling, vulnerability thresholds, architecture/design protections, compliance) in any project type; this can prevent SVG smuggling by requiring filters/sanitizers in the design of content-handling systems, but leaves residual risk from incomplete requirements, non-ICT projects, or post-design implementation gaps.
T1027.018prevents — integrating security risk assessment, requirements derivation (including from threat modelling), and reviews into the project life cycle can surface and block the introduction of invisible-Unicode concealment in project deliverables, but the control is silent on detection mechanisms, tooling, or enforcement that would stop the technique in every case
T1036prevents — integrating security risk assessment, requirements (incl. authentication, access control, logging, monitoring, non-repudiation), threat modelling and compliance into the project life cycle can prevent some masquerading vectors (e.g. by mandating proper naming, metadata, and detection interfaces in delivered artifacts), but leaves many post-delivery runtime renaming, file-type trickery, and evasion techniques untouched
T1036.002prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and design protections against known threats; this can stop RTLO-based filename spoofing from being introduced in developed/delivered software or project artifacts, but leaves attacker-controlled external files, user-executed payloads, and non-project contexts untouched.
T1036.004prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (including from threat modelling), and treatment of project risks including those tied to execution/communications, which reaches the design-time slice of naming tasks/services to look benign but leaves post-design runtime masquerading and non-ICT projects as a named remainder
T1036.008prevents — integrating security risk assessment, requirements (including validation/sanitization and compliance), threat modelling, and architecture protections into the project life cycle can stop many instances of file-type masquerading from being introduced or deployed, but does not reach all delivery vectors or post-project execution paths for this technique
T1036.010prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. authentication, access provisioning, authorization, and compliance), and governance review throughout the project life cycle; this prevents many masquerading account creations in new systems, services, or deployments by enforcing proper naming and identity controls, but leaves residual cases (e.g., post-deployment adversary actions, legacy accounts, or non-project-managed environments) untouched.
T1037prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. for boot/logon mechanisms, auth, access control, logging), threat modelling and architecture protection that can stop insecure initialization scripts from being introduced in development or configuration projects; this is a genuine but minority slice of T1037 (most instances arise from post-deployment admin activity or existing OS mechanisms rather than new project deliverables).
T1037.001prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling and policy), and treatment into the project life cycle for all project types; this can prevent the insecure design/implementation choice that allows an adversary-controlled logon script to be registered for persistence, but only reaches the subset of such weaknesses introduced during development or configuration projects and leaves post-deployment or non-project vectors untouched.
T1037.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements derivation (incl. authz, logging, compliance) across all project types, which can prevent insecure logon-script configurations from being introduced in AD/GPO projects; this is a genuine but minority slice of the persistence technique (most instances arise from post-deployment admin actions or existing configs, not new projects).
T1040prevents — A.5.8 mandates early and periodic project risk assessment, security requirements (incl. encryption, authentication, logging, and compliance), threat modelling, and architecture protection that directly stop sniffing by requiring encrypted protocols, secure auth, and network design choices; this covers many but not all cases (e.g. legacy cleartext, post-deployment misconfigs, or non-project-managed environments).
T1041prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including communication security and derived requirements (e.g. data leakage detection, logging/monitoring interfaces, non-repudiation), which can prevent the design or implementation of C2-capable exfiltration paths in in-house or supplier-managed projects; this is a genuine but minority slice of the technique's surface (most T1041 abuse occurs in already-deployed third-party malware or post-compromise living-off-the-land, outside project risk management).
T1048prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for confidentiality, access control, monitoring, compliance, and third-party contracts) across all project types; this can prevent many T1048 vectors (e.g., insecure cloud/IaaS/SaaS designs, unmonitored protocols, weak auth) when applied to development and deployment projects, but leaves residual cases (e.g., post-deployment adversary behavior on already-built systems, non-project-managed environments, or insider exfil using permitted tools).
T1048.001prevents — integrating security risk assessment, requirements derivation (including encryption, authentication, access control, logging, compliance), threat modelling and architecture protection into the project life cycle can stop many symmetric-exfiltration designs from being built or deployed, but does not block all post-compromise manual key-exchange or alternate-channel choices an adversary can still make in already-compromised environments
T1048.003prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including communication security and explicit derivation of requirements (e.g. confidentiality, encryption interfaces, compliance, threat modeling) that would block unencrypted exfiltration in the delivered system or architecture; this is genuine but only a minority slice because the control is governance/process-oriented, applies only to new/ongoing projects, does not reach already-deployed systems or runtime enforcement, and leaves residual gaps in non-ICT projects or incomplete requirement flow-down.
T1052prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (including for physical assets, access provisioning, third-party agreements, and controls like data leakage detection) across all project types, which can prevent many physical exfiltration vectors from being introduced in project deliverables or processes; however, it is governance/process-oriented and does not directly enforce runtime controls on user-introduced media in operational air-gapped scenarios.
T1052.001prevents — A.5.8 mandates integrating security risk assessment, requirements elicitation (including data classification, access controls, monitoring, and compliance), and periodic treatment/review into every project lifecycle; this directly prevents many classes of USB-exfiltration vectors (e.g., by requiring no unnecessary data on removable media, proper authorization, DLP hooks, and threat modeling of physical exfil paths) but leaves residual cases (e.g., insider misuse of authorized USB devices or post-deployment operational bypasses) unaddressed by project management alone.
T1053.007detects — A.5.8 mandates periodic risk assessment, progress review, effectiveness evaluation/testing of treatments, and governance follow-up throughout the project life cycle, which can surface anomalous or malicious container orchestration jobs introduced via project deliverables, but does not require or perform ongoing runtime detection of the technique itself once deployed in a cluster.
T1053.007prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling), and treatment into the project life cycle for all project types; this can prevent insecure-by-default orchestration job configurations from being introduced in the first place, but only reaches the subset of T1053.007 that arises during project-managed deployments rather than runtime abuse of already-deployed orchestration features.
T1056.002prevents — A.5.8 mandates early and periodic project risk assessment, security requirements derivation (including authentication, access control, user duties, and threat modeling), and governance review that can prevent the insecure design/implementation choices enabling GUI input capture prompts in delivered systems or software.
T1056.003prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including auth, access control, logging, threat modeling), and periodic review into the project life cycle for any project; this directly prevents the insecure design and implementation that would allow an adversary to install credential-capturing code on an externally-facing portal during development or updates.
T1059prevents — A.5.8 mandates that information security risks (including those from execution of projects and from requirements such as application security per 8.26) are assessed, treated, and reviewed throughout the project life cycle, which can constrain or remove interpreters from builds or designs in some project types, but leaves the bulk of platform-default interpreters and post-deployment abuse untouched.
T1059.005prevents — A.5.8 mandates early and periodic information security risk assessment/treatment plus explicit derivation of requirements (including from threat modelling) across all project types; this prevents many (but not all) VB-abuse vectors by forcing secure design choices that can disable, sandbox or remove the attack surface for VBA/VBScript macros and scripts before they reach production.
T1059.007prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including security requirements, threat modelling, and architecture/design protections that can stop JS abuse techniques from being introduced into delivered systems or project artifacts, but this is a governance/integration process that does not reach all execution vectors (e.g. adversary-supplied external JS, post-delivery abuse, or non-project environments) and leaves residual exposure per the event-lane calibration examples.
T1059.008prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for network devices, access controls, authentication, logging, and third-party assurance) throughout any project life cycle, which can prevent the insecure-by-default CLI configurations and permission models that enable T1059.008; it does not guarantee prevention in all cases (e.g., post-deployment changes or non-project-managed devices).
T1059.009prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including authentication, authorization, access provisioning, compliance, and threat modeling) throughout the project life cycle for all projects; this directly constrains the design and implementation of cloud environments so that the abuse path (inadequate permissions, unauthenticated API access, missing controls on CLIs/shells/SDKs) is prevented in the delivered tenant, though residual risk remains from runtime credential compromise, misconfiguration, or incomplete enforcement.
T1059.013prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (incl. access control, auth, logging, threat modeling) integrated into any project life cycle; this can prevent insecure-by-default container platforms or images that enable T1059.013, but does not guarantee removal of all CLI/API abuse vectors once deployed.
T1068prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including threat modelling, vulnerability thresholds, and architecture protection) in all projects, which directly prevents many exploitable vulnerabilities from reaching production and thereby stops the T1068 technique from being available; it is only partial because it does not guarantee flawless implementation or address already-deployed vulnerable components.
T1069.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including access provisioning, authorization, authentication assurance, and compliance) that address permission-group discovery as a project risk, but this is governance-level integration that does not technically block the post-authentication enumeration techniques once credentials are obtained.
T1072prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access provisioning, authorization, authentication assurance, and compliance) for all projects including those delivering or integrating centralized deployment tools, which directly constrains the insecure-by-default configurations and permission models that enable T1072; it does not guarantee those requirements are correctly implemented or that all deployment-tool projects will be subjected to the process.
T1078prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. authentication, access provisioning, authorization, third-party clauses, and identity assurance), and governance review throughout the project life cycle, which directly constrains the creation or persistence of the exact account/permission conditions T1078 abuses (inactive accounts, excessive overlap, weak auth); this is a genuine but bounded slice of the technique because many compromise vectors (phishing, keylogging, supply-chain credential theft) sit outside project-management controls.
T1078.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authz, credential handling, third-party compliance), and treatment throughout the lifecycle, which directly prevents many default-account creation and persistence cases in new systems, integrations, and deployments; it leaves residual cases (e.g., factory defaults on unmanaged appliances, post-deployment changes, or non-project COTS) untouched.
T1078.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of requirements (authentication, access provisioning/authorization, credential strength via policy, third-party clauses, etc.) inside every project; this directly constrains the design and configuration choices that would otherwise allow easy domain-account compromise via weak defaults, password reuse, or missing privilege boundaries, but leaves residual paths such as runtime credential dumping (T1003) or post-deployment operational failures outside the project lifecycle.
T1078.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (auth, access control, credential handling, third-party assurance) in every project type, which can prevent insecure local-account creation or configuration that enables the technique, but does not guarantee enforcement of those requirements at runtime or eliminate all abuse vectors such as password reuse or dumping.
T1078.004prevents — A.5.8 mandates early/periodic risk assessment, security requirements (incl. authz, MFA-derived, credential handling, third-party assurance), and treatment throughout the project life cycle for any project (incl. cloud/ICT), which directly constrains many root causes of T1078.004 such as weak defaults, over-privileged roles, missing MFA, and poor credential management; it does not reach post-deployment account compromise vectors like phishing, brute force, or runtime misconfigurations in live cloud environments.
T1080prevents — integrating security risk assessment, requirements (incl. access control, integrity, monitoring, threat modelling), and reviews into the project life cycle for shared repositories and deliverables directly constrains the introduction or persistence of taintable content in those locations, but leaves residual paths such as post-deployment modifications, unmonitored shares, or non-project-managed binaries
T1087.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including access provisioning, authorization, authentication assurance, and compliance) that can drive preventive controls against account enumeration, but does not itself implement or enforce any technical barrier to the technique once authenticated access exists.
T1092prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including for communication security, third-party interfaces, and removable-media-adjacent assets) inside every project; this directly constrains the class of projects that would bake in air-gap C2 via removable media, but leaves residual risk in non-project-managed environments, legacy systems, and post-deployment changes.
T1098prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (auth, access control, policy compliance, third-party assurance) integrated into any project/SDLC, which directly blocks many account-manipulation vectors at design time; it does not reach runtime manipulation of already-deployed accounts or post-compromise actions by an adversary who already holds sufficient permissions.
T1098.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (authentication, access provisioning, third-party assurance, compliance) in all project lifecycles, which can stop many credential-addition vectors at design or procurement time, but leaves residual paths when the technique is executed post-compromise by an already-privileged actor inside a running environment.
T1098.002prevents — A.5.8 mandates early/periodic project risk assessment, security requirements elicitation (incl. authz, access provisioning, compliance), and governance review throughout any project life cycle; this directly constrains projects that could introduce or allow the mailbox-delegation misconfiguration, but leaves residual risk in non-project changes, post-deployment ops, and insider/admin abuse outside the project boundary.
T1098.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including access provisioning, authorization, authentication confidence, and third-party clauses) in all projects; this constrains many project-based paths to adding cloud roles/permissions (e.g. during IAM design or supplier onboarding) but leaves post-deployment account abuse, direct API abuse by already-privileged actors, and non-project vectors untouched.
T1098.004prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, access control, third-party clauses), and governance review that can prevent insecure SSH key management from being designed or deployed in ICT, cloud, or infrastructure projects; this reaches only a minority slice of the technique because most instances arise from post-deployment runtime abuse rather than project deliverables.
T1098.005prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. auth/access/MFA clauses), threat modelling and compliance checks that can block insecure device-registration paths in MFA/Intune projects; this reaches only the project-delivery slice of the technique, not post-deployment abuse by a compromised insider.
T1098.006prevents — A.5.8 mandates integrating security risk assessment, treatment, and requirements (including access control, authorization, authentication, and compliance) into all project phases, which would prevent many insecure-by-design RBAC/ABAC configurations that enable T1098.006; it does not reach runtime privilege escalations against already-deployed clusters or non-project changes.
T1098.007prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (e.g., access provisioning, authorization, least-privilege-derived controls, and third-party clauses) in every project type; this prevents the technique in new or modified systems by design but leaves residual risk in already-deployed systems, legacy accounts, and non-project changes.
T1102.002prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. comms), threat modelling and architecture protection that can stop legitimate web services from being selected or configured as bidirectional C2 channels during project delivery; this is a genuine but minority slice of the technique, which also arises post-deployment via runtime compromise or adversary-chosen services outside any project.
T1102.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and treatment of risks such as internal/external communication security throughout the project life cycle, which can prevent selection or insecure configuration of one-way web-service C2 channels in developed systems.
T1104prevents — A.5.8 mandates early and periodic project risk assessment, security requirements derivation (incl. threat modelling, architecture protection against known threats, and comms security), and governance review throughout the SDLC; this directly prevents many multi-stage C2 designs from being introduced in custom or procured tools, but leaves residual cases (e.g. adversary reuse of third-party RATs, post-deployment staging, or non-project-managed components) untouched.
T1110prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication strength, MFA-like needs, password policy alignment, and assurance levels for identities/third parties), and integration into SDLC/governance, which can prevent many brute-force vectors at design time; however, it is a process-level control that does not itself enforce runtime mechanisms like lockouts, MFA, or rate limiting, leaving a large residual slice of the technique (especially post-compromise or offline guessing) unaddressed.
T1110.001prevents — A.5.8 mandates integrating security risk assessment/treatment and deriving requirements (including authentication strength, password policies, account lockout, MFA, and monitoring) into all projects, which directly stops most password-guessing techniques at the design stage; the bounded remainder is legacy or exempted components allowed by the control's own exception language.
T1110.002prevents — A.5.8 mandates early and ongoing integration of information security risk assessment, requirements (including authentication strength, password-related needs, and compliance), and treatment into all project lifecycles, which can prevent weak password storage, hashing, or credential-handling choices that enable cracking (as in the T1110.002 description).
T1110.003prevents — integrating security risk assessment, requirements (incl. authentication strength and MFA-like clauses), and threat modelling into the project life cycle can prevent password spraying by mandating stronger auth mechanisms or policies that stop the technique from succeeding, but this is limited to new/updated projects and does not address existing deployed systems or non-project-managed environments
T1110.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of authentication, access control, credential, and compliance requirements (including password policies and MFA-like measures) into project deliverables, which can prevent credential stuffing by enforcing stronger auth in developed systems; this is only a slice of the technique's surface because it does not reach already-deployed systems, legacy services, or non-project-managed environments.
T1111prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, MFA-relevant clauses, threat modelling), and governance review that can prevent insecure MFA designs or implementations allowing interception; this reaches only a minority slice of the technique (pre-deployment design/requirements), not runtime interception vectors such as keyloggers, SMS compromise or token replay on already-deployed systems.
T1114.001prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including data classification, protection needs for confidentiality/integrity/availability, access controls, logging, and compliance), and periodic treatment/review into the project life cycle; this can prevent the technique by ensuring email-handling projects (e.g., mail clients or archiving tools) are architected without insecure local plaintext storage of sensitive data, but leaves residual risk in non-project-managed environments, legacy systems, and post-deployment user behavior.
T1114.002prevents — A.5.8 mandates early and periodic risk assessment/treatment plus explicit derivation of requirements (e.g. authentication, access control, logging, compliance) that can block credential misuse and external collection paths in email projects, but does not guarantee enforcement of those requirements at runtime and leaves many post-deployment execution vectors untouched.
T1114.003detects — A.5.8 mandates that information security risks (including those from project-delivered systems like email/transport rules) are assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces misconfigurations or abuse vectors such as hidden forwarding rules before or during deployment, but does not itself instrument runtime detection of the technique once adversaries execute it post-delivery.
T1114.003prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling and policy), and treatment into the project life cycle for all projects; this can prevent the insecure design/implementation that allows unrestricted forwarding-rule creation and hiding, but leaves residual risk from runtime abuse by already-credentialed users or admins and from non-development projects.
T1127prevents — A.5.8 mandates early/periodic security risk assessment, requirements derivation (incl. from threat modelling), and treatment throughout the project life cycle for any project type; this directly prevents many T1127-enabling developer utilities or signed proxies from being introduced into production environments, but leaves a bounded remainder for post-deployment abuse of already-trusted third-party or legacy tools that survive the project gates.
T1127.001detects — A.5.8 mandates that information security risks (including those from project execution and third-party tools) are assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces anomalous or risky use of build tools like MSBuild in development projects but does not mandate runtime detection of the technique itself.
T1127.002prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including for third-party components, authentication, access control, logging, and compliance), and governance review throughout the SDLC; this prevents many ClickOnce abuse vectors (e.g. by blocking unsafe deployment practices or requiring stronger auth/authorization in delivered apps) but leaves open-ended residual paths such as post-delivery user execution or startup-folder persistence that the control does not reach.
T1127.003prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling), and treatment into the project life cycle for all projects; this reaches the build-process abuse vector in development projects and can stop malicious .jam files from being introduced, but leaves a bounded remainder for non-development projects, post-delivery execution, and developer errors that still ship vulnerable build configs.
T1133prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. authentication, access control, third-party assurance, and threat modeling) for all projects, which directly constrains many T1133 vectors (e.g., exposed unauthenticated services, weak remote gateways, insecure Tor hidden services) when followed in design/deployment; it does not guarantee prevention of all instances (e.g., misconfigurations or post-deployment changes).
T1136prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. access provisioning, authorization, authentication assurance, and compliance) that address account-creation risks in project deliverables and environments, but does not stop an already-privileged adversary from executing the technique post-compromise.
T1136.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. access provisioning, authorization, authentication assurance, and third-party clauses) in all project types; this constrains creation of unmanaged local accounts as a project deliverable or during execution, but leaves residual creation by post-project adversaries or in unmanaged/legacy systems.
T1136.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. access provisioning, authorization, authentication assurance, and third-party clauses) that can block creation of unauthorized domain accounts when followed; it does not guarantee enforcement or stop an already-privileged adversary from executing the technique.
T1136.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. access provisioning, authorization, authentication assurance, and compliance) in all projects; this constrains creation of low-visibility persistence accounts as part of project risk handling, but only reaches the subset of account creations that occur inside managed projects and does not block out-of-band or post-project adversary actions.
T1137prevents — A.5.8 mandates early and periodic information security risk assessment/treatment plus explicit requirements derivation (including from threat modelling) in all projects, which reaches the Office-application persistence mechanisms when they are introduced or configured as part of a project deliverable, but leaves untouched the dominant case of an already-deployed Office suite whose startup features are later abused by an adversary without any project involvement.
T1137.001detects — A.5.8 requires determining and addressing information security requirements (including from threat modelling, incident reviews, vulnerability thresholds, logging/monitoring interfaces, and macro handling via policy) and reviewing effectiveness throughout the project life cycle, which surfaces the Office template macro persistence technique in development or configuration projects but does not mandate runtime detection of its use post-deployment.
T1137.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. from threat modelling, policy, and macro-relevant controls like 8.26), and treatment throughout the project life cycle; this can stop macro-persistence from being introduced in custom or procured Office-based solutions, but leaves the dominant existing-installation abuse vector (user/system templates, registry hijacks, and macro enablement on already-deployed Office) untouched.
T1137.002prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. from threat modelling), and integration of security into project management across all project types; this can prevent the insecure design/implementation choice that leaves the Office Test key available for abuse in delivered Office-based solutions or custom add-ins, but leaves a bounded remainder for non-project vectors, post-delivery changes, and non-ICT projects where the technique is simply enabled by default Office installation.
T1137.003detects — A.5.8 requires determining and integrating information security requirements (including from threat modelling, incident reviews, vulnerability thresholds, logging/monitoring interfaces, and compliance) into project management and deliverables; this surfaces the malicious form technique as a risk during development or customization of Outlook-based projects but does not mandate runtime detection of the technique once deployed.
T1137.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including from threat modelling), and integration into the full project life cycle for any project type; this reaches the Outlook Forms persistence technique when it would be introduced via custom development or configuration projects, but leaves a bounded remainder for ad-hoc mailbox-level abuse on already-deployed Outlook instances outside any project context.
T1137.004detects — A.5.8 requires determining and integrating information security requirements (including from threat modelling, incident reviews, vulnerability thresholds, logging/monitoring interfaces, and compliance) into project management and deliverables; this surfaces the malicious-Home-Page persistence technique when it appears in project artefacts or requirements, but only for in-scope projects and only at the requirements/governance layer, leaving runtime or post-deployment detection of the technique itself outside the control's defined scope.
T1137.004prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including from threat modelling), and integration into the full project life cycle for any project type; this reaches the Outlook Home Page abuse in custom/internal development or configuration projects but leaves the dominant case (adversary post-compromise abuse of an already-shipped legacy feature in end-user Outlook) untouched.
T1137.005detects — A.5.8 requires determining and integrating information security requirements (including from incident reviews, threat modelling, logging/monitoring interfaces, and compliance) into project management and deliverables; this surfaces the malicious-rule technique when it appears in custom or procured Outlook/Office projects but does not require ongoing runtime detection of the technique once deployed in production mailboxes.
T1137.005prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling and policy), and treatment into the project life cycle for all projects; this can prevent the introduction of vulnerable Outlook configurations or unaddressed persistence vectors during development/customization projects, but leaves open-ended residual risk in non-project scenarios, post-deployment changes, and user/admin actions outside the project scope.
T1137.006detects — A.5.8 mandates determining and integrating information security requirements (including from threat modelling, incident reviews, vulnerability thresholds, logging/monitoring interfaces, and compliance) into project management and deliverables; this surfaces the need for detection of anomalous add-in behaviour at design time but does not itself perform or mandate runtime detection of the T1137.006 technique once deployed.
T1137.006prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling and policy), and treatment into the project lifecycle for all projects; this can prevent insecure add-in loading/persistence mechanisms from being designed or deployed in custom Office-based solutions or extensions, but leaves the dominant existing add-in abuse surface (third-party or already-installed add-ins on endpoints) untouched.
T1176prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. from threat modelling), and treatment of project risks including those tied to deliverables and third-party components; this constrains many extension-abuse vectors at design and procurement time but leaves residual paths (social engineering of users, post-install abuse of benign extensions, and marketplace compromises outside the project lifecycle) untouched.
T1176.001prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including for third-party components, authentication, access controls, and compliance), and ongoing treatment/review into all project lifecycles, which would prevent many classes of malicious or vulnerable browser extensions from being introduced via development, procurement, or deployment projects; however, it does not reach post-deployment abuse, silent file manipulation, or extensions installed outside any project context.
T1176.002prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling), and treatment into the full project life cycle for all projects (explicitly including non-ICT and development-tool projects); this directly constrains the supply-chain and development practices that allow malicious IDE extensions to be published or side-loaded, but leaves open benign-extension abuse, post-install execution, and projects that do not fully implement the control.
T1185prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. auth, access control, threat modelling), and governance review that can prevent vulnerable browser/session-handling code or configurations from reaching production; this is a genuine but minority slice of T1185's attack surface (most instances arise from unaddressed browser flaws or post-deployment injection rather than project defects).
T1187detects — A.5.8 mandates that information security risks (including those tied to authentication mechanisms and external resource access in projects) are assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces forced-authentication risks during development or configuration of systems that could enable the technique.
T1187prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. authentication, access control, threat modelling), and integration into all project types; this can prevent many project-borne forced-auth vectors (e.g. unsafe defaults, unvetted external links, weak auth in delivered systems) but leaves residual techniques that exploit runtime user/system behavior outside the project lifecycle.
T1189prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. app security per 8.26, threat modelling, secure architecture against known threats), and governance review throughout the project life cycle; this directly prevents many drive-by vectors (watering-hole compromises of legitimate sites, XSS in web apps, insecure client-side code) when the technique's delivery site or exploited browser/plugin is built or updated in a project, but leaves untouched adversary-controlled sites, third-party unmaintained components, and non-project-browsing scenarios.
T1190prevents — Requiring threat modelling and security requirements at project inception leads to design choices that close the common entry points adversaries exploit in public-facing applications.
T1195prevents — A.5.8 mandates integrating security risk assessment/treatment, requirements derivation (incl. from threat modelling, policy, compliance), and governance review into the project life cycle for all projects (incl. those producing deliverables), which directly constrains many listed supply-chain manipulation vectors (dev tools/env, source repos, open-source deps, update mechanisms) before they reach the consumer; it does not address physical interdiction, factory-infected images, or post-project distribution outside the project scope.
T1195.001prevents — A.5.8 mandates integrating security risk assessment, treatment, and requirements (including for dependencies, third-party components, threat modelling, and supply-chain aspects) into all project lifecycles, which directly constrains the opportunity for an adversary to introduce malicious dependencies/tools before they reach the consumer.
T1195.002prevents — A.5.8 mandates early/periodic risk assessment, security requirements (incl. supply-chain-relevant ones like 8.26 app security, threat modelling, third-party clauses), and governance review throughout the project life cycle, which directly constrains the opportunity for source/manufacturer-side manipulation in software projects; it does not reach non-project or external-supplier supply chains outside the organization's own development/delivery processes.
T1195.003prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including supply-chain security requirements (e.g. via threat modelling, compliance, third-party clauses), which can prevent some hardware tampering in the supply chain of project deliverables; it does not guarantee prevention for all projects or all supply-chain vectors.
T1199prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including third-party access provisioning, authorization, contracts, and assurance levels) for all projects; this directly constrains the insecure granting and oversight of trusted third-party relationships that enable T1199, but leaves residual gaps in ongoing enforcement, legacy relationships, and non-project contexts.
T1203prevents — A.5.8 mandates early and periodic security risk assessment, treatment, and requirements derivation (including threat modelling, secure architecture/design, and compliance) across all project types, which directly prevents many unsecure coding practices that create the client-application vulnerabilities T1203 exploits; it does not reach every possible vulnerability (e.g. third-party library defects introduced post-design or zero-days).
T1204prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. user awareness, training, policies, and controls like 5.12 classification or 8.26 app security), and governance that can integrate anti-social-engineering measures into project deliverables, lowering the chance users will execute adversary payloads; this is a genuine but minority slice of the technique (most T1204 vectors arise from external phishing or post-compromise lures outside any single project's scope).
T1204.001prevents — A.5.8 mandates early and periodic project risk assessment/treatment plus explicit derivation of security requirements (including user awareness, authentication, access control, logging, threat modelling and compliance) that can be flowed into delivered systems or processes, thereby preventing some social-engineering-triggered link-click execution paths; it does not reach user behavior outside project deliverables or block all delivery vectors.
T1204.002prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including user duties, authentication, access controls, threat modelling), and periodic treatment/review into every project life cycle; this can prevent delivery of systems or deliverables whose design makes malicious-file execution likely (e.g., by requiring safe document handling, reduced attack surface, or user training), but leaves open user-behavior and post-delivery execution vectors that the control does not reach.
T1204.003prevents — A.5.8 mandates early/periodic risk assessment, threat modelling, security requirements (incl. for third-party images/containers), and governance review throughout the project life cycle, which can prevent procurement or deployment of malicious/backdoored images in IaaS/container projects; it does not reach ad-hoc user actions or runtime naming tricks outside formal project management.
T1204.005prevents — A.5.8 mandates early and periodic information security risk assessment/treatment in all projects (including ICT/development), deriving requirements from threat modelling/vulnerability thresholds/policy and ensuring architecture protects against known threats; this reaches the supply-chain/dependency risk slice of T1204.005 but leaves open-ended residual (unvetted third-party installs, typosquatting success, post-project runtime execution) that the control does not close.
T1207prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (incl. authz, logging, compliance) in any project; this constrains rogue-DC registration in AD-infrastructure or domain-controller projects but leaves open non-project vectors, unmanaged environments, and post-deployment execution.
T1210prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including threat modelling, vulnerability thresholds, compliance, and architecture protection) in all projects, which directly prevents many exploitable remote-service vulnerabilities from being introduced or left unpatched during design, build, and deployment.
T1211prevents — integrating security risk assessment, requirements derivation (including logging/monitoring interfaces, threat modelling), and periodic review into the project life cycle directly reduces the introduction of exploitable vulnerabilities that enable stealth/evasion techniques such as suppressing logging or hiding in unmonitored components; it is not full because the control is process-oriented governance that cannot guarantee flawless implementation or catch every possible flaw.
T1212prevents — A.5.8 mandates early/periodic security risk assessment, requirements derivation (including auth, credentialing, threat modelling), and treatment throughout the project life cycle, which prevents many exploitable credential-access vulnerabilities from being introduced into delivered systems or products.
T1213prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including classification, access control, authentication, logging, compliance, and third-party clauses) for all projects including those that produce or configure information repositories, which directly constrains the improper-configuration root cause named in the T1213 source prose; it does not reach every possible post-deployment abuse vector or non-project repository.
T1213.001prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including classification, access controls, threat modelling), and periodic treatment/review into all project lifecycles, which directly constrains the insecure project practices that leave Confluence repositories containing sensitive items like credentials, diagrams, and policies accessible to adversaries.
T1213.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of security requirements (including classification, access controls, compliance, and threat modeling) for all projects including those producing or managing SharePoint repositories, which directly constrains the insecure configuration that leaves the listed sensitive items exposed for mining.
T1213.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access control, authentication, logging, and third-party clauses) for all projects including those involving code repositories, which directly constrains the conditions that let an adversary reach and harvest from internal/private repos; it does not guarantee enforcement of those requirements at runtime or eliminate all access paths, leaving a bounded remainder.
T1213.004prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. classification, access control, logging, compliance), threat modelling and treatment throughout the project life cycle for any project delivering systems or services; this directly prevents insecure-by-default CRM deployments that leave customer PII exposed to post-compromise mining, but leaves residual risk from already-deployed instances, insider threats after access is gained, and incomplete enforcement of derived requirements.
T1213.005prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. classification, access control, logging, compliance), threat modelling and governance review that directly addresses the information-classification, sharing and leakage risks enabling T1213.005; it does not guarantee the specific controls will be chosen or flawlessly implemented on every messaging platform, leaving a genuine residual slice.
T1213.006prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including access control, authentication, logging, compliance, and third-party clauses) in all projects, which can prevent insecure database deployments or configurations that enable mining; however, it is governance/process-oriented and does not directly stop the technique once databases exist or are compromised.
T1218.005detects — A.5.8 mandates that information security risks (including those from project execution such as internal/external communication) are assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces anomalous or risky use of tools like mshta.exe when projects incorporate threat modeling, monitoring requirements, or incident reviews, but this is limited to project-derived artifacts and does not broadly instrument runtime detection of the technique post-deployment.
T1218.005prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. app security per 8.26), threat modelling and architecture protections that can stop mshta.exe abuse from being introduced into delivered systems or project-managed environments; this is genuine but only a minority slice of the technique's attack surface (adversary post-compromise use of a living-off-the-land binary on already-deployed Windows endpoints).
T1218.015prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling), and treatment into the project life cycle for any project type; this directly prevents many Electron-abuse vectors by ensuring secure architecture, design, and configuration choices (e.g. sandboxing, command restrictions, JS integrity) are required and reviewed before and during development of Electron-based apps.
T1219.001prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling), and treatment into the full project life cycle for all projects; this reaches the IDE-tunneling technique in development projects by forcing early identification and treatment of remote-development C2/persistence risks, but leaves a bounded remainder for non-project contexts, legacy IDEs already in use, and post-deployment abuse of developer workstations.
T1221prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including those from threat modelling), determination of security requirements for all project types, and integration of controls such as authentication, access provisioning, and compliance needs into project deliverables and architecture, which can stop template-injection flaws from being introduced in custom or procured document-handling software but leaves the dominant end-user execution vector (malicious Office/RTF documents) untouched.
T1484prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (incl. authz, access provisioning, compliance, and policy-derived controls) throughout the project life cycle for any project; this directly constrains the insecure configurations and permission models that enable T1484 when applied to identity/domain projects, but leaves a large remainder for post-deployment changes, non-project-managed environments, and runtime abuse by already-privileged actors.
T1484.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access controls, authorization, compliance, and threat modeling) throughout any project life cycle; this addresses the improper delegation and weak GPO access-control configuration that enables T1484.001, but only for projects that touch AD/GPO (a minority slice of all projects, with no coverage once deployed).
T1484.002detects — A.5.8 mandates that information security risks (including those tied to authentication, authorization, trust relationships, and third-party identity providers) be assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces misconfigurations like malicious trust modifications when they arise during project execution or reviews, but only for project-managed changes and not for post-deployment runtime or adversarial manipulation outside project oversight.
T1484.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. authentication, authorization, third-party trust clauses, and compliance) in all projects, which directly constrains the project-stage misconfigurations that enable T1484.002; it does not reach runtime or post-deployment trust manipulation by an already-privileged actor.
T1485prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including availability, backup-derived needs, and contingency planning) in all projects, which can prevent many data-destruction vectors at design time; it does not reach runtime execution, propagation, or post-compromise deletion on live systems.
T1485recovers — A.5.8 requires determining and integrating information security requirements (including availability protection, backup/contingency needs, and recovery-related clauses) into project management and deliverables, which can enable post-destruction recovery for project-owned assets but does not itself restore state or guarantee recovery of arbitrary destroyed data.
T1486recovers — A.5.8 requires determining and integrating information security requirements (including contingency planning and backup-related needs) into project lifecycles so that post-impact recovery mechanisms exist; this partially enables recovery from T1486's encryption but does not itself perform the restoration.
T1491prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including integrity requirements, threat modelling, and derived controls (e.g. 5.12 classification, access controls, logging) that can stop defacement from being introduced in delivered systems or web assets; this reaches only the project-origin slice of T1491, not post-deployment execution against existing content.
T1491.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including integrity protection, access control, monitoring, and threat modeling) that address the integrity-discrediting technique in project deliverables and execution, but leaves residual risk in already-deployed systems and non-project changes.
T1491.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for external systems, integrity protection, threat modelling, and compliance) throughout any project life cycle, which prevents the class of external defacement by ensuring such risks are designed out of externally-facing assets before and during deployment.
T1495prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements derivation (including threat modelling, contingency planning, and protection of architecture/design against known threats) inside project lifecycles; this can prevent firmware corruption techniques from being introduced in developed or procured products, but leaves a large remainder for existing deployed firmware, non-project-managed devices, and post-deployment adversary actions.
T1496prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (incl. availability protection, threat modelling, and operational environment safeguards) that can stop resource hijacking from being introduced or left unaddressed in project deliverables, but this is limited to the project-management slice and does not reach already-deployed or non-project-origin systems.
T1496.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (incl. availability protection, threat modelling, contingency planning) that can stop compute-hijacking risks from being introduced in project-managed systems, but this is a governance process that does not guarantee technical prevention of the post-deployment technique across all platforms or unmanaged assets.
T1496.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (incl. availability protection, access control, monitoring/logging, threat modeling) that can stop bandwidth-hijacking techniques from being introduced or exploited in project-managed systems, but only for the subset of projects an organization actually runs through formal governance; it does not reach already-deployed systems, ad-hoc compromises, or runtime botnet/proxyjacking behaviors outside the project lifecycle.
T1496.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements elicitation (including for availability, logging, third-party services, and compliance), threat modeling, and governance review throughout the project life cycle; this directly prevents insecure design or implementation choices that enable public web forms and messaging services to be abused for SMS pumping at scale, but leaves residual risk from post-deployment changes, incomplete requirements, or non-ICT projects where the technique could still be introduced.
T1496.004prevents — A.5.8 mandates integrating security risk assessment, treatment, and requirements (including for third-party/SaaS services, access controls, compliance, and threat modeling) into all project lifecycles, which can prevent many hijacking vectors at design/procurement time but leaves residual post-deployment abuse paths and already-compromised accounts untouched.
T1498prevents — integrating security risk assessment, requirements (incl. availability, authentication, access control, logging, compliance), threat modelling and contingency planning into the project life cycle can prevent some classes of Network DoS (e.g. by mandating adequate bandwidth, anti-spoofing, or DDoS-resistant architecture in delivered systems), but leaves many deployment-time, configuration, and external volumetric vectors untouched
T1498recovers — A.5.8 requires determining and integrating availability requirements (including from contingency planning) into project deliverables, which can produce recovery mechanisms for DoS-impacted services, but the control itself only governs project processes and does not perform or guarantee post-attack state restoration.
T1499prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (including availability, threat modelling, and architecture protection) in all projects, which can prevent many endpoint DoS weaknesses from being introduced during design/build; it does not stop runtime execution of the technique by an already-present adversary.
T1499recovers — A.5.8 requires determining and integrating availability requirements (including contingency planning) into project deliverables, which can produce recovery mechanisms for DoS-impacted services, but the control itself only governs project processes and does not perform or guarantee post-attack state restoration.
T1499.002prevents — A.5.8 mandates early and periodic risk assessment/treatment plus explicit derivation of availability, authentication, access control, logging/monitoring, and third-party requirements in project lifecycles (including non-ICT), which directly blocks many service-exhaustion vectors at design time; it stops short of mandating runtime mitigations such as rate limiting or autoscaling that close the remainder of volumetric/renegotiation attacks.
T1499.003prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (including availability needs, threat modelling, and architecture protection against known threats), and treatment throughout the project life cycle, which prevents this application-level exhaustion technique from being designed/built into delivered systems; it does not reach runtime configuration, deployment, or non-project-originating applications.
T1499.004prevents — A.5.8 mandates early/periodic risk assessment, threat modelling, requirements derivation (including availability needs, vulnerability thresholds, and architecture protection against known threats) and governance review throughout the project life cycle, which prevents many exploitable vulnerabilities from reaching production but leaves zero-days, post-deployment exploits, and non-project-managed systems as a large residual.
T1505prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. for ICT projects, threat modelling, architecture protection, and third-party components) throughout the project life cycle, which directly constrains the introduction of malicious extensible server components as a project deliverable; it does not reach post-delivery installation or non-project abuse vectors on already-deployed systems.
T1505.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. from threat modelling), secure architecture/design, and governance review across all project types; this reaches the development-time introduction of malicious/persistent stored procedures or unsafe CLR assemblies but leaves residual gaps (e.g. post-deployment changes, misconfigurations, or non-project-managed DB instances).
T1505.002prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (including from threat modelling), secure architecture/design, and governance review in all projects; this directly prevents registering a malicious transport agent during Exchange-related development or deployment projects, but leaves residual risk in non-project paths such as post-deployment admin abuse or insider modification of a live production Exchange server.
T1505.003prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. app security per 8.26), threat modelling, secure architecture/design and compliance checks throughout the project life cycle; this prevents many (but not all) web-shell insertion paths when the web server or app is built or modified as part of a project.
T1505.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including for ICT projects, threat modeling, and third-party components) that can prevent malicious IIS component installation when followed; this is a genuine but minority slice of the technique because the control is governance/process-oriented and does not itself enforce technical restrictions on DLL/module installation.
T1525prevents — A.5.8 mandates integrating security risk assessment/treatment and deriving requirements (incl. from threat modelling, compliance, and architecture protection against known threats) into all project lifecycles, which reaches the slice of T1525 where an image is built or updated as part of a managed project but leaves the dominant post-compromise runtime implantation vector (and non-project image changes) untouched.
T1528prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including those tied to CI/CD pipelines, container/K8s service accounts, OAuth app registration flows, and token-handling architecture), plus explicit derivation of requirements such as authentication strength, access provisioning, non-repudiation, and third-party clauses; this stops many T1528 vectors at design time, but leaves residual paths (e.g., runtime container compromise after project delivery, social-engineering grant flows, or post-deployment token theft) untouched by the project-management control.
T1530prevents — A.5.8 mandates integrating security risk assessment/treatment, requirements derivation (including access control, authentication, classification, compliance), and governance review into the project life cycle, which directly prevents many misconfigurations that enable T1530 when applied to cloud storage projects; it does not reach adversary abuse of already-leaked credentials or post-deployment operational errors.
T1534prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including security requirements, threat modelling, authentication, access controls, user awareness, logging, and compliance that can stop many internal spearphishing vectors (e.g. via better MFA, credential handling, impersonation resistance, and user training) from being introduced in delivered systems or processes, but leaves residual paths such as post-deployment account compromises, unaddressed legacy internal chat vectors, and human execution errors outside the project lifecycle.
T1537prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. access control, auth, logging, compliance), and governance review that can block insecure designs allowing intra-cloud exfil to adversary accounts; this reaches only the project/dev slice of T1537, not runtime abuse of existing legitimate accounts or APIs.
T1538prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements derivation (including access, authentication, monitoring, and third-party clauses) that can prevent credential theft or overly permissive dashboard exposure in project-managed cloud environments; it does not guarantee prevention for all configurations or post-deployment operational use.
T1539prevents — A.5.8 mandates integrating security risk assessment, requirements elicitation (including auth, access control, non-repudiation, logging, and threat modeling), and periodic review into the project life cycle; this can prevent classes of session-cookie weaknesses (e.g., missing HttpOnly/Secure flags, weak session management, or insufficient MFA) from being designed or coded into delivered systems, but leaves many post-delivery vectors (malware theft, local memory scraping, phishing/AiTM, JS injection) untouched.
T1542.002prevents — integrating security risk assessment, requirements derivation (including from threat modelling), architecture/design protection, and periodic treatment/review into the project life cycle directly prevents many classes of component-firmware modification by ensuring integrity, authentication, and supply-chain requirements are addressed before components are acquired or integrated; it leaves a bounded remainder for sophisticated post-deployment or out-of-project-supply-chain attacks on already-deployed firmware.
T1542.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including for firmware/boot processes, third-party assurance, and compliance) in any project life cycle, which can prevent insecure ROMMON images from being introduced during device/firmware projects; it does not reach ad-hoc or post-deployment upgrades on existing network devices.
T1542.005prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including for network devices, boot processes, and third-party components) throughout the project life cycle, which can prevent the vulnerable configurations that enable T1542.005, but does not guarantee their absence in all deployed devices or address post-deployment manipulation.
T1543.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for non-ICT projects) that can address systemd service creation/modification risks in project-managed Linux environments, but does not guarantee enforcement or coverage of ad-hoc/non-project changes.
T1543.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for non-ICT projects) that address persistence mechanisms, privilege escalation, and hidden/masquerading services when they are part of project deliverables or operational changes; this stops the technique at the design/implementation stage for many cases but leaves residual gaps for ad-hoc post-deployment abuse or unmanaged systems.
T1543.005prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for non-ICT projects, threat modeling, access controls, and third-party assurance) that can stop the creation or modification of container services for persistence/escalation when those risks are identified and addressed in the project life cycle; it does not guarantee this for every container deployment or runtime modification outside project-managed deliverables.
T1546prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (including auth, access control, logging, and threat modeling) in all projects, which can prevent insecure event-trigger mechanisms from being introduced or modified in project deliverables, but leaves residual risk in non-project contexts, legacy systems, runtime abuse, and incomplete enforcement.
T1546.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and integration of controls such as access provisioning, logging, and compliance throughout the project life cycle, which can prevent insecure defaults like modifiable file associations in delivered systems; this reaches only a slice of the technique (new/custom software) and leaves existing systems, non-project changes, and runtime Registry edits untouched.
T1546.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for non-ICT projects) that can address shell config modification as a persistence risk, but does not itself stop the technique from being introduced or executed.
T1546.007detects — A.5.8 requires determining and reviewing information security requirements (including from threat modelling, incident reviews, vulnerability thresholds, logging/monitoring interfaces, and third-party assurance) and periodic risk treatment evaluation throughout the project life cycle; this surfaces the Netsh Helper DLL persistence technique in custom/project-developed components or when it violates derived requirements, but does not mandate ongoing runtime detection of the technique post-deployment.
T1546.008prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, access control, compliance), threat modelling and architecture protection that can stop many classes of accessibility-feature abuse from being introduced during development or configuration projects, but leaves residual paths (e.g. post-deployment Registry changes, third-party components, or non-ICT projects) unaddressed.
T1546.013prevents — A.5.8 mandates early and periodic risk assessment/treatment plus explicit security requirements (including for custom code, third-party components, access controls, logging, and threat modeling) in all project types; this prevents many profile-modification vectors when applied to PowerShell-related development or deployment projects, but leaves a large remainder for non-project vectors such as direct admin/script modification of existing profiles on production systems.
T1546.015prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including threat modelling, architecture protection against known threats, and compliance) across all project types; this reaches the design-time insertion of COM hijacking persistence in custom or in-house projects but leaves a bounded remainder for third-party/supply-chain components, post-deployment changes, and non-project-managed environments.
T1546.016prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including for third-party components, threat modeling, and compliance) in all projects, which would surface and block many malicious installer-script insertions during legitimate software development or procurement; it does not reach adversary modification of already-distributed third-party installers or runtime abuse of legitimate ones by end users.
T1547.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (including from threat modelling and policy), and treatment of project risks including execution aspects such as secure configuration; this can prevent the insecure-by-default registry/startup mechanisms from being introduced in developed or deployed systems, but does not stop an already-compromised or non-project-managed endpoint from having the technique applied.
T1547.006prevents — A.5.8 mandates early and periodic security risk assessment, requirements derivation (including from threat modelling), and treatment throughout the project life cycle for any project type; this prevents many kernel-module-based persistence techniques from being introduced in custom or in-house development projects, but leaves a large remainder for third-party/supplier kernels, COTS OS components, and post-deployment loading that the control does not reach.
T1547.007prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and integration into the full project life cycle for any project type; this reaches the design-phase insertion of plist-based auto-reopen persistence in macOS projects but leaves residual gaps in non-project code changes, post-deployment modifications, and incomplete enforcement of all derived requirements.
T1547.012detects — A.5.8 mandates that information security risks (including those from project execution and third-party components) are assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces anomalous or malicious print-processor registrations when performed as part of a managed project but does not require runtime monitoring of the boot-loaded technique itself.
T1547.012prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. for ICT/facility projects), threat modelling, architecture protection, and compliance that can address print-spooler abuse in development or configuration projects, but does not stop the technique in already-deployed systems or non-project contexts.
T1548prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (authz, access provisioning, assurance levels, compliance) that address elevation-control weaknesses in project deliverables, but does not guarantee prevention of all bypass techniques (e.g. implementation flaws or post-delivery exploits) across every project type and platform.
T1548.001prevents — A.5.8 mandates early and periodic risk assessment, treatment, and requirements derivation (including authz, access provisioning, and threat modeling) across all project types, which directly prevents many insecure setuid/setgid configurations from being introduced in developed or procured software, but leaves residual cases such as already-deployed vulnerable binaries, admin misconfigurations, or non-project-managed systems.
T1548.003prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access provisioning, authorization, least-privilege principles, and compliance) within any project life cycle; this directly constrains poor sudo/sudoers configurations that enable T1548.003 when those configurations are introduced or modified as part of a project or deliverable, but leaves open configurations changed post-project, by non-project actors, or on unmanaged systems.
T1548.005prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including access provisioning, authorization, authentication confidence, and compliance) throughout the project life cycle, which directly constrains misconfigurations that enable temporary elevated access techniques; it is partial because the control is governance/process-oriented and does not itself enforce or implement the technical permission boundaries.
T1548.006prevents — A.5.8 mandates early/periodic project risk assessment, security requirements elicitation (including authz, access provisioning, compliance, and threat modeling), and governance review that would surface and block insecure TCC permission models or bypasses in any macOS-related project deliverable; this prevents the technique in developed products but leaves residual risk in already-deployed systems, non-project changes, and adversary post-compromise abuse of legitimate grants.
T1550prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including auth requirements, threat modelling, and derived controls (e.g. 5.32, 8.26) that can stop alternate auth material from being introduced or left stealable in project deliverables; this reaches only the project-origin slice of the technique, not runtime theft or use on existing systems.
T1550.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. auth/access controls, threat modelling, compliance), and governance review across all project types; this can prevent insecure token issuance, storage, or permission models that enable T1550.001, but leaves residual gaps in runtime token protection, detection of compromise, and non-project-managed environments.
T1550.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. authn, access control, credential handling, and threat modeling), and governance review that can prevent insecure designs allowing Kerberos ticket theft or forgery in new systems, but leaves existing deployed Windows environments and operational credential-dumping vectors untouched.
T1550.004prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including authn requirements, threat modelling, and derived controls (e.g. session protection, MFA strength, logging), which can prevent the cookie-theft vector from being introduced in developed or configured systems; this is only a slice of the technique's full surface (e.g. already-deployed SaaS/IaaS, runtime theft, or non-project environments).
T1552prevents — Integrating security risk assessment, requirements derivation (including credential protection, authentication, access controls, and compliance), threat modeling, and governance reviews into the project life cycle directly prevents many classes of unsecured credential storage from being designed or built into delivered systems and products.
T1552.001prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including credential exposure in files during dev, config, deployment or cloud/container projects) plus explicit derivation of security requirements (e.g. from threat modelling, classification, auth, logging, third-party clauses) that can stop insecure credential storage from being introduced; this is genuine but only a slice of the class because the technique also covers post-deployment runtime search of existing files, backups, or user-created credential stores outside any project lifecycle.
T1552.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of security requirements (including authentication, key protection, access controls, and compliance) for all project types, which directly prevents insecure storage of private keys by design in developed or acquired systems; it does not reach ad-hoc discovery or post-compromise export on already-deployed systems.
T1552.005prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. access provisioning, auth assurance, threat modelling, and compliance) across all project types; this can prevent the metadata API from being left exposed by insecure defaults or unaddressed SSRF vectors in project deliverables, but leaves residual risk from runtime misconfigurations, post-project changes, and non-project-managed instances.
T1552.006prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including from threat modelling and compliance), and governance review that would prevent most GPP usages embedding credentials in domain policies; residual exists for legacy or non-project-managed GPP instances and for post-deployment discovery of the public AES key.
T1552.007prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. authz, secrets handling, logging), threat modelling and architecture protections that can identify and block insecure container API exposure or credential-gathering paths in project deliverables; this reaches only a slice of the technique because the control is governance/process-oriented, applies only to new/ongoing projects, and leaves runtime misconfigurations or existing deployments untouched.
T1552.008prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of security requirements (including auth, access control, logging, non-repudiation, and third-party clauses) for all projects, which when applied to comms/collaboration tools would block unsecured credential sharing in chat; this is genuine but only a minority slice because the control is governance/process-oriented, does not itself enforce runtime protections or remove already-shared messages, and leaves residual risk in non-project contexts or bypassed requirements.
T1553.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. architecture/design protection against known threats via threat modelling etc.), and governance review that would surface and block hijackable SIP/trust-provider designs in development projects; this reaches only the subset of T1553.003 that originates in custom or in-house projects, not the dominant case of abusing already-shipped OS components.
T1553.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. authentication, trust, third-party assurance, and compliance) in all projects, which can prevent supply-chain or development-time installation of atypical/malicious root certs; it does not address post-compromise installation by already-running adversary code on Linux/macOS/Windows endpoints.
T1553.006prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. app security per 8.26), threat modelling, and architecture/design protections that can stop unsafe policy-modification allowances from being introduced in development or deployment projects; this reaches only a slice of the technique (project-borne changes), not runtime admin/kernel exploits on already-deployed systems.
T1554prevents — integrating security risk assessment, requirements derivation (including for delivered products/services), threat modelling, and architecture/design protection into the project life cycle directly prevents many classes of binary modification by ensuring secure development, supply, and configuration practices before binaries reach production hosts
T1555.006prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including authentication, access provisioning, authorization, and compliance) in all projects, which directly constrains the privilege paths and misconfigurations that enable T1555.006; it does not guarantee those requirements are correctly implemented or that all runtime privilege escalations are blocked.
T1556prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. authentication, access control, threat modelling), and governance review throughout any project lifecycle, which prevents many classes of authentication-process modification by design; it leaves residual techniques that can be introduced post-project or via supply-chain/third-party components.
T1556.003prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (incl. authN, access control, threat modeling), and periodic treatment/review into the project lifecycle, which would prevent many insecure PAM modifications if applied to auth-related development or configuration projects; it does not reach ad-hoc post-deployment patching of existing PAM components on Linux/macOS systems.
T1556.005prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, credential protection, compliance), and treatment review across any project type; this directly constrains enabling reversible encryption (a known weak/legacy auth choice) in AD-related projects or FGPP configs, but leaves residual gaps in non-project changes, runtime abuse, or unenforced legacy needs.
T1556.006prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. authentication strength, MFA-relevant clauses from policy/contracts), threat modelling and integration into project/SDLC governance, which prevents many classes of MFA-weakening design or configuration choices from reaching production; it does not stop post-deployment adversarial modification of already-deployed MFA mechanisms.
T1556.007prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including authentication, access control, third-party assurance, and threat modeling) throughout any project life cycle; this directly constrains the design and implementation choices that would allow hybrid identity backdoors (e.g., insecure PTA/AD FS configs or unvetted agents), but leaves residual gaps in runtime enforcement, post-deployment changes, and non-project-managed environments.
T1556.008prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including auth and credential handling), threat modelling, and governance review that can prevent insecure designs allowing malicious network provider DLL registration during system or app projects.
T1556.009prevents — A.5.8 mandates integrating security risk assessment/treatment and deriving requirements (including auth/access rules, MFA, policy compliance) into all project lifecycles, which can prevent weak or bypassable conditional access policies from being introduced or altered during design/implementation, but does not stop post-deployment adversarial modification of existing policies.
T1557prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. comms, auth, encryption, threat modeling), and governance review that can prevent many AiTM enablers (weak protocols, poor network design, missing TLS requirements) from reaching production; it does not reach runtime protocol abuse or post-deployment configuration changes on existing assets.
T1557.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. authentication, access control, network comms), threat modelling and compliance that can address name-resolution spoofing/relay risks in ICT or infrastructure projects, but does not guarantee deployment of specific mitigations like disabling LLMNR/NBT-NS/mDNS or requiring secure alternatives on all systems.
T1557.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and integration of controls such as authentication, access provisioning, logging/monitoring, and compliance throughout the project life cycle; this can prevent insecure network configs or missing mitigations that enable rogue DHCP spoofing in delivered systems, but only for project-owned deliverables and leaves attacker techniques on existing/production networks untouched.
T1558prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. authentication, access control, threat modelling), and governance review throughout the project life cycle, which can prevent insecure Kerberos designs or implementations that enable ticket theft/forgery; this reaches only a slice of the technique because many instances arise from runtime compromise, misconfiguration or operational errors outside project delivery.
T1558.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, access control, credential protection), threat modelling and compliance that can address Kerberos/KRBTGT risks in AD-related projects, but does not guarantee prevention of the post-compromise KRBTGT hash theft or ticket forgery technique itself.
T1558.002prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. authentication, access control, threat modelling), and governance review that can prevent silver-ticket-enabling flaws (weak service-account passwords, poor key protection, missing monitoring) from being designed into systems; it does not reach runtime credential theft or post-deployment Kerberoasting that supplies the hash.
T1558.004prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including authentication, access control, and compliance) in all projects; this can drive enabling Kerberos pre-authentication (the direct preventive control) during identity/account provisioning or AD configuration projects, but the control is governance-level and does not itself enforce the technical setting.
T1559.002prevents — A.5.8 mandates early and periodic security risk assessment/treatment plus explicit requirements derivation (threat modelling, policy compliance, auth/access controls, logging) in all project types including ICT; this can prevent DDE-enabled Office/CSV payloads at design time by requiring safer defaults or macro-less alternatives, but leaves residual execution paths (registry-enabled DDE, post-delivery poisoning, remote DCOM invocation) unaddressed by project governance alone.
T1559.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including input validation, auth, privilege separation, and threat modeling), and governance review that would stop most insecure XPC designs from reaching production; it does not reach every ad-hoc or post-release XPC implementation, leaving a bounded remainder.
T1561.002recovers — A.5.8 requires determining and integrating information security requirements (including contingency planning and backup-related needs) into projects so that post-wipe recovery mechanisms exist and are tested; this restores state after the technique has run, matching the recovers verb with a named remainder for unbacked or unrecoverable systems.
T1563prevents — integrating security risk assessment, requirements (incl. authentication, access control, session-related protections), threat modelling and compliance into the project life cycle directly reduces the chance that vulnerable remote-service session mechanisms are built or deployed, but does not stop all hijacking vectors (e.g. post-deployment credential theft, unpatched protocol flaws, or insider abuse of legitimate sessions)
T1563.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of requirements (incl. authentication, access provisioning, third-party clauses, and threat modeling) that can address SSH agent exposure, session trust, and key management in project deliverables, but leaves residual gaps in runtime agent-socket protections and post-compromise root scenarios not guaranteed by project-level requirements.
T1564.006prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. threat modelling, monitoring/logging interfaces, and protection of assets in project deliverables) across all project types; this reaches the project-management slice that would introduce or allow virtualization-based hiding techniques, but leaves a large remainder of post-deployment adversary use on already-compromised hosts.
T1565prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit integrity requirements (including threat modelling, classification, non-repudiation, logging) throughout the project life cycle, which directly prevents many classes of data-manipulation flaws from being designed or built into the delivered system or process.
T1565.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit integrity requirements (including for stored data via classification, threat modelling, and derived controls) throughout any project life cycle, which prevents many classes of stored-data manipulation by design; it leaves residual cases (e.g., post-deployment insider or supply-chain manipulation of already-deployed data stores) as a named remainder.
T1565.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit integrity requirements (including transmission, non-repudiation, logging, and architecture protection against known threats) throughout the project life cycle, which prevents many instances of transmitted-data manipulation by design; it leaves residual cases (e.g., post-deployment network-level manipulation or insider tools on complex systems) unaddressed.
T1565.003prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including integrity requirements, threat modelling, and derived controls (e.g. 5.12 classification, logging, non-repudiation) that can stop runtime data manipulation defects from being introduced in project deliverables; this reaches only the project-origin slice of the technique, not post-delivery binary modification or runtime attacks on existing systems.
T1566prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. user awareness, authentication, logging, threat modeling), and governance review that can integrate anti-phishing controls (e.g. email security, awareness training, MFA) into delivered systems or processes, but does not itself stop phishing messages from being sent or block delivery/execution.
T1566.001prevents — A.5.8 mandates early and periodic project risk assessment, security requirements (incl. for apps, auth, logging, user duties, third-party contracts), threat modelling and architecture protections that can stop many classes of spearphishing-enabling defects from being introduced in developed or procured systems, but leaves the human-targeted social-engineering delivery vector itself untouched.
T1566.002prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling, policies, user duties, logging/non-repudiation, compliance), and governance review throughout the project life cycle; this can prevent many spearphishing vectors (e.g. via better auth, consent flows, URL handling, user awareness in delivered systems) but leaves residual social-engineering execution, obfuscation, and non-ICT project gaps.
T1566.003prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling, policies, and third-party agreements), and integration across all project types, which directly prevents many T1566.003 vectors by hardening third-party service policies, user awareness duties, and procurement clauses before deployment; it does not reach all social-engineering rapport-building outside formal projects.
T1566.004prevents — A.5.8 mandates integrating security risk assessment, requirements (incl. user awareness, authentication, access control, and social-engineering-relevant clauses), and threat modeling into all projects, which can prevent vishing vectors when applied to awareness programs, MFA processes, or user-facing system designs; however, it is a governance/project-level control that does not directly stop the social engineering technique itself.
T1567prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. for external comms, data leakage detection interfaces, business-process monitoring, and third-party contracts) that can block exfiltration paths in project design; this reaches only a slice of T1567 because the control is governance/process-oriented, applies only to new/changed projects, and does not itself enforce runtime blocks on legitimate web services.
T1567.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (including from threat modelling), and treatment of project risks including communication/security aspects throughout the lifecycle, which can prevent insecure designs or misconfigurations that enable covert exfiltration to code repos when projects involve such services.
T1567.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (including access control, logging/monitoring, data leakage detection interfaces, and third-party agreements) that can block sanctioned exfiltration paths to cloud storage when applied to relevant projects; this is only a slice of the ATT&CK class because the technique can still be used by compromised accounts, malware on unmanaged endpoints, or in non-project contexts without triggering project-level controls.
T1567.003prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling and policy), and treatment into the project life cycle; this can prevent some classes of exfiltration-to-text-storage by baking in controls like DLP, egress filtering, or approved-tool policies during development, but leaves the post-deployment operational technique largely untouched and does not guarantee prevention of all instances.
T1567.004detects — A.5.8 mandates that information security risks (including those tied to project deliverables, third-party integrations, and SaaS services) are assessed, treated, reviewed, and tested throughout the project life cycle, which surfaces webhook-based exfiltration risks when they are introduced via project-owned SaaS links or custom integrations, but does not itself perform detection of the technique in operation.
T1567.004prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling and policy), and treatment into the project life cycle for all project types; this can prevent webhook-based exfiltration by blocking insecure designs or SaaS integrations that enable it, but only for weaknesses introduced during projects and not for post-deployment abuse or non-project scenarios.
T1572prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. comms security, threat modelling, and controls for monitoring/non-repudiation) in all projects; this can prevent tunneling techniques from being designed into or allowed by project deliverables, but leaves residual risk from post-project misconfigurations, runtime abuse, or non-project-managed environments.
T1574prevents — integrating security risk assessment, requirements (incl. app security, auth, access control, logging), threat modelling and secure design into the project lifecycle directly prevents many hijack techniques from being introduced during development or procurement of the affected programs, libraries, or configurations, but leaves residual risk from runtime environment changes, supply-chain compromises, or post-deployment hijacks not caught in project gates
T1574.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (incl. from threat modelling), secure architecture/design, and treatment of project risks including execution aspects such as internal/external communication security; this reaches a slice of T1574.001 (e.g. preventing insecure designs or supply-chain choices that enable sideloading/hijacking) but leaves the dominant runtime loading-order and substitution vectors untouched.
T1574.005prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including those from insecure defaults like weak installer file/directory permissions), explicit derivation of security requirements (e.g. access control, authorization, and protection needs for assets), and integration into the full project life cycle for any project type; this directly constrains the root cause for many instances of the technique but leaves residual cases (e.g. third-party installers, post-project changes, or non-project-managed software).
T1574.007prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and integration into the full project life cycle for any project type; this reaches the design-time prevention of PATH-interception flaws (e.g. via hardened defaults, search-path hardening, or controlled env setup) in developed or procured software but leaves residual execution-time hijacks on already-deployed unmodified systems and non-project-managed environments.
T1574.008prevents — integrating security risk assessment, requirements derivation (including secure design and threat modeling), and reviews into the project life cycle can prevent vulnerable code patterns (e.g. non-full-path calls) from being introduced in developed or procured software, but the control is silent on enforcement mechanisms, third-party binaries, or already-deployed vulnerable programs
T1574.009prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. from threat modelling), and design protections that can identify and eliminate unquoted-path flaws before code or config ships, but does not guarantee they will be caught in every non-ICT project or that all instances are removed.
T1574.010prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including access control, authorization, and compliance), and integration into the full project life cycle, which directly prevents the insecure permission settings on service binaries from being introduced during development or acquisition of the affected systems.
T1574.011prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (incl. access control, authorization, compliance), and integration into SDLC for any project type; this reaches the design-time permission/ACL misconfiguration slice of the technique but leaves runtime/config drift, non-project services, and post-deployment changes as a large unaddressed remainder.
T1574.012prevents — A.5.8 mandates early and periodic security risk assessment/treatment plus explicit requirements (e.g. authentication, access control, logging, threat modeling) in all project types including ICT; this reaches the design-time abuse surface of COR_PROFILER (e.g. by requiring secure defaults or disabling unsafe profiler hooks) but leaves residual paths such as in-memory process-scope abuse or post-deployment configuration changes.
T1578.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access control, authorization, compliance, and architecture protection via threat modeling) throughout any project life cycle; this directly constrains creation of insecure-by-design cloud instances that enable evasion, but leaves residual gaps for post-deployment or non-project adversary actions.
T1578.005prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements (including for cloud/ICT projects, threat modeling, compliance, and architecture protection), which can stop the configuration-modification technique from being introduced or approved in project-managed environments, but leaves open post-deployment changes, non-project contexts, and residual approval gaps.
T1580prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access control, authentication, authorization, monitoring, and compliance) in all projects, which when followed prevents many misconfigurations that enable unauthenticated or over-privileged discovery via APIs/CLIs; it does not reach every possible discovery vector or post-deployment drift.
T1583.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. threat modelling, compliance, architecture protection), and governance review that can surface and block acquisition of attacker-controlled or lookalike domains in legitimate projects, but does not constrain adversary acquisition/repurposing of domains outside any organizational project lifecycle.
T1584prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including for third-party suppliers, contracts, and project deliverables) across any project type, which directly constrains the legitimate acquisition or development of infrastructure that adversaries could later compromise or repurpose in the pre-attack phase; this is a genuine but minority slice of the broad technique that also covers post-compromise use, botnets, and adversary-on-adversary actions outside organizational project lifecycles.
T1584.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit requirements (incl. third-party contracts, authentication, access control, compliance, and threat modeling) for all projects; this directly constrains the renewal gaps, help-desk social engineering, weak cloud-management configs, and deprovisioned DNS entries that enable T1584.001, but leaves open social-engineering of external registrars, email-account compromise outside project scope, and legacy domains acquired before the control applied.
T1586prevents — A.5.8 mandates early/periodic risk assessment, treatment, requirements derivation (incl. authentication, access control, third-party clauses, threat modelling), and governance review in all projects; this constrains many project-borne vectors for account compromise (e.g., weak supplier credentials, poor auth requirements, unaddressed third-party risks) but leaves residual paths such as external credential theft, phishing-for-info, or post-compromise persona development outside the project lifecycle.
T1586.003prevents — A.5.8 mandates early and periodic information security risk assessment/treatment plus explicit requirements for authentication, access provisioning, third-party assurance, and compliance in all projects (including those acquiring cloud infrastructure or services), which directly constrains many listed compromise vectors such as weak credentials, insufficient MFA, or unvetted providers; it leaves open adversary-side methods like external phishing or credential purchase that sit outside project governance.
T1587.001prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including threat modeling), and treatment into the project life cycle for all projects, which directly constrains the in-house/contracted development of custom malware by forcing early identification and mitigation of the resulting risks and requirements.
T1587.004prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling/vulnerability thresholds), and treatment into all project lifecycles, which directly constrains in-house/contracted exploit development by forcing early identification and handling of the very bugs/vulnerabilities the technique relies on and produces.
T1588.005prevents — Integrating security risk assessment, requirements derivation (including from threat modelling and vulnerability thresholds), and treatment into the project life cycle can prevent some classes of exploitable bugs from reaching production and thereby stop the adversary from acquiring a usable exploit for them, but this leaves many other vectors (publicly known exploits, purchased zero-days, stolen exploits, and exploits against already-deployed systems) untouched.
T1589prevents — A.5.8 mandates early and periodic assessment/treatment of information security risks (including identity-related ones) plus explicit derivation of requirements such as authentication, access provisioning, MFA confidence, and user responsibilities in every project type; this constrains many project-borne exposures that enable T1589 but leaves external/public data, social media, and non-project reconnaissance vectors untouched.
T1589.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. auth, MFA, credential handling, logging, third-party clauses), threat modelling and compliance that directly constrain credential-gathering vectors such as weak defaults, reuse, leaks in repos, and supplier MFA bypasses; residual external elicitation, dark-web purchase and post-compromise collection remain outside project scope.
T1589.003prevents — A.5.8 mandates early and periodic information security risk assessment/treatment in all projects (including non-ICT), plus explicit derivation of requirements from threat modelling, classification, access controls, user duties, logging, compliance, and third-party assurance; this directly constrains public exposure of employee names in project deliverables/websites/social channels, but leaves open employee names already public from non-project sources and does not guarantee removal of all such data.
T1590.003prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including third-party trust dependencies and supply-chain access) plus explicit requirements for contracts, supplier agreements, and third-party assurance, which stops many trust-relationship reconnaissance opportunities from arising; it leaves open-ended public data exposures and post-contract discovery that sit outside project governance.
T1591.002prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including third-party/supply-chain relationships and associated information security requirements) and requires that these be addressed in project planning and governance, which can prevent some exposure of business-relationship details that would otherwise be left in public data sets or leaked via poor supplier contracts; it does not stop active adversary elicitation such as phishing for information or public searches.
T1593.003prevents — A.5.8 mandates integrating security risk assessment/treatment and deriving requirements (incl. from threat modelling, classification, access controls, non-repudiation, compliance) into all projects, which directly prevents many classes of accidental leakage of credentials/API keys/employee data in public repos when those repos are project deliverables or part of the project lifecycle.
T1598prevents — A.5.8 mandates integrating information security risk assessment, requirements (including awareness of duties, authentication, access controls, and compliance), and treatment into all projects, which can prevent some social-engineering phishing vectors (e.g., via awareness, MFA requirements, or policy-driven controls in project deliverables), but leaves the bulk of PRE technique execution (adversary crafting and sending messages) untouched.
T1598.001prevents — integrating security risk assessment, requirements derivation (including awareness, policies, third-party clauses, and threat modeling), and governance reviews into the project life cycle can prevent many project decisions that enable easier spearphishing via third-party services (e.g., weak external comms, inadequate user training, lax supplier contracts), but cannot stop all social-engineering lures that rely on human factors outside project scope
T1598.002prevents — A.5.8 mandates integrating security risk assessment, requirements (incl. user awareness, authentication, access control, non-repudiation, monitoring), and threat modeling into all projects, which can reduce the likelihood of successful spearphishing by hardening user behavior, credentials, and processes against social engineering lures, but does not stop the adversary technique itself from being executed.
T1598.003prevents — integrating security risk assessment, requirements (incl. user awareness, authentication, logging, compliance), threat modelling and governance reviews into every project life cycle directly lowers the chance that an organization builds or deploys the processes, training gaps, weak MFA, or unmonitored channels that let spearphishing links succeed, but cannot stop an external adversary from sending the message
T1598.004prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including authentication, access control, user awareness, non-repudiation, and compliance), and periodic treatment/review into every project life cycle; this directly prevents many vishing pretexts that rely on poor authentication, spoofable caller trust, missing user training on duties, or unaddressed social-engineering risks in operational processes, but leaves residual techniques (e.g., external robocalls or reconnaissance-driven pretexts against non-project assets) untouched.
T1599prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including boundary protection, access control, authentication, and compliance) in all projects, which when followed prevents many classes of misconfigured or vulnerable perimeter devices that adversaries could compromise to bridge networks; it is only partial because the control is governance/process-oriented and does not itself enforce or test the resulting device configurations.
T1600prevents — A.5.8 mandates early and periodic assessment/treatment of information security risks (including crypto requirements, threat modelling, and protection needs for confidentiality/integrity) throughout any project life cycle, which prevents many instances of device encryption weakening by design; it does not reach post-deployment adversary manipulation of already-deployed network devices.
T1600.001prevents — A.5.8 mandates early and periodic assessment/treatment of project risks (including crypto strength in design/requirements for ICT or network projects) and deriving protection needs from threats, which can stop weak ciphers from being introduced; it does not reach post-deployment modification of already-deployed device images or runtime CLI changes on live network devices.
T1601prevents — A.5.8 mandates integrating security risk assessment, treatment, and requirements (including architecture/design protection via threat modeling, compliance, and operational needs) into all project lifecycles, which can prevent many classes of system-image modification by ensuring hardened, threat-resistant designs are specified and reviewed before deployment; however, it is a governance/process control that does not itself enforce technical mechanisms at runtime or in storage on already-deployed embedded devices.
T1601.001prevents — integrating security risk assessment, requirements (including for third-party components, integrity, and compliance), threat modelling, and governance reviews into the project life cycle for network device firmware/OS images would prevent many (but not all) opportunities for an adversary to obtain and patch a system image with malicious modifications
T1602prevents — A.5.8 mandates early/periodic risk assessment, treatment, and derived security requirements (including access control, authentication, logging, and compliance) that can prevent insecure configuration repositories from being deployed or left exposed, but this is a governance process that does not guarantee technical prevention for all repository exposures or adversary access paths on network devices.
T1602.001prevents — A.5.8 mandates early/periodic project risk assessment, security requirements derivation (including from threat modelling), and integration of controls such as access provisioning, authentication, logging/monitoring, and compliance into project deliverables, which can prevent insecure SNMP/MIB exposure in managed network devices when those are project outputs; this is only a slice of the technique's attack surface (e.g. existing deployed devices, misconfigurations post-deployment, or non-project-managed infrastructure).
T1602.002prevents — A.5.8 mandates integrating security risk assessment/treatment and deriving requirements (including for network assets, access controls, authentication, logging, and third-party compliance) into all project lifecycles, which can prevent insecure network device configs that enable T1602.002 if applied to device/software projects; it does not reach already-deployed devices or non-project changes.
T1606prevents — A.5.8 mandates early/periodic risk assessment, security requirements (incl. authn, access control, logging, third-party assurance), threat modelling and compliance in all projects; this constrains many project-level decisions that enable T1606 (e.g. weak token issuance logic, missing secret protection, overly permissive AssumeRole policies) but does not reach runtime forging techniques that exploit already-deployed flawed implementations.
T1606.001prevents — A.5.8 mandates early and periodic assessment/treatment of project risks including security requirements, threat modelling, authentication needs, and protection of architecture/design against known threats; this can prevent cookie-forging flaws (e.g. weak session token generation or insufficient secret protection) from being introduced in developed or configured applications, but leaves residual risk in third-party SaaS/IaaS, legacy systems, and non-project-managed environments.
T1606.002prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of authentication, access control, non-repudiation, and third-party assurance requirements in every project (including identity/federation projects), which directly constrains the design decisions that would allow an untrusted or weakly protected SAML signing certificate — the root prerequisite for T1606.002 — but cannot guarantee that every project will identify or correctly treat every possible certificate-management threat.
T1608.004prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. threat modelling, app security per 8.26), and design protections that directly constrain staging malicious web content or drive-by infrastructure in organizational projects, but leaves adversary-controlled external sites, acquired domains, and non-project watering holes untouched.
T1608.005prevents — A.5.8 mandates early and periodic project risk assessment/treatment plus explicit derivation of information security requirements (including threat modelling, authentication, access control, non-repudiation, compliance, and third-party clauses) that reach the design of systems and deliverables; this constrains many of the infrastructure-acquisition, site-cloning, domain-registration, and link-masking steps an adversary would take inside a project, but leaves untouched adversary activity wholly outside any organizational project lifecycle.
T1609prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (incl. authz, access provisioning, compliance) in all projects, which can prevent insecure container configs or overly permissive admin services that enable T1609, but does not guarantee prevention of all permission or deployment flaws that allow the technique.
T1610prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including for non-ICT projects, threat modeling, access controls, and third-party assurance) that can stop insecure or vulnerable container deployments from being introduced as project deliverables, but leaves open adversary-driven runtime deployment of malicious or misconfigured containers outside any project lifecycle.
T1611prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. isolation, architecture protection via threat modelling, and derived needs for confidentiality/integrity/availability) throughout the project life cycle, which directly prevents many container/virtualization escape vectors at design/build time; it reaches only a partial slice because it is a governance/integration control that does not itself enforce runtime isolation mechanisms or eliminate all implementation flaws.
T1612prevents — A.5.8 mandates early/periodic risk assessment, threat modelling, requirements derivation (including for container images in ICT projects), and treatment of project risks such as build-time security, which directly constrains the T1612 technique in managed projects but leaves residual cases (non-project ad-hoc builds, unmanaged hosts, or incomplete enforcement).
T1621prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (incl. authentication needs, MFA-relevant clauses, user duties, and threat modelling), and periodic treatment/review into all projects, which can prevent weak MFA implementations that enable T1621-style fatigue or push abuse, but does not guarantee strong-enough mechanisms (e.g. number matching, rate limiting) or block the technique once MFA is deployed.
T1648prevents — A.5.8 mandates early/periodic risk assessment, treatment, and security requirements (including for cloud/ICT projects, threat modeling, access controls, and compliance) throughout the project life cycle, which can prevent insecure serverless deployments that enable T1648 but does not guarantee prevention of all abuse vectors (e.g., post-deployment misconfigurations or runtime event triggers).
T1649prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit derivation of authentication requirements (including identity assurance, access provisioning, and third-party controls) inside project lifecycles, which directly constrains the enrollment, misconfiguration, and protection gaps that enable certificate theft or forgery; it does not reach runtime certificate-store access, golden-certificate root-key compromise, or non-project-managed assets, leaving a named remainder.
T1650prevents — Integrating security risk assessment, requirements derivation (including for third-party/supply-chain and project deliverables), threat modelling, and governance reviews into the project life cycle can prevent some acquisitions of access by hardening high-value targets (e.g. software dev, IT contracting, telecom) against the very weaknesses brokers exploit and sell, but leaves the purchase act itself, broker networks, and already-compromised footholds untouched.
T1657prevents — A.5.8 mandates early/periodic risk assessment, treatment, and requirements derivation (including threat modelling, contingency planning, access controls, logging, and compliance) across all project types, which directly prevents many financial-theft techniques (BEC/social engineering, ransomware extortion, unauthorized transfers) from being introduced during project delivery; residual techniques such as post-deployment cryptocurrency exploits or pure social-engineering campaigns remain outside the project-lifecycle scope.
T1666prevents — A.5.8 mandates early/periodic risk assessment, treatment, and integration of security requirements (including policy compliance, access controls, monitoring, and third-party assurance) into all project lifecycles, which would prevent many hierarchy-modification techniques if applied during IaaS/cloud project design and governance; it stops short of full coverage because it is a process-level control that does not itself enforce runtime guardrails or block post-deployment API abuse such as LeaveOrganization/CreateAccount.
T1671prevents — A.5.8 mandates early/periodic project risk assessment, security requirements (incl. authz, access provisioning, third-party clauses, threat modeling), and governance review across all project types; this directly constrains the creation/co-opting of malicious OAuth integrations during SaaS/cloud projects but leaves attacker-driven post-deployment consent, legacy integrations, and non-project adversary actions as a large unaddressed remainder.
T1675prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access provisioning, authorization, authentication confidence, and third-party/contractual clauses) in all project types; this can prevent insecure-by-default ESXi/VMware Tools configurations that enable T1675, but only for new or redesigned projects and does not reach already-deployed environments or non-project changes.
T1677detects — A.5.8 requires periodic risk assessment, progress review, effectiveness evaluation/testing of treatments, and follow-up at predefined stages, which can surface poisoned-pipeline risks or anomalies during project oversight, but does not mandate or perform ongoing detection of the live technique itself.
T1677prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. threat modelling, access controls, logging, and third-party assurance) throughout the project life cycle; this directly constrains Direct and Indirect poisoning vectors in CI/CD projects but leaves Public Pipeline Execution (fork-based PRs, untrusted inputs, self-hosted runners) as a large unaddressed remainder.
T1684prevents — A.5.8 mandates integrating security risk assessment, requirements (incl. user duties, awareness of responsibilities, access provisioning, and compliance), and periodic treatment/review into every project life cycle; this directly constrains many social-engineering vectors (e.g., help-desk, vendor, recruiting, consent, and MFA-change workflows) by forcing them to be threat-modeled, authorized, and governed before they exist, but leaves residual human-targeted execution paths that training or policy alone cannot fully eliminate.
T1684.001prevents — A.5.8 mandates early/periodic risk assessment, requirements derivation (including authentication, access provisioning, user duties, non-repudiation, and third-party clauses), and governance review throughout the project life cycle; this directly prevents many impersonation vectors by hardening identity/trust mechanisms and policies in delivered systems, but leaves residual social-engineering execution paths that rely on human factors outside project deliverables.
T1684.002prevents — A.5.8 mandates early and periodic project risk assessment/treatment plus explicit derivation of security requirements (including authentication, non-repudiation, compliance, and third-party clauses) that can drive DMARC/SPF/DKIM policies into email-related projects, but does not itself enforce, configure, or test those technical controls and leaves many non-project vectors (e.g., misconfigured legacy services, internal Direct Send) untouched.
T1685.001prevents — A.5.8 mandates that information security risks (including those to logging/monitoring) be assessed, treated, and reviewed throughout the project life cycle and that derived requirements (e.g. transaction logging, interfaces to logging systems) be built into delivered products/services, which stops many but not all instances of the technique from being introduced during development or configuration of in-scope projects.
T1685.002prevents — A.5.8 mandates integrating security risk assessment/treatment and requirements (including logging/monitoring derived from policy, business processes, and other controls) into all project lifecycles, which can prevent insecure-by-default logging configurations from being deployed in cloud/ICT projects; it does not stop post-deployment adversarial modification by a privileged user.
T1686.001prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (including access controls, authorization, and compliance) integrated into any project life cycle; this prevents the insecure-by-default or misconfigured firewall rules that enable T1686.001 when projects define and enforce cloud architecture, but leaves residual gaps in runtime operations, insider abuse of valid permissions, and non-project changes.
T1686.002prevents — A.5.8 mandates integrating security risk assessment/treatment and deriving requirements (including for network devices, access controls, and compliance) into all project lifecycles, which can prevent insecure-by-design firewall configs that enable T1686.002; however, it is governance/process-oriented and does not directly stop post-deployment adversarial modification via valid accounts or exploits.
T1687prevents — A.5.8 mandates early/periodic security risk assessment, treatment, and requirements derivation (including threat modelling, vulnerability thresholds, and architecture protection against known threats) throughout the project life cycle, which prevents many exploitable vulnerabilities from being introduced into defensive components; it does not reach all implementation defects or post-deployment vulnerabilities that enable the technique.
T1689prevents — A.5.8 mandates early/periodic risk assessment, treatment, and explicit security requirements (incl. threat modelling, compliance, authentication, logging/monitoring interfaces, and protection of architecture against known threats) throughout the project life cycle; this directly constrains the inclusion or retention of backward-compatible downgrade vectors in delivered systems, but leaves residual risk in runtime exploitation, legacy environments, and non-project-managed components.

Prevented OWASP Web Top 10 (2025) risks (15)

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).

A01←P →P A04←P A05←P A06→P A08←P

Why these map — AI rationale (under review)

A01mitigates — A.5.8 requires that information security risks (including access control requirements derived from policies, threat modelling, business processes, and compliance) are assessed, integrated, reviewed, and treated throughout the project life cycle, which bounds the realized impact of some broken access control defects (e.g. via derived authz, logging, or third-party clauses) but does not limit the consequence of an already-realised weakness.
A06mitigates — A.5.8 requires integrating security risk assessment, requirements elicitation (including threat modelling, authz, logging, etc.) and governance reviews into the project lifecycle, which can surface and bound the blast radius or downstream impact of design-level weaknesses even if the flawed architecture itself is not removed.
A06prevents — A.5.8 mandates integrating security risk assessment, requirements derivation (including from threat modelling), and design-level protections into the project lifecycle, which directly blocks many insecure-design weaknesses from being baked in; it is not a complete barrier because flawed designs can still arise from incomplete application of the process or from risks outside the identified set.

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.