Managing inclusion and exclusion rules

To support more diverse network topologies, the Plixer ML Engine can be uniquely tailored to its environment using custom rules defining inclusions and exclusions for its functions. These rules can be managed from the Admin > Alarm Monitor > ML Rules view of the Plixer Scrutinizer web interface.

Inclusion rules

An inclusion rule defines either a network address (hosts/subnets) or exporter interface as a network data source for the Plixer ML Engine. Each rule also includes a sensitivity setting (see below) that is applied to the asset specified.

Malware detection, which uses pre-trained classification models to recognize generic malware behaviors, can also be enabled for individual inclusions.

Inclusion sensitivity

An inclusion’s sensitivity setting can be used to tune the engine’s tolerance for behavioral deviations for the host/subnet or exporter interface. Lowering the sensitivity setting for an asset will cause even minor deviations to be reported as detections, resulting in a higher volume of alarms. Conversely, increasing the sensitivity will allow for greater deviation, which translates to fewer detections reported.

When defining inclusions, the sensitivity setting should be left at its default value. After a period of 7 days (recommended), if too many unwarranted detection alarms are triggered, the sensitivity can be increased to the next level.

Exclusion rules

Exclusion rules can be used to ignore one or more ML-driven detections for traffic originating from a specified source and/or bound for a specified destination.

If expected traffic/activity triggers alarms, one or more exclusion rules should be created to exempt the sources and/or destination addresses from the detections being reported.

Recommendations

As part of the Plixer ML Engine’s initialization, inclusion rules are automatically created for the 20 most suitable network assets (hosts and and exporters/interfaces) based on its default dimension definitions. If necessary, additional rules should be created to cover all assets associated with critical/sensitive network activity (“crown jewel” assets) and hard-to-monitor traffic (e.g., IoT devices, operational technology, etc.).

The following resources are examples of network assets that are highly recommended for inclusion:

  • AD servers

  • DB servers

  • DBS servers

  • DHCP servers

  • Web servers

  • Source code repositories

  • Object repositories

  • FTP servers

If there are assets whose typical behavior is being reported as anomalous/suspicious, exclusion rules should be defined to exempt the traffic from superfluous detections.