-| Swissbit | ![n] | ![y]| ![y]| ![n]| ![n] | https://www.swissbit.com/en/products/ishield-fido2/ |

-System-preferred MFA is a Microsoft managed setting, which is a [tristate policy](#authentication-method-feature-configuration-properties). For preview, the **default** state is disabled. If you want to turn it on for all users or a group of users during preview, you need to explicitly change the Microsoft managed state to **enabled** by using Microsoft Graph API. Sometime after general availability, the Microsoft managed state for system-preferred MFA will change to **enabled**.

-description: Get guidance on meeting multifactor authentication requirements outlined in US government OMB memorandum 22-09.

-This series of articles offers guidance for using Azure Active Directory (Azure AD) as a centralized identity management system for implementing Zero Trust principles, as described in the US federal government's Office of Management and Budget (OMB) [memorandum 22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf).

-The memo requires that all employees use enterprise-managed identities to access applications, and that phishing-resistant multifactor authentication (MFA) protect those personnel from sophisticated online attacks. Phishing is the attempt to obtain and compromise credentials, such as by sending a spoofed email that leads to an inauthentic site.

-Adoption of MFA is critical for preventing unauthorized access to accounts and data. The memo requires MFA usage with phishing-resistant methods, defined as "authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system." The first step is to establish what MFA methods qualify as phishing resistant.

-U.S. Federal agencies will be approaching this guidance from different starting points. Some agencies will have already deployed modern credentials such as [FIDO2 security keys](../authentication/concept-authentication-passwordless.md#fido2-security-keys) or [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-overview), many are evaluating [Azure AD certificate-based authentication](../authentication/concept-certificate-based-authentication.md) (currently in Public Preview), some are just starting to modernize their authentication credentials. This guidance is meant to inform agencies on the multiple options available to meet phishing-resistant MFA requirements with Azure AD. The reality is that phishing-resistant MFA is needed sooner than later. Microsoft recommends adopting phishing-resistant MFA method as soon as possible by whichever method below best matches the agency's current capability. Agencies should approach the phishing-resistant MFA requirement of the memorandum from the mindset of what can I do **now** to gain phishing-resistance for my accounts. Implementing phishing-resistant MFA will provide a significant positive impact on improving the agency's overall cybersecurity posture. The end goal here is to fully implement one or more of the modern credentials. However, if the quickest path to phishing-resistance is not a modern approach below, agencies should take that step as a starting point on their journey towards the more modern approaches.

-

-### Modern approaches

-### Protection from external phishing

-**[Microsoft Authenticator](../authentication/concept-authentication-authenticator-app.md) and conditional access policies that enforce managed devices**. Managed devices are Hybrid Azure AD joined device or device marked as compliant.

-Microsoft Authenticator can be installed on the device accessing the application protected by Azure AD or on a separate device.

->[!Important]

->

->To meet the phishing-resistant requirement with this approach:

->

->- Only the device accessing the protected application needs to be managed

->- All users allowed to use Microsoft Authenticator must be in scope for conditional access policy requiring managed device for access to all applications.

->- An additional conditional access policy is needed to block access targeting the Microsoft Intune Enrollment Cloud App. All users allowed to use Microsoft Authenticator must be in scope for this conditional access policy.

->

->Microsoft recommends that you use the same group(s) used to allow the Microsoft Authenticator App authentication method within both conditional access policies to ensure that once a user is enabled for the authentication method they are simultaneously in scope of both policies.

->

->This conditional access policy effectively prevents both:

->

->- The most significant vector of phishing threats from malicious external actors.

->- A malicious actor's ability to phish Microsoft Authenticator to register a new credential or join a device and enroll it in Intune such that it will be marked as compliant

-For more information on deploying this method, see the following resources:

->

-> Today, Microsoft Authenticator by itself is not phishing-resistant. You must additionally configure conditional access policy requiring managed device to gain protection from external phishing threats.

-**Federated Identity Provider (IdP) such as Active Directory Federation Services (AD FS) that's configured with phishing-resistant method(s).** While agencies can achieve phishing resistance via federated IdP, adopting or continuing to use a federated IdP adds significant cost, complexity and risk. Microsoft encourages agencies to realize the security benefits of Azure AD as a cloud based identity provider, removing [associated risk of a federated IdP](../fundamentals/protect-m365-from-on-premises-attacks.md).

-For more information on deploying this method, see the following resources:

-### Additional phishing-resistant method considerations

-Your current device capabilities, user personas, and other requirements might dictate specific multifactor methods. For example, if you're adopting FIDO2 security keys that have only USB-C support, they can be used only from devices with USB-C ports.

-Consider the following when evaluating phishing-resistant MFA methods:

-## Implementation considerations for phishing-resistant MFA

-The following sections describe support for implementing phishing-resistant methods for both application and virtual device sign-in scenarios.

-The following table details the availability of phishing-resistant MFA scenarios, based on the device type that's used to sign in to the applications:

-| Device | AD FS as a federated identity provider configured with certificate-based authentication| Azure AD certificate-based authentication| FIDO2 security keys| Windows Hello for Business| Microsoft Authenticator with conditional access policies that enforce hybrid Azure AD join or compliant devices |

-| MacOS device| | | Edge/Chrome | Not applicable|  |

-To learn more, see [Browser support for FIDO2 passwordless authentication](../authentication/fido2-compatibility.md).

-To enforce the use of phishing-resistant MFA methods, integration might be necessary based on your requirements. MFA should be enforced when users access applications and devices.

-For each of the five phishing-resistant MFA types previously mentioned, you use the same capabilities to access the following device types:

-| Azure Linux virtual machine (VM)| Enable the [Linux VM for Azure AD sign-in](../devices/howto-vm-sign-in-azure-ad-linux.md). |

-| Azure Windows VM| Enable the [Windows VM for Azure AD sign-in](../devices/howto-vm-sign-in-azure-ad-windows.md). |

-| Azure Virtual Desktop| Enable [Azure Virtual Desktop for Azure AD sign-in](/azure/architecture/example-scenario/wvd/azure-virtual-desktop-azure-active-directory-join). |

-| VMs hosted on-premises or in other clouds| Enable [Azure Arc](../../azure-arc/overview.md) on the VM and then enable Azure AD sign-in. (Currently in private preview for Linux. Support for Windows VMs hosted in these environments is on our roadmap.) |

-| Non-Microsoft virtual desktop solution| Integrate the virtual desktop solution as an app in Azure AD. |

-### Enforcing phishing-resistant MFA

-Conditional access enables you to enforce MFA for users in your tenant. With the addition of [cross-tenant access policies](../external-identities/cross-tenant-access-overview.md), you can enforce it on external users.

-[Azure AD B2B collaboration](../external-identities/what-is-b2b.md) helps you meet the requirement to facilitate integration among agencies. It does this by:

-You must enforce MFA for partners and external users who access your organization's resources. This is common in many inter-agency collaboration scenarios. Azure AD provides cross-tenant access policies to help you configure MFA for external users who access your applications and resources.

-By using trust settings in cross-tenant access policies, you can trust the MFA method that the guest user's tenant is using instead of having them register an MFA method directly with your tenant. These policies can be configured on a per-organization basis. This ability requires you to understand the available MFA methods in the user's home tenant and determine if they meet the requirement for phishing resistance.

-## Password policies

-The memo requires organizations to change password policies that are proven ineffective, such as complex passwords that are rotated often. This includes the removal of the requirement for special characters and numbers, along with time-based password rotation policies. Instead, consider doing the following:

-* Use [password protection](..//authentication/concept-password-ban-bad.md) to enforce a common list of weak passwords that Microsoft maintains. You can also add custom banned passwords.

-* Use [self-service password reset](..//authentication/tutorial-enable-sspr.md) to enable users to reset passwords as needed, such as after an account recovery.

-* Use [Azure AD Identity Protection](..//identity-protection/concept-identity-protection-risks.md) to be alerted about compromised credentials so you can take immediate action.

-Although the memo isn't specific on which policies to use with passwords, consider the standard from [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html).

-The following articles are part of this documentation set:

-[Meet identity requirements of memorandum 22-09](memo-22-09-meet-identity-requirements.md)

-[Enterprise-wide identity management system](memo-22-09-enterprise-wide-identity-management-system.md)

-[Authorization](memo-22-09-authorization.md)

-[Other areas of Zero Trust](memo-22-09-other-areas-zero-trust.md)

-For more information about Zero Trust, see:

-[Securing identity with Zero Trust](/security/zero-trust/deploy/identity)

-export FEDERATED_IDENTITY_CREDENTIAL="myFedIdentity"

- $len = $using:vmsCount

-> If you use the webhook action, your target webhook endpoint must be able to process the various JSON payloads that different alert sources emit. You can't pass security certificates through a webhook action. If the webhook endpoint expects a specific schema, for example, the Microsoft Teams schema, use the Logic Apps action to transform the alert schema to meet the target webhook's expectations.

-A standardized schema can help you minimize the number of integrations, which simplifies the process of managing and maintaining your integrations.

-The new schema enables a richer alert consumption experience in both the Azure portal and the Azure mobile app.

-If the custom properties are not set in the Alert rule, this field will be null. Note: today this is only supported for Metric Alerts other alert types will contain null in this field.

-| configurationItems |The list of affected resources of an alert.<br>In some cases, the configuration items can be different from the alert targets. For example, in metric-for-log or log alerts defined on a Log Analytics workspace, the configuration items are the actual resources sending the telemetry and not the workspace.<br><ul><li>In the log alerts API (Scheduled Query Rules) v2021-08-01, the `configurationItem` values are taken from explicitly defined dimensions in this priority: `Computer`, `_ResourceId`, `ResourceId`, `Resource`.</li><li>In earlier versions of the log alerts API, the `configurationItem` values are taken implicitly from the results in this priority: `Computer`, `_ResourceId`, `ResourceId`, `Resource`.</li></ul>In ITSM systems, the `configurationItems` field is used to correlate alerts to resources in a configuration management database. |

-|failingPeriods |In an alert rule with a dynamic threshold, the number of evaluation periods that don't meet the alert threshold that will trigger an alert. For example, you can indicate that an alert is triggered when 3 out of the last five evaluation periods aren't within the alert thresholds. |

-Then you define these elements for the resulting alert actions by using:

-An *alert rule* monitors your telemetry and captures a signal that indicates something is happening on the specified resource. The alert rule captures the signal and checks to see if the signal meets the criteria of the condition. If the conditions are met, an alert is triggered, which initiates the associated action group and updates the state of the alert.

-After an alert is triggered, the alert is made up of:

-Alert processing rules allow you to apply processing on fired alerts. Alert processing rules are different from alert rules. Alert rules generate new alerts, while alert processing rules modify the fired alerts as they're being fired.

-You can write code to process your telemetry before it's sent from the SDK. The processing includes data that's sent from the standard telemetry modules, such as HTTP request collection and dependency collection.

-[Add properties](./api-filtering-sampling.md#add-properties) to telemetry by implementing `ITelemetryInitializer`. For example, you can add version numbers or values that are calculated from other properties.

-[Filtering](./api-filtering-sampling.md#filtering) can modify or discard telemetry before it's sent from the SDK by implementing `ITelemetryProcessor`. You control what is sent or discarded, but you have to account for the effect on your metrics. Depending on how you discard items, you might lose the ability to navigate between related items.

-[Sampling](./api-filtering-sampling.md) is a packaged solution to reduce the volume of data that's sent from your app to the portal. It does so without affecting the displayed metrics. And it does so without affecting your ability to diagnose problems by navigating between related items like exceptions, requests, and page views.

-To learn more, see [Filter and preprocess telemetry in the Application Insights SDK](./api-filtering-sampling.md).

-Plug-ins for the Application Insights SDK can customize how telemetry is enriched and processed before it's sent to the Application Insights service.

-* Filtering with telemetry processors lets you filter out telemetry in the SDK before it's sent to the server. For example, you could reduce the volume of telemetry by excluding requests from robots. Filtering is a more basic approach to reducing traffic than sampling. It allows you more control over what's transmitted, but it affects your statistics. For example, you might filter out all successful requests.

-* [Telemetry initializers add or modify properties](#add-properties) to any telemetry sent from your app, which includes telemetry from the standard modules. For example, you could add calculated values or version numbers by which to filter the data in the portal.

-* [The SDK API](./api-custom-events-metrics.md) is used to send custom events and metrics.

-As of version 6.4.0-main-02-22-2023-3ee44b9e, Windows metric collection has been enabled for the AKS clusters. Onboarding to the Azure Monitor Metrics add-on enables the Windows DaemonSet pods to start running on your node pools. Both Windows Server 2019 and Windows Server 2022 are supported. Follow these steps to enable the pods to collect metrics from your Windows node pools.

- POST /<appId>/oauth2/v2.0/token

-1. To interact with the storage account, the app uses the Azure Storage Client Library for .NET to create a reference to the account with [CloudStorageAccount](/dotnet/api/microsoft.azure.storage.cloudstorageaccount), and from that creates a [CloudBlobClient](/dotnet/api/microsoft.azure.storage.blob.cloudblobclient).

- CloudBlobClient blobClient = CreateCloudBlobClient(StorageAccountName, StorageAccountKey);

-1. The app uses the `blobClient` reference to create a container in the storage account and upload data files to the container. The files in storage are defined as Batch [ResourceFile](/dotnet/api/microsoft.azure.batch.resourcefile) objects that Batch can later download to the compute nodes.

- List<string> inputFilePaths = new List<string>

- List<ResourceFile> inputFiles = new List<ResourceFile>();

- foreach (string filePath in inputFilePaths)

- inputFiles.Add(UploadFileToContainer(blobClient, inputContainerName, filePath));

- BatchSharedKeyCredentials cred = new BatchSharedKeyCredentials(BatchAccountUrl, BatchAccountName, BatchAccountKey);

- using (BatchClient batchClient = BatchClient.Open(cred))

- CloudTask task = new CloudTask(taskId, taskCommandLine);

- task.ResourceFiles = new List<ResourceFile> { inputFiles[i] };

- Microsoft Defender CSPM protects across all your multicloud workloads, but billing only applies for Servers, Databases and Storage accounts at $15/billable resource/month. If you have one of the following plans enabled, you will receive a discount.

-Current Microsoft Defender for Cloud customers receive automatically applied discounts (5-25% discount per billed workload based on the highest applicable discount).

-Refer to the following table:

-Customers will have until June 30, 2023 to resolve this issue. After this date, only the most recent DevOps Connector created where an instance of the DevOps organization exists, will remain onboarded to Defender for DevOps.

-description: This article provides answers to the frequently asked questions about the MedTech service.

-To learn more about the MedTech service open-source projects, see [Open-source projects](git-projects.md).

-The MedTech service requires device and FHIR destination mappings to perform normalization and transformation processes on device message data. To learn how the MedTech service transforms device data into [FHIR Observations](https://www.hl7.org/fhir/observation.html), see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

-\* Reference [Configure the MedTech service for manual deployment using the Azure portal](deploy-new-config.md#destination-properties) for a functional description of the MedTech service resolution types (**Create** or **Lookup**).

-No. The MedTech service doesn't back up the device messages that is sent to the event hub. The event hub owner controls the device message retention period within their event hub, which can be from one to 90 days. Event hubs can be deployed in [three different service tiers](../../event-hubs/event-hubs-quotas.md?source=recommendations#basic-vs-standard-vs-premium-vs-dedicated-tiers). Message retention limits are tier-dependent: Basic one day, Standard 1-7 days, Premium 90 days. If the MedTech service successfully processes the device message data, it's persisted in the FHIR service, and the FHIR service backup policy applies.

-To learn more about the MedTech service open-source projects, see [Open-source projects](git-projects.md).

-If you have successfully deployed the prerequisite resources, you're now ready to deploy the [MedTech service](deploy-manual-prerequisites.md) using your workspace.

-description: The MedTech service has a robust open-source (GitHub) library for ingesting device messages from popular wearable devices.

-Check out our open-source projects on GitHub that provide source code and instructions to deploy services for various uses with the MedTech service.

-> [Choose a deployment method for the MedTech service](deploy-new-choose.md)

-description: This article explains how to configure the MedTech service metrics.

-In this article, you'll learn how to configure the MedTech service metrics in the Azure portal. You'll also learn how to pin the MedTech service metrics tile to an Azure portal dashboard for later viewing.

-description: This article explains how to enable the MedTech service diagnostic settings.

-In this article, you'll learn how to enable diagnostic settings for the MedTech service to:

-> - Create a diagnostic setting to export logs and metrics for audit, analysis, or troubleshooting of the MedTech service.

-> - Use the Azure Log Analytics workspace to view the MedTech service logs.

-> - Access the MedTech service pre-defined Azure Log Analytics queries.

-description: This article describes how to use the MedTech service Mapping debugger.

-description: This article describes how to use the MedTech service monitoring and health check tabs.

-description: This article provides an overview of the MedTech service device data processing stages. The MedTech service ingests, normalizes, groups, transforms, and persists device message data in the FHIR service.

-Transform is the next stage where normalized messages are processed using the user-selected/user-created conforming and valid [FHIR destination mapping](how-to-configure-fhir-mappings.md). Normalized messages get transformed into FHIR Observations if a matching FHIR destination mapping has been authored. At this point, the [Device](https://www.hl7.org/fhir/device.html) resource, along with its associated [Patient](https://www.hl7.org/fhir/patient.html) resource, is also retrieved from the FHIR service using the device identifier present in the device message. These resources are added as a reference to the FHIR Observation being created.

-> [Overview of the MedTech service FHIR destination mapping](how-to-configure-fhir-mappings.md)

-description: This article provides an overview of the MedTech service device mapping.

-> [Overview of the MedTech service FHIR destination mapping](how-to-configure-fhir-mappings.md)

-description: In this article, you'll learn about the MedTech service, its features, functions, integrations, and next steps.

-> [Choose a deployment method for the MedTech service](deploy-new-choose.md)

-description: This article assists troubleshooting and fixing MedTech service deployment errors.

-||

-description: This article assists troubleshooting and fixing MedTech service error logs.

-||

- * The **Azure role assignments** show that your event hub has an **Azure Event Hubs Data Receiver** role assigned to your MedTech service’s system-assigned managed identity. If not, follow these [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-device-message-event-hub). 

-4. On the Azure portal, go to your event hub, and assign the **Azure Event Hubs Data Receiver** role to your MedTech service's user-assigned managed identity (see [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-device-message-event-hub), but use the user-assigned managed identity instead of the system-assigned managed identity).

-**Fix**: On the Azure portal, go to your event hub, and assign the **Azure Event Hubs Data Receiver** role to your MedTech service (see [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-device-message-event-hub)).

-**Fix**: On the Azure portal, go to your FHIR service, and assign the **FHIR Data Writer** role to your MedTech service (see [step-by-step instructions](deploy-new-deploy.md#grant-access-to-the-fhir-service)).

-**APPLIES TO:** :::image type="icon" source="./media/applies-to/yes.png" border="false":::Azure Database for PostgreSQL - Single Server :::image type="icon" source="./media/applies-to/yes.png" border="false":::Azure Database for PostgreSQL - Flexible Server

-You'll need:

-|Section |Tasks |

-|||

-|**Authentication** | 1. Generate deployment credentials. |

-|**Deploy** | 1. Deploy the database. |

-> [!IMPORTANT]

-You'll use the connection string as a GitHub secret.

-2. Select **Set up your workflow yourself**.

-2. Delete everything after the `on:` section of your workflow file. For example, your remaining workflow may look like this.

-1. Rename your workflow `PostgreSQL for GitHub Actions` and add the checkout and login actions. These actions check out your site code and authenticate with Azure using the GitHub secret(s) you created earlier.

-2. Use the Azure PostgreSQL Deploy action to connect to your PostgreSQL instance. Replace `POSTGRESQL_SERVER_NAME` with the name of your server. You should have a PostgreSQL data file named `data.sql` at the root level of your repository.

-3. Complete your workflow by adding an action to logout of Azure. Here's the completed workflow. The file appears in the `.github/workflows` folder of your repository.

-

- :::image type="content" source="media/how-to-deploy-github-action/gitbub-action-postgres-success.png" alt-text="Log of GitHub Actions run":::

-2. Select your Application.

-description: "Learn how to install the connector Azure Information Protection to connect your data source to Microsoft Sentinel."

-# Azure Information Protection connector for Microsoft Sentinel

-**Azure Information Protection** helps protect your data whether itΓÇÖs stored in the cloud or in on-premises infrastructures. Control and help secure email, documents, and sensitive data that you share outside your company. From easy classification to embedded labels and permissions, enhance data protection at all times with Azure Information Protection. With Azure Information Protection you can:

-Integrate Microsoft Azure Information Protection logs with Sentinel to view dashboards, create custom alerts, and improve investigation.

-[Get started with Azure Information Protection >](https://aka.ms/asi-aip-get-started)

-## Connector attributes

-| Connector attribute | Description |

-| | |

-| **Log Analytics table(s)** | InformationProtectionLogs_CL<br/> |

-| **Data collection rules support** | Not currently supported |

-| **Supported by** | [Microsoft Corporation](https://support.microsoft.com) |

-## Next steps

-For more information, go to the [related solution](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/azuresentinel.azure-sentinel-solution-azureinformationprotection?tab=Overview) in the Azure Marketplace.

-Azure Spring Apps diagnostics supports interactive troubleshooting apps running in virtual networks without configuration. Azure Spring Apps diagnostics identifies problems and guides you to information that helps troubleshoot and resolve them.

-The following procedure starts diagnostics for networked applications.

-1. Go to your Azure Spring Apps Overview page.

-1. Select **Diagnose and solve problems** in the menu on the left navigation pane.

-1. Select the third category, **Networking**.

- 

-After you select the **Networking** category, you can view two issues related to Networking specific to your virtual-network injected Azure Spring Apps instances: **DNS Resolution** and **Required Outbound Traffic**.

- 

-Select your target issue to view the diagnostic report. A summary of diagnostics will be displayed, such as:

-* *Resource is not deployed in your own virtual network*.

-Some results contain related documentation. Different subnets will display the results separately.

-If you select **DNS Resolution**, results will indicate whether there are DNS issues with applications. Healthy apps are listed as follows:

-The following diagnostic report example indicates that the health of the application is unknown. The reporting time frame does not include the time when the health status was reported. Assume that the context end time is *2021-03-03T04:20:00Z*. The latest TIMESTAMP in the **DNS Resolution Table Renderings** is *2021-03-03T03:39:00Z*, the previous day. The health check log may not have been sent out because of a blocked network.

-The unknown health status results contain related documentation. You can select the left angle bracket to see the drop-down display.

-

-If you misconfigured your Private DNS Zone record set, you will get a critical result such as: `Failed to resolve the Private DNS in subnet xxx`.

-In the drop-down **DNS Resolution Table Renderings** you will find the detail message info from which you can check your config.

-If you select **Required Outbound Traffic**, results will indicate whether there are outbound traffic issues with applications. Healthy apps are listed as follows:

-If any subnet is blocked by NSG or firewall rules, and if you have not blocked the log, you will find the following failures. You can check whether you overlooked any [Customer Responsibilities](./vnet-customer-responsibilities.md).

-

-If there is no data in the `Required Outbound Traffic Table Renderings` within 30 minutes, the result will be `health status unknown`.

-Maybe your network is blocked or the log service is down.

-

-iscsicli RemovePersistentTarget $yourStorageTargetIQN $yourStorageTargetPortalPort $yourStorageTargetPortalHostName

-# Web Application Firewall CRS rule groups and rules

-Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits. This is done through rules that are defined based on the OWASP core rule sets 3.2, 3.1, 3.0, or 2.2.9. Rules can be disabled on a rule-by-rule basis, or you can set specific actions by individual rule. This article contains the current rules and rule sets offered. In the rare occasion that a published ruleset needs to be updated, it will be documented here.

-CRS is enabled by default in Detection mode in your WAF policies. You can disable or enable individual rules within the Core Rule Set to meet your application requirements. You can also set specific actions per rule. The CRS supports block, log and anomaly score actions. The Bot Manager ruleset supports the allow, block and log actions.

-By default, CRS version 3.2 and above will leverage anomaly scoring when a request matches a rule, CRS 3.1 and below will block matching requests by default. Additionally, custom rules can be configured in the same WAF policy if you wish to bypass any of the pre-configured rules in the Core Rule Set.

-When you use CRS, your WAF is configured to use anomaly scoring by default. Traffic that matches any rule isn't immediately blocked, even when your WAF is in prevention mode. Instead, the OWASP rule sets define a severity for each rule: Critical, Error, Warning, or Notice. The severity affects a numeric value for the request, which is called the anomaly score:

-> Request attributes by key and values are only available in CRS 3.2 or newer and Bot Manager 1.0 or newer.

-In contrast, if your WAF detects the header's name (`My-Header`) as an attack, you could configure an exclusion for the header *key* by using the **RequestHeaderKeys** request attribute. The **RequestHeaderKeys** attribute is only available in CRS 3.2 or newer and Bot Manager 1.0 or newer.

-Per-rule exclusions are available when you use the OWASP (CRS) ruleset version 3.2 or later or Bot Manager ruleset version 1.0 or later.

-For CRS 3.2 (on the WAF_v2 SKU) and newer, these limits are as follows when using a WAF policy for Application Gateway:

-The Azure Application Gateway Web Application Firewall (WAF) v2 comes with a pre-configured, platform-managed ruleset that offers protection from many different types of attacks. These attacks include cross site scripting, SQL injection, and others. If you're a WAF admin, you may want to write your own rules to augment the core rule set (CRS) rules. Your custom rules can either block, allow, or log requested traffic based on matching criteria. If the WAF policy is set to detection mode, and a custom block rule is triggered, the request is logged and no blocking action is taken.