Demystifying attack surface reduction rules – Part 1

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Hey everyone! António and Rob here!

 

For the past few years, we’ve been working closely with many of our customers, assisting them in their journeys toward adopting the full Microsoft Defender ATP stack. Throughout these relationships, we’ve answered innumerable questions about Microsoft Defender ATP attack surface reduction (ASR) rules.

 

We’ve decided to compile all the major ones into a blog series and share it with the broader world.

In this multi-part series blog post, we’ll hopefully cover many, if not all, of your questions about ASR rules, and how to successfully adopt them in your organization.

 

Let's start with the Why and the What!

 

#1 What is the difference between ASR and ASR rules?

ASR and ASR rules are two different things. Attack surface reduction, or ASR, is an umbrella term for all the built-in and cloud-based security features Windows 10 offers that help to minimize the surface of attack, or areas of entry, for an attacker. It’s what you would call a HIPS (Host Intrusion Prevention System) solution, in industry lingo. In Microsoft Defender ATP, ASR includes the following:

  • Attack surface reduction rules
  • Hardware based isolation
  • Application control
  • Exploit protection
  • Network protection
  • Web protection
  • Controlled folder access
  • Network firewall

You can learn about all these capabilities in our documentation. You’ll see in this list that ASR rules are one of the features under the attack surface reduction umbrella.

 

#2 Why do I need ASR rules?

Attack surface reduction rules help close off many of the common entry points used by malware and ransomware, preventing attacks from ever reaching the point where AV and EDR solutions would detect them.

 

It’s not about trusting or not trusting certain kinds of activity; it’s about not allowing specific actions that we know to be commonly associated with malicious activity.

 

This of course does not mean you don’t need other endpoint solutions. The idea is to provide security and monitoring at each layer. Why give malware and exploits even an inch (or a centimeter) of your endpoints’ surface area before you let your corporate users in to start being productive.

 

A very good analogy is the liquids restrictions when entering a checkpoint at an airport. It’s not about whether the security personnel trust you or not. There is just the general, and mandatory, rule that no liquids above a certain volume are allowed. As you can understand, this minimizes the risk of, or even mitigates against, certain types of attacks.

 

In essence, ASR rules are here to help you reduce the attack surface of an endpoint by minimizing the places where your organization might be vulnerable to cyberthreats and attacks.

 

#3 Why were ASR rules created?

ASR rules were created so that enterprises can secure their endpoints along with protections that work alongside Microsoft Defender ATP, Microsoft Defender antivirus, and Endpoint Detection and Response (EDR), to provide a robust endpoint solution that gives security admins the control and visibility they need.

 

#4 What kinds of protection do they offer?

ASR rules offer a broad range of built-in rules to secure your endpoint, covering areas like Office applications (think macros, DDE’s, etc.) subversion or leverage, but also things like Webmail, script, WMI, LSASS, and much more.

 

#5 What are the specific requirements for enabling ASR rules?

Yes, the requirements are the following:

  • Computers running Windows 10, versions 1709 and later,  Windows Server version 1803 (Semi-Annual Channel or later) and Windows Server 2019
  • Windows 10  /Enterprise/Education
  • Microsoft Defender antivirus must be active (cannot be in passive mode!)
  • Some rules require cloud-delivered protection to be enabled

Although ASR rules do not require an E5 license, with E5 you’ll gain enhanced optics and data insights, thanks to the power of the Microsoft Cloud.

 

For more information on the differences between E3 and E5 for ASR rules, please refer to Attack surface reduction features across Windows versions

 

In future parts of this blog, we will cover the different reporting mechanisms and you’ll be able to see the exact benefits of E5 for ASR rules.

 

#6 What are the available rules? And, are they available in all Windows versions?

As of now, we provide you a total of 15 rules. Spanning across multiple pillars of protection, like Office, Credentials, Scripts, E-Mail, etc.

 

All ASR rules, except for Block persistence through WMI event subscription, are supported on Windows 1709 and later.

 

ASR rules

E-mail and Webmail

Block executable content from email client and webmail

Microsoft Office

Block all Office applications from creating child processes

Block Office applications from creating executable content

Block Office applications from injecting code into other processes

Block Win32 API calls from Office macros

Block Office communication application from creating child processes

Executables and Scripts

Block JavaScript or VBScript from launching downloaded executable content

Block execution of potentially obfuscated scripts

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Use advanced protection against ransomware

3rd Party Apps

Block Adobe Reader from creating child processes

Windows Credentials

Block credential stealing from the Windows local security authority subsystem

Windows Management Interface (WMI)

Block process creations originating from PSExec and WMI commands

Block persistence through WMI event subscription (Requires Windows 10 version 1903)

Device Control

Block untrusted and unsigned processes that run from USB

 

 

#7 What rules to enable? All!? Or can I turn on individual rules?

No, you don’t need to enable all ASR rules. You can turn on rules individually to meet your needs.

To help you figure out what’s best for your environment, we highly recommended that you enable ASR rules in audit mode. With this approach, you’ll be able to determine the possible impact on your organization, e.g. your line-of-business applications.

 

Sadly, many line-of-business applications were written with limited security concerns, and they might perform tasks that resemble malware or malicious activity.

 

By monitoring audit data and adding exclusions for necessary applications, you can deploy ASR rules without impacting productivity.

 

To sum it up, Audit mode allows you to make a more informed decision, about which rules you will effectively enable. We’ll further explore this in the next future series of this blog.

 

#8 What are the rules Microsoft recommends enabling?

This is actually a tricky one… the answer is: it depends!

 

We created ASR rules leveraging data insights on the most common attacked areas and what areas we know can be commonly thwarted to compromise an organization.

 

With that said, you might have a follow-up question: why doesn’t Microsoft prevent that from happening from the very beginning?

 

Well, Office macros is a good example.

Do we love them? No! They are a security nightmare…

Do we need them? Yes!

 

We have millions of customers that still dearly depend on Office macros to run their businesses. It’s not a simple decision for an organization to enforce or determine that, starting tomorrow, all macros won’t be ever be able to, create a child process, for example. But what if you don’t allow macros at all in your environment (e.g. disable VBA and macros all together)? Then the ASR rules related to these scenarios probably will have very little meaning in your environment.

 

Hopefully you’ll now understand why the answer is, “it depends”.

 

Overall, we recommend enabling every possible rule. Nevertheless, there are some clear cut cases where you shouldn’t enable a rule. For example, we do not recommend enabling the Block process creations originating from PSExec and WMI commands rule, if you’re using Microsoft Endpoint Configuration Manager (or, System Center Configuration Manager - SCCM) to manage your endpoints.

 

We highly recommend you reading each rule specific information and/or warnings, which are available in our public documentation.

 

Here’s the specific warning that is called out for the example given above:

 

ASR_Part1_Warning.png

 

 

OK! That’s a wrap for the first blog post in this series on attack surface reduction rules! Stay tuned for more in the coming weeks. If you want to come back and view all the blogs in this series, you can follow it here.

 

See you soon!

 

António Vasconcelos and Rob Mallicoat

Program Managers @ Microsoft Defender ATP Product Group

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.