A.5.27 Organizational
Learning from information security incidents
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (12)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- IR-4mostlyaligns with — Both controls require using incident data to refine response procedures and reduce recurrence through root-cause analysis and control updates.
- IR-4mostlycovers — A.5.27's explicit focus on learning from incidents and feeding those lessons back to reduce future likelihood/consequences directly accounts for the third bullet of IR-4 (incorporating lessons learned into procedures/training/tests); the first two bullets of IR-4 (implementing the broader handling capability and coordinating with contingency planning) remain a real residual of the target not addressed by this control.
- IR-8mostlyaligns with — Both controls mandate updating the incident response plan based on lessons learned from actual incidents.
- AT-2partialaligns with — Both controls require incorporating real incident examples into awareness training to reduce future occurrences.
- IR-5partialaligns with — Both controls emphasize ongoing tracking of incident types and volumes to inform security improvements.
- RA-3partialaligns with — Both controls require feeding incident-derived information into the risk assessment process to adjust likelihood or impact values.
- IR-5covers — 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.
Aligned NIST CSF 2.0 outcomes (25)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- ID.IM-01mostlyaligns with — Lessons extracted from incident evaluations are fed back into security improvements, directly supporting the CSF outcome of identifying enhancements from evaluations.
- ID.IM-03mostlyaligns with — Quantifying incident types, volumes, and costs from operational execution provides the data needed to spot improvements in day-to-day processes and procedures.
- ID.RA-05mostlyaligns with — Recurring or serious incidents and their root causes are used to refresh the risk assessment and prioritize additional controls, matching the CSF intent to combine threats, vulnerabilities, and impacts for risk-informed decisions.
- ID.IM-02partialaligns with — Incident-derived insights can be incorporated into future security tests and exercises, though the control itself does not mandate test-based identification of improvements.
- PR.AT-01partialaligns with — Real incident examples are leveraged to raise general personnel awareness and improve future avoidance and response behaviors.
- ID.IM-01implements — A.5.27's post-incident learning process directly operationalizes the identification of improvements from security evaluations that ID.IM-01 requires within the identify/improve domain
- ID.IM-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.
- ID.IM-03implements — A.5.27 operationalizes learning/improvement from incidents (an operational process) that directly serves the broader ID.IM-03 outcome of identifying improvements from execution of operational processes, within the same improvement domain but without explicit naming of incident learning.
- ID.RA-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.AT-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Related OWASP ASVS 5.0 requirements (5)
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).
Mitigated MITRE ATT&CK techniques (797)
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).
Why these map — AI rationale (under review)
- T1001.003detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment and awareness can surface recurring impersonation-based C2 (once it has already produced detectable incidents), but the control itself performs no real-time detection and leaves the bulk of in-flight protocol impersonation untouched.
- T1003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized T1003 incidents after the fact but does not instrument or surface the technique itself in flight.
- T1003responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) directly enable containment, eradication and root-cause actions once a realized T1003 event is underway, with the named remainder being the pre-detection window before the incident is known.
- T1003.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of LSASS credential-dumping incidents after they occur but does not instrument or surface the technique itself in real time.
- T1003.002detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface SAM-extraction incidents after they occur (feeding risk assessment and training), but this is governance-level post-incident aggregation rather than active detection of the in-memory/registry technique itself.
- T1003.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs and feeding that into risk assessment and awareness; this surfaces patterns of credential-dumping incidents (including NTDS targeting) after they occur, but does not instrument or surface the live technique itself.
- T1003.003prevents — A.5.27's post-incident learning loop (quantify, identify recurring causes, update risk assessment, add controls, and feed examples into awareness training) can prevent future recurrences of T1003.003 after the first occurrence, but does nothing to stop the initial execution of the technique.
- T1003.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-dumping incidents (including LSA Secrets) after they occur but does not instrument or surface the in-progress technique itself.
- T1003.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of cached-credential theft after incidents occur but does not instrument or surface the T1003.005 technique itself in real time.
- T1003.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of DCSync-based credential access after incidents occur but does not instrument or detect the technique in flight or before impact.
- T1003.006responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment, eradication, and root-cause handling of a realised DCSync incident once underway.
- T1003.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces credential-dumping incidents after they occur (as incidents) but does not instrument or surface the T1003.007 technique itself in flight.
- T1003.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-dumping incidents after they occur but does not instrument or surface the specific T1003.008 technique in flight.
- T1007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1007 when it has already produced an incident but does not instrument or surface the discovery technique itself in real time.
- T1016.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of post-compromise discovery techniques like T1016.001 when they trigger logged incidents, but only a minority slice of its occurrences (those that become declared incidents) rather than the technique in flight or in most executions.
- T1020detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful exfiltration incidents (including automated ones) after the fact but does not instrument or detect the T1020 technique in flight.
- T1020responds — A.5.27's post-incident procedures to evaluate, quantify, and feed lessons into the incident management plan (5.24) and risk treatment directly enable containment/eradication response once automated exfiltration is detected as an incident.
- T1021detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces patterns of remote-service abuse after incidents occur but does not instrument or detect the technique in flight, leaving the bulk of live T1021 executions outside its scope.
- T1021.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful RDP abuse after the fact as incidents but does not instrument or detect the technique in flight.
- T1021.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of SMB share abuse after incidents occur but does not instrument or surface the technique in flight or before impact.
- T1021.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of DCOM-based lateral movement after incidents occur but does not instrument or detect the technique in flight or in the environment.
- T1021.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces patterns of successful SSH logins as incidents after they occur but does not instrument or detect the technique in flight.
- T1021.004prevents — learning from past incidents to update risk assessments, add controls, and improve training can prevent recurrence of SSH abuse via valid accounts on some vectors (e.g., by hardening configs or awareness), but leaves many others (e.g., novel credential compromise or key misuse) untouched
- T1021.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of VNC abuse as an incident type after the fact but does not instrument or detect the technique in flight.
- T1021.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of WinRM-based incidents after they occur but does not instrument or detect the technique in flight.
- T1021.008prevents — post-incident lessons that update risk assessments, add controls, refine incident plans, and improve training can prevent recurrence of this technique when it stems from identifiable, recurring root causes (e.g., overly permissive cloud console defaults or weak credential handling), but this is only a slice of the technique's attack surface.
- T1027.003detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment/training can surface steganography use after an incident has been declared, but does not itself perform detection of the technique in flight or in artifacts.
- T1027.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of HTML smuggling incidents after they occur (a detection act) but does not instrument or surface the technique in flight or in artifacts before impact.
- T1027.012detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces post-compromise LNK-smuggling incidents (as recurring patterns or examples) but does not instrument or surface the technique itself in flight or pre-execution.
- T1030detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of chunked exfiltration (as an incident or near-miss) after the fact but does not instrument or detect the live technique itself.
- T1036detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of masquerading incidents after they occur (a detection slice) but does not instrument or surface the technique in flight or in artifacts.
- T1036.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of invalid-signature deception incidents after they occur (a detection act) but does not instrument or surface the technique itself in real time or in code.
- T1036.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness training; this surfaces patterns of RTLO-based incidents after they occur (especially if recurring or costly) but does not instrument or surface the technique in flight or in artifacts before impact.
- T1036.002prevents — A.5.27 uses post-incident lessons (including recurring RTLO-based social-engineering attempts) to update risk assessments, add controls, and improve awareness/training that can stop the technique from succeeding against aware users and processes.
- T1036.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces renamed-utility incidents after they occur as part of the broader incident-management data set, but does not itself instrument or surface the rename technique in flight.
- T1036.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of masquerading incidents after they occur but does not instrument or detect the technique itself in real time or in code/config review.
- T1036.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those into risk assessment and awareness; this surfaces patterns of double-extension incidents after they occur (e.g. via user reports or logs) but does not instrument or surface the technique itself in flight or in artifacts.
- T1036.007prevents — post-incident learning that updates risk assessment, adds controls, and improves awareness/training can reduce the future likelihood of users falling for double-extension social engineering, but does not stop the technique itself from being available or executed
- T1036.010detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of masquerade-account incidents after they occur (a detection function) but only for realized incidents that are logged and reviewed, leaving the vast majority of stealthy or un-incidented technique executions untouched.
- T1036.011detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1036.011 use after incidents occur but does not instrument or surface the in-memory overwrite technique itself.
- T1037detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1037-based incidents after they occur but does not instrument or detect the technique in flight or at execution time.
- T1037.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces patterns of logon-script persistence after incidents have occurred, but does not instrument or surface the technique in flight or before impact.
- T1037.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces the technique after it has produced a detectable incident but does not mandate instrumentation that would catch the plist modification or hook execution itself, leaving most execution paths unseen until impact occurs.
- T1037.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of persistence techniques like T1037.003 after incidents occur but does not mandate detection mechanisms for the technique itself.
- T1037.004detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs, plus feeding lessons into risk assessment and awareness, can surface recurring RC-script persistence incidents after they have executed on reboot, but this is post-incident knowledge rather than real-time detection of the technique and leaves the large remainder of first-time or non-recurring abuse undetected.
- T1037.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence via startup items after they have executed as incidents, but does not instrument or surface the technique itself in real time.
- T1039detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of post-compromise data collection from shares as recurring incidents (after the fact) but does not instrument or surface the T1039 technique itself in flight.
- T1040detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces network-sniffing incidents after they have occurred (as incidents) but does not instrument or surface the passive sniffing technique itself in real time.
- T1041detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized exfiltration incidents (including over C2) after the fact as part of learning, but does not instrument or surface the technique in flight.
- T1046detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1046 when it has already succeeded as an incident, but does not instrument or surface the technique itself in real time or before impact.
- T1047detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those lessons into risk assessment and additional controls; this surfaces patterns of WMI abuse after incidents occur (e.g. via recurring T1047-driven events) but does not itself instrument or detect the technique in flight.
- T1048detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of exfiltration incidents (including T1048) after they occur as part of the incident-management loop, but only for realized incidents rather than preemptively detecting the technique in flight.
- T1048.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of exfiltration incidents (including this technique) after they occur but does not instrument or detect the technique in flight.
- T1048.002detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment and awareness can surface patterns of asymmetric-exfiltration incidents after they occur, but does not itself instrument or detect the technique in flight or at the point of occurrence.
- T1048.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of unencrypted exfiltration incidents after they occur but does not instrument or detect the technique in flight.
- T1052.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of USB exfiltration incidents after they occur (especially recurring ones) but does not instrument or detect the technique in flight or before completion.
- T1053detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring T1053 abuse as an incident pattern after the fact but does not instrument or detect the technique in flight.
- T1053.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of recurring at-abuse incidents after they occur (a detection effect) but does not instrument or surface the technique in flight, leaving the bulk of real-time or pre-incident detection untouched.
- T1053.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring cron-based persistence incidents after they occur (and can be tallied as incidents) but does not instrument or surface the technique itself in real time or before impact.
- T1053.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring scheduled-task abuse as an incident pattern after the fact but does not instrument or detect the technique itself in flight.
- T1053.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces recurring timer-based persistence after incidents occur but does not instrument or detect the technique in flight or at install time.
- T1053.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of recurring T1053.007 abuse after incidents have occurred, but does not instrument or surface the technique in flight or before impact.
- T1055detects — A.5.27 requires quantifying/monitoring incident types (which can include process-injection incidents) and feeding that into risk assessment and awareness to reduce future likelihood, which surfaces knowledge of the technique after it has run as an incident.
- T1055responds — A.5.27's post-incident procedures (quantify/monitor types+costs, update risk assessment, add controls, enhance training) directly feed into containment/eradication lessons that bound the impact of a T1055 incident once underway, with the named remainder being immediate tactical response steps that live in 5.24/5.26 rather than this clause.
- T1055.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of DLL injection incidents after they occur but does not instrument or surface the in-flight technique itself.
- T1055.001responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) enable a response function once an in-progress DLL injection is detected as an incident, but the control itself performs no containment or eradication.
- T1055.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized T1055.002 incidents after the fact but does not instrument or surface the technique in flight, leaving the dominant detection slice to SI-4-style monitoring.
- T1055.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1055.003 incidents after they occur but does not instrument or surface the in-flight technique itself.
- T1055.003responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response that can contain/eradicate a realized T1055.003 incident and reduce future ones, but the control is governance-oriented and does not itself perform containment or eradication.
- T1055.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of APC injection incidents after they occur but does not instrument or surface the in-flight technique itself.
- T1055.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful ptrace-injection incidents after they occur but does not instrument or surface the technique in flight on Linux systems.
- T1055.009detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces post-incident patterns that could include proc-memory-injection techniques when they trigger logged incidents, but does not mandate or perform real-time detection of the technique itself.
- T1055.011detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of EWM injection only after incidents have already occurred and been logged as security events, but does not instrument or surface the in-process technique itself.
- T1055.013detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful doppelgänging incidents after they occur but does not instrument or surface the in-flight technique itself.
- T1055.014detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized VDSO hijacking incidents after the fact but does not instrument or surface the in-flight technique itself.
- T1055.015detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces ListPlanting incidents after they occur as part of broader incident data but does not mandate or perform specific detection of the technique itself.
- T1056detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces realized input-capture incidents after the fact as part of the incident-management loop, but does not instrument or surface the technique itself in flight.
- T1056.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized keylogging incidents after the fact but does not instrument or surface the technique itself in flight.
- T1056.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness training; this surfaces patterns of successful GUI Input Capture incidents after they occur but does not instrument or surface the technique in flight or in code.
- T1056.002prevents — post-incident lessons that update risk assessments, add controls, improve training, and refine incident scenarios can prevent recurrence of this social-engineering technique in future similar incidents, but this is only one slice of the class (most instances arise from proactive adversary innovation rather than repeated identical incidents).
- T1056.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-capture incidents (including web-portal variants) after they occur, but does not instrument or surface the technique itself in real time.
- T1056.003prevents — post-incident lessons that update risk assessments, add controls, and improve training/awareness can prevent recurrence of the same or similar web-portal credential-capture incidents, but this is only one slice of the technique’s attack surface (initial exploitation paths, admin-access post-compromise variants, and platform diversity remain largely untouched by learning alone)
- T1056.004detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs can surface credential-hooking incidents once they have produced observable effects (e.g., reported breaches or anomalous authentication events), but the control is silent on real-time detection of the hooking technique itself and does not require instrumentation that would catch it in flight.
- T1057detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs can surface recurring process-discovery activity once it has already produced a logged incident, but this is post-facto governance on realized events rather than real-time or preventive detection of the discovery technique itself.
- T1059detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces patterns of interpreter abuse after incidents occur but does not mandate detection mechanisms or real-time identification of the technique itself.
- T1059responds — A.5.27's post-incident procedures (quantify/monitor types+costs, feed lessons into the incident management plan, risk assessment, and awareness training) enable containment/eradication response improvements once a T1059 abuse incident is underway, but only address the organizational learning slice rather than direct tactical response actions.
- T1059.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of PowerShell abuse after incidents occur but does not mandate or perform detection of the technique in flight.
- T1059.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of Unix shell abuse after incidents occur but does not instrument or detect the technique in flight or in code.
- T1059.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of Python-based execution after incidents occur but does not instrument or detect the technique in flight or in logs.
- T1059.007prevents — post-incident lessons that update risk assessments, add controls, improve training and refine incident scenarios can prevent recurrence of this JS-abuse technique in future campaigns, but the control only acts after an incident has already occurred and does not stop the first use.
- T1059.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of CLI abuse on network devices after incidents occur (a detection act) but does not instrument or observe the technique in flight, leaving the bulk of real-time detection to other controls.
- T1059.009detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful cloud API abuse after the fact as incidents but does not instrument or surface the technique itself in flight.
- T1059.011detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of Lua-based execution incidents after they occur but does not mandate or guarantee detection of the technique itself in flight.
- T1069.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns from past domain-group-enumeration incidents but does not instrument or detect the live technique itself.
- T1070.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of post-intrusion file-deletion activity as an incident indicator but does not instrument or surface the T1070.004 technique itself in real time.
- T1070.004responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response that can contain/eradicate the deletion technique once underway as part of incident handling, but this is indirect governance rather than direct containment action.
- T1070.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces post-incident cleanup activity when it is treated as an observable incident, but the narrow, low-impact, post-execution nature of T1070.005 (removing a no-longer-needed share) is only a minority slice of what the control monitors and most instances go un-incidented.
- T1070.009detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed that into risk assessment and awareness, surface knowledge of the T1070.009 technique after it has run as part of an incident; this is genuine but only a minority slice because the control is scoped to post-incident evaluation rather than real-time or proactive detection of the cleanup itself.
- T1070.010detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of post-delivery evasion (including relocation) once they become incidents, but does not instrument or surface the in-flight technique itself.
- T1071.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful T1071.002 use after the fact as incidents but does not instrument or surface the technique itself in flight.
- T1071.003detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed that into risk assessment and awareness, can surface patterns of anomalous mail-protocol C2 once incidents are declared, but does not itself instrument or detect the live technique before or during its use.
- T1071.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful DNS tunneling/beaconing incidents after they have occurred (as incidents), but does not instrument or surface the live technique itself.
- T1072detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1072 abuse after incidents occur (e.g. recurring lateral movement via deployment tools) but does not instrument or surface the technique in flight or before impact.
- T1074detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of staging incidents after they occur (as part of broader incident evaluation) but does not instrument or surface the T1074 technique itself in flight or in artifacts.
- T1078detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of valid-account abuse after incidents occur (a detection slice) but does not instrument or surface the technique in flight or before impact.
- T1078prevents — learning from past incidents to update risk assessments, add controls, and improve training can reduce the future likelihood of account compromises (e.g., via better credential hygiene or inactive-account cleanup), but this is an indirect governance process that does not itself stop the technique from running
- T1078responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) act on realized credential-abuse events to contain recurrence and eradicate root causes, but only after the technique has already run and only for the subset of incidents that are detected and evaluated.
- T1078.001prevents — learning from past incidents to update risk assessments, add controls, and improve training can prevent recurrence of default-account abuse in future similar incidents, but does not stop the initial or novel use of the technique
- T1078.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of domain-account abuse after the fact as incidents but does not instrument or detect the technique in flight.
- T1078.002prevents — post-incident learning that updates risk assessments, adds controls, and improves training can prevent recurrence of the specific compromise vectors (e.g., credential dumping or password reuse) that led to prior domain-account abuse, but this is only a minority slice of the broad technique class
- T1078.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of local-account abuse after incidents occur but does not instrument or surface the technique itself in real time.
- T1080detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1080-based incidents (e.g., recurring lateral movement via tainted shares) after they occur, but does not instrument or surface the technique itself in real time or in code.
- T1083detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns that include file-and-directory-discovery incidents after they have occurred, but does not instrument or surface the technique itself in real time.
- T1087.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of account-enumeration incidents after they occur but does not instrument or surface the T1087.003 technique itself in real time.
- T1090.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of internal-proxy C2 once incidents are declared but does not instrument or detect the live technique itself.
- T1090.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of proxy-based C2 incidents after they occur but does not instrument or detect the live technique itself.
- T1095detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and controls; this surfaces patterns of non-application-layer C2 (e.g., ICMP or VMCI use) after incidents occur, but does not itself instrument or detect the technique in flight.
- T1098detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring account-manipulation patterns post-incident as knowledge (the `detects` act) but only for incidents already logged and only against the subset that produce detectable signals, leaving the bulk of stealthy or first-time manipulations outside its scope.
- T1098.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of credential-addition incidents (a detectable post-compromise signal) but does not instrument or guarantee detection of the technique itself in flight.
- T1098.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of persistent-access or BEC incidents that use T1098.002, but does not instrument or surface the technique itself in real time.
- T1098.002prevents — post-incident analysis and risk updates (including new controls) can identify and block the permission-granting patterns that enable T1098.002 persistence in future similar incidents, but this is an indirect, after-the-fact process that does not stop the technique on first use
- T1098.003detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, plus using that to identify recurring/serious incidents, can surface patterns of role-addition activity once it has produced detectable incidents, but does not directly instrument or detect the technique itself in real time or before impact.
- T1098.003prevents — post-incident lessons that update risk assessments, add controls, and improve training can constrain the cloud-role technique in future (e.g., tighter IAM baselines or awareness of permission-creep patterns), but this is only a minority slice of the class whose dominant vectors are real-time permission abuse after compromise.
- T1098.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence via SSH authorized_keys after incidents have occurred, but only for realized incidents that are reported and analyzed, not the technique in flight or pre-impact.
- T1098.004prevents — post-incident learning that updates risk assessments and adds controls can prevent recurrence of this persistence technique in future similar incidents, but only for the subset of causes already observed and analyzed; it does not stop the first occurrence or unrelated vectors.
- T1098.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of device-registration incidents (e.g., anomalous enrollments or MFA-bypass events) after they occur but does not instrument or guarantee detection of the technique itself in real time or across all platforms.
- T1102detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of web-service C2 once incidents have occurred and are being evaluated, but does not instrument or detect the live technique itself.
- T1102.001detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, plus using that to identify recurring incidents and update risk assessment, can surface dead-drop resolver usage when it produces observable incidents, but this is after-the-fact, limited to incidents that actually trigger detection, and does not broadly detect the technique itself.
- T1102.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of bidirectional web-service C2 once incidents are declared, but does not itself instrument or detect the live technique amid normal traffic.
- T1102.003detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment/training can surface recurring patterns of one-way web-service C2 after compromise, but does not itself instrument or detect the live technique.
- T1104detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns that could include multi-stage C2 incidents after they occur, but does not instrument or detect the technique itself in flight.
- T1110detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces brute-force attempts that succeed enough to become logged incidents but does not instrument or guarantee detection of the technique itself while in flight or before impact.
- T1110prevents — post-incident learning that updates risk assessment and adds controls can prevent recurrence of the same brute-force technique (or similar ones) in the future, but this is an indirect governance/learning mechanism that does not stop the technique from being attempted or succeeding on its first occurrence
- T1110.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of authentication failures from password guessing (especially where they trigger detectable events like 4625) but does not mandate instrumentation that would catch stealthier guessing vectors (e.g. LDAP/Kerberos, cloud SSO, or non-event-triggering attempts), leaving a large named remainder.
- T1110.001prevents — post-incident learning that updates risk assessments, adds controls, improves the incident plan and raises awareness can prevent future password-guessing attempts (e.g. by tightening lockout policies or MFA), but the control is indirect, after-the-fact and does not guarantee any specific preventive measure against this technique.
- T1110.001responds — A.5.27 requires using incident evaluation (including quantified types/volumes/costs) to update the incident management plan, risk assessment, and add controls that reduce likelihood/consequences of future similar incidents; this directly matches the `responds` verb's post-event containment/eradication via lessons-learned improvements, with the named remainder being the initial incident impact before the updated plan/controls engage.
- T1110.002prevents — post-incident learning that updates risk assessments, adds controls, improves the incident plan, and enhances training can prevent recurrence of the specific credential-theft vector that enabled cracking (e.g., weak hashing, poor password policy, or exfiltration paths), but leaves many other root causes untouched.
- T1110.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of sprayed-password attempts that become incidents but does not mandate real-time detection of the technique itself, leaving the bulk of in-flight spraying outside the clause.
- T1110.003prevents — A.5.27 uses incident data to identify recurring password-spraying patterns, update risk assessments, and add targeted controls that stop the technique from succeeding in the future; this is genuine prevention but only a minority slice because the control is reactive/post-incident and does not stop the first occurrence or non-recurring instances.
- T1110.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces credential-stuffing incidents after they occur (as failed logins or breaches) but does not instrument or guarantee detection of the technique itself in flight.
- T1110.004prevents — post-incident learning that updates risk assessment and adds controls (including to authentication practices and user training on password reuse) can prevent some credential-stuffing attempts, but the control is indirect, after-the-fact, and does not reach the dominant technical vectors such as rate limiting, MFA, or credential hygiene at the authentication boundary
- T1111detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those lessons into risk assessment and additional controls; this surfaces patterns of MFA-interception incidents after they occur (a detection act) but only for realized incidents, not the technique itself in flight, and only reaches the subset of T1111 that produces reportable incidents rather than the full class.
- T1112detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful T1112-based incidents after they occur (as incidents) but does not instrument or surface the technique itself in flight or in artifacts.
- T1113detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of screen-capture incidents after they occur but does not mandate or perform detection of the T1113 technique itself.
- T1114detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of email collection incidents after they occur (a detection act) but only for realized incidents, not the T1114 technique itself in flight or pre-execution, leaving most of the class undetected.
- T1114responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) and risk treatment enable response activities once an email-collection incident is underway, but the clause itself performs no containment/eradication and the bulk of T1114's collection mechanics sit outside its post-incident scope.
- T1114.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of local email collection incidents after they occur (a detection slice) but does not instrument or surface the adversary technique itself in real time or before impact.
- T1114.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of remote email collection incidents after they occur (a detection act) but does not instrument or surface the technique in flight or before impact, leaving most of the ATT&CK class unreached.
- T1114.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of forwarding-rule abuse once they have produced detectable incidents, but does not instrument or surface the rule-creation technique itself before impact occurs.
- T1114.003prevents — Learning from past incidents to update risk assessments, add controls, and improve training/awareness can reduce the future likelihood of this technique being introduced via policy or user behavior, but does not stop an adversary (or insider) who already has valid credentials from creating the rule.
- T1114.003responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) enable response actions once an email-forwarding incident is detected and under way, but the control stops at learning/plan updates and does not itself perform containment or eradication.
- T1119detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of automated collection incidents after they occur but does not instrument or detect the technique in flight or in the specific ways described (e.g. command-line searches, cloud ETL, discovery sub-techniques).
- T1123detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface recurring audio-capture incidents after they occur, feeding risk assessment and awareness updates; this is genuine but limited post-facto detection of the technique's realized impact rather than real-time observation of capture itself.
- T1127detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1127 usage after incidents occur (a form of detection) but only for realized incidents, not in-flight technique execution or preemptive discovery.
- T1127.001detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed that into risk assessment and awareness, can surface recurring patterns of MSBuild abuse after incidents occur, but this is post-incident knowledge aggregation rather than real-time detection of the technique itself.
- T1127.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of ClickOnce abuse after incidents occur but does not instrument or detect the technique in flight or at execution time.
- T1127.002prevents — post-incident lessons that update risk assessments, add controls, improve training, and refine incident scenarios can prevent some future ClickOnce abuse vectors (especially user-execution and awareness-driven ones) but do not stop the core technique itself
- T1127.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of JamPlus abuse after incidents occur but does not instrument or detect the technique in flight or at execution time.
- T1132.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful encoded-C2 incidents after they have occurred (a detection of realized impact) but does not instrument or surface the encoding technique itself in traffic or code.
- T1132.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of non-standard encoding in past incidents (a detection act) but only after they have already succeeded as incidents, leaving the vast majority of in-flight or novel uses of the technique untouched.
- T1134.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of token-impersonation incidents after they occur but does not instrument or surface the in-progress technique itself.
- T1134.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of token-impersonation incidents after they occur but does not instrument or surface the technique in flight or in code.
- T1134.005detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, plus feeding evaluation results into risk assessment and awareness, can surface SID-History Injection after it has produced a detectable incident, but this is post-facto governance that does not mandate or perform any specific detection mechanism for the technique itself.
- T1135detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1135 use once it has already occurred in past incidents, but does not instrument or detect the technique in flight or in new instances.
- T1136detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of account-creation incidents (a detectable post-compromise behavior on supported platforms) but does not mandate or perform detection of the technique itself in flight.
- T1136.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of domain-account creation as an incident indicator (especially recurring ones) but does not instrument or detect the technique in flight or at creation time.
- T1136.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of cloud-account creation as an incident type after the fact (and can inform detection tuning), but does not itself perform detection of the technique while it is occurring.
- T1137detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1137-based incidents after they occur but does not instrument or surface the technique itself in real time.
- T1137.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those into risk assessment and awareness; this surfaces recurring Office-template-macro persistence incidents after they have been logged as incidents, but does not instrument or surface the technique itself in real time or in code/config review.
- T1137.001prevents — post-incident lessons that update risk assessment and add controls can constrain macro-enabled template abuse (e.g. via policy, trusted-location hardening, or macro restrictions), but this is an indirect governance/learning loop that leaves many deployment paths untouched
- T1137.002detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs surface patterns of Office Test abuse once incidents occur and are reported, feeding risk assessment and awareness; this is genuine but limited to post-incident detection of recurrence rather than proactive discovery of the technique itself.
- T1137.002prevents — A.5.27's post-incident analysis and risk-update loop can identify the Office Test persistence pattern as a recurring vector and drive additional controls that stop it from being (re)introduced, but the control itself is governance-level learning and does not directly prevent the technique.
- T1137.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces recurring Outlook Forms persistence incidents after they occur (as in the event-lane sense of `detects`), but only for incidents already realized and only where the organization has chosen to instrument and classify them.
- T1137.003prevents — A.5.27's post-incident lessons-learned loop (quantify/monitor recurring incidents, feed risk assessment, add controls, update training) can prevent future T1137.003 abuse once an initial case has been observed and its root cause addressed, but does nothing to stop the first occurrence or non-recurring instances.
- T1137.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring persistence techniques like T1137.004 after they have produced detectable incidents, but does not mandate or perform detection of the technique itself in flight or at rest.
- T1137.004prevents — post-incident lessons that update risk assessment, add controls, and enhance training (including examples of this exact persistence technique) lower the odds an adversary can introduce and maintain an Outlook Home Page, but do not stop a determined or already-privileged actor from performing the configuration change
- T1137.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring Outlook-rules persistence incidents after they occur but does not instrument or detect the rule-creation or rule-trigger technique itself.
- T1137.005prevents — A.5.27's post-incident learning and risk-update loop (b) can identify recurring Outlook-rules persistence as a pattern, feed it into the risk assessment, and drive additional controls that stop the technique from being (re)introduced, but this is an indirect governance/learning mechanism that does not itself block rule creation or execution.
- T1137.005responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response to a realized T1137.005 persistence incident once underway, but the control is governance-level and does not itself perform containment or eradication.
- T1137.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring add-in persistence incidents after they occur (as in the event-lane anchors for monitoring vs T1055), but does not instrument or surface the add-in technique itself in real time or before impact.
- T1137.006prevents — A.5.27 uses incident-derived lessons to update risk assessments, add controls, and improve training/awareness, which can prevent recurrence of this persistence technique in future similar incidents but does not stop the initial abuse of Office add-ins.
- T1176.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of browser-extension incidents after they occur (a detection act) but only for realized incidents, not the technique itself in flight or pre-execution, leaving the bulk of T1176.001 unreached.
- T1176.001prevents — post-incident lessons that update risk assessments, add controls, improve training, and refine incident plans can prevent some social-engineering and awareness-related installation vectors of browser extensions, but do not stop file manipulation, app-store bypasses, or post-compromise abuse techniques
- T1185detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized browser hijacking incidents after the fact but does not instrument or surface the technique in flight or in code.
- T1187detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of forced-authentication incidents after they occur (e.g. via anomalous SMB/WebDAV traffic logged as incidents) but does not itself perform detection and leaves most in-flight or novel instances unreached.
- T1189detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those into risk assessment and awareness updates; this surfaces patterns from realized drive-by incidents after the fact but does not instrument or detect the technique while it is in flight.
- T1189prevents — post-incident lessons that update risk assessments, add controls, improve training, and refine incident scenarios can stop recurrence of the same drive-by vectors (e.g., watering-hole sites or unpatched browsers) for affected users or environments, but this is only a minority slice of the broad technique class that spans novel sites, zero-days, and one-off compromises.
- T1190detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of successful T1190 exploits after they have become incidents but does not instrument or detect the technique itself in flight.
- T1190prevents — learning from past incidents to update risk assessments, add controls, and improve training can prevent some classes of public-facing application exploits (e.g., recurring misconfigurations or unpatched OWASP Top 10 issues) but leaves many others (zero-days, novel bugs, one-off glitches) untouched
- T1197detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring BITS-abuse incidents after they occur but does not mandate or guarantee detection of the technique itself in flight.
- T1199detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of supply-chain compromise (including via trusted relationships) after they have occurred, but only for incidents already realized and reported rather than proactively detecting the technique in flight.
- T1203prevents — post-incident learning that updates risk assessments and adds controls can prevent recurrence of the same client-exploitation vector (e.g., by hardening vulnerable apps or blocking the delivery path), but this is only a minority slice of T1203 because most instances arise from unknown or unpatched vulnerabilities that have not yet produced an observed incident.
- T1204detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of user-execution incidents (especially post-phishing) after they occur but does not instrument or surface the technique in flight, leaving the dominant real-time detection slice untouched.
- T1204prevents — post-incident lessons that update risk assessment, add controls, improve the incident plan, and enhance awareness/training demonstrably lower the future probability of user execution via social engineering or phishing follow-on, but this is an indirect governance/learning loop that cannot stop every instance and leaves residual techniques untouched.
- T1204responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment/eradication once a user-execution incident is underway, with the named remainder being pre-containment impact already realized (as in the T1486 anchor).
- T1204.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness training; this surfaces patterns of successful malicious-link incidents after they occur (a form of detection) but does not instrument or surface the technique in flight or before impact, leaving the dominant pre-execution social-engineering slice untouched.
- T1204.001prevents — post-incident learning that updates risk assessment, adds controls, and improves awareness/training can prevent some future social-engineering-driven clicks on malicious links, but leaves the dominant technical delivery vectors (phishing infrastructure, browser exploits, file drops) untouched
- T1204.001responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) directly enable containment, eradication and root-cause updates once a malicious-link execution event is underway, with the named remainder being the pre-detection window addressed by other verbs.
- T1204.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of successful malicious-file executions after the fact as incidents but does not instrument or surface the technique in flight or before impact.
- T1204.002prevents — A.5.27 uses incident data to update risk assessments, add controls, refine the incident plan, and improve awareness/training, which can prevent recurrence of social-engineering-driven malicious-file execution in future incidents (per guidance points a–c).
- T1204.002responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, update risk assessment, add controls, enhance training with real examples) directly engage containment/eradication/follow-up once a T1204.002 user-execution incident has occurred, with the named remainder being incidents that evade detection entirely.
- T1204.003detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface recurring malicious-image executions (and their root causes) after the fact to inform risk assessment and training, but this is post-incident knowledge rather than real-time detection of the technique and does not reach all instances (e.g., one-off or undetected executions).
- T1204.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those into awareness training and risk updates; this surfaces patterns of ClickFix-style social-engineering incidents after they occur (and can inform detection rules), but does not itself instrument or surface the technique in flight.
- T1204.004prevents — post-incident lessons that update risk assessment, add controls, and enhance user awareness/training directly lower the chance users fall for the social-engineering ClickFix trick in the future
- T1204.004responds — A.5.27's post-incident procedures (quantify/monitor types+costs, update risk assessment, add controls, enhance training with real examples) directly enable containment/eradication response once a ClickFix-style social-engineering execution is underway, with the bounded remainder being purely preventive training slices that sit in 6.3 instead.
- T1204.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of malicious-library incidents after they occur (e.g., recurring supply-chain compromises) but does not instrument or surface the technique itself in real time or in code.
- T1205detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of realized T1205 incidents after the fact but does not instrument or surface the signaling technique itself in flight.
- T1205.001detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs can surface port-knocking incidents once they have been classified and logged as security events, but the control itself supplies no detection mechanism and stops at post-incident learning.
- T1205.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of realized T1205.002 incidents (once triggered and visible as an incident) but the technique's passive, low-activity nature (no active socket until a crafted packet arrives) sits outside routine incident monitoring scope, leaving most instances undetected per the source prose.
- T1207detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed evaluation into risk assessment and additional controls, can surface patterns from incidents that used or resulted from T1207 (e.g., via forensic artifacts that were not fully obscured), but the technique's explicit design to bypass logging/SIEM and obstruct analysis means detection is neither mandated nor reliable for this specific method.
- T1210detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful T1210 exploitation incidents after they occur but does not instrument or detect the technique in flight or pre-execution.
- T1210prevents — post-incident learning that updates risk assessments and adds controls can prevent recurrence of the specific exploited vulnerabilities or configurations that enable T1210, but leaves many other unlearned remote-service vulnerabilities untouched
- T1212detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns from realized T1212 incidents (after they have succeeded) but does not instrument or surface the exploitation technique itself in flight.
- T1212prevents — A.5.27's post-incident analysis and risk-update loop can identify recurring credential-exploitation patterns (e.g., replay or Kerberos flaws) and drive additional controls that stop the technique from recurring, but this is after at least one incident has occurred and only for the subset of cases that produce detectable incidents rather than silent first-time successes.
- T1213.005detects — A.5.27's procedures to quantify/monitor incident types, volumes, costs and recurring patterns surface knowledge of incidents that used or discussed T1213.005 (e.g. exfiltration via messaging or IR-evasion via chat), but do not instrument or surface the technique's execution itself in real time.
- T1216detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1216 abuse after incidents occur but does not instrument or detect the technique in flight.
- T1216.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of living-off-the-land abuse (including SyncAppvPublishingServer.vbs proxying) after incidents occur, but only for incidents already realized and only within the scoped monitoring, leaving the initial technique execution itself undetected.
- T1218detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1218 use after incidents occur but does not instrument or detect the proxy-execution technique in flight or in advance.
- T1218.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of .chm abuse after incidents occur but does not instrument or detect the technique in flight or at execution time.
- T1218.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1218.002 abuse after incidents occur (e.g. recurring CPL proxying) but does not instrument or surface the technique in flight or in code.
- T1218.002prevents — post-incident learning that updates risk assessments, adds controls, improves training and the incident plan can prevent recurrence of this technique when it was previously observed and analyzed as a recurring pattern
- T1218.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of CMSTP abuse after incidents occur but does not instrument or detect the technique in flight or at execution time.
- T1218.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of InstallUtil abuse after incidents occur but does not instrument or detect the technique in flight or in logs.
- T1218.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of mshta.exe abuse after incidents occur but does not instrument or detect the technique in flight or at execution time.
- T1218.005prevents — A.5.27's post-incident analysis and risk-update loop can identify recurring mshta.exe abuse patterns from past incidents and drive additional controls that stop the technique from succeeding again, but this is after-the-fact learning rather than direct prevention and leaves first-time or non-recurring uses untouched.
- T1218.005responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, update risk assessment, add controls, enhance training) engage the administrative/follow-up half of incident response once an mshta-based execution has occurred, but do not perform containment or eradication of the running technique itself.
- T1218.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of msiexec abuse after incidents occur but does not mandate or perform detection of the technique in flight.
- T1218.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces the technique after it has produced a detectable incident but does not mandate instrumentation that would catch the living-off-the-land abuse itself.
- T1218.009detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed lessons into risk assessment and awareness, can surface recurring abuse of signed binaries like Regsvcs/Regasm after incidents occur, but this is post-facto knowledge rather than proactive detection of the technique in flight and reaches only the subset of incidents that are logged, reported and evaluated.
- T1218.010detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of Regsvr32 abuse after incidents occur but does not instrument or detect the technique in flight.
- T1218.011detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those lessons into risk assessment and additional controls; this surfaces patterns of rundll32 abuse after incidents occur (e.g. via recurring incident data) but does not itself instrument or detect the live technique.
- T1218.012detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces post-incident patterns that could include verclsid.exe abuse but does not instrument or surface the technique in flight or before impact.
- T1218.013detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of mavinject-based injection incidents after they occur but does not instrument or detect the technique in flight or in logs.
- T1218.014detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs plus feeding lessons into risk assessment and awareness can surface recurring abuse of signed binaries like mmc.exe after incidents occur, but this is governance-level post-incident learning rather than active detection of the technique in flight or at execution time.
- T1218.015detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of Electron abuse after incidents occur but does not instrument or detect the technique in flight or at execution time.
- T1219detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of RAT abuse after incidents occur but does not instrument or detect the technique in flight or pre-compromise.
- T1219responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, feed lessons into the incident management plan, risk assessment, and additional controls) directly enable containment/eradication response to an already-underway RAT C2 session once detected, with the named remainder being the initial abuse of defensive-tool remote features that may evade early response.
- T1219.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of IDE tunneling when it has already produced reportable incidents, but does not instrument or detect the tunneling technique itself in real time.
- T1219.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces patterns of recurring T1219.002 use after incidents have occurred, but does not instrument or detect the technique in flight or before impact.
- T1219.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of hardware-based C2 post-incident but does not instrument or detect the technique in flight or at installation time.
- T1220detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1220 use (as incidents) after the fact but does not instrument or detect the technique's execution itself.
- T1221detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those into risk assessment and awareness; this surfaces post-incident patterns of template-injection (as a recurring delivery vector) but does not instrument or surface the technique itself in flight or in artifacts.
- T1221prevents — Post-incident analysis and updates to risk assessment, incident plans, and training can identify recurring template-injection patterns and add controls that stop the technique from succeeding in future similar incidents, but this is an indirect governance/learning loop that does not itself block the technique on first use.
- T1222.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces patterns of permission-modification incidents (or their downstream effects) after they occur but does not instrument or surface the T1222.001 technique itself in real time.
- T1222.002detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs can surface T1222.002 when it is part of a logged incident, feeding back into risk assessment and training, but this is post-incident knowledge acquisition rather than real-time detection of the technique itself and reaches only the subset of uses that produce reportable incidents.
- T1484detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1484 abuse after the fact as incidents but does not instrument or surface the technique itself in real time.
- T1484.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of GPO-modification incidents (or their downstream effects) after they occur, but only for incidents already logged and only as part of post-incident learning rather than real-time detection of the technique itself.
- T1484.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of realized T1484.002 incidents after the fact but does not instrument or detect the trust-modification technique itself in flight.
- T1485detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces data-destruction incidents after they occur (as in the event-lane anchors for monitoring vs T1055) but only for incidents already realized, not the technique itself in all its pre-impact or non-incident forms.
- T1485prevents — Learning from past incidents (quantifying types/volumes/costs, feeding risk assessment, updating the incident plan, and enhancing training) can identify recurring destruction patterns and drive additional controls that stop the technique from recurring, but this is an indirect governance/learning loop that does not itself stop any given instance of T1485.
- T1485responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, update risk assessment, add controls, enhance plan and training) directly enable containment/eradication response to a realized T1485 data-destruction event and feed improvements that bound future similar incidents.
- T1486detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces patterns from realized T1486 ransomware incidents after they occur but does not instrument or surface the technique in flight or before impact.
- T1486recovers — A.5.27 requires using incident evaluation (including costs, types, and recurring ransomware patterns) to update risk assessments, add controls, and enhance the incident management plan and training, which directly supports post-encryption recovery planning and reduces future consequences as in the cp-9 vs T1486 anchor.
- T1486responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training and the incident management plan) directly enable containment, eradication, and lessons-learned response once a T1486 ransomware event is underway, with the named remainder being real-time technical containment steps that live in separate IR procedures.
- T1489detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces patterns of service-stop incidents (including those inhibiting response) after they occur but does not instrument or surface the T1489 technique itself in real time.
- T1489responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment and controls, enhance response plan and training) enable learning that improves future containment/eradication once a service-stop technique is underway, but this is indirect governance rather than direct response action and leaves most of the technique's mechanics (e.g., cloud API abuse, ESXi, data-prep stops) untouched.
- T1490detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces patterns of T1490 (e.g., recurring ransomware that deletes shadow copies) after the fact as an incident, but does not instrument or surface the live technique itself.
- T1490responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance response plan and training) directly enable containment/eradication response once T1490 is underway, with the named remainder being purely proactive/preventive slices of the control.
- T1491detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces defacement incidents after they occur as part of the incident-management data stream, but only reaches the subset of defacements that are formally declared and logged as incidents rather than all possible instances.
- T1491responds — A.5.27's post-incident procedures (quantify/monitor, update risk assessment and controls, enhance response plan and training) engage the containment/eradication/follow-up half of `responds` once a defacement is underway and discovered, but the clause's own text is silent on immediate containment or eradication of the defacement itself and the technique's visual-impact payload can complete before any organizational response begins.
- T1491.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces Internal Defacement (a visible post-intrusion incident) as a recurring pattern so additional controls can be chosen, but does not itself instrument or observe the defacement technique in flight.
- T1491.001prevents — A.5.27 procedures that quantify/monitor incidents and feed lessons into risk assessment, additional controls, incident-plan updates and awareness training can prevent recurrence of the post-intrusion T1491.001 technique by closing the enabling weaknesses or improving detection/response that would otherwise allow it; this is only a slice of the full technique surface (initial access, persistence, lateral movement, etc.).
- T1491.001responds — A.5.27's post-incident procedures (quantify/monitor types+costs, update risk assessment+controls, enhance response plan and training with real examples) directly engage containment/eradication/follow-up once an internal defacement incident is underway, with the named remainder being purely technical eradication steps that live in other controls such as SI-2.
- T1491.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces external defacement when it has already occurred and is tallied as an incident, but does not require or guarantee proactive detection mechanisms for the technique itself.
- T1491.002prevents — post-incident learning that updates risk assessment and adds controls can prevent recurrence of the specific external defacement TTP, but the control is after-the-fact, scoped only to observed incidents, and does not stop first-time or novel uses of the technique
- T1491.002responds — A.5.27's post-incident procedures (quantify/monitor, feed lessons into the incident management plan, risk assessment, and awareness training) enable organizational response to an external defacement once it has occurred, but only address the aftermath and future prevention rather than active containment or eradication of the ongoing technique.
- T1496detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces hijacking incidents after they occur (as incidents) but does not instrument or detect the technique itself in flight.
- T1496prevents — learning from past incidents to update risk assessments, add controls, and improve training can prevent some hijacking vectors (e.g., by addressing recurring causes or raising awareness of cryptomining indicators), but leaves the bulk of post-compromise resource-abuse techniques untouched
- T1496responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable containment/eradication response to hijacking once underway, but only address the subset that has already manifested as a detectable incident rather than all hijacking activity.
- T1496.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces compute-hijacking incidents after they have occurred (as incidents) but does not instrument or surface the technique itself in real time or in code.
- T1496.001responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) enable response actions once a compute-hijacking incident is underway, but the control is governance-oriented and does not itself perform containment or eradication.
- T1496.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces bandwidth-hijacking incidents after they occur as part of the incident-management data set, but only for those that rise to the level of declared incidents rather than all bandwidth-abuse activity.
- T1496.002prevents — post-incident learning that updates risk assessments and adds controls can prevent recurrence of bandwidth-hijacking incidents, but the control is a governance/learning process that does not itself stop the initial technique from running
- T1496.002responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, feed into incident plan updates, risk assessment, and additional controls) directly enable containment/eradication response once a bandwidth-hijacking incident is underway, with the named remainder being purely preventive awareness/training slices in clause (c).
- T1496.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces SMS-pumping incidents after they have begun (especially cost/volume spikes), but the control is silent on real-time detection mechanisms or telemetry that would catch the technique in flight before impact accrues.
- T1496.003prevents — A.5.27's post-incident analysis and risk-update loop can identify SMS-pumping patterns, feed them into the risk assessment, and drive additional controls that stop the technique from recurring, but the control itself is reactive (after at least one incident) and does not stop the first occurrence.
- T1496.003responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, feed into risk assessment, add controls, update plan and training) enable organizational response to an SMS pumping incident once underway, but the clause itself performs no containment/eradication and stops at learning to reduce future likelihood/consequences.
- T1496.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of SaaS hijacking (e.g. anomalous SES/SNS/LLM usage spikes) after they have occurred as incidents, but does not instrument or surface the technique in flight or before impact.
- T1498detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized Network DoS incidents after they occur but does not instrument or detect the technique in flight or before impact.
- T1498responds — A.5.27's procedures for quantifying/monitoring incident types, volumes and costs, feeding into enhanced incident management plans (5.24), risk updates and additional controls directly enable containment/eradication once a Network DoS is underway, with the named remainder being pre-impact detection or purely external volumetric floods that exhaust upstream bandwidth before organizational response can engage.
- T1498.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized flooding incidents (the technique) after they occur but does not instrument or surface the attack in flight, leaving the dominant real-time detection slice untouched.
- T1498.001prevents — post-incident learning that updates risk assessments and adds controls can prevent recurrence of the same flooding technique (or similar ones) in the future, but this is an indirect governance/learning mechanism that does not stop the technique from being executed in the first place
- T1498.001responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, update risk assessment, add controls, enhance training) directly enable containment/eradication response to a realized T1498.001 flood once underway, with the named remainder being real-time in-incident actions outside its after-the-fact scope
- T1498.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of reflection-amplification DoS incidents after they occur but does not instrument or detect the live technique itself.
- T1498.002responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response to a realized T1498.002 DoS but do not themselves contain or eradicate the attack in flight
- T1499detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of realized Endpoint DoS incidents after they occur but does not instrument or detect the technique in flight, leaving the dominant pre-impact and real-time detection slice untouched.
- T1499recovers — post-incident learning from quantified DoS data directly feeds updates to the incident management plan, risk assessment, and additional controls that restore service availability faster and reduce future downtime impact
- T1499responds — A.5.27's procedures for quantifying/monitoring incidents, identifying causes, and using that to enhance the incident management plan (5.24) and determine/implement additional controls directly engage the core of `responds` (containment/eradication/follow-up once an Endpoint DoS is underway), with the named remainder being pre-incident prevention slices that belong to other verbs.
- T1499.001detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface DoS incidents (including OS exhaustion floods) after they occur so their patterns can feed risk assessment and training; this is genuine but limited detection because it is post-incident, aggregate, and does not require real-time or technical identification of the technique itself.
- T1499.001responds — A.5.27's procedures for quantifying/monitoring incident types, volumes and costs, then using that to enhance the incident management plan (5.24), directly enable containment/eradication once an OS-exhaustion flood is underway, with the named remainder being pre-impact detection or purely technical blocking that lives in other controls.
- T1499.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of service-exhaustion incidents after they occur but does not instrument or detect the T1499.002 technique in flight.
- T1499.002prevents — post-incident learning that updates risk assessments and adds controls can prevent recurrence of similar service-exhaustion incidents, but the control is indirect, after-the-fact, and does not itself stop any specific flood or renegotiation technique
- T1499.002responds — A.5.27's procedures for quantifying/monitoring incident types, volumes and costs, feeding into enhanced incident management plans (5.24), updated risk assessments and additional controls directly enable containment/eradication once a service exhaustion flood is underway, with the named remainder being pre-impact detection or purely technical flood filtering outside the post-incident learning loop.
- T1499.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of application-exhaustion DoS incidents after they occur but does not mandate instrumentation that would detect the technique in flight.
- T1499.003responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable containment/eradication response to a realized DoS flood once underway, but only address the technique's recurrence rather than direct in-flight response actions.
- T1499.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and controls; this surfaces patterns of exploitation incidents (including DoS crashes) after they occur but does not instrument or surface the in-flight technique itself.
- T1499.004recovers — A.5.27 uses post-incident lessons (including from availability-impacting crashes) to update risk assessments, add controls, and improve response plans that can restore availability faster in future similar events, but the control itself performs no restoration action.
- T1499.004responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) and risk assessment enable containment/eradication response once an exploitation incident is underway, but the control is governance-oriented and does not itself perform the response actions.
- T1505detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface recurring patterns that can include T1505 abuse after the malicious component has been installed and triggered an observable incident
- T1505.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of abuse (including transport-agent persistence) after incidents occur, but only for realized events that are reported and analyzed, not for the technique itself in flight or before impact.
- T1505.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of web-shell incidents after they occur but does not instrument or surface the T1505.003 technique itself in real time.
- T1505.003responds — A.5.27's post-incident procedures (quantify/monitor types+costs, update risk assessment+controls, enhance response plan and training) directly enable containment/eradication once a web-shell incident is underway, with the named remainder being the initial detection step that lives in other controls.
- T1505.004detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed evaluation into risk assessment and additional controls, can surface recurring IIS component installation incidents post-facto as part of incident management; this is a genuine but minority slice of the broad persistence technique (most instances go undetected until impact or are not classified as reportable incidents).
- T1518detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1518 use after incidents have occurred (a detection slice) but does not instrument or surface the technique in flight or in non-incident contexts.
- T1518.002detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs can surface post-incident patterns of backup-software discovery (as a precursor to ransomware impact techniques), but this is after-the-fact incident evaluation rather than real-time detection of the discovery technique itself, and applies only to incidents that have already been raised.
- T1528detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of token-theft incidents after they occur (a detection function) but only for realized incidents, not the technique itself in flight, and only the subset that organizations choose to classify and track as incidents.
- T1528prevents — post-incident learning that updates risk assessments, adds controls, and improves training/awareness can prevent recurrence of the social-engineering vector (and some token-exposure patterns) but leaves the technical compromise paths (container breakout, CI/CD pipeline compromise, IMDS abuse on already-breached resources) untouched.
- T1529detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces T1529 when it has already produced a detectable incident (especially one that impedes response/recovery), but the control is silent on real-time detection of the technique itself and many executions (e.g., clean reboot of an unattended system) produce no incident record at all.
- T1529recovers — A.5.27 uses post-incident lessons (including from shutdown/reboot events that impede recovery) to update risk assessments, add controls, and improve plans/training, which can reduce future consequences and thereby aid organizational recovery from similar events, but does not itself restore system state.
- T1529responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment and controls, enhance response plan and training) directly support containment/eradication and root-cause learning once a T1529 shutdown/reboot event is underway, with the named remainder being immediate technical containment that lives in 5.26 rather than this learning clause.
- T1531detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of account-access-removal incidents (especially when tied to ransomware) after they occur, but does not instrument or detect the live technique itself.
- T1531prevents — learning from past incidents updates risk assessments, adds controls, and improves training/incident plans, which can prevent some future instances of this technique (especially in ransomware playbooks) but leaves the majority of direct execution vectors (account manipulation commands, Group Policy, esxcli, etc.) untouched.
- T1531recovers — A.5.27 uses post-incident lessons (including from account-access-removal ransomware patterns) to update risk assessments, add controls, and improve response plans that restore legitimate account access, but the control itself performs no restoration action.
- T1531responds — A.5.27's post-incident procedures (quantify/monitor, feed lessons into the incident management plan per 5.24, update risk assessment, add controls, and enhance training) directly enable containment/eradication response to T1531 once it has begun, especially its explicit use to impede IR/recovery in ransomware scenarios; mostly because the control is procedural/governance and does not itself execute the on-the-ground response actions.
- T1534detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of realized internal spearphishing incidents after they occur (a form of post-incident detection) but does not instrument or surface the technique while it is in flight.
- T1534prevents — A.5.27's post-incident learning, risk updates, and awareness enhancements can prevent recurrence of the initial account compromise stage that enables internal spearphishing, but do not stop the technique once an account is already compromised or address its multi-staged delivery vectors directly.
- T1534responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment, eradication, and root-cause handling of an internal spearphishing campaign once underway, with the named remainder being purely pre-compromise detection or awareness aspects.
- T1535detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces the technique after it has run (via incident data) but only for incidents that are already detected and logged elsewhere, leaving the core evasion (no monitoring in unused regions) untouched.
- T1537detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1537 incidents after they occur (as the control's own examples of 'recurring or serious incidents' illustrate) but does not instrument or surface the technique in flight, leaving the dominant detection surface (cloud API monitoring, anomalous internal transfers, SAS link creation) untouched.
- T1538detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs to identify recurring or serious incidents and feed that into risk assessment and awareness; this surfaces patterns of credential abuse or dashboard enumeration after the fact as incidents, but only for those that rise to the monitored threshold and does not broadly detect the T1538 technique in flight.
- T1539detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of session-cookie theft incidents after they occur but does not instrument or surface the T1539 technique itself in real time.
- T1539prevents — post-incident learning that updates risk assessment and adds controls (including awareness enhancements) can prevent recurrence of this technique when the root cause was a prior incident of the same type, but this is only one slice of the many unrelated ways the technique can first arise
- T1542.003responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) and risk treatment enable response actions once a suspected bootkit is detected, but the control itself performs no containment/eradication and the technique's low-level persistence makes full response difficult without prior suspicion.
- T1543.001detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment and awareness can surface recurring Launch Agent persistence after it has already succeeded, but does not mandate or perform real-time detection of the technique itself.
- T1543.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces recurring systemd-service persistence incidents after they occur but does not instrument or detect the technique in flight or at creation time.
- T1543.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of service-creation incidents after they occur but does not instrument or detect the technique in flight or in the registry.
- T1543.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring persistence techniques such as Launch Daemon installation after they have already executed as an incident, but only for those incidents that are actually detected and reported — the control itself supplies no instrumentation or detection mechanism for the technique.
- T1546detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1546-based incidents after they occur but does not instrument or surface the technique itself in real time or before impact.
- T1546responds — A.5.27's post-incident procedures (quantify/monitor incidents, feed lessons into the incident management plan, risk assessment, and awareness training) enable organizational response to T1546 once it has run and been detected as an incident, but the control stops at learning and planning updates rather than performing containment/eradication of the active technique.
- T1546.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence incidents (including file-association changes) after they have occurred, which is detection, but only for incidents that are already logged and recognized as security events rather than the technique itself in real time.
- T1546.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness; this surfaces recurring persistence techniques such as screensaver abuse after they have triggered detectable incidents, but does not mandate real-time detection of the registry manipulation or screensaver launch itself.
- T1546.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring WMI-subscription persistence incidents after they have executed (as incidents), but does not instrument or surface the technique itself in flight or in the environment.
- T1546.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence incidents (including shell config mods when they trigger detectable events) but does not instrument or surface the technique itself in real time.
- T1546.005detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs surface recurring persistence incidents (including trap-based ones) after they occur, feeding risk assessment and training, but this is post-incident knowledge rather than real-time detection of the technique and leaves many trap uses undetected until impact.
- T1546.006detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed evaluation into risk assessment and awareness, can surface post-execution persistence incidents of this type once they trigger and are logged/reported, but the control has no instrumentation, telemetry or detection mechanism of its own and reaches only those incidents that have already been observed and classified as such.
- T1546.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring persistence via Netsh Helper DLL as an observed incident pattern but does not instrument or surface the technique itself in real time.
- T1546.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of accessibility-feature abuse after incidents occur (a detection act) but only for realized incidents, not the technique in flight or pre-execution, leaving the bulk of T1546.008 instances outside its scope.
- T1546.008prevents — post-incident learning that updates risk assessment and adds controls can prevent recurrence of this technique by hardening accessibility features or related configuration, but only for the subset of future incidents that have already been observed and analyzed; it does not stop first-time or novel uses.
- T1546.009detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of AppCert DLL abuse after incidents occur but does not instrument or detect the technique in flight or before impact.
- T1546.010detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of AppInit DLL abuse after incidents occur but does not instrument or detect the technique in flight or before impact.
- T1546.011detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of shim abuse after incidents occur but does not instrument or detect the technique in flight or in the environment.
- T1546.012detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces IFEO-injection incidents after they occur (as with other persistence/escalation techniques) but only for those that trigger detectable incidents, leaving the bulk of stealthy or pre-impact abuse unreached.
- T1546.013detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence/escalation incidents (including those using T1546.013) after they have occurred, but does not instrument or surface the technique itself in flight or pre-execution.
- T1546.014detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces emond-abuse incidents after they occur (as incidents) but does not instrument the technique itself and leaves the bulk of pre-incident or non-incident detections untouched.
- T1546.015detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs plus feeding lessons into risk assessment and awareness can surface recurring COM hijacking incidents after they occur, but this is post-incident learning rather than proactive detection of the technique itself.
- T1546.016detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of installer-script abuse after incidents occur (a detection act) but only for realized incidents, not the technique in flight or pre-execution, leaving the bulk of T1546.016 executions outside its scope.
- T1546.016prevents — post-incident lessons that update risk assessments, add controls, and improve training can reduce the future likelihood of this technique being introduced via supply-chain or insider means, but the control is after-the-fact, indirect, and leaves the dominant technical vectors (malicious installer scripts, permission inheritance) untouched
- T1546.017detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed that into risk assessment and awareness, can surface udev-rule persistence when it triggers an observable incident, but this is after-the-fact and depends on the incident being noticed and classified as such; the control has no instrumentation, real-time observation or specific detection of the rule-addition or udev-trigger technique itself.
- T1546.018detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring persistence via Python hooks as an observed incident pattern but does not instrument or surface the technique in flight or before impact.
- T1547.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence incidents (including registry-run-key malware) after they have executed, but does not mandate or guarantee detection of the technique itself in flight.
- T1547.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1547.002 persistence after incidents occur but does not instrument or surface the technique itself in real time.
- T1547.003detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed that into risk assessment and awareness, can surface recurring persistence via time-provider abuse once it has triggered detectable incidents, but this is after-the-fact governance on realized events rather than proactive detection of the technique itself.
- T1547.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence incidents (including Winlogon abuse) after they have occurred, but does not mandate or perform detection of the technique itself in flight.
- T1547.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of SSP abuse after incidents occur but does not instrument or detect the technique in flight or at the point of registry modification.
- T1547.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of kernel-module rootkits after they have been used in incidents but does not instrument or surface the technique itself in real time.
- T1547.009detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of persistence via shortcut modification after incidents occur (as in the event-lane sense of `detects`), but only for realized incidents rather than preemptively identifying the technique in flight or in artifacts, leaving most of the technique's execution outside the control's scope.
- T1547.010detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of port-monitor persistence incidents after they occur (as with any realized technique) but does not instrument or surface the technique itself in flight.
- T1547.012detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces the technique after it has produced a detectable incident but does not instrument the boot-time print-processor load itself.
- T1547.013detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of persistence techniques like T1547.013 after they have run and caused incidents, but does not instrument or detect the .desktop file modification itself.
- T1547.014detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of persistence techniques like T1547.014 after they have succeeded as incidents, but does not instrument or detect the technique's execution itself.
- T1547.015detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1547.015-based incidents after they occur but does not instrument or surface the technique itself in real time.
- T1548.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of UAC-bypass incidents after they occur but does not instrument or detect the technique in flight or in code.
- T1548.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs and feeding that into risk assessment and awareness; this surfaces patterns of privilege-escalation incidents (including sudo-abuse T1548.003) after they occur, but does not instrument or surface the technique itself in real time.
- T1548.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1548.004 abuse after incidents occur but does not instrument or surface the technique in flight or before impact.
- T1548.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of successful T1548.005 abuse after the fact as incidents but does not instrument or detect the technique in flight or before impact.
- T1548.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces TCC-manipulation incidents after they occur (as incidents) but does not instrument or surface the TCC-abuse technique itself in real time.
- T1550.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of token-theft incidents after they occur (and can inform detection tuning), but the control itself performs no direct detection of the T1550.001 technique and the guidance leaves scope and instrumentation entirely to the organization.
- T1550.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of PtT-based incidents after they occur (a detection act) but only for realized incidents, not the technique in flight or pre-execution, leaving the bulk of T1550.003's stealthy credential-use path outside its scope.
- T1550.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of session-cookie theft incidents after they occur but does not instrument or surface the T1550.004 technique itself in flight.
- T1550.004prevents — post-incident analysis and risk updates can lead to additional controls (e.g. session cookie protections, shorter lifetimes, or MFA hardening) that stop the technique from succeeding in future similar incidents, but this is an indirect governance/learning loop that does not itself stop cookie theft or reuse.
- T1552.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-in-files incidents after they occur (a detection slice) but does not instrument or surface the adversary technique itself in real time or in code/config review.
- T1552.001prevents — post-incident lessons that update risk assessments and add controls can prevent recurrence of credential-in-files incidents (e.g., by mandating secret managers or scanning), but this is an indirect governance/learning loop that does not stop the initial search or insecure storage itself
- T1552.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-in-registry incidents after they occur but does not instrument or surface the T1552.002 technique itself in real time.
- T1552.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this can surface patterns of credential exposure via shell history as recurring incidents after they occur, but does not mandate or perform detection of the T1552.003 technique itself.
- T1552.004prevents — post-incident lessons that update risk assessments and add controls can prevent recurrence of the insecure-storage patterns that enable this technique, but the control is governance-only, acts after an incident has already occurred, and reaches only a minority slice of the technique’s causes.
- T1552.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs and feeding that into risk assessment and awareness; this surfaces patterns of credential-harvesting incidents (including GPP abuse) after they occur but does not instrument or surface the technique itself in real time.
- T1552.007detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs can surface recurring credential-gathering incidents (including via container APIs) after they occur, feeding risk assessment and awareness, but this is post-incident detection of patterns rather than real-time detection of the T1552.007 technique itself.
- T1552.008detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed evaluation into risk assessment and awareness, can surface patterns of credential-in-chat incidents after they occur (e.g., recurring exfiltration via Slack/Teams), but this is post-incident knowledge rather than real-time detection of the T1552.008 technique itself, and the control's scope is limited to incident-derived insights rather than broad telemetry or scanning.
- T1552.008prevents — learning from past incidents to update risk assessments, add controls, and improve training/awareness can reduce the chance users will share credentials in chat (and thus the technique never runs), but this is an indirect governance/learning loop that only reaches a slice of the human-error root cause
- T1553.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding the resulting knowledge into risk assessment and additional controls; this surfaces patterns of SIP/trust-provider hijacking incidents after they occur but does not instrument or surface the technique itself in real time.
- T1553.004detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs plus feeding evaluation results into risk assessment and awareness can surface post-compromise root-certificate installation as a recurring or serious incident type, but this is after-the-fact knowledge only and does not instrument or guarantee detection of the technique itself.
- T1553.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring MOTW-bypass incidents after they occur but does not mandate detection mechanisms for the technique itself.
- T1553.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces post-incident patterns of policy-modification TTPs (especially recurring ones) but does not instrument or surface the technique in flight or before impact.
- T1554detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and controls; this surfaces patterns of binary-compromise incidents after they occur (a detection act) but only for realized incidents, not the technique itself in flight or pre-execution, leaving most of T1554's stealthy modification path outside its scope.
- T1555detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface recurring credential-theft incidents after they occur (feeding risk assessment and training), but do not require or perform detection of the T1555 technique itself while in flight or in the environment.
- T1555.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-theft incidents (including Keychain use) after they occur, which is detection at the incident level, but does not instrument or surface the T1555.001 technique itself in real time or in code.
- T1555.003detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface browser-credential theft when it has already become an observed incident, feeding the learning loop; this is genuine detection of the technique's realized impact but only a minority slice because most T1555.003 executions remain undetected until they trigger an incident report.
- T1555.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-theft incidents (including T1555.004) after they occur but does not instrument or surface the technique itself in real time.
- T1555.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized T1555.005 incidents after they occur but does not instrument or detect the technique in flight or before impact.
- T1555.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential theft via secrets managers after incidents occur but does not instrument or detect the live technique itself.
- T1556detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of authentication-modification incidents after they occur (a form of detection) but does not mandate instrumentation that would catch the technique in flight or before impact.
- T1556.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces post-incident patterns of domain-controller authentication bypasses (e.g., via anomalous LSASS behavior or recurring credential anomalies) but does not mandate real-time detection of the in-memory patch itself.
- T1556.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-harvesting incidents (including those using malicious password filters) after they occur, but does not instrument or surface the technique itself in real time.
- T1556.003detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and use to update risk assessment and awareness can surface PAM modifications after they enable an incident, but this is strictly after-the-fact knowledge with no instrumentation or real-time detection mechanism required by the control.
- T1556.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of credential-theft incidents (including those using reversible encryption) after they occur, which is detection, but only for realized incidents rather than the configuration change or technique itself, and only the subset that produces detectable security events.
- T1556.005prevents — A.5.27's post-incident analysis and risk-update loop can identify the reversible-encryption misconfiguration as a recurring root cause and drive additional controls that stop the technique from being enabled, but the control itself only acts after an incident has already occurred and does not stop the initial abuse.
- T1556.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding the resulting knowledge into risk assessment and additional controls; this surfaces patterns that could reveal hybrid-identity backdoors once they produce detectable incidents, but the control has no instrumentation, telemetry or detection mechanism of its own and stops at post-incident learning.
- T1556.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-capture incidents (including this technique) after they occur, but only for incidents already logged and does not guarantee detection of the technique itself.
- T1556.009detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed evaluation into risk assessment and awareness, can surface the T1556.009 technique once it has produced a detectable incident, but this is limited to post-incident analysis of realized events rather than proactive or real-time detection of policy modification itself.
- T1557detects — post-incident quantification, monitoring of types/volumes/costs, and root-cause analysis of recurring/serious incidents can surface AiTM patterns after they occur (feeding risk assessment and awareness), but the control is silent on real-time or proactive detection of the technique in flight
- T1557.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces name-resolution-poisoning incidents after they occur as part of the incident-management data stream, but only the realized incidents that are recognized and logged, not the technique itself in flight or the broader class of poisoning attempts.
- T1557.001responds — A.5.27 requires using incident evaluation (types, volumes, costs, recurring causes) to update risk assessments, add controls, and enhance the incident management plan and training, which directly enacts the containment/eradication response to an already-underway T1557.001 poisoning/relay event per the event-lane definition.
- T1557.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces ARP poisoning only after it has produced a detectable incident, which is a genuine but minority slice of the technique's possible executions (most instances may be silent or never escalate to a logged incident).
- T1557.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of realized DHCP spoofing incidents after the fact (a detection event) but does not instrument or surface the technique in flight, nor does the control itself perform detection.
- T1557.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of evil-twin incidents after they occur (the detection act) but only for realized incidents, not the pre-connection technique itself, leaving the bulk of the technique outside the control's view.
- T1557.004prevents — post-incident learning that updates risk assessments, adds controls, improves training and incident scenarios can prevent recurrence of evil-twin social-engineering attacks by raising user awareness and closing specific gaps, but this is only one slice of the multi-vector technique (technical signal spoofing, PNL responses, certificate tricks) that lives on the network-device platform.
- T1557.004responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) enable response actions once an evil twin incident is detected and underway, but the control is governance-oriented and does not itself perform containment or eradication.
- T1558detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful T1558 incidents after they occur but does not instrument or detect the technique in flight or before impact.
- T1558.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of golden-ticket use after incidents occur but does not mandate real-time detection of the technique itself.
- T1558.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of successful Kerberoasting (or its downstream effects) after the fact as incidents but does not instrument or surface the technique itself in flight.
- T1558.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful AS-REP roasting incidents after they occur but does not instrument or surface the technique itself in flight.
- T1558.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of credential-theft incidents (including ccache theft) after they occur, which is detection at the incident level, but does not instrument or surface the T1558.005 technique itself in real time.
- T1559.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of DDE-based incidents after they occur but does not instrument or surface the technique in flight or in artifacts.
- T1559.002prevents — post-incident learning that updates risk assessments, adds controls, improves training, and refines the incident plan can stop recurrence of this technique (e.g. by disabling DDE via registry keys or blocking related phishing vectors), but only for the subset of future instances that would have produced detectable incidents; novel or first-time uses remain unreached.
- T1559.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of XPC abuse incidents after they occur (a form of detection) but does not instrument or surface the technique in flight or in code, leaving the large remainder of proactive or runtime detection untouched.
- T1560.001detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs (plus feeding that into risk assessment and awareness) can surface patterns of archive-via-utility behavior once it has produced detectable incidents, but does not itself instrument or observe the technique in flight.
- T1560.003detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs (plus feeding that into risk assessment and awareness) can surface post-exfiltration patterns of custom-archived data as recurring incidents, but this is after-the-fact knowledge with no real-time detection mechanism or coverage of the technique itself.
- T1561detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces post-incident patterns of disk-wipe events (especially recurring or high-impact ones) but does not instrument or surface the technique while it is underway.
- T1561responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment, eradication, and post-incident response once a disk-wipe event is underway, with the named remainder being pre-compromise detection or purely technical recovery steps outside its scope.
- T1561.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of disk-wipe incidents after they occur (a form of detection) but does not mandate or perform ongoing monitoring of the technique itself.
- T1561.001responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training and the incident management plan) directly enable containment/eradication response to a realized T1561.001 wipe once underway, with the named remainder being purely preventive upstream improvements that sit outside the `responds` verb.
- T1561.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces post-incident patterns of disk-structure-wipe events (especially when widespread) but does not instrument real-time detection of the technique itself.
- T1561.002recovers — A.5.27's post-incident lessons-learned process (quantify/monitor incidents, update risk assessment, add controls, enhance training and the incident management plan) directly feeds recovery improvements that reduce the future likelihood or consequences of a T1561.002 wipe, including better backup/restore mechanisms for boot structures; mostly because the control itself is procedural/governance and does not execute the actual recovery.
- T1563detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces hijacking incidents after they occur (as with any realized T1563 event) but does not mandate instrumentation that would catch the session takeover itself, leaving most of the technique unobserved until impact.
- T1563responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response that can contain/eradicate a realized session-hijacking incident and reduce its consequences, but the clause is silent on real-time containment/eradication mechanics and the bulk of T1563's execution (hijacking preexisting sessions) sits outside its scope.
- T1563.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized SSH hijacking incidents (post-breach) but does not instrument or surface the in-flight technique itself, leaving the bulk of detection to other controls.
- T1563.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized RDP hijacking incidents after the fact but does not instrument or surface the in-flight technique itself.
- T1563.002responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable response to an realized RDP hijacking by containing fallout, feeding lessons into the incident plan, and reducing recurrence risk, but the clause itself performs no real-time containment/eradication and stops at learning mechanisms.
- T1564.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of hidden-user account creation or modification after they have occurred as incidents, but does not instrument or surface the technique in flight or in code/config itself.
- T1564.002prevents — post-incident lessons that update risk assessments and add controls can prevent recurrence of the same hidden-user technique in future incidents, but the control is after-the-fact, non-specific to this TTP, and does not stop the initial execution
- T1564.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of hidden-window usage once incidents are reported but does not instrument or surface the technique itself in real time or in code/config review.
- T1564.008detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of hidden-alert incidents after the fact but does not instrument or surface the rule-creation or email-hiding technique itself.
- T1564.008prevents — A.5.27's post-incident learning and risk-update loop (b) can identify recurring hidden-email patterns, feed them into the risk assessment, and drive additional controls that stop the technique from recurring, but this is an indirect, after-the-fact process that does not stop the initial abuse of inbox/transport rules.
- T1564.008responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response to the impacts of T1564.008 once it has run and hidden alerts/C2, but the control is silent on containment/eradication of the active rule itself
- T1564.009detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of resource-fork usage once incidents occur but does not instrument or surface the technique itself in real time or in code.
- T1564.011detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of T1564.011 usage after incidents occur but does not instrument or surface the technique in flight or in code.
- T1564.012detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of hidden-file use after incidents occur but does not instrument or surface the T1564.012 technique itself in real time or before impact.
- T1565detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface data-manipulation incidents after they occur (feeding risk assessment and awareness), but this is post-incident knowledge rather than real-time detection of the T1565 technique itself.
- T1565responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable containment/eradication response to realized T1565 data-manipulation events once underway, but only address the subset that become logged incidents rather than all in-flight manipulations.
- T1565.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces some post-incident manipulation of stored data as an observed pattern but does not instrument or detect the technique while it is running.
- T1565.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns from realized T1565.002 incidents after the fact but does not instrument or surface the in-transit manipulation technique itself.
- T1565.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of runtime data manipulation incidents after they occur (a detection function) but only for realized incidents that are reported and analyzed, leaving the vast majority of stealthy or unreported technique executions untouched.
- T1566detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding the resulting knowledge into risk assessment and awareness/training; this surfaces patterns of realized phishing incidents after they occur (a form of detection) but does not mandate or perform proactive detection of phishing messages or attempts themselves.
- T1566prevents — post-incident lessons that update risk assessment, add controls, improve the incident plan and raise awareness can stop some future phishing campaigns from succeeding (especially targeted/spearphishing that recurs), but the control does not stop the initial delivery or human-click techniques themselves and leaves the bulk of opportunistic mass-phishing untouched
- T1566responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training and the incident plan) directly enable containment, eradication and lessons-learned response once a phishing campaign is underway, with the bounded remainder being real-time tactical containment steps that live in dedicated IR procedures (5.24).
- T1566.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness training; this surfaces patterns of successful spearphishing-attachment incidents after they occur but does not instrument or surface the technique in flight or pre-execution.
- T1566.001prevents — post-incident lessons that update risk assessment, add controls, refine the incident plan, and improve awareness/training can stop some future spearphishing-attachment attempts from succeeding, but this is only an indirect, after-the-fact slice of the social-engineering and user-execution chain described in the technique.
- T1566.001responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment, eradication, and root-cause handling of realized spearphishing-attachment events once underway.
- T1566.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding the resulting knowledge into risk assessment and awareness/training; this surfaces patterns of successful spearphishing-link incidents after they have occurred but does not instrument or surface the technique itself in flight or pre-execution.
- T1566.002prevents — post-incident learning that updates risk assessment, adds controls, improves training and the incident plan can prevent recurrence of the social-engineering/user-execution slice of T1566.002; it has no effect on the technical delivery, obfuscation, exploit or consent-phishing mechanisms of the same technique.
- T1566.002responds — A.5.27 requires using incident evaluation (types, volumes, costs) to enhance the incident management plan, update risk assessments, add controls, and improve awareness/training — directly enacting the post-incident containment/eradication and lessons-learned steps that `responds` names for a realized T1566.002 campaign.
- T1566.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of successful spearphishing-via-service incidents after they occur (a detection effect) but does not instrument or surface the technique in flight or before impact, leaving the dominant pre-compromise social-engineering slice untouched.
- T1566.003prevents — post-incident lessons that update risk assessment, add controls, improve the incident plan and raise awareness can prevent some future instances of this social-engineering technique, but the control is after-the-fact, indirect, and does not reach the dominant human-targeted delivery vector itself
- T1566.003responds — A.5.27's post-incident evaluation and use of incident data to enhance the incident management plan, risk assessment, and awareness/training directly supports containment/eradication response to spearphishing incidents once they have occurred, but only reaches a slice of the full technique (e.g., user-targeted social engineering via third-party services) rather than the whole class.
- T1566.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into awareness training and risk treatment; this surfaces vishing incidents after they occur (and can inform detection tuning) but does not itself perform detection of the technique in flight.
- T1566.004prevents — A.5.27 uses incident-derived lessons to update risk assessments, add controls, refine the incident plan, and improve awareness training, which can reduce the future likelihood of successful vishing by addressing recurring social-engineering patterns and user behaviors.
- T1566.004responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) enable containment/eradication response once a vishing incident is underway, but the control is scoped to post-incident learning rather than direct response actions.
- T1567detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of exfiltration-over-web-service incidents after they occur but does not mandate or perform detection of the technique itself.
- T1567.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of exfiltration incidents (including to code repos) after they occur but does not instrument or detect the T1567.001 technique in flight.
- T1567.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of exfiltration incidents (including to cloud storage) after they occur but does not instrument or detect the T1567.002 technique in flight.
- T1567.003detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs surface exfiltration incidents (including to text storage sites) after they occur as part of post-incident evaluation, but this is governance-level collection rather than specific detection instrumentation and does not address the technique's pre-incident or in-flight use.
- T1567.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces webhook-exfil incidents after they occur as part of broader incident data but does not mandate or perform detection of the technique itself.
- T1567.004prevents — A.5.27's post-incident analysis and risk-update loop can identify webhook exfiltration patterns, feed them into the risk assessment, and drive additional preventive controls that stop the technique from recurring, but this is an indirect, after-the-fact process that does not stop the first occurrence and leaves many initial or novel instances untouched.
- T1567.004responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable containment/eradication response to webhook exfiltration once detected as an incident, but only address the aftermath and not the in-flight technique itself
- T1568detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of dynamic-resolution C2 incidents after they occur but does not instrument or surface the technique itself in real time.
- T1568.001detects — A.5.27 procedures that quantify/monitor incident types, volumes and costs can surface recurring Fast Flux DNS C2 patterns as part of post-incident evaluation, but the control is silent on real-time or proactive detection of the technique itself.
- T1568.002detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and use of lessons to update risk assessment and awareness can surface recurring DGA-driven C2 incidents after they occur, but does not itself instrument or detect the technique in flight or at execution time.
- T1568.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of DNS-calculation C2 incidents after they occur but does not instrument or detect the technique itself in real time.
- T1569detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of service-abuse incidents after they occur but does not instrument or detect the technique in flight.
- T1569.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of service-execution incidents after they occur but does not instrument or detect the technique in flight or at the point of abuse of services.exe/sc.exe/PsExec.
- T1569.002responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24) enable response actions once a service execution technique is underway, but the control is limited to post-incident learning rather than direct containment/eradication of the technique itself.
- T1569.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces recurring patterns that include systemctl abuse as an incident type, but only after the fact and only for incidents already logged — it does not instrument or surface the technique in flight.
- T1571detects — A.5.27's post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment and awareness can surface patterns of non-standard port usage after incidents occur, but does not mandate or perform proactive detection of the technique itself.
- T1572detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of tunneling-based incidents after they occur (a detection act) but only for realized incidents, not the technique in flight or pre-execution, leaving the bulk of T1572's stealthy encapsulation undetected until impact.
- T1574.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of realized DLL-abuse incidents after they occur but does not instrument or detect the technique in flight or before impact.
- T1574.001prevents — learning from past incidents to update risk assessments, add controls, and improve training can prevent recurrence of the same or similar DLL abuse patterns (e.g., via new procedural or awareness controls), but leaves many novel or first-time instances of the broad technique untouched
- T1574.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of dylib-hijacking incidents after they occur but does not instrument or surface the technique in flight or in code.
- T1574.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding the resulting knowledge into risk assessment and awareness; this surfaces patterns of realized T1574.005 incidents after they have occurred but does not instrument or surface the underlying installer-file-permission weakness itself.
- T1574.006detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful linker-hijacking incidents after they occur but does not instrument or detect the technique in flight or before impact.
- T1574.007detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces PATH-interception incidents after they occur as part of the incident-management data set, but does not instrument or surface the technique itself in real time or before impact.
- T1574.008detects — post-incident quantification, monitoring of incident types/volumes/costs, and feeding lessons into risk assessment and awareness can surface search-order hijacking when it has already produced a detectable security incident, but the control does not require or describe any real-time detection mechanism for the technique itself
- T1574.009detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those into risk assessment and awareness; this surfaces realized path-interception incidents (after execution) as part of the incident-management data set but does not instrument or surface the technique itself in flight or pre-execution.
- T1574.009prevents — post-incident lessons that update risk assessments and add controls can prevent recurrence of this configuration-based technique in future systems or updates, but the control is after-the-fact, indirect, and does not stop the technique from being introduced or used initially
- T1574.010detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs surface realized T1574.010 incidents (and feed risk assessment/training) but do not require or perform detection of the technique itself in flight or pre-impact.
- T1574.012detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of COR_PROFILER abuse after incidents occur but does not instrument or detect the technique in flight or at the point of execution.
- T1574.014detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs can surface AppDomainManager injection after it has produced a detectable incident, feeding the evaluation loop; this is genuine but only a minority slice of the technique's possible executions (many of which may remain undetected or un-incidented).
- T1578detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces post-incident patterns of T1578 (or its effects) as recurring events but does not instrument or surface the technique in flight or before impact.
- T1578responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable containment/eradication response to T1578 once the modification has begun as an incident, but only address a slice of the full technique (e.g., recurring evasion via snapshots) rather than the dominant creation/deletion paths.
- T1578.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces patterns of cloud-instance deletion as an evasion technique after the fact but does not instrument or surface the deletion act itself in real time.
- T1578.003recovers — A.5.27's post-incident learning and risk-update loop (including forensic-cost quantification) can drive controls that restore recoverability of deleted instances (e.g., via immutable snapshots or separate logging), but the control itself only improves future preparedness and does not perform the recovery act.
- T1578.003responds — A.5.27's procedures for quantifying/monitoring incidents, identifying causes, and using that to enhance the incident management plan (5.24) directly engage the post-incident response activities of containment/eradication once a cloud instance deletion is underway and detected.
- T1578.004responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response to the technique once it has run, but only address the class at the governance level without containing or eradicating any specific instance of snapshot reversion on IaaS.
- T1578.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of quota/policy/region modifications after they have already succeeded as incidents, but only for those that rise to detectable incidents rather than all stealthy technique executions.
- T1588.005prevents — post-incident learning that updates risk assessments and adds controls can reduce the future availability or successful use of purchased/stolen exploits (via better patching, monitoring of exploit markets, or hardening), but this is an indirect, after-the-fact process that leaves most of the pre-attack acquisition technique untouched
- T1589.001prevents — post-incident learning that updates risk assessments, adds controls, and improves training/awareness can stop some future credential-gathering techniques (e.g., by hardening MFA, reducing password reuse, or blocking common phishing vectors), but leaves many others (dark-web purchases, site compromises, infostealer logs, etc.) untouched.
- T1595detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of successful active scanning that became incidents, but does not require real-time detection of the scanning technique itself while it is underway.
- T1595.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces scanning incidents after they occur as part of the incident-management loop, but only for incidents that cross the detection threshold and become recorded incidents (most pre-attack scanning never does).
- T1595.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns from realized incidents (including those enabled by prior vuln scanning) but does not instrument or surface the pre-compromise recon technique itself.
- T1595.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns from realized wordlist-scanning incidents after the fact but does not instrument or detect the reconnaissance technique itself while it is underway.
- T1598detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness updates; this surfaces patterns of realized phishing-for-information incidents after they occur (a detection act) but only for those that have already succeeded and been classified as incidents, leaving the vast bulk of the technique (pre-delivery, in-flight, or unreported attempts) untouched.
- T1598prevents — post-incident learning that updates risk assessments, adds controls, improves training and awareness, and refines incident scenarios can reduce the future likelihood of successful phishing-for-information by addressing root causes and human factors, but this is an indirect, after-the-fact process that does not stop any given phishing attempt from being launched.
- T1598.001prevents — Learning from past incidents to update risk assessments, add controls, improve training, and refine incident scenarios can reduce the future likelihood of successful spearphishing by addressing recurring social-engineering patterns, but does not stop the initial delivery or reconnaissance that enables the technique.
- T1598.002prevents — post-incident learning that updates risk assessment, adds controls, improves training and awareness directly lowers the chance users fall for the social-engineering lure in future similar incidents (see guidance b and c), but does not stop the adversary from sending the message or block all vectors such as reconnaissance-driven lures or non-user-mediated attachments
- T1598.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into risk assessment and awareness training; this surfaces patterns from realized spearphishing-link incidents after they occur (a detection act) but does not instrument or discover the technique in flight or before delivery.
- T1598.003prevents — post-incident learning that updates risk assessment, adds controls, and improves awareness/training can reduce the future likelihood of successful spearphishing (especially the social-engineering/user-click slice), but does not stop the adversary technique itself from being executed.
- T1598.003responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training with real examples) directly enable containment/eradication and root-cause learning once a spearphishing-link incident is underway, with the named remainder being pre-delivery reconnaissance that never reaches the organization.
- T1598.004prevents — post-incident learning that updates risk assessment, adds controls, improves training and awareness can reduce the future likelihood of successful vishing by addressing recurring social-engineering patterns, but this is an indirect governance/learning loop that does not stop the technique from being attempted and leaves the bulk of execution (recon, spoofing, urgency) untouched
- T1598.004responds — A.5.27's procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment/eradication once a vishing incident is underway, with the named remainder being pre-compromise reconnaissance that falls outside post-incident response.
- T1599detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of boundary-device compromises (a recurring incident type) after they occur, which is detection, but only for realized incidents rather than the bridging technique itself and only as input to later controls.
- T1602.001detects — A.5.27 procedures for quantifying/monitoring incident types, volumes and costs can surface SNMP MIB dumps when they are formally declared and logged as incidents, but this is post-facto, depends on existing detection feeding the incident process, and does not inherently instrument or identify the technique itself.
- T1602.002detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces some post-incident patterns that could include configuration-dumping techniques but does not instrument or surface the technique itself in flight or in the configuration repository.
- T1609detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of container admin abuse after incidents occur but does not instrument or detect the live technique itself.
- T1610detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs (plus feeding lessons into risk assessment and awareness) surface recurring or serious container-deployment incidents after they occur, but this is post-incident learning rather than real-time detection of the T1610 technique itself and reaches only the subset of incidents that are recognized and logged as such.
- T1612detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed those into risk assessment and awareness updates, can surface patterns of container-build abuse after incidents occur, but this is post-incident knowledge generation rather than real-time detection of the T1612 technique itself.
- T1620detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed those into risk assessment and awareness updates, can surface reflective code loading once it has produced a detectable incident, but the control itself supplies no instrumentation, telemetry or detection mechanism and reaches only those incidents that have already been observed and classified.
- T1621detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of MFA-fatigue or push-abuse incidents after they occur but does not instrument or surface the technique in flight or in code.
- T1621prevents — learning from past MFA-fatigue or push-bombardment incidents directly feeds updated risk assessments, additional controls, awareness training, and refined incident scenarios that reduce the likelihood of the same technique recurring
- T1621responds — A.5.27's post-incident procedures (quantifying/monitoring incidents, feeding lessons into the incident management plan, risk assessment, and awareness training) enable containment/eradication response to MFA-fatigue or push-bombardment techniques once they have begun, but this is only a minority slice of the technique's surface (most executions are prevented upstream by auth controls rather than responded to after the fact).
- T1649detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of certificate theft/forgery incidents after they occur (a detection slice) but does not instrument or surface the technique in flight or in code/config.
- T1649prevents — Post-incident analysis and risk updates can lead to additional controls that stop recurrence of the specific certificate theft/forge vectors seen before, but this is after-the-fact learning that does not stop the initial technique from running and is silent on most root causes such as enrollment rights, CA key protection, or misconfigurations.
- T1651detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of abuse (including T1651 executions that become incidents) but only after the fact and only for those that cross the incident threshold, leaving the bulk of stealthy or non-escalated technique uses undetected.
- T1653detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1653 use as recurring incidents (after the fact) but does not instrument or surface the live technique itself.
- T1654detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs (plus feeding that into risk assessment and response improvement) can surface log-enumeration activity when it triggers an incident or is visible in centralized logs, but this is indirect, post-facto, and limited to incidents that are already recognized rather than reliably catching the technique in all its forms (e.g. stealthy real-time monitoring or offline export).
- T1657detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of financial-theft incidents (ransomware extortion, BEC, etc.) after they occur but does not instrument or surface the adversary technique itself in flight.
- T1657prevents — A.5.27's post-incident learning loop (quantify/monitor types+costs, feed into risk assessment, add controls, update plans/training) reduces likelihood of recurrence for financial-theft campaigns that leave detectable incidents, but cannot stop novel or first-time executions of the technique itself.
- T1657responds — A.5.27 procedures for quantifying/monitoring incidents and feeding lessons into the incident management plan (5.24), risk assessment, and additional controls directly enable containment/eradication response once a financial theft incident is underway, with the named remainder being the pre-detection window of the theft itself.
- T1659detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of content-injection incidents (especially recurring ones) after they occur but does not instrument or surface the in-flight technique itself.
- T1665detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed evaluation into risk assessment and additional controls, can surface patterns of hidden C2 infrastructure once incidents occur and are logged, but does not itself instrument or detect the traffic manipulation, filtering, or evasion techniques in flight or pre-incident.
- T1667detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs to identify recurring or serious incidents; this surfaces email bombing when treated as an incident (e.g., inbox floods as DoS/harassment), but the control is silent on real-time detection of the technique itself and many instances go unlogged as formal incidents.
- T1667prevents — A.5.27's post-incident learning, quantification, and use of incident data to update risk assessments and add controls can identify email-bombing patterns and drive preventive measures (e.g., better signup validation or inbox rules), but this is an indirect governance/learning process that does not itself stop the technique from running, leaving most of the class (automation, flooding, precursor use) untouched.
- T1667responds — A.5.27's post-incident procedures (quantify/monitor types/volumes/costs, update risk assessment, add controls, enhance training) directly enable containment/eradication response to an ongoing or just-realized email-bombing flood once it is treated as an incident.
- T1671detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs, then feed those into risk assessment and awareness, can surface recurring OAuth-integration persistence incidents after they occur, but this is post-incident learning rather than proactive detection of the technique itself and reaches only the subset of incidents that are already logged and recognized as security events.
- T1673detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of VM-discovery incidents after they occur (as incidents) but does not instrument or surface the discovery technique itself in real time, leaving the bulk of in-flight discovery outside the control's defined act.
- T1677detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces poisoned-pipeline incidents after they occur (as incidents) but does not instrument the CI/CD build process itself to catch the injection technique in flight.
- T1679detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of selective-exclusion ransomware behavior after incidents occur (the detection act), but only for realized incidents and only as an input to later controls, leaving the in-flight technique itself unreached.
- T1684detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding lessons into awareness training and risk treatment; this surfaces social-engineering incidents after they succeed (and can inform detection tuning) but does not itself perform detection of the technique while it is in flight.
- T1684prevents — A.5.27 uses post-incident lessons (including social engineering examples) to update risk assessments, add controls, and enhance training that can stop some future T1684 executions, but this is after-the-fact learning that does not stop the initial technique from running and leaves many instances untouched.
- T1684responds — A.5.27's post-incident procedures (quantify/monitor types+costs, feed lessons into the incident management plan, update risk assessment, add controls, and enhance awareness training with real examples) directly enable containment/eradication response to social engineering incidents once underway, with the bounded remainder being purely technical indicators that the control does not address.
- T1684.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding those lessons into risk assessment, plan updates and awareness training; this surfaces patterns of successful impersonation incidents (e.g. BEC) after they occur but does not instrument real-time detection of the technique itself.
- T1684.001prevents — post-incident lessons that update risk assessments, add controls, refine incident plans, and improve awareness/training can stop some future impersonation campaigns from succeeding, but this is an indirect governance/learning loop that leaves the bulk of the social-engineering technique (recon, infrastructure, targeting, urgency tricks) untouched
- T1684.001responds — A.5.27's post-incident procedures (quantify/monitor types+costs, feed lessons into the incident management plan, update risk assessment, add controls, and enhance awareness training with real examples) directly enable containment, eradication, and organizational response once an impersonation-based social-engineering incident is underway.
- T1685detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and plan updates; this surfaces T1685 incidents after they occur (especially recurring ones) but does not mandate or guarantee detection of the technique in flight or before impact.
- T1685prevents — learning from past incidents to update risk assessments, add controls, and improve training can prevent some recurrences of tool-tampering techniques by closing identified gaps, but does not stop the initial or novel execution of T1685
- T1685responds — A.5.27's post-incident learning and updates to the incident management plan (including scenarios/procedures) and risk treatment enable a response process that can contain/eradicate tool-tampering once detected, but the control itself is governance-level learning rather than direct containment action.
- T1685.001detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of T1685.001 (or its effects) as recurring incidents but does not instrument or surface the technique itself in real time.
- T1685.001prevents — A.5.27 procedures that quantify/monitor incident types, feed lessons into risk assessment, and add controls can prevent recurrence of the T1685.001 technique in future incidents, but this is an after-the-fact learning loop that does not stop the initial technique from running.
- T1685.002prevents — A.5.27's post-incident learning and risk-update loop can identify recurring logging-disabling patterns and drive additional preventive controls, but does not itself stop the technique from being executed by a privileged adversary.
- T1685.004detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces patterns of audit-disabling incidents after they occur but does not instrument or surface the in-progress technique itself.
- T1685.005detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs and feeding that into risk assessment and awareness; this surfaces patterns of log-clearing as an incident indicator (especially recurring ones) but does not instrument or guarantee detection of the technique in flight or in isolation.
- T1685.005responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) directly support containment/eradication response to a log-clearing incident once underway, with the named remainder being that it does not itself perform real-time containment actions.
- T1685.006responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance response plan and training) engage the core of `responds` once the log-clearing has occurred and is discovered, but only on the administrative/follow-up slice while containment/eradication of the already-realised hiding-of-evidence is empty.
- T1686detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces some post-incident firewall-tampering events as recurring patterns but does not instrument or detect the technique in flight or at the point of execution.
- T1686responds — A.5.27's post-incident procedures (quantify/monitor incidents, update risk assessment, add controls, enhance training) enable organizational response to a realized T1686 incident once underway, but only address the technique's downstream effects rather than containing or eradicating the firewall tampering itself.
- T1686.001detects — A.5.27's procedures to quantify/monitor incident types, volumes and costs surface patterns of firewall modifications as recurring incidents, feeding risk assessment and awareness, but this is post-incident knowledge rather than real-time detection of the technique in flight.
- T1686.003detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and awareness; this surfaces post-incident patterns of firewall tampering as recurring incidents but does not instrument or detect the live technique itself.
- T1690detects — A.5.27 requires quantifying/monitoring incident types, volumes and costs then feeding that into risk assessment and additional controls; this surfaces patterns of command-history tampering as an incident type after the fact, but only for incidents that are already logged, reported or otherwise visible to the organization, leaving the stealthy slice that the technique is explicitly designed to create undetected.
Prevented OWASP Web Top 10 (2025) risks (14)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- A01mitigates — post-incident analysis and added controls can limit the blast radius or recurrence of realized broken-access-control incidents (e.g., via updated procedures or awareness), but the control does not act on an already-successful authorization bypass to reduce its consequences
- A09finds — A.5.27 requires quantifying/monitoring incident types, volumes and costs and using that data to identify recurring or serious incidents, which surfaces (finds) undetected logging/alerting failures when they produce visible incidents; it does not discover silent failures that never surface as incidents.
- A09mitigates — Learning from incidents (including quantifying/monitoring types, volumes and costs) can feed back into improved logging/alerting controls and awareness, which bounds the realized consequences of undetected incidents, but does not change the fact that the logging/alerting failure itself remains present and realized.
- A10mitigates — A.5.27 uses post-incident lessons (including those from mishandled exceptions that leak info or fail open) to update risk assessments, add controls, and improve training, which bounds the future consequences of A10 weaknesses without stopping the initial mishandling itself.
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.