Adding Custom Standards to Defender

Lesson: Mastering Custom Standards in Microsoft Defender for Cloud

Introduction: Why Custom Standards Matter

In the landscape of modern cloud infrastructure, security is rarely a "one-size-fits-all" endeavor. While Microsoft provides excellent baseline security frameworks—such as the Microsoft Cloud Security Benchmark (MCSB)—these are designed to cover the widest possible range of organizational needs. They function as a foundational starting point, ensuring your resources meet general industry best practices. However, your organization likely operates under unique regulatory requirements, internal governance policies, or specific operational constraints that these general benchmarks simply cannot address out of the box.

This is where the concept of "Custom Standards" in Microsoft Defender for Cloud becomes essential. By creating and applying custom standards, you bridge the gap between generic security recommendations and your specific business requirements. Whether you need to enforce a naming convention, ensure that specific encryption standards are met, or mandate the presence of specific tags for cost-tracking and ownership, custom standards allow you to codify your organization’s security policy directly into the cloud management plane.

Understanding how to build, deploy, and manage these standards is a critical skill for any cloud security engineer. It transforms Defender for Cloud from a passive monitoring tool into an active enforcement engine. When you take control of your security posture through custom standards, you reduce the risk of configuration drift, simplify compliance audits, and ensure that every resource deployed in your environment aligns with your internal security mandate.

Understanding the Architecture of Security Standards

Before we dive into the creation of custom standards, it is important to understand how Defender for Cloud organizes security policies. At the core of this system are three primary components: Policy Definitions, Initiatives (Policy Sets), and Assignments.

Policy Definitions

Policy definitions are the building blocks. A policy definition is a JSON document that describes a specific rule—for example, "Ensure all storage accounts disable public network access." These rules define the "what" of your security posture. They contain the logic that evaluates a resource to see if it is compliant or non-compliant.

Initiatives (Policy Sets)

An initiative is a collection of policy definitions grouped together to achieve a specific goal. If a policy is a single rule, an initiative is a compliance framework. When you see "ISO 27001" or "PCI-DSS" in Defender for Cloud, you are looking at a large-scale initiative composed of dozens or hundreds of individual policy definitions.

Assignments

An assignment is the action of applying an initiative or a policy to a specific scope, such as a subscription or a management group. You cannot evaluate resources against a policy until that policy has been assigned to a scope. Custom standards are essentially custom initiatives that you create and assign to your environment.

Callout: Policy vs. Initiative Think of a Policy as a single traffic law, such as "Stop at red lights." Think of an Initiative as the entire traffic code book, which includes all the rules for a specific jurisdiction. You build custom standards by creating a custom initiative and then adding the specific, relevant policy definitions that matter to your organization.

Step-by-Step: Creating a Custom Security Standard

Creating a custom standard is a structured process that begins in the Azure Policy service and is then surfaced through the Defender for Cloud dashboard. Follow these steps to build your own custom security standard.

Step 1: Define the Requirement

Before touching the Azure portal, clearly define what you want to achieve. A common requirement is to ensure that all Virtual Machines have a specific tag, such as "Environment: Production." Without a clear requirement, you risk creating "noisy" policies that generate alerts for resources that don't actually need to adhere to the rule.

Step 2: Create a Custom Policy Definition

1. Navigate to the Azure Policy service in the Azure Portal.
2. Select Definitions from the sidebar.
3. Click + Policy definition.
4. Choose the Definition location (usually a management group for better visibility).
5. Provide a name and description for your policy.
6. In the Policy rule section, use the JSON editor to define the logic.

Here is an example of a policy definition that checks if a resource has a specific tag:

{
  "if": {
    "field": "tags['Environment']",
    "exists": "false"
  },
  "then": {
    "effect": "audit"
  }
}

This policy checks if the "Environment" tag is missing. If it is, the policy triggers an "audit" effect, which flags the resource as non-compliant in your Defender for Cloud dashboard without actually blocking the deployment.

Step 3: Create a Custom Initiative

Once you have your policy definitions, you need to group them into an initiative.

1. In the Azure Policy service, select Definitions.
2. Click + Initiative definition.
3. Choose the scope where the initiative should live.
4. Give it a name, such as "Corporate Tagging Standard."
5. In the Policies tab, click Add policy definition and select the custom policy you created in Step 2.

Step 4: Assign the Initiative

1. Go to the Assignments section in Azure Policy.
2. Click Assign initiative.
3. Select the scope (e.g., your production subscription).
4. Review and create the assignment.

Once assigned, Defender for Cloud will begin evaluating your resources against this new standard. It may take up to 30 minutes for the initial evaluation to complete and reflect in the Security Posture dashboard.

Advanced Policy Logic: Using Parameters

Hardcoding values into your policies makes them rigid and difficult to manage at scale. Instead, use parameters to make your policies reusable. By using parameters, you can define the logic of a policy once and then supply different values for different environments.

For example, instead of hardcoding "Environment: Production," you can create a parameter for the tag name and the tag value.

"parameters": {
  "tagName": {
    "type": "String",
    "metadata": {
      "displayName": "Tag Name",
      "description": "The name of the tag to enforce."
    }
  }
}

When you use parameters, you define the "what" in the policy rule and the "which" in the assignment. This allows you to assign the same policy to your Dev environment (looking for "Environment: Dev") and your Prod environment (looking for "Environment: Prod") using a single, unified policy definition.

Note: Always prioritize using built-in policies before creating custom ones. Microsoft updates their built-in policies frequently to account for new Azure features. If you create a custom policy, you become responsible for maintaining it as Azure services evolve.

Integrating Custom Standards into Defender for Cloud

Once your custom initiative is assigned, it won't automatically appear in the Defender for Cloud "Regulatory Compliance" dashboard. You must explicitly add it to the dashboard.

1. Open Microsoft Defender for Cloud.
2. Navigate to Regulatory compliance in the left menu.
3. Click on Manage compliance policies.
4. Select your subscription or management group.
5. Click Add more standards.
6. Find your custom initiative in the list and click Add.

This step is crucial because it links your Azure Policy-based initiative to the Defender for Cloud reporting engine. Now, your custom standard will appear alongside the standard benchmarks like CIS or NIST, allowing you to see your compliance posture in a single view.

Best Practices for Managing Security Standards

Managing security posture is a continuous process, not a one-time project. As your cloud environment grows, your standards will need to adapt. Follow these best practices to maintain a healthy security posture.

1. Adopt "Policy as Code"

Do not rely on the Azure Portal for creating and updating policies. Use a CI/CD pipeline (such as GitHub Actions or Azure DevOps) to deploy your policy definitions and initiatives. Store your JSON policy files in a Git repository. This provides a version history, allows for peer review through pull requests, and ensures that your security standards are documented and reproducible.

2. Start with "Audit" Before "Deny"

When introducing a new security standard, always start with the "Audit" effect. If you immediately set an effect to "Deny," you risk breaking production applications that were previously non-compliant. By using "Audit," you can identify the resources that violate the policy, contact the resource owners, and allow them time to remediate the issue before you switch the policy to "Deny" or "DeployIfNotExists."

3. Use Management Groups

Do not assign policies at the subscription level if you have multiple subscriptions. Use Management Groups to apply policies to your entire organizational hierarchy. This ensures consistency and prevents "policy drift" where one subscription has different security rules than another.

4. Regularly Review and Prune

Policies that are no longer relevant should be retired. An accumulation of legacy policies can lead to "alert fatigue," where security teams become overwhelmed by thousands of minor violations. Set a schedule—perhaps quarterly—to review your active custom standards and ensure they still serve a business purpose.

Common Pitfalls and How to Avoid Them

Even experienced cloud engineers fall into common traps when implementing custom standards. Here is how to navigate the most frequent challenges.

Pitfall: Over-Complex Policy Logic

It is tempting to write highly complex, nested logic in your policies to cover every edge case. This makes the policy difficult to debug and slow to evaluate.

• The Fix: Keep policies modular. Instead of one massive policy that checks five different things, create five separate, simple policies and group them into an initiative. This makes troubleshooting much easier.

Pitfall: Neglecting the "Remediation" Aspect

A policy that tells you you're failing is helpful, but a policy that fixes the issue for you is better.

• The Fix: Use the DeployIfNotExists effect when possible. This effect automatically runs a deployment task to bring a resource into compliance. For example, if a storage account is created without encryption, the policy can automatically trigger a task to enable encryption on that resource.

Pitfall: Ignoring RBAC Requirements

Policies that use the DeployIfNotExists effect require a Managed Identity to perform the remediation.

• The Fix: When assigning a policy that uses this effect, ensure the assignment is created with a "System Assigned Identity" and that this identity has the necessary permissions (RBAC roles) to modify the resources in your subscription. If the identity lacks permissions, the remediation will fail silently.

Warning: Be extremely cautious with the "Deny" effect on critical production resources. A poorly written policy with a "Deny" effect can prevent you from deploying necessary updates or scaling your infrastructure during an incident. Always test "Deny" policies in a sandbox environment before promoting them to production.

Comparing Standard vs. Custom Approaches

Troubleshooting Custom Standards

If your policy is not working as expected, follow this systematic troubleshooting process:

1. Check the Evaluation State: In the Azure Policy dashboard, click on the specific policy assignment. Look at the "Compliance state." If it says "Not Started," wait a bit longer. If it says "Non-compliant" but you believe it should be compliant, examine the specific resource details.
2. Verify the Scope: Ensure the policy was assigned to the correct management group or subscription. It is easy to accidentally assign a policy to a parent management group that doesn't propagate down the way you expect, or to the wrong subscription entirely.
3. Check Policy Logic: Use the "Evaluation details" feature in the Azure Policy portal to see exactly which part of your JSON rule is failing. It will show you the "Actual value" of the resource property compared to the "Expected value" defined in your policy.
4. Review RBAC Permissions: If you are using DeployIfNotExists or Modify effects, check the Managed Identity of the policy assignment. Go to the "Assignments" tab, click your assignment, and check the "Identity" tab to see if it has the required permissions on the resource group or subscription.

The Role of Automation in Standard Management

As your organization grows, manually managing these standards becomes impossible. You should treat your policy deployments like software deployments. By using tools like Terraform or Bicep, you can define your entire security posture as code.

For instance, using Bicep, you can define an initiative and its assignments in a single file:

resource customInitiative 'Microsoft.Authorization/policySetDefinitions@2021-06-01' = {
  name: 'CorporateSecurityStandard'
  properties: {
    policyDefinitions: [
      {
        policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/...'
      }
    ]
  }
}

By automating this, you ensure that every new subscription created in your organization is automatically "born" with your custom security standards applied. This eliminates the "configuration gap" that occurs when a new project starts without the proper security controls in place.

Industry Standards vs. Internal Policy

It is common to confuse industry standards (like SOC2 or HIPAA) with internal custom standards. Industry standards are usually static documents that define a requirement. Your custom standards are the technical implementation of those requirements.

For example, a SOC2 requirement might say, "All data at rest must be encrypted." Your custom standard would be the actual policy that audits for the presence of encryption on Azure SQL, Storage Accounts, and Managed Disks. You should aim to map your custom policies to these high-level requirements. Defender for Cloud allows you to add "Regulatory Compliance" reports that map your policies to specific controls, making your audits significantly faster.

Summary: Key Takeaways for Success

Mastering custom standards in Defender for Cloud is about more than just checking boxes; it is about building a scalable, automated security architecture. Keep these key takeaways in mind as you build your security posture:

• Start with the Baseline: Always begin with the Microsoft Cloud Security Benchmark. Only add custom standards when the built-in benchmarks are insufficient for your specific business or regulatory needs.
• Policy as Code is Mandatory: Never manage security policies manually in the portal for production environments. Use Git-based workflows to track changes, review code, and deploy policies consistently.
• Audit Before Enforcing: Always use the "Audit" effect first. It is better to have a slow, controlled rollout of a policy than to accidentally break a production application with a "Deny" rule.
• Think in Modularity: Build small, reusable policy definitions and aggregate them into initiatives. This makes your infrastructure easier to maintain and troubleshoot when things go wrong.
• Leverage Managed Identities for Remediation: When you need policies to fix issues automatically, use the DeployIfNotExists effect combined with a properly configured System Assigned Identity.
• Map to Business Goals: Every custom policy should be tied to a clear business or regulatory requirement. If you cannot explain why a policy exists, it is likely just adding noise to your security dashboard.
• Continuous Review: Security is not a "set it and forget it" task. Schedule regular reviews of your policy set to prune obsolete rules and ensure they remain aligned with your evolving cloud environment.

By following this structured approach, you transition from simply reacting to security alerts to proactively defining the security culture of your cloud environment. Custom standards empower your team to enforce the rules that matter most, ensuring that your organization remains secure, compliant, and resilient in the face of constant change.

Frequently Asked Questions

Can I apply a policy to only a specific resource group?

Yes. When you assign an initiative or policy, you can select the "Scope" to be a specific resource group. However, be aware that this can lead to fragmented security postures. It is generally better to apply policies at a higher scope (like a subscription) and use "Exclusions" if certain resource groups need a different configuration.

How long does it take for a policy change to take effect?

Policy assignments are usually picked up within 30 minutes, but the actual evaluation of existing resources can take up to 24 hours depending on the volume of resources and the complexity of the policy. For new resources, evaluation is generally near-instant as the resource is created.

Can I share custom policies between different Azure tenants?

Azure Policy definitions are scoped to a management group or subscription within a single tenant. To share policies across tenants, you would need to export the JSON definitions from one tenant and import/deploy them into the other using a CI/CD pipeline.

What is the difference between "Audit" and "AuditIfNotExists"?

"Audit" is a general-purpose effect that checks if a property exists or meets a condition. "AuditIfNotExists" is a specialized effect that checks for the existence of a related resource (e.g., "Check if a diagnostic setting exists for this VM"). It is more powerful but requires more specific logic to define what the "related resource" is.

Is there a limit to how many policies I can assign?

There are service limits on the number of policy assignments per subscription. While these limits are quite high, you should still aim to consolidate your requirements into initiatives rather than creating hundreds of individual policy assignments, as this keeps your management overhead low and your performance high.