🛡️ Essential 8 Guide

Event logs are protected from unauthorised modification and deletion.

Summary

Event logs are protected from unauthorized modification and deletion to preserve logs for incident response and compliance. RBAC in Microsoft Defender XDR and Microsoft Sentinel restricts access to event logs, preventing tampering and enabling centralized protection and monitoring.¹

Justification

Event logs are a primary forensic artefact during incident response. Without tamper protection, an attacker with local admin or Domain Admin privileges can clear Windows Security/System/Application event logs (using wevtutil cl) or delete Log Analytics workspace data — effectively destroying the evidence trail needed to determine breach scope, dwell time, and lateral movement paths.

Centralising logs to a Log Analytics workspace with RBAC and an immutable delete lock decouples the log store from the endpoint, so even a fully compromised endpoint cannot retroactively erase its own audit trail. This is a core requirement of the ASD ISM and PSPF audit logging expectations.

Protected Event Logging (PowerShell) adds an additional layer: script block logs are encrypted with a public key before being written to the event log, meaning even a local administrator cannot read sensitive credential or token data captured during script execution without the corresponding private key.

A Microsoft Sentinel analytics rule alerting on Windows Security Event ID 1102 (Windows audit log cleared) and ID 1100 (Event logging service stopped) provides near-real-time detection of log tampering attempts — closing the gap between action and response.

Design Decision

[!NOTE] The RBAC configuration will be applied in Microsoft Defender XDR and Microsoft Sentinel to protect event logs from tampering. Access controls will be enforced to restrict modification and deletion of event logs to authorized personnel.

Prerequisites

• Permissions/Roles:
  • Centralized log management requires RBAC on the log analytics / monitoring platform to restrict access and monitor for log modifications or deletions. ¹
  • Enforce access controls in security tooling to protect event logs from tampering, such as Defender XDR and Microsoft Sentinel. ²
  • Onboard a SIEM to centralize security telemetry and enable centralized analysis (e.g., Microsoft Sentinel). ³
  • Configure log access restrictions using Group Policy for Windows event logs where applicable. ¹
  • Use ADMX backed policies to enforce event log access restrictions (examples include ADMX_EventLog policies). ⁴
  • Enable Protected Event Logging to encrypt potentially sensitive event log data where supported. ⁵
• Dependencies:
  • Centralized log infrastructure (Azure Monitor / Log Analytics) to collect logs from all relevant sources. ¹
  • Consider exporting logs to immutable storage to prevent tampering. ¹
  • Windows Event Forwarding to route event logs to the central store. ⁶
  • Microsoft Sentinel onboarding to provide SIEM capabilities for centralized monitoring. ³

Implementation Steps

RBAC protection of event logs in Defender XDR and Sentinel

1. Centralize event logs from Azure services into a Log Analytics workspace to enable RBAC enforcement and tamper protection.¹

2. Apply role-based access controls to the Log Analytics workspace to restrict write, read, and delete actions on event logs and related configuration.¹

3. Enable a lock on the Log Analytics workspace to block deletion, purge, and retention configuration changes.¹

4. Configure automated exports of log data to immutable storage (such as Immutable Storage for Azure Blob Storage) to prevent tampering.¹

5. Ensure privileged activity logs are stored with RBAC protections and monitored for modify and delete activities. Integrate with Defender XDR and Sentinel for centralized analysis.¹

Windows 11 Security Event Log — Built-in Access Controls and Hardening

Windows 11 enforces access controls on the Security event log at the operating system level, providing a baseline of protection before any additional Group Policy or SIEM hardening is applied.

Default access control behaviour:

The Security event log channel is unique among Windows event logs: standard users receive no read access at all. Access to other channels (Application, System) is granted to standard users for read purposes, but the Security log is restricted exclusively to BUILTIN\Administrators and NT AUTHORITY\SYSTEM. This is enforced by the Windows Security Descriptor on the event log channel itself.

Clearing the Security event log requires privilege escalation:

Clearing the Security event log (wevtutil cl Security or via Event Viewer) requires the “Manage auditing and security log” user right (SeSecurityPrivilege), which is assigned by default only to BUILTIN\Administrators. Running this command without elevation produces Access is denied — even for users in the local Administrators group if UAC is active and the process is not elevated. Standard users cannot clear the log under any circumstances without first being granted the privilege explicitly.

Detection — Event IDs to monitor:

These events should be forwarded to Microsoft Sentinel via Windows Event Forwarding or the Log Analytics agent and should trigger an immediate analytics alert, as log clearing during an active session is a strong indicator of attacker anti-forensics activity.⁷

Further hardening via Group Policy (Intune Settings Catalog):

The default ACL on the Security log can be explicitly enforced or further restricted using the Channel_Log_FilePermissions_1 ADMX-backed policy to define an SDDL string on the Security channel.⁴

1. In Intune > Devices > Configuration > + Create policy > Settings Catalog.
2. Search for Event Log Service and locate Security: Control Event Log Access.
3. Set the SDDL value to restrict access. The default Windows SDDL grants Administrators full control and denies all others:

O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x3;;;BO)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x3;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;S-1-5-33)(A;;0x2;;;S-1-5-32-573)

1. To alert on any changes to this policy, enable Audit Policy Change (Event ID 4719) in the audit policy and forward those events to Sentinel.⁴

[!NOTE] Removing the “Manage auditing and security log” user right from Administrators entirely (SeSecurityPrivilege via User Rights Assignment GPO) will prevent all local log clearing — including by helpdesk and IT administrators. This is the highest-assurance configuration but can complicate legitimate incident response activities. Consider using this setting only on high-value or classified workloads, or as a compensating control on machines where log clearing should never be required.

Lock a Retention Policy to Prevent Removal (Preservation Lock)

Microsoft Purview retention policies can be made permanently immutable by applying a Preservation Lock. Once locked, no administrator — including a Global Administrator — can disable, delete, or make the policy less restrictive. The retention duration can only be extended, never shortened.⁸

[!WARNING] Applying a Preservation Lock is irreversible through normal administrative means. Once enabled, the policy is permanently bound to its retention duration and scope. The only mechanism for removal is a formal written request submitted to Microsoft by an authorised legal representative of the organisation, confirming the regulatory basis for the change. This cannot be performed by IT administrators or even Microsoft Support without that legal authorisation. Only apply a Preservation Lock after the retention policy has been fully reviewed, tested, and confirmed correct.

When to apply Preservation Lock:

• The organisation is subject to regulatory requirements that mandate tamper-proof retention records — such as AFDA records disposal obligations, PSPF protective security requirements, or ISM audit log retention at ML3.
• Legal or compliance counsel has reviewed and approved the retention duration and scope.
• The policy has been validated in a test environment and confirmed to cover the correct locations and users.

To apply a Preservation Lock to an existing retention policy:

Preservation Lock is intentionally unavailable in the Purview portal UI to prevent accidental activation. It must be applied via PowerShell only.

1. Connect to Security & Compliance PowerShell:

Connect-IPPSSession

1. Apply Preservation Lock to the target policy by name:

Set-RetentionCompliancePolicy -Identity "Your-Policy-Name" -RestrictiveRetention $true

1. Confirm the lock has been applied:

Get-RetentionCompliancePolicy -Identity "Your-Policy-Name" | Select-Object Name, RestrictiveRetention

The RestrictiveRetention property must return True to confirm the lock is active.⁸

[!NOTE] Once locked, Set-RetentionCompliancePolicy will reject any attempt to shorten the retention period, narrow the scope, or delete the policy. Only extending the retention duration is permitted. Any modification or removal of the lock requires a formal legal request from the organisation’s authorised legal representative submitted directly to Microsoft. This process is specifically designed for regulatory compliance scenarios where the organisation must demonstrate to an external auditor or regulator that records cannot be altered or deleted by any internal party.

Additional related information

• How to set event log security locally or by using Group Policy provides step-by-step instructions to configure log access permissions How to set event log security locally or by using Group Policy
• Policy CSP - ADMX_EventLog describes the ADMX-backed policy for configuring per-log access controls Policy CSP - ADMX_EventLog
• Policy CSP - ADMX_EventLogging covers enabling and configuring event log logging protections, including Protected Event Logging Policy CSP - ADMX_EventLogging
• Centralize security log management and enable SIEM/SOAR capabilities for cross-service threat detection Logging and Threat Detection
• Use Preservation Lock to restrict changes to retention policies and retention label policies explains how to apply an irreversible lock to Purview retention policies via PowerShell, and the Microsoft legal process required for any subsequent modification or removal Use Preservation Lock — Microsoft Purview
• Event 1102 — The audit log was cleared details the Windows security audit event generated whenever the Security event log is cleared, including the account responsible, and is the primary detection signal for log tampering Event 1102 — Windows Security auditing