No Alert for Security Solution Changes in Azure

Security tooling only protects you while it is running. The moment someone disables a security solution, deletes a connector, or swaps out a partner integration, your defensive coverage drops, and the worst time to learn about that is during an incident. This Lensix check verifies that your Azure subscription has an activity log alert watching for security solution changes so that those events do not slip by silently.

---

What this check detects

The activitylog_nosecuritysolution check inspects your Azure subscription for an activity log alert rule that fires when a security solution is created, updated, or deleted. Specifically, it looks for an alert scoped to the operation:

Microsoft.Security/securitySolutions/write

Security solutions in Azure are the partner and first-party security products registered against your subscription. These include integrations like web application firewalls, antimalware offerings, and third-party tools onboarded through Microsoft Defender for Cloud. When one of these is modified or removed, an entry lands in the Azure Activity Log. The problem is that an entry in a log nobody is watching is not much of a control.

If no alert rule exists for this operation, the check fails. It is a monitoring gap rather than a direct misconfiguration of a resource, but the downstream risk is just as real.

---

Why it matters

Disabling or tampering with security tooling is a classic step in an attacker's playbook. It maps directly to the MITRE ATT&CK technique Impair Defenses (T1562). An adversary who gains control plane access wants to reduce the chance of detection, and turning off the very products designed to catch them is an efficient way to do that.

Consider a few scenarios:

• Attacker with compromised credentials. A phished or leaked service principal with Contributor rights removes a security solution to blind your detection pipeline before moving laterally. With no alert, the change goes unnoticed for days.
• Insider risk. A disgruntled or careless engineer deletes a partner WAF integration to "fix" a connectivity issue, leaving an application exposed. Nobody flags it until traffic anomalies surface much later.
• Accidental drift. A misconfigured automation script or a Terraform run with stale state deletes a security solution that was added manually. Without an alert, the gap persists silently.

The business impact compounds because the absence of monitoring delays detection. Faster detection shrinks dwell time, and dwell time is one of the strongest predictors of breach cost. There is also a compliance angle: frameworks like the CIS Microsoft Azure Foundations Benchmark and several SOC 2 and ISO 27001 controls expect monitoring of changes to security configuration. A missing alert here is an audit finding waiting to happen.

---

How to fix it

You need to create an activity log alert that watches the security solution write operation and routes it to an action group so a human or automated workflow actually gets notified. Here is how to do it across the portal, CLI, and infrastructure as code.

Step 1: Create an action group

An action group defines who gets notified and how. If you already have one, skip to the next step and reuse its name.

az monitor action-group create \
  --name "security-alerts-ag" \
  --resource-group "monitoring-rg" \
  --short-name "SecAlerts" \
  --action email security-team [email protected]

Step 2: Create the activity log alert

Now create the alert rule scoped to your subscription, filtered on the security solution write operation, and linked to the action group.

az monitor activity-log alert create \
  --name "alert-security-solution-changes" \
  --resource-group "monitoring-rg" \
  --scope "/subscriptions/<subscription-id>" \
  --condition category=Administrative and operationName=Microsoft.Security/securitySolutions/write \
  --action-group "security-alerts-ag" \
  --description "Alert when a security solution is created, updated, or deleted"

Replace <subscription-id> with your actual subscription ID. The category=Administrative condition ensures you are matching control plane operations.

Step 3: Configure it in the Azure Portal

If you prefer the console:

1. Open Monitor in the Azure Portal.
2. Go to Alerts, then select Create, then Alert rule.
3. Set the scope to your subscription.
4. Under Condition, choose the Activity Log signal type and search for the Create or Update Security Solutions operation.
5. Attach an existing action group or create a new one.
6. Name the rule and create it.

Step 4: Define it as code with Terraform

For repeatable, version-controlled deployments, define the alert in Terraform so it travels with the rest of your subscription baseline.

resource "azurerm_monitor_action_group" "security_alerts" {
  name                = "security-alerts-ag"
  resource_group_name = "monitoring-rg"
  short_name          = "SecAlerts"

  email_receiver {
    name          = "security-team"
    email_address = "[email protected]"
  }
}

resource "azurerm_monitor_activity_log_alert" "security_solution_changes" {
  name                = "alert-security-solution-changes"
  resource_group_name = "monitoring-rg"
  scopes              = ["/subscriptions/${var.subscription_id}"]
  description         = "Alert when a security solution is created, updated, or deleted"

  criteria {
    category       = "Administrative"
    operation_name = "Microsoft.Security/securitySolutions/write"
  }

  action {
    action_group_id = azurerm_monitor_action_group.security_alerts.id
  }
}

Step 5: Verify the alert exists

az monitor activity-log alert list \
  --resource-group "monitoring-rg" \
  --query "[?contains(condition.allOf[].equals, 'Microsoft.Security/securitySolutions/write')].name" \
  --output table

Re-run the Lensix check after deployment to confirm the finding clears.

---

How to prevent it from happening again

Fixing the alert once is good. Making sure it can never silently go missing again is better. A few approaches scale well.

Bake it into your subscription baseline

Every new subscription should inherit a standard set of activity log alerts, including this one. Put the Terraform module above into a shared subscription bootstrap module that every team applies. When a new subscription is provisioned, the alert comes with it by default.

Enforce with Azure Policy

Azure Policy can audit and even deploy activity log alerts using the DeployIfNotExists effect. This automatically creates the alert on subscriptions that lack it, closing the gap without manual intervention.

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Resources/subscriptions"
  },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Insights/activityLogAlerts",
      "existenceCondition": {
        "field": "Microsoft.Insights/activityLogAlerts/condition.allOf[*].equals",
        "equals": "Microsoft.Security/securitySolutions/write"
      },
      "roleDefinitionIds": [
        "/providers/Microsoft.Authorization/roleDefinitions/749f88d5-cbae-40b8-bcfc-e573ddc772fa"
      ]
    }
  }
}

Gate it in CI/CD

If your subscriptions are managed through pipelines, add a policy-as-code step that fails the build when the alert definition is missing from the plan. Tools like Checkov, OPA/Conftest, or a simple terraform plan assertion can block a merge that would drop the alert. Pair this with a scheduled Lensix scan so drift introduced outside the pipeline still gets caught.

---

Best practices

This single alert is part of a broader monitoring discipline. To get the most value, layer it into a wider strategy.

• Cover the full set of security-relevant operations. Beyond security solutions, alert on changes to network security groups, NSG rules, security policies, firewall rules, and policy assignments. Together they form a tripwire across your security posture.
• Route alerts to a real destination. An action group that emails a shared mailbox nobody reads is theater. Wire alerts into your incident tooling, such as PagerDuty, Opsgenie, or a Teams channel with ownership, so someone is accountable for triage.
• Test your alerts. Periodically make a benign change in a non-production subscription and confirm the alert fires end to end. Untested alerting fails silently exactly when you depend on it.
• Apply at the right scope. For organizations with many subscriptions, consider whether management group level monitoring through Defender for Cloud and centralized Log Analytics gives you better coverage than per-subscription alerts alone.
• Document the response. When this alert fires, responders should know what a legitimate security solution change looks like versus a suspicious one. A short runbook turns a notification into a fast decision.

Monitoring changes to your security tooling is a low-effort, high-value control. It costs almost nothing to run, it integrates cleanly with infrastructure as code, and it gives you early warning the moment your defenses are touched. Set it up once, enforce it everywhere, and let Lensix confirm it stays in place.