About the Plixer ML Engine

Once deployed and configured, the engine is able to ingest flow data through Plixer Scrutinizer and apply multiple machine learning techniques to identify potentially problematic activity on the network.

The Plixer ML Engine has several key functions that enable intelligent, multi-layered anomaly and threat detection in a Plixer One Enterprise deployment:

Comprehensive network behavior modeling

Leveraging the large volumes of flow data collected by Plixer Scrutinizer, the engine is capable of building behavioral models encompassing network activity at any scale. It can then learn to recognize deviations and suspicious activity, such as data accumulation/exfiltration, tunneling, and lateral movement, that may indicate an attack on the network.

Accessible behavioral insights for network assets

After being alerted to anomalous behavior, network and security teams can drill down into the associated hosts, IP address groups, and/or exporter interfaces to better understand the details of their involvement in the reported detection.

Highly configurable ML modeling

The Plixer ML Engine monitors network activity based on user-customizable dimensions and inclusion/exclusion rules. Consistently repeated traffic patterns, asset/group importance, and data seasonality are all taken into consideration as well, resulting in models that are uniquely tailored to each environment.

ML-based malware detection

Using pre-trained classification models, the engine is able to recognize generic activity patterns that are associated with common classes of malware, including command and control, remote access trojans, and exploit kits. This adds another layer of protection to further reduce risk and mean time to resolution (MTTR) when threats are detected.

Continuous observation and learning

As it ingests additional flow data, the Plixer ML Engine updates its behavior models based on a schedule that defines weekdays, weeknights, and weekends to account for changes in legitimate activity patterns and improve recognition of advanced threats that attempt to disguise their behavior.

Configuration options

After being deployed, the Plixer ML Engine adapts its monitoring functions to the assets and traffic data observed to be available in the Plixer Scrutinizer environment. This allows it to function optimally in common enterprise scenarios. However, the engine can also be further tailored to more unique network and security requirements.

Dimensions and inclusions

To ensure that its behavior models represent only relevant network activity, the Plixer ML Engine supports custom dimension definitions and inclusion/exclusion rules.

  • ML dimensions: Define traffic (based on protocol and port used) by host or exporter for ingestion by the engine

  • ML rules: Define inclusion or exclusion rules for network assets to be monitored by the engine

The default configuration for the Plixer ML Engine includes recommended dimension definitions, which are used to automatically select suitable data sources as inclusions. After the engine is deployed and set up, the ML Dimensions and ML Rules management views under Admin > Alarm Monitor in the web interface should be compared against the monitoring requirements for the environment and updated if necessary.

Global settings

The global settings under Admin > Settings in the Plixer Scrutinizer web interface can be used to configure parameters for certain ML functions and behaviors across all engines in an environment.

  • ML AD Users: Add/edit Microsoft Azure account credentials for AD Users UEBA integration

  • ML Alerts: Manage thresholds for alerts related to engine vitals and sensitivity for Microsoft Office 365 detections

  • ML Data Limits: Manage model and host count limits to use for training and prediction

  • ML Training Schedule: Manage behavior model seasonality settings

With the exception of adding an Azure account, leaving the above settings at their default values is recommended for new Plixer ML Engine deployments.

Engine settings

After an engine has been fully deployed, its resource utilization settings can be modified via the tray in the ML engine management page.

These settings are applied on a per-engine basis and can be used to optimize pod counts and process resource utilization based on an engine’s expected worklaod.