When deploying attack surface reduction rules, it's important we follow a methodical and careful release schedule including four distinct steps: plan, test, implement, and operationalize. Let's take a look at each of these steps in more detail. Phase one is the Plan step. Here we want to start with the right business unit, and identify some ASR champions within that unit who can provide real world impact to the ASR rules and help tune the implementation. These champions will help with the initial rules rollout and provide preliminary testing feedback.

Champions are typically employees who are more technically adept and are not derailed by temporary work stoppages. In addition, during the plan phase, we will identify line of business apps, and business processes used across the organization. We want to understand how these apps are used with various business units, and get an inventory of the apps that are approved for use across the entire organization. The last part of the plan phase is to define reporting and response team roles and responsibilities. These are the people that will help monitor and communicate ASR rule status and activity. They will need to gather reports, share them appropriately with the right team members, and escalate when necessary. It is recommended to deploy ASR rules in 'rings', where each ring represents groups of devices. We work our way from the smallest inner ring to the largest outer ring, only transitioning to the next ring once the inner one has been successfully deployed.

The second phase is Test. Here we will begin turning on the ASR rules with the rules set to Audit. This will start with our ASR champion users or devices in the innermost ring. It is recommended to enable all the rules in Audit, so we can determine which ones are triggering during testing. Next we will use the reporting page in the Microsoft Defender portal to understand what actions have triggered a rule. We can sort, filter, and search these issues to understand what apps might be causing an issue. Once we've identified our issues, we can add exclusions as necessary.

Phase three is to Implement. This moves our rings from testing into a functional state. To do this, we transition the ASR rules from audit to block, typically starting with the rule that has the fewest trigger events. When available, we want to take advantage of Warn mode setting, which will help limit disruptions. Once the inner ring is deployed, we will start to move outward to the next ring following the same protocol of audit mode first, then implement. If problematic rules arise, we can shift them back to audit or add exclusions while we debug.

Phase four is Operationalize. At this point we have fully deployed ASR rules and should have a process in place to monitor and respond to ASR related activities. These include managing false positives, keeping up with reports, and hunting, a process of using queries to dig into ASR reporting. This will help us better understand the threat landscape and continue to refine our rules to address the needs of the organization and devices.