BIPI
BIPI

Defender for Cloud has 1200 recommendations. Here's how to find the 30 that matter.

Cloud Security

Azure Defender for Cloud surfaces every misconfiguration with equal urgency, including the ones that do not apply to your environment. Without scoping and suppression you cannot ship the actually-important fixes.

By Arjun Raghavan, Security & Systems Lead, BIPI · March 24, 2024 · 7 min read

#azure#defender#cloud-security

An insurance client showed us their Defender for Cloud dashboard: 1247 active recommendations, secure score 38%, and a security team that had stopped looking at the tool. The recommendations included 'Enable JIT VM access' on a VM scale set that did not need access at all, and 'MFA should be enabled on accounts with owner permissions' on a service principal that does not have a person behind it. The signal was buried under recommendations that did not apply.

Defender for Cloud is not designed to be consumed raw. It is designed to be scoped, suppressed, and prioritised by exploitability. The teams that do that pay attention to it; the teams that do not stop looking.

Scope by management group, not subscription

Treat the management group hierarchy the same way you treat AWS OUs. Production, non-production, sandbox, and platform should each have their own Defender baseline. The 'do not assess' policies for sandbox should disable cost-driven plans like Defender for Servers and ratchet the recommendation set to a minimum. Production gets the full plan and the strict baseline. We see secure scores climb 15-25 points just by removing sandbox noise from the production view.

Suppression rules with a life span

Every suppression rule we create has an expiration date, a reason field, and a tag for the workload it covers. The expiration is rarely longer than 90 days. When it lapses, the suppression returns and either the recommendation has been remediated by then or it gets re-suppressed with a fresh justification. Permanent suppressions exist only for environmental truths, like a public IP on a load balancer that is supposed to be public.

Prioritise by exploitability, not severity

The Defender severity is calibrated for a generic environment. Two recommendations marked High can have wildly different real-world risk: a public-facing VM with an unpatched CVE versus an internal storage account with an old TLS version. Use the Attack Path Analysis view in Defender CSPM to find the chains where a low-severity recommendation feeds a high-severity one. Those are the fixes worth shipping this sprint.

12%
of recommendations typically map to a real attack path
60%
are in-scope for the environment but low real-world risk
28%
are out-of-scope: deprecated services, sandbox resources, or false positives

The recommendations to action first

Public-facing resources with high-severity unpatched CVEs. Storage accounts with public anonymous access enabled. Key Vaults without firewall rules. Subscription owner roles with unenforced MFA. Service principals with no expiration on credentials. Network security groups with port 22 or 3389 open to 0.0.0.0/0. Defender's own configuration drift, where Defender plans were disabled at the subscription level.

  • Public-facing resources with active CVEs in the Microsoft Threat Intelligence feed
  • Storage accounts and Key Vaults exposed to all networks
  • Privileged role assignments without MFA conditional access
  • Service principal credentials older than 12 months
  • Network rules permitting management ports from the internet
  • Disabled Defender plans on production subscriptions

Recommendations to accept the risk on

Some recommendations are correct in the abstract but expensive to satisfy and low-impact in your environment. 'Network traffic data collection agent should be installed on Linux virtual machines' adds a paid agent to every VM for marginal additional visibility once you already have NSG flow logs. 'Diagnostic logs in App Service should be enabled' on a stack of staging apps generates noise nobody reads. Document the acceptance, suppress with an expiry, and move on.

Pipe to the SIEM, not to the email digest

Defender's email digest is unreadable above 50 recommendations. Stream the alerts and recommendations into Sentinel via the data connector and write workbooks that filter by your scoping criteria. The team that owns the workload sees only the recommendations for their resources, the security team sees the org view, and the executive dashboard shows secure score trend by management group. Each audience gets a useful view of the same underlying data.

Defender for Cloud rewards investment in tuning. The clients who do that work get an opinionated, attack-path-aware view of their Azure posture. The ones who do not have a 1200-item to-do list nobody will ever finish.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.