Planning for Device Compliance
Planning for Attack Surface Reduction
Configuring Security Baselines
The course is part of these learning pathsSee 3 more
This course explores the suite of tools available in Microsoft Endpoint Manager for establishing and maintaining security posture in an organization. These include tools like Microsoft Intune, used for enrolling devices as well as creating and enforcing device compliance, and Microsoft Defender, used for implementing device antivirus and malware defense tools. This course will also review the activities involved in reducing attack surfaces in an organization that bad actors could use to penetrate and expose sensitive data. This sensitive data is protected through the implementation of attack surface reduction rules which are deployed through careful auditing and testing to prevent any loss of productivity. This course will also touch on the security baselines made available to organizations wishing to enact a more granular security posture and have access to tools like secure score for evaluating the effectiveness of these efforts against known best practices.
- Create a compliance policy
- Monitor enrolled devices
- Setup surface attack reduction rules
- Deploy surface attack reduction rules
- Review security baselines
- Examine Microsoft secure score
This course is designed for individuals who are responsible for setting up and monitoring device compliance and security in Microsoft 365 as well as those pursuing Microsoft certifications.
To get the most from this course, you should have some familiarity and experience with the Microsoft 365 security suite of tools including Microsoft Endpoint Manager.
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.
Steve is an experienced Solutions Architect with over 10 years of experience serving customers in the data and data engineering space. He has a proven track record of delivering solutions across a broad range of business areas that increase overall satisfaction and retention. He has worked across many industries, both public and private, and found many ways to drive the use of data and business intelligence tools to achieve business objectives. He is a persuasive communicator, presenter, and quite effective at building productive working relationships across all levels in the organization based on collegiality, transparency, and trust.