ASD ISM 1624 Protect PowerShell script block logs
What it says
PowerShell script block logs are protected by Protected Event Logging functionality.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPowerShell logs are safeguarded by secure event logging that ensures their protection.
PowerShell is a tool often used to automate tasks on computers. If someone with bad intentions gets access to your system, they could use PowerShell to cause harm without you knowing. Protecting PowerShell logs ensures that any activity is recorded and cannot be tampered with, helping to detect and prevent misuse.
Free. Save your status, tasks and notes.
Why it matters
If PowerShell script block logs are not protected with Protected Event Logging, attackers can tamper with or hide executed scripts, delaying detection and enabling compromise.
How to implement
IT team should enable Protected Event Logging for PowerShell: They need to configure the computers so that all PowerShell activities are securely logged.
This can be done by adjusting settings in Windows Group Policy to ensure logs are encrypted and stored safely.
System administrators should review PowerShell log settings regularly: They must check that logging is enabled and that the logs are being stored correctly.
These checks can be scheduled monthly by going into the system's event viewer and reviewing the configuration settings.
Security officers should provide training for staff on recognising suspicious PowerShell activity: They should organise a workshop or session to go over what PowerShell is and why certain activities need observation.
Use examples of common scripts and explain the importance of reporting anything unusual.
Management should ensure there's a policy for responding to PowerShell log alerts: Document procedures for what to do when suspicious activities are detected in the logs.
This should include who to notify and what information needs to be gathered to verify the issue.
Procurement should verify that new software includes features compatible with Protected Event Logging: When buying new software or IT services, ensure they are compatible with secure logging practices.
Include this requirement in procurement checklists and contracts.
Keep it running
Confirm Protected Event Logging is enabled and uses the correct certificate; routinely validate that PowerShell Script Block Logging events are being recorded and are not writable by users.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The Group Policy settings documentation: Request a printout or screenshot showing how Protected Event Logging is configured for PowerShell.
Look at
Settings that indicate logs are encrypted.
Good evidence
Shows clear configurations where the log settings are enabled and set to secure storage areas.
- Check 2 of 5What an auditor asks for
Ask for
A recent audit of PowerShell log reviews: Request the report from the latest review of PowerShell logs.
Look at
The date and findings to ensure reviews are happening regularly and are thorough.
Good evidence
Includes a review within the last month showing identified and actioned items.
- Check 3 of 5What an auditor asks for
Ask for
Training attendance records for PowerShell security courses: Request the sign-in sheets or electronic records for staff training sessions.
Look at
High participation numbers and updated content that includes PowerShell-specific topics.
Good evidence
Shows recent training with a majority of relevant staff in attendance.
- Check 4 of 5What an auditor asks for
Ask for
The incident response policy that includes PowerShell: Require a copy of the procedures for handling detected PowerShell misuse.
Look at
Clear steps and team responsibilities if unusual activity is logged.
Good evidence
Provides a detailed, easy-to-follow plan with assigned roles.
- Check 5 of 5What an auditor asks for
Ask for
Contract details with software providers: Request terms of purchase that specify secure logging compliance for PowerShell.
Look at
Clauses that require compatibility with Protected Event Logging.
Good evidence
Includes explicit requirements in the procurement documents.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.13, Protect event logs from unauthorised changes or deletion, which this control covers in full and more.
ASD Essential Eight: 5 mappings
This control is broader than E8-AH-ML2.13.
ISM-1624 requires PowerShell script block logs to be protected using Protected Event Logging functionality. E8-AH-ML2.13 requires protection of event logs from unauthorised modification and deletion at a general level, which includes PowerShell event logs. ISM-1624 is a more specific requirement focused on a particular Windows logging feature and log source, while E8-AH-ML2.13 is broader and does not prescribe a specific mechanism.
This control partially meets E8-AC-ML2.6.
ISM-1624 requires PowerShell script block logs to be protected using Protected Event Logging functionality. E8-AC-ML2.6 requires event logs generally to be protected from unauthorised modification and deletion, which includes PowerShell-related event logs in scope. ISM-1624 is a specific technical instantiation for one high-value log source (PowerShell script blocks), whereas E8-AC-ML2.6 applies broadly to event logs across systems.
This control partially meets E8-RA-ML2.8.
ISM-1624 requires PowerShell script block logs to be protected using Protected Event Logging functionality. E8-RA-ML2.8 requires event logs to be protected from unauthorised modification and deletion across the environment, which would encompass PowerShell logs as a subset. ISM-1624 is narrower because it specifies one log type and a particular protection approach rather than a general requirement for all event logs.
- E8-AH-ML2.11Centrally log PowerShell module, script block, and transcription eventsPartially overlaps
This control partially overlaps E8-AH-ML2.11.
ISM-1624 requires PowerShell script block logs to be protected using Protected Event Logging to prevent tampering and unauthorised disclosure. E8-AH-ML2.11 relates by requiring PowerShell module, script block and transcription logging to be centrally logged, which is a common way to improve integrity and retention of these logs. ISM-1624 focuses on the protection mechanism for script block logs specifically, while E8-AH-ML2.11 focuses on central collection across multiple PowerShell log types rather than the specific protection method.
This control partially overlaps E8-MF-ML2.7.
E8-MF-ML2.7 requires event logs to be protected from unauthorised modification and deletion. ISM-1624 strengthens this outcome for a specific log source by requiring PowerShell script block logs to be protected using Protected Event Logging, reducing opportunities for attackers to tamper with that telemetry. ISM-1624 is narrower (PowerShell-specific) and does not, by itself, address protection of all event logs across the environment.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.