Application Control
Assessing Application Control.
Introduction
Control objective
The objective of the Application Control strategy is to ensure applications are only accessible from appropriate locations and to the appropriate users.
Expectation
Organisations are expected to have a comprehensive approach to managing and controlling the execution of software applications.
The approach must include the full lifecycle of approving, deploying, and removing software applications. At higher maturity levels, log retention and monitoring are required.
The scope of application control is also extended from just workstations to internet-facing servers at Maturity Level 2 and all workstations and servers at Maturity Level 3.
Implementing application control
Identify business-critical applications and formally approve their use.
Develop application control rules to ensure that only approved applications can be executed.
Maintain the application control rules using a change management program.
Validate application control rules on an annual or more frequent basis.
Contents
Guidance
Assessment scope
When carrying out application control assessments, it’s important to consider paths related to standard user-profiles and temporary directories that are utilised by operating systems, web browsers, and email clients. These can include:
%userprofile%*%temp%*%tmp%*%windir%\Temp*
Based on the system’s setup, some overlap may be present; for example, %temp% and %tmp% are usually found within %userprofile%.
It is important to note that the last major update to the maturity model introduced compiled Hypertext Markup Language (HTML) (
.chmfiles), HTML applications (.htafiles) and control panel applets (.cplfiles) to the list of file types that need to be controlled. Some application control solutions may not support these file types.
Assessing Application Control
To assess the effectiveness of application control strategies:
Identify authorised programs.
Identify the application control approach that is being used (if in place).
Assess the controls using assessment methods and tools.
Determine the associated maturity level.
Assessment methods
Application control assessments are possible without tools, but the efficacy of the tests will be significantly reduced, and edge cases that malicious actors might exploit could be missed. For instance, threat actors might deploy bespoke tools to enumerate weak paths in a system.
The ACSC provides guidelines and recommendations on the methods and tools that can be used to assess the control.
The only true way to test is to attempt execution against all file types in all locations.
SysInternals AccessChk application can be used to generate output of folder permissions, but this is only relevant, potentially, for Level 1.
E8MVT
The Essential Eight Maturity Verification Tool (E8MVT) tests application control policies by attempting to write and execute certain file types in specific locations.
The tool also checks that Microsoft’s recommended block rules and drive block rules are implemented.
ACVT
The Application Control Verification Tool (ACVT) tests application control policies by enumerating all sub-directories and attempting to write and execute each relevant file type from each location.
Both the E8MVT and ACVT are part of ASD’s toolkit, available through their partner program.
Scripts
Get AppLocker Policies
Get-AppLockerPolicy -Effective -Xml | Set-Content ('c:\windows\temp\curr.xml')`Get-AppLockerPolicy -Local | Test-AppLockerPolicy -Path C:\Windows\System32\*.exe -User EveryoneTest in calc.exe or notepad.exe:
Test-AppLockerPolicy -XMLPolicy C:\windows\temp\curr.xml -Path C:\windows\system32\calc.exe, C:\windows\system32\notepad.exe -User EveryoneSysinternals accesschk
If only trusted Microsoft tools are permitted on the system, SysInternals AccessChk can be used for outputting folder permissions, noting this is only suitable for a path-based approach to implementing the control.
accesschk -dsuvw [path] > report.txtRunning whoami /groups would also need to be executed to determine which user groups a typical standard user belonged to in order to determine the effective permissions for each path.
This approach is, however, likely to be tedious in assessing effectively.
Maturity Level 1 guidance
The intent of application control at Maturity Level 1 can be met without a dedicated application control solution. This is achieved through file system permissions to prevent unnecessary access to user profile directories and temporary folders.
The execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets is prevented on workstations from within standard user profiles and temporary folders used by the operating system, web browsers and email clients.
Given how complex file system permissions can become, it’s essential to attempt to write and execute from all user-accessible directories to effectively check application control.
ACSC’s Essential Eight Maturity Verification (E8MVT) and Application Control Verification (ACVT) tools (available to ACSC partners) can assist in achieving this. A number of other tools on the market can also enumerate a file system to perform this test.
Where applicable, PowerShell cmdlets can be used to test and review AppLocker policies and Sysinternals accesschk can be used if only Microsoft-based tools are available to use.
For a system on which tools cannot be run, and assuming a path-based approach is used, screenshots of the ‘effective access’ permissions for specified folders can be requested. This, however, has limitations because unless screenshots of access permissions are requested for every folder and sub-folder (for which there are usually many), it will not be possible to comprehensively assess whether read, write and execute permissions exist for a given user. Consequently, this will likely impact the quality of evidence cited in the final report.
At a minimum, screenshots for key paths (such as temporary folders used by the operating system, web browsers and email clients) should be requested and examined to determine whether inheritance is set, noting that at any point in a path, application control inheritance previously set by an operating system may be disabled by an application installer
Maturity Level 2 guidance
Whereas Maturity Level 1 is focused on End-User Compute (EUC) endpoints, Level 2 extends application control to internet-facing servers and includes additional log-retention requirements.
Maturity Level 3 guidance
Maturity Level 3 builds on Level 2 in that it requires log monitoring, application control on all servers, and the implementation of Microsoft’s block rules. Application control rulesets also need to be validated at least annually.
Other considerations
Considering Kernel
Virtual memory is split into kernel and user space. The scope to which an application control solution protects a system’s kernel should also be considered.
Identifying adversary attempts to execute malicious code
Application control can help identify attempts to execute malicious code.
This can be achieved by configuring application control to generate event logs for allowed and blocked executions.
Event logs should include relevant information such as:
name of the file
date/time stamp
username of the executing user
Application control logs can also be ingested into an SIEM/SOAR system to allow for and contribute to a broader context of the threat landscape.
AppLocker and WDAC
AppLocker and Windows Defender Application Control (WDAC) are both security features in Windows, designed to control application usage and restrict unauthorised software. However, they have distinct differences:
Design and Purpose:
AppLocker: Primarily aimed at providing administrators with the ability to specify which users or groups can run particular applications, based on unique identities of files. It’s more about managing application access than outright security.
WDAC: Focuses more on security. It is designed to prevent malware and untrusted applications from running by enforcing code integrity policies.
Scope and Control:
AppLocker: Works at a more granular level, allowing control over scripts, executable files, Windows Installer files, DLLs, and packaged app installers.
WDAC: Controls the entire spectrum of executable code on the system, including kernel-mode drivers and user-mode applications.
Implementation and Management:
AppLocker: Managed through Group Policy, making it easier to implement in an environment already using Group Policy for configurations.
WDAC: Managed through PowerShell and uses a different policy format, which can be more complex to set up but offers higher security. -
Flexibility and Usability:
AppLocker: Offers more flexibility and is simpler to configure, especially for smaller organizations or those with less complex needs.
WDAC: While it provides a stronger security posture, implementing and managing it can be more challenging, particularly in environments with diverse applications.
System Requirements:
AppLocker: Available on Windows 7 and newer versions but only for Enterprise and Ultimate editions.
WDAC: This feature is available on Windows 10 and Windows Server 2016 and later, offering broader support across different Windows editions.
Security Level:
AppLocker: Considered less robust in terms of security compared to WDAC, as it lacks the more comprehensive system-wide controls.
WDAC: Provides a more secure environment by ensuring that only trusted software runs on the system.
In summary, while AppLocker is more user-friendly and easier to manage, particularly for application access control, WDAC offers a more comprehensive and secure approach, focusing on system integrity and malware prevention. The choice between the two would depend on the organisation's specific needs and capabilities, particularly in terms of desired security level and ease of management.