Service behavior monitoring

Plixer One Enterprise addresses the limitations of traditional security technologies by applying AI and ML techniques to provide early, generic detections for activity associated with advanced persistent threats (APTs).

These detections rely on behaviors rather than signatures and give security teams an additional layer of defense against attempts to use common services to infiltrate, infect, and exploit network resources.

Overview

Plixer One Enterprise’s approach to anomaly detection relies on the ML Engine to turn the flow data collected by Scrutinizer into behavioral models that represent typical host activity. All incoming flow data can then be compared against these baseline models to proactively scan for potentially malicious activity and alert security teams in real time.

Configuring anomaly detection

The ML Engine’s anomaly detection functions can be adapted to any type of environment through its configuration:

Dimensions	Services/applications (protocol and port) whose behavior is modeled and monitored for anomaly detection
Inclusions	Hosts (by exporter or subnet) being monitored for anomalous behavior
Sensitivity	The tolerance for deviations from baseline service behavior for hosts associated with the inclusion

Defining dimensions and inclusions for the engine isolates traffic information to reduce the amount of “noise” and maximize the accuracy of detections. Organizations are also able to tune detections to their unique processes and workflows by adjusting the sensitivity for individual inclusions.

Hint

Low sensitivity is generally recommended for critical subnets (e.g., finance, HR, etc.) where all irregularities should be reported, while a High can be used for hosts whose security requirements are less strict.

Investigating anomaly detections

Once anomalous behavior is reported via an alarm, the appropriate response can be determined using a combination of Scrutinizer workflows, including:

• Drilling down into the alarm (e.g., Plixer Security Intelligence, Lateral Movement Behavior, etc.) and checking the timeline to determine whether the detection is an isolated observation or an ongoing event

• Inspecting event artifacts to see which hosts were involved and drilling into them to gain further insights from Endpoint Analytics

• Reviewing activity via the Behavior tab when drilling into hosts from the Explore > Entities > Hosts view.

• Running Source and Destination reports on the hosts to check for traffic between them and external IP addresses

Hint

After running an initial report, it can be refined directly from the output view to enable further investigation.

Workflows

The following workflow(s) show how alarms related to anomalous service behavior are used to investigate potential cyber attacks:

Detecting anomalies and deviations

Continuously monitor traffic anomalies or traffic deviations that exceed set thresholds using dynamic ML-modeled baselines.

Workflow

Machine learning allows Scrutinizer to alert users to anomalous traffic utilization patterns typically associated with security incidents.

Note

This workflow requires the Plixer ML Engine for predictive modeling. Contact Plixer Technical Support to learn more about licensing options.

All incoming flow data can be compared against these baseline models to proactively scan for potentially malicious activity and report discoveries in real time.

From there, the next steps should be to set up reports and use them to generate forecasts.

Identify which areas of the network (devices and interfaces) have the majority of traffic:

• What types of traffic would you expect to see – VoIP, HTTP, SQL?

• Business application traffic like Salesforce, AWS, Azure etc.

• DNS requests to dedicated DNS servers on the network

Now consider traffic that may be anomalous:

• Does Remote Desktop Protocol make sense on this network, is there a business use case for RDP?

• Should there be SSH traffic to critical hosts?

Based on the above considerations, create/run one or more reports to isolate traffic data for services, hosts, or device groups that are most likely to be involved in malicious activity. Once saved, these reports can then be used to forecast expected traffic patterns and highlight deviations (e.g., an anomalous ICMP data trend in outbound WAN usage for edge devices) that can be analyzed to identify threats.

Next steps would be to customize alerts for this behavior or other traffic deviations that exceed user-defined thresholds configured for the report(s).

Tip

Scrutinizer’s alarm policies can be assigned custom notification profiles. To add one or more notification actions for all report thresholds, create a notification profile and assign it to the Report Threshold Violation policy.