Custom network analysis policy creation for Snort 3

A custom network analysis policy creation for Snort 3 is a data-driven configuration process that

  • enables advanced users to customize the default network analysis policy for specific network requirements or to optimize performance, and

  • utilizes JSON and JSON Schema based on the OpenAPI specification to configure inspectors and settings.

Network analysis policy customization overview

The default network analysis policy is tuned for typical network requirements and optimal performance. In most situations, you do not need to customize the policy. However, when you have a specific network requirement or when you are facing performance issues, the default network analysis policy can be customized. Note that customizing the network analysis policy is an advanced configuration that should only be done by advanced users or Cisco Support.

In Snort 3, the list of inspectors and settings are not in a one-to-one mapping with the Snort 2 list of preprocessors and settings. The number of inspectors and settings available in Firewall Management Center forms a subset of those that Snort 3 supports. See https://snort.org/snort3 for more information on Snort 3. See https://www.cisco.com/go/snort3-inspectors for more information on the inspectors available in Firewall Management Center.

Note
  • While upgrading the Firewall Management Center to the 7.0 release, the changes that were done in the Snort 2 version of the network analysis policy are not migrated to Snort 3 after the upgrade.

  • Unlike the intrusion policy, there is no option to synchronize Snort 2 network analysis policy settings to Snort 3.

Default inspector updates

Lightweight Security Package (LSP) updates may contain new inspectors or modifications to integer ranges for existing inspector configurations. After you install an LSP, new inspectors or updated ranges will be available under Inspectors in the Snort 3 Version of your network analysis policy.

Binder inspector

Binder inspector defines the flow when a particular inspector has to be accessed and taken into consideration. When the traffic matches the conditions defined in the binder inspector, only then the values and configurations for that inspector come into effect. For example:

For the imap inspector, the binder defines the following condition when it has to be accessed. That is when:

  • Service is equal to imap.

  • Role is equal to any.

a

If these conditions are met, then use the type imap.

Singleton inspectors

Singleton inspectors contain a single instance. These inspectors do not support adding more instances like multiton inspectors. Settings of a singleton inspector apply to all traffic, not to a specific segment.

For example:

{
   "normalizer":{
      "enabled":true,
      "type":"singleton",
      "data":{
         "ip4":{
            "df":true
         }
      }
   }
}

Multiton inspectors

Multiton inspectors contain multiple instances which you can configure as needed. These inspectors support configuring settings based on specific conditions, such as network, port, and VLAN. One set of supported settings is called an instance. There is a default instance, and you can also add additional instances based on specific conditions. If the traffic matches that condition, the settings from that instance are applied. Otherwise, the settings from the default instance are applied. Also, the name of the default instance is the same as the name of the inspector.

For a multiton inspector, when you upload the overridden inspector configuration, you also need to include and define a matching binder condition (conditions under when the inspector has to be accessed or used) for each instance in the JSON file, otherwise, the upload will result in an error. You can also create new instances. Ensure that you include a binder condition for each new instance you create to avoid errors.

For example:

  • Multiton inspector where the default instance is modified.

    {
       "http_inspect":{
          "enabled":true,
          "type":"multiton",
          "instances":[
             {
                "name":"http_inspect",
                "data":{
                   "response_depth":5000
                }
             }
          ]
       }
    }
  • Multiton inspector where the default instance and default binder is modified.

    {
       "http_inspect":{
          "enabled":true,
          "type":"multiton",
          "instances":[
             {
                "name":"http_inspect",
                "data":{
                   "response_depth":5000
                }
             }
          ]
       },
       "binder":{
          "type":"binder",
          "enabled":true,
          "rules":[
             {
                "use":{
                   "type":"http_inspect"
                },
                "when":{
                   "role":"any",
                   "ports":"8080",
                   "proto":"tcp",
                   "service":"http"
                }
             }
          ]
       }
    }
  • Multiton inspector where a custom instance and a custom binder is added.

    {
       "http_inspect":{
          "enabled":true,
          "type":"multiton",
          "instances":[
             {
                "name":"http_inspect1",
                "data":{
                   "response_depth":5000
                }
             }
          ]
       },
       "binder":{
          "type":"binder",
          "enabled":true,
          "rules":[
             {
                "use":{
                   "type":"http_inspect",
                   "name":"http_inspect1"
                },
                "when":{
                   "role":"any",
                   "ports":"8080",
                   "proto":"tcp",
                   "service":"http"
                }
             }
          ]
       }
    }