Defender in Intune: dedicated policies instead of a baseline

Security baselines are the recommended starting point, and for a while that is exactly what they are. This chapter is about what happened after one of them quietly stopped a BitLocker policy from applying — and what replaced it.

Why not the baseline

	Security baseline	Dedicated policies
Initial setup	Fast — everything preconfigured	Slower
Transparency	Opaque: hundreds of implicit settings	You know where every setting comes from
Conflicts	Frequent, and silent	Visible before you create them
Changing or removing	Not always effective	Immediate

The decisive experience: a BitLocker policy was not applying because the Defender baseline configured the same settings differently. Intune marks those settings Conflict and applies neither — no error, no warning, the device just keeps the Windows default.

Removing the BitLocker section from the baseline was not enough. The conflict survived hours and several check-ins. It cleared only after deleting the baseline entirely.

The rule adopted: one policy per function. More verbose to set up, but you always know which policy owns a setting, and conflicts become visible before they exist rather than after.

A — Defender Antivirus

Endpoint security → Antivirus → Microsoft Defender Antivirus.

Setting	Value
Allow Realtime Monitoring	Allowed
Allow Cloud Protection	Allowed
Cloud Block Level	High
Cloud Extended Timeout	50
Allow Behavior Monitoring	Allowed
Allow Script Scanning	Allowed
Submit Samples Consent	Send safe samples automatically
Signature Update Interval	4 hours
Schedule Quick Scan Time	120 (02:00)
Disable Local Admin Merge	Disable Local Admin Merge
PUA Protection	PUA Protection on. Detected items are blocked

Two of these deserve an explanation.

PUA Protection blocks adware, toolbars, installer bundles and cryptominers: categories the antivirus otherwise lets through because they are not malware in the strict sense. Good ratio of benefit to nuisance.

B — Attack Surface Reduction, in Audit

Endpoint security → Attack surface reduction → Attack Surface Reduction Rules.

ASR rules do not use signatures. They block behaviours that malware relies on almost always and legitimate software almost never — Office spawning a child process, a macro calling the Win32 API, a script reading credentials out of LSASS.

The rules configured, all in Audit:

• Executable content from email and webmail
• Office child processes · Office executable content · Office code injection
• JavaScript and VBScript launching downloaded executables
• Obfuscated scripts
• Win32 API calls from Office macros
• Credential stealing from LSASS
• Unsigned processes running from USB
• Persistence through WMI
• Advanced ransomware protection

Plan to revisit the audit logs after roughly two weeks, and promote to Block the rules that never fired against anything legitimate.

C — Firewall profile

Endpoint security → Firewall → Windows Firewall.

Setting	Value
Enable Domain Network Firewall	True
Enable Private Network Firewall	True
Enable Public Network Firewall	True
Everything else	Not configured

Also left unconfigured: VM Creator Id, Auditing (very verbose logs), Network List Manager.

The guiding principle

Configure as little as possible.

Every setting you specify is one more thing that can conflict or behave unexpectedly. Not configured means “leave the Windows default”, which in most cases is sensible — and, more importantly, predictable.

That is the real argument against baselines. Not that their defaults are wrong, but that there are hundreds of them, you did not choose them individually, and when one of them collides with something you did choose, nothing tells you.

Still to do

• After roughly two weeks, review the ASR logs and promote the clean rules to Block.
• Consider Defender for Business onboarding — EDR and vulnerability management, already included in the licence.
• Consider Windows Hello for Business, to move away from passwords entirely.