Policies
Group NSM rules that share a priority and a scope into one NSM policy
An NSM policy has one priority, so group NSM rules that need to run at the same priority into one NSM policy, and give each NSM policy one need. You can then read your NSM policies in priority order and know what each firewall contains and why.
The trade-off is that every NSM rule in an NSM policy applies to every scope that you deploy the NSM policy to. Where you need customizations or unique scoping, use separate NSM policies.
Common reasons to make NSM rules a separate NSM policy include the following:
| Reason | Example NSM policy | When it applies |
|---|---|---|
| Placed early in the firewall's rule order | Threat intelligence/block lists | The NSM traffic inspection rules must be evaluated on each firewall before the rules from most other NSM policies, such as block lists that need to stop traffic before any other inspection. |
| Placed late in the firewall's rule order | Baseline enforcement | The NSM traffic inspection rules must be evaluated on each firewall after the rules from most other NSM policies, such as enforcement that acts on the results of earlier inspection. |
| Wins or yields on configuration settings | Mandatory firewall settings, Firewall defaults | The NSM firewall configuration rules set a property that other NSM policies also set. When two NSM policies set the same property, the NSM policy with the higher priority (lower number) wins. For example, Mandatory firewall settings at a high priority sets logging that no other NSM policy can override, and Firewall defaults at a low priority sets fallback values that any more specific NSM policy can override. |
| Broad scope | Baseline managed rules | The NSM rules apply to a large part of your organization, such as every resource in All Public Facing Resources. |
| Specific scope | Technology-specific managed rules | The NSM rules apply only to resources that share a technology, resource type, or network role, such as a Technology apps scope. |
| Application or business unit scope | Application exceptions, Business unit baseline | The NSM rules apply only to one Application scope or one business unit's OU, and are often owned by that team. |
For how this applies to each firewall type, see the recommended NSM policies for AWS WAF and AWS Network Firewall.
Use separate NSM policies when different teams own the NSM rules
We recommend a separate NSM policy for each team, even when the teams' NSM rules use the same priority range and scope. For example, we recommend that threat analysts own their own Threat intelligence/block lists NSM policy, instead of adding their NSM rules to an NSM policy that the central team owns. Each team can then version, test, and roll back its own NSM rules without changing another team's NSM policy.
The exception is an NSM rule that's specific to one application. For example, if a threat intelligence NSM rule applies only to App1, it can go in one of App1's NSM policies.
Inspect with low priority numbers and enforce with high priority numbers
We recommend low priority numbers for NSM policies that count or inspect, so they run first, and high priority numbers for NSM policies that enforce, where enforcing makes sense, so they run last. NSM policies between the two, such as exceptions, can then act on the results of inspection before enforcement.
Because each NSM policy has its own priority and scope, a central team can own the inspect and enforce NSM policies across the organization, while application teams add NSM policies between them for only their own applications. Application teams don't need to change the central team's NSM policies, and the central team doesn't need a different NSM policy for each application. For how this applies to AWS WAF, see Label-Based Exceptions.
Set priority deliberately
For priority recommendations and strategies, see Policy Priority.
Choose remediation options