DET0289: Detection Strategy for Disable or Modify Cloud Log
DET0289 matters because changes to cloud logging can remove the evidence needed to understand an incident. The related ATT&CK technique, Disable or Modify...
Analyst context for executives and security teams
DET0289 matters because changes to cloud logging can remove the evidence needed to understand an incident. The related ATT&CK technique, Disable or Modify Cloud Log (T1685.002), is a defense-impairment behavior across IaaS, SaaS, identity provider, and office suite environments where an actor with sufficient permissions may reduce or alter audit and application logging to hide activity.
Executive priority
Treat cloud logging control as a resilience and incident-readiness issue, not only a monitoring feature. Leaders should ask whether high-value cloud, identity, SaaS, and office environments can prove when logging was disabled, modified, or disconnected; who approved the change; and whether independent evidence remains available for investigation, audit, and recovery decisions.
Technical view
SOC, detection engineering, and IR teams should validate monitoring for administrative changes to cloud audit logging, application logging, and log integrations in the related platform categories: IaaS, SaaS, identity provider, and office suite. Because the official detection strategy object does not provide detailed analytics, teams should map local control-plane and admin-event telemetry to the related behavior: disabling, modifying, or reducing log collection, including examples such as AWS CloudWatch or CloudTrail where applicable.
Likely telemetry
- Cloud control-plane audit events for logging configuration changes
- SaaS and office suite administrative audit logs
- Identity provider administrative activity and permission changes
- Cloud audit and application log configuration state
- Log pipeline, integration, and ingestion health events
Detection direction
- Alert on disabling, modifying, or disconnecting audit/application logging and log integrations in covered cloud services.
- Correlate logging changes with the actor identity, role, source, time, and surrounding privileged activity.
- Tune for expected administrative maintenance, but require approval context because legitimate changes can look similar to defense impairment.
- Validate that detections still fire when logs are reduced or integrations are modified, not only when a complete disable event is recorded.
- Review gaps where the detection source depends on the same logging path that could be impaired.
Mitigation priorities
- Restrict permissions that can alter cloud logging and log integrations to tightly controlled administrative roles.
- Require change approval and review for logging configuration changes in IaaS, SaaS, identity provider, and office suite environments.
- Maintain independent monitoring of log pipeline health and configuration state so loss of visibility is itself visible.
- Prioritize retention and centralization of audit evidence needed for incident response and compliance support.
- Periodically test whether teams can identify who changed logging, what changed, and whether investigative evidence remains available.
Analyst notes and limits
This take is based on the DET0289 detection strategy metadata and its relationship to T1685.002 Disable or Modify Cloud Log. The decision value is strongest for cloud security, SOC readiness, incident response, identity governance, and compliance evidence where cloud audit logs are relied on for reconstruction of activity.
The official detection strategy fields supplied here do not include a description, detection logic, tactics, or platforms. Platform and tactic context comes from the related technique only. Local cloud services, log architectures, permissions, and change processes are required to determine actual detection coverage.
Detection Strategy for Disable or Modify Cloud Log
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1685.002 | Disable or Modify Cloud Log Sub-technique | This object detects Disable or Modify Cloud Log. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 804091c212dc… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0289Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.