Introduction to Attack Surface Reduction (ASR)
Attack surfaces are all the places where your organisation is vulnerable to cyber threats and attacks. Attack Surface Reduction (ASR) refers to a set of strategies and techniques aimed at minimising the possible pathways or vectors that attackers can exploit.
Microsoft provides a readily available set of capabilities for organisations that utilise E3 or E5 licenses for their employees. ASR rules are the umbrella term that Microsoft uses to describe these features that better safeguard organisational endpoints from malware and ransomware through blocking the entry point of where the attack may occur.
ASR was initially introduced as part of a suite of Windows Defender exploit guard features in Windows 10, version 1709 back in October, 2017. Since then, we’ve come a long way with the introduction of Microsoft Defender for Endpoint as a centralised security management tool. It takes security features from older versions of Windows like Defender Firewall and Advanced Threat Protection to enable interoperability between Microsoft security tools.
In this article we will focus on ASR itself, delving into the intricate details necessary to determine whether implementing such rules are suitable for your organisation.
How Does ASR Work?
It’s important to note that ASR is different from your traditional Anti-Virus (AV) or Endpoint Detection and Response (EDR) solutions as its primary focus is not to identify and remove known malware using any known signature or anomaly detection techniques. ASR’s goal is instead to minimise the attack surface by reducing the potential avenues of attack and mitigate the security risk.
What does this mean? For example, you might set up an ASR rule to “Block all Office applications from creating child processes”. Malicious software often leverages Microsoft Office applications and exploit code to download and execute any additional payloads from creating child processes (e.g., spell, grammar checkers or print drivers) that spawn under the parent process (e.g., Microsoft Word, Excel, PowerPoint etc.). By setting up this ASR rule on the device, any child process that is created from Microsoft Office’s parent processes will be automatically blocked. This prevents the risk of malware from ever gaining a foothold by mitigating the entry point of the attack.
Nevertheless, a deep understanding of the organisation’s business and processes is vital to avoid any impacts to your operational environment. Therefore, it is imperative not to enable ASR rules indiscriminately within your organisation, as this could inadvertently impede essential day-to-day operations. For instance, if ASR rules block critical processes necessary for network printers to function, end-users may encounter obstacles in tasks such as printing.
Why Should Your Organisation Implement ASR?
So, by now you understand that ASR is not your typical EDR or AV solution since it doesn’t even detect, analyse or block attacks. So, is implementing it worthwhile? The simple answer is yes - you can treat it as an add-on to your existing Next Generation AV / EDR capabilities and employ a defence-in-depth approach that doesn’t rely on a single measure or control to thwart attacks. Additionally, if you have at a minimum Microsoft E3 licences then you already have the option to implement ASR rules in your organisation because it comes with the Microsoft Defender for Endpoint (Plan 1) capabilities.
[Source: Microsoft]
Moreover, organisations that have regulatory compliance requirements should seriously consider ASR rules. Well known cyber security standards and best practice guides for Australian businesses such as the ASD’s Essential Eight references recommendations to implement ASR rules like to have Microsoft Office macros being blocked from making Win32 API calls. For more on the latest Essential 8 requirements read our related blog here.
Prerequisites
You’ll need to have an E3 licence at the very least. This includes Microsoft 365 Frontline (E3), Enterprise (E3 and E5) and Education customers (A3 and A5). Unfortunately, this feature is not offered for Office 365 and Microsoft 365 Business customers, even as an add-on. As a caveat, the timeline of implementing ASR rules for your organisation will vary. Depending on the size of your organisation, deployment can start from as little as two months but must also consider your organisation’s change management practices and “noise” in your I.T network based off the applications and processes used. Some considerations include:
Target Audience – Do you want to allocate ASR rules for your employees, or do you want to allocate ASR rules per device (i.e., workstation and server)?
Environment - Which ASR rules are most suited for your business needs and won’t impact productivity negatively?
Exclusions – Which applications and folder paths do you already know that need to be excluded/whitelisted from ASR rules?
We recommend spending at least a month in just monitoring the ASR rules in audit mode before actively blocking anything. This ensures enough data is collected to analyse and find any benign processes which might be flagged by the rules. The good news is ASR rules are more of a set and forget kind of policy to implement. The setting up of ASR rules is relatively seamless for most organisations, however the identification and analysis of which processes to exclude is the bulk of the work. It should be noted that once ASR rules are fully implemented, it’s important to observe the environment periodically in case any new processes need to be added to the ASR rules exclusion list with the ever-changing business requirements and new technologies being introduced.
ASR Rules Breakdown
The table below details the current rules available by category:
ASR Rule Name | Category |
Block abuse of exploited vulnerable signed drivers | Misc rule |
Block Adobe Reader from creating child processes | Productivity apps rule |
Block all Office applications from creating child processes | Productivity apps rule |
Block credential stealing from the Windows local security authority subsystem (lsass.exe) | Lateral movement & credential theft |
Block executable content from email client and webmail | Email rule |
Block executable files from running unless they meet a prevalence, age, or trust list criterion | Polymorphic threat |
Block execution of potentially obfuscated scripts | Script rule |
Block JavaScript of VBScript from launching downloaded executable content | Script rule |
Block Office applications from creating executable content | Productivity apps rule |
Block Office applications from injecting code into other processes | Productivity apps rule |
Block Office communication application from creating child processes | Productivity apps rule |
Block persistence through WMI event subscription | Lateral movement & credential theft |
Block process creations originating from PSExec and WMI commands | Lateral movement & credential theft |
Block untrusted and unsigned processes that run from USB | Polymorphic threat |
Block Webshell creation for Servers | Polymorphic threat |
Block Win32 API calls from Office macros | Script rule |
Use advanced protection against ransomware | Polymorphic threat |
Dependencies
For ASR rules to work, Microsoft Defender Antivirus must be enabled and configured as the primary antivirus solution and must be in either of the following modes:
Primary antivirus/antimalware solution
State: Active mode
Meaning Microsoft Defender Antivirus must not be in passive, EDR in block mode, limited periodic scanning or off modes. Besides exclusion rules, which allow you to specify exclusions for processes and file paths to be exempted from ASR rules, you can also incorporate "per-rule exclusions." These exclusions link specific processes and file paths to be exempted from a particular ASR rule.
ASR is currently only supported for the following operating systems:
· Windows 10 Pro, version 1709 or later
· Windows 10 Enterprise, version 1709 or later
· Windows Server, version 1803 (Semi-Annual Channel) or later
· Windows Server 2022
· Windows Server 2019
· Windows Server 2016 (requires onboarding)
· Windows Server 2012 R2 (requires onboarding)
Additional Components
Additional components offered as part of the ASR suite include:
Controlled folder access: Works by only allowing trusted apps to access protected folders. Trusted apps can be configured manually or automatically added by Microsoft. Apps are added to the list based upon their prevalence and reputation, apps that are highly prevalent throughout your organisation and that have never displayed any behaviour deemed malicious are considered trustworthy and are added to the list automatically.
Windows system folders are protected by default including the common system folders. Users are allowed to add additional folders and allow apps to give access to the folders. The Windows folders that are protected by default are:
c:\Users\<username>\Documents
c:\Users\Public\Documents
c:\Users\<username>\Pictures
c:\Users\Public\Pictures
c:\Users\Public\Videos
c:\Users\<username>\Videos
c:\Users\<username>\Music
c:\Users\Public\Music
c:\Users\<username>\Favorites
Device Control: Device control features within Microsoft Defender for Endpoint empower your security team to manage users' ability to install and utilise peripheral devices such as USB drives, CDs, printers, Bluetooth devices, and other external hardware with their computers. Your security team can customise device control policies to enact rules such as:
Restricting users from installing and using particular devices, such as USB drives.
Prohibiting users from installing and using any external devices, except for specific exceptions.
Permitting users to install and use specified devices.
Allowing users to install and use solely BitLocker-encrypted devices with Windows computers.
Exploit protection: Exploit protection automatically applies many exploit mitigation techniques to operating system processes and apps once detected. It is a feature that works along with Defender for Endpoint which can give you detailed reporting into exploit protection events in the “Action Center”.
Network protection: Network protection helps protect devices from Internet-based events. Being an ASR capability, it can help protect your organisation from accessing dangerous domains through applications such as phishing scams, exploits and other malicious content.
Web protection: Web protection within Microsoft Defender for Endpoint comprises Web threat protection, Web content filtering, and Custom indicators. This capability enables you to safeguard your devices from online threats and gives you control over undesirable content.
Planning for ASR Rule Deployment
You can configure ASR rules using one of the following methods:
Microsoft Intune (for managed devices)
3rd party Mobile Device Management (MDM)
Microsoft System Center Configuration Manager (SCCM)
Group Policy
PowerShell
When undertaking a large-scale implementation, especially one that could potentially affect your day-to-day business operations, it's crucial to approach it with methodical planning and execution. It's imperative to meticulously plan, test, implement, and operationalise these rules. We recommend a ring approach - a progressive method of software deployment that reduces risk and enhances system availability.
[Source: Microsoft]
ASR allows you to test your rules in the following modes:
Audit – Allows you to evaluate how ASR rules will affect your organisation if enabled. We recommend running all rules in audit mode so you can understand how they affect your in-line business applications.
Warn – Allows your end users to see a dialogue box that pops out when content is blocked by an ASR rule. The dialogue box offers the user an option to unblock the content such that the user can retry their action or to ignore and continue blocking. If the user unblocks the content, the content remains unblocked for 24 hours, then blocking resumes.
Block – When enabled, block mode will automatically block any detections caught under the ASR rules. Users will be notified if the content is blocked through a dialogue box.
Implementation of ASR should be a cyclic process. First, enable all of users or a pilot group to have the ASR rules turned on in audit mode for a set amount of time (usually at least one month to gather enough data). Microsoft Defender will begin to collect and allow you to observe which processes will be blocked if the ASR rule was to be turned to block mode. After analysis, you will be able to add/define your exclusions and continue monitoring and assess business impact.
Once you’re positive and confident that the ASR rules will cause no business impact, you can change the ASR rule from audit mode to block mode for your pilot group of users and repeat the process again for another batch of users back in audit mode. For rules you might seem problematic for your organisation, we recommend using ‘warn’ mode after auditing before changing it to block mode. This will be rinsed and repeated with regularly reviews and additions to your exclusion rules as they come up until you have coverage across your entire organisation.
How Spartans Security Can Help?
Spartans Security can aid you through working with your business, from the planning through to implementation stage. We have engaged with a diverse range of industries in the delivery of ASR. Navigating Microsoft's complex array of interfaces in their constantly evolving landscape and features can be challenging. We acknowledge the difficulty in comprehending all the configurations involved if you’re not regularly deploying them. Our security consultants are experts in their field and can help you deliver ASR or other Microsoft security products in a low risk and easy to understand manner.
We understand that each business is different and we will work with your team, third-party vendors, and any other stakeholders to provide you with tailored advice in your ASR journey based on your organisation’s needs.
Conclusion
There are an abundance of technical details to navigate here; nevertheless, we emphasise that the bulk of the effort is dedicated to the planning and analysis phase.
ASR rules are implemented to counter techniques commonly employed by malicious actors to enable them to perform malicious tasks. By disabling certain frequently exploited functions which are deemed as unneeded, we can close these attack vectors without compromising performance or increasing operational friction.
If you have any questions or need help in implementing ASR for your business, then feel free to reach out at info@spartanssec.com
Comments