Unboxing Defender for Business, Part 3: Attack Surface Reduction rules

If you haven’t been following this series, let me catch you up. First, understand that Microsoft recently made a huge announcement: their enterprise-class endpoint security solution, known as Microsoft Defender for Endpoint, has been re-packaged and released for the SMB (and included in the popular Microsoft 365 Business Premium SKU) under the name Microsoft Defender for Business.

Third-party endpoint security vendors are on notice. Why buy an EDR tool again if you already have one included in your normal productivity suite? Oh and it integrates with all of your other software and every major device platform. Oh and it consistently leads in the Gartner magic quadrant, too. Yeah, that’s why it was a huge announcement.

So far in the series exploring this massive product, we have covered the initial set up with the so-called “Simplified configuration process,” and then we followed it up with a look at Threat & Vulnerability Management (TVM). In this article, we will examine Attack surface reduction (ASR) rules.

What are Attack Surface Reduction rules?

ASR rules help us to prevent bad things from happening in the first place. We do this by shutting down or blocking specific functionality that most information workers do not need in order to do their daily jobs. Most of these rules exist because of the techniques used in the wild by attackers to gain unauthorized access, steal credentials, establish persistence, etc. If there are holes we can plug up simply by disabling some of these commonly exploited features, and we can do it without impacting productivity, then that is what we call an all-around Good Idea.

Now I would love to tell you that we have a “simplified” configuration wizard for ASR rules with Defender for Business. Alas, not so. Not yet, anyway. I suspect that sometime in the future, we will find ASR rules in the Microsoft 365 Defender security center, under Endpoints > Device configuration, where we currently find the policies for Next-generation protection and  Firewall settings. For now, you access and deploy these policies the same way you would in Defender for Endpoint: via Microsoft Endpoint Manager.

Step 1. Configure an ASR audit policy

From Endpoint security > Attack surface reduction click Create Policy.

Selecting Windows 10 and later as your Platform, you will notice that we have multiple Profile types (more on the others later), but for now just choose Attack surface reduction rules and click Create.

Give the policy a name such as “Company ASR rules” and (optionally) a description. Then proceed to the Configuration settings page. Read through each rule to get an idea of what types of behaviors the ASR rules cover (and see this reference for more details). It is recommended to start your deployment by placing each rule into Audit mode.*

*Note: I just learned that one of these rules is soon going to be enabled by default: Block credential stealing from the local security authority subsystem (lsass.exe). This is great news, since lsass.exe controls access to the area in memory where credentials are stored: a prime target for attackers. You may consider enabling this one right away as well.

Proceed through to the Assignments page, and make your desired assignment (I chose All devices in this example).

Review and create your policy on the last page.

Step 2. Monitoring ASR rules with TVM

One way to monitor the ASR rules is to use Threat & Vulnerability Management. From the Microsoft 365 security center (https://security.microsoft.com), go to the Vulnerability management > Recommendations page. Find the Filter option.

Expand Security controls and choose Attack surface reduction, then click Apply.

Choose any of the rules (in this example I picked Block JavaScript or VBScript from launching downloaded executable content), and then scroll down to find the User impact section.

TVM will use telemetry from the devices reporting in, to tell you whether there will be an expected user impact by enabling the rule in question. (Note: Devices must be onboarded to MDB and have Real-time protection enabled for this to work, plus it can take awhile to collect the telemetry, so you may need to give it some more time).

From here you can choose to open a Remediation request, for either all exposed devices or just the ones with no expected user impact.

These requests go to Microsoft Endpoint Manager, where they can be assigned to a technician (I encourage you explore these features on your own; use the Tutorials as I mentioned in the previous article).

Step 3. Switch rules to Block mode as appropriate

As you are able to confirm the relative safety of enabling these rules without negative user impact, go back to Endpoint Manager, and edit your ASR rules to Enable or Block mode as appropriate.

Now of course you may end up with a situation where certain devices need to be excluded from the “Block” policy, and then you would need to manage separate policies in that case (some set for Audit and others set to Block). In the future, we expect “per-rule” exceptions will be possible, hopefully reducing the number of policies you need to manage. For now, just rinse and repeat the process as needed any of the rules that have been identified as safe to enable.

Other notes

In the Enterprise subscription, there is an additional monitoring capability for ASR rules (usually found under Reports), but it appears this feature is not yet available for the Business subscription. The reporting feature allows us to more easily identify what exceptions could be made for those devices which TVM reports as having “expected user impact.” (Note: I suspect that we will have this report included with MDB before the product reaches GA).

The ASR rules are just one piece of the Attack Surface Reduction features included with Microsoft Defender for Business, but they are the absolute best place to start for the vast majority of organizations out there. Other ASR strategies like Device Control, Application Guard, and Application Control may be of interest to some businesses with specific requirements, but almost everyone can benefit from implementing ASR rules immediately.

Therefore, I would suggest that everyone who has access to the MDB preview start piloting the ASR experience as it exists today, and at least reduce your attack surface where TVM identifies no expected user impact.