Most organizations rely on industry-standard baselines like CIS or STIG to secure their endpoints—but these out-of-the-box policies often don’t align perfectly with the real-world needs of diverse environments. That’s where custom security baselines come in.

In this post, I’ll walk you through how I create and implement custom security baselines in Microsoft Defender for Endpoint (MDE)—the same way we do in enterprise environments. Whether you're a security analyst, compliance lead, or IT engineer, you'll find real XML examples, baseline tuning techniques, and KQL validation methods that will help you strike the right balance between security and stability.

🧩 Step-by-Step: How I Build a Custom Security Baseline in MDE

Creating a tailored security baseline involves more than just downloading templates. Here’s my real-world workflow—one I’ve used with enterprise clients to align configurations with both compliance standards and operational practicality.

✅ 1. Download the Default Baseline

Start with Microsoft’s official MDE security baseline from their GitHub repository. It typically includes:

xccdf file: Defines the configuration rules
oval file: Describes the conditions under which rules apply
README: Provides implementation and deployment guidance

📦 These XML files form the foundation of your baseline logic.

✅ 2. Identify Irrelevant or Break-Prone Rules

Not all default rules will fit your environment. I usually:

Run a test deployment in a sandbox VM
Monitor for performance degradation, conflicting policies, or feature breakage
Collaborate with compliance teams to apply waivers or exceptions

🧠 Example: Disabling SMBv1 is critical, but disabling all legacy TLS versions might break internally hosted applications or legacy endpoints.

✅ 3. Edit the xccdf Rules to Fit Your Environment

Open the .xccdf.xml file using a text editor like Visual Studio Code. You'll see structured rule definitions like:

<xccdf:Rule id="Ensure-SMBv1-Disabled">
  <xccdf:title>Ensure SMBv1 is Disabled</xccdf:title>
  <xccdf:description>Disable the SMBv1 protocol to reduce attack surface.</xccdf:description>
  <xccdf:fix>Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol</xccdf:fix>
</xccdf:Rule>

🔧 You can modify the <xccdf:fix> command to suit your systems, or comment out the rule if it causes conflicts.

✅ 4. Test in a Controlled Lab Environment

Before deploying across the org, I always:

Use an isolated VM or pilot group for testing
Monitor the system using Microsoft Defender logs
Validate changes using KQL queries (covered below)

🛡️ Bonus Tip: Use Attack Surface Reduction (ASR) logs in Defender to detect blocked behavior related to your new baseline.

✅ 5. Package and Deploy via Intune or Group Policy

Once the baseline passes lab validation:

Package the updated XML for deployment
Use Microsoft Endpoint Manager (Intune) or Group Policy for rollout
Follow a phased deployment: pilot group → department → full org

🧩 If you're managing infra-as-code, integrate this step into Azure DevOps pipelines for automated compliance enforcement.

🧪 Validating the Baseline Using KQL (Kusto Query Language)

After deployment, the job isn’t over. You need to verify that your baseline is functioning correctly, and identify any drift or misconfiguration. For that, I use KQL queries in Microsoft Defender and Azure Sentinel.

✅ Common Validation Queries

🔍 Check if a Policy Was Successfully Applied

DeviceEvents
| where ActionType == "PolicyChanged"
| where AdditionalFields contains "SMBv1"

💡 This shows if your SMBv1 rule was triggered and applied successfully across devices.

🔎 Detect Failed Policy Applications

DeviceEvents
| where ActionType == "PolicyApplicationFailed"
| project Timestamp, DeviceName, AdditionalFields

💡 Use this to identify endpoints where your config couldn’t be applied.

🧪 Check Compliance Status of Critical Rules

DeviceTvmSecureConfigurationAssessment
| where ConfigurationId == "Ensure-SMBv1-Disabled"
| project DeviceName, AssessedTime, ConfigurationValue, ExpectedValue, IsCompliant

💡 This query tracks the compliance state of the SMBv1 rule over time.

⚙️ Combine With Alerts & Automation

You can go beyond manual checks by:

Triggering alerts for non-compliance using Defender’s alerting engine
Visualizing results in Power BI dashboards
Embedding queries in Azure Workbooks for scheduled compliance audits

✅ This KQL-based validation step helps you catch silent failures early and prove that your secure configurations are being enforced—not just assumed.

🔚 Conclusion

Custom baselines give you the power to enforce security without breaking your business-critical apps. Microsoft Defender for Endpoint offers an incredibly flexible framework to help you do this—if you know how to tweak it.

By editing xccdf and oval files, testing rigorously, and validating through KQL and PowerBI, you’re no longer just applying policies. You’re building a resilient, transparent, and compliant security posture.

💬 Have questions about MDE, baselines, or KQL?
Leave a comment below or connect with me on LinkedIn – I'm happy to help you build more secure systems.

🔔 Follow @cybershiv for real-world cybersecurity tutorials, red teaming insights, and cloud security tips from the trenches.

💛 Enjoyed this guide? Support my work here → BuyMeACoffee.com/cybershiv

🔐 How to Build a Custom Security Baseline in Microsoft Defender for Endpoint (MDE)