ASD ISM 1658 Restrict execution of drivers via application control
What it says
Application control restricts the execution of drivers to an organisation-approved set.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsures only approved drivers are run on systems, enhancing security.
This control ensures that only the drivers officially approved by your organisation are allowed to run on your computers and devices. This matters because unapproved or malicious drivers can be used by attackers to gain control of your systems, potentially causing data breaches or system failures.
Free. Save your status, tasks and notes.
Why it matters
Unapproved drivers can introduce kernel-level vulnerabilities, enabling privilege escalation or malware persistence, causing breaches and outages.
How to implement
IT team should establish a list of approved drivers: Create an official list of drivers that are allowed to run on all organisation-owned devices, ensuring they are safe and necessary for operations.
The IT team should work with software vendors and review the security of each driver before adding it to the list.
System administrators should configure application control: Use the system's built-in security settings to limit driver execution to only those on the approved list.
This involves adjusting the operating system's policy settings to block any drivers not included in the approved set.
Procurement team should involve IT in driver approval: Whenever acquiring new hardware or software that requires drivers, have the procurement team collaborate with IT to vet the drivers.
IT should check whether new drivers are secure and compatible with the current systems before allowing their use.
IT team should train staff: Conduct training sessions for all staff to ensure they understand the importance of using approved drivers and how to request a driver to be added to the approved list.
Use straightforward language and scenarios relevant to their everyday tasks.
System administrators should regularly review the approved drivers list: Schedule routine checks to ensure that the list of approved drivers is current and remove any that are no longer needed or pose a security risk.
This task can be done quarterly or whenever major updates occur.
Keep it running
Maintain an approved driver allow-list; review new driver releases, and routinely audit endpoints so only allow-listed/signed drivers load at boot/runtime.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The current list of approved drivers: Request the document or database that contains all drivers currently authorised by the organisation.
Look at
Recent updates or addition dates to ensure the list is actively maintained.
Good evidence
A well-organised list with recent entries and rationale for approval.
- Check 2 of 5What an auditor asks for
Ask for
Demonstration of application control settings: Request a live or recorded demonstration of the application control settings on a representative system.
Look at
How these settings limit driver execution to only those on the approved list.
Good evidence
Systems actually blocking unapproved drivers in practice.
- Check 3 of 5What an auditor asks for
Ask for
Staff training records: Request evidence that staff have been trained on the importance of using approved drivers and the procedure for driver approval.
Look at
Attendance records and training materials.
Good evidence
Clear records of recent training sessions with feedback from participants.
- Check 4 of 5What an auditor asks for
Ask for
Logs of driver execution attempts: Request log files from systems that show attempts to run drivers and whether they were approved or blocked.
Look at
Failed execution attempts of unapproved drivers.
Good evidence
Logs showing blocked attempts, indicating effective enforcement.
- Check 5 of 5What an auditor asks for
Ask for
Incident reports related to driver issues: Request any incidents reports that involved driver-related security issues.
Look at
Documentation showing how such issues were handled or prevented.
Good evidence
Reports that describe incidents and demonstrate lessons learned and mitigation steps.
Mappings
Closest match in ASD Essential Eight: E8-AC-ML3.2, Application control restricts driver execution to an approved set, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.18.
Annex A 8.18 requires tight restriction of utilities capable of overriding system and application controls, which includes mechanisms that could introduce or load privileged components. ISM-1658 restricts driver execution to an approved set via application control, reducing the risk of installing/loading drivers that can subvert OS controls. ISM-1658 is specifically about drivers, whereas Annex A 8.18 covers a wider class of high-privilege utilities and administrative tools beyond drivers.
ASD Essential Eight: 7 mappings
This control is equivalent to E8-AC-ML3.2.
ISM-1658 requires application control to restrict the execution of drivers to an organisation-approved set. E8-AC-ML3.2 states the same requirement using the same mechanism (application control) and the same scope (drivers only). Implementing either control would largely satisfy the other for driver execution restrictions.
This control partially meets E8-AC-ML1.1.
E8-AC-ML1.1 requires application control on workstations to ensure only approved software runs. ISM-1658 is broader in that it specifies application control must also restrict driver execution to an organisation-approved set, which is one specific class of executable content. E8-AC-ML1.1 would typically contribute to this outcome, but does not explicitly call out drivers.
This control partially meets E8-AC-ML1.3.
E8-AC-ML1.3 mandates application control so that only organisation-approved applications and scripts, including executables and libraries, can run. ISM-1658 applies the same concept to drivers, a narrower subset of executable code, under broader E8-AC-ML1.3.
This control partially overlaps E8-AC-ML1.2.
E8-AC-ML1.2 requires application control to cover user profiles and temporary folders to stop unapproved code running from those user-writable locations. ISM-1658 requires application control to restrict execution of drivers to an organisation-approved set, which is another application-control use case. Both rely on application control enforcement, but ISM-1658 is about driver execution (and kernel-level risk) rather than location-based coverage of user/temporary folders.
This control partially overlaps E8-AC-ML2.1.
E8-AC-ML2.1 requires application control on internet-facing servers to prevent unauthorised code from running. ISM-1658 supports this objective by requiring application control to restrict drivers to an organisation-approved set, reducing kernel-level execution risk on those servers. ISM-1658 is a narrower technical subset (drivers specifically) compared with the broader execution control implied by E8-AC-ML2.1.
This control partially overlaps E8-AC-ML3.1.
E8-AC-ML3.1 requires implementing application control on non-internet-facing servers to restrict execution to approved software. ISM-1658 strengthens that implementation by requiring application control to specifically restrict driver execution to an organisation-approved set on those systems. E8-AC-ML3.1 does not explicitly call out drivers, so ISM-1658 is an implementation-hardening requirement rather than the same control.
This control supports E8-AC-ML2.4.
ISM-1658 requires application control to restrict the execution of drivers to an organisation-approved set. E8-AC-ML2.4 mandates validating application control rulesets at least annually, which helps ensure the approved-driver allowlist/deny rules used to meet ISM-1658 remain accurate and effective over time. The candidate is about governance/assurance of rulesets, whereas ISM-1658 is the specific driver execution restriction outcome.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.