Derivation rules

Write the Defender pricing tier for a subscription (Microsoft.Security/pricings/write); setting any plan to 'Free' disables threat-detection for that resource type subscription-wide. This blinds Defender without altering any resource access controls.

Write Defender for Cloud security contacts (Microsoft.Security/securityContacts/write); removing or replacing email/phone recipients silences external alert notification delivery out-of-band from the Azure portal, reducing off-portal incident-response triggers.

Create or modify a Defender for Cloud alert suppression rule (Microsoft.Security/ alertsSuppressionRules/write); suppressed alert types are auto-dismissed before analysts see them, reducing SOC visibility into the suppressed attack patterns.

Delete an action group, silencing the response actions (email, SMS, webhook, Azure Function, Logic App, Automation Runbook) for ALL alert rules that reference it - a high-blast-radius evasion against automated incident response.

Delete an activity log alert rule, silencing automated detection triggered by Azure Resource Manager (ARM) control-plane events (resource creation, deletion, policy changes, role assignments). Activity log alerts are distinct from scheduled-query and metric alerts, on their own ARM resource type.

Delete a metric alert rule, silencing automated detection triggered by metric thresholds (CPU, memory, network, custom metrics). Metric alerts fire independently of log-search alerts and are on distinct ARM resource types.

Delete a scheduled query (log search) alert rule, silencing automated detection based on KQL log queries - disables alerting on specific threat patterns or compliance baselines.

Delete Sentinel analytics rules to silence specific threat detections (defense evasion - disable alerting for attack techniques).

Disable or modify Sentinel analytics rules to suppress alerts for specific TTPs (defense evasion).

Modify Sentinel automation rules to suppress automated incident response or redirect handling to an attacker-controlled playbook.

Delete a Sentinel data connector to stop ingestion from a specific data source, creating a blind spot.

Principal with securitycenter.settings.update can disable SCC detection services at org or project scope, permanently stopping finding generation for the disabled services.

Principal holds effective securitycenter.assets.list permission (recon-only read).

Principal holds effective securitycenter.findings.setState or .setMute permission.

Principal holds effective securitycenter.muteconfigs.create or .update permission.

Principal holds effective securitycenter.notificationconfigs.delete permission to delete notification routing configs.

Principal holds effective securitycenter.notificationconfigs.update permission to modify notification routing.

Principal holds effective securitycenter.findings.list permission (recon-only read).

Principal holds effective securitycenter.settings.update permission at org or project scope.

Principal with securitycenter.muteconfigs.create or .update can create or modify a mute config that auto-suppresses matching SCC findings, silencing targeted detection signals while SCC appears operational.

Principal with securitycenter.findings.setState or findings.setMute can individually mark findings as INACTIVE or MUTED, removing them from the active queue without a rule-based mute config.

Principal with securitycenter.notificationconfigs.delete or .update can delete or modify notification configs that route SCC findings to external systems (SIEM, SOAR, ticketing), disrupting the downstream alerting pipeline.

Principal with both securitycenter.findings.list and securitycenter.assets.list can enumerate all SCC findings and the full GCP asset inventory, providing complete org-wide resource reconnaissance.

Principal with securitycenter.findings.list can enumerate all SCC findings across their scope, revealing exploitable misconfigurations.