Behavioral Analytics

Behavioral Analytics compares observed runtime activity with a learned process baseline. It helps identify a known program doing something unusual, such as spawning a new child, contacting a new destination, accessing a new file area, changing its invocation pattern, or running outside its established schedule.

An anomaly is deviation evidence, not proof of compromise. The displayed value describes signal strength. Confirm impact by reviewing the event, process lineage, workload, related alerts, and other evidence before treating it as an incident.

Workspace guide

Open Detect > Behavioral Analytics. The workspace has five tabs:

Tab	Use it to
Behavioral Anomalies	Triage scored runtime deviations and open their evidence drawer.
Anomaly Exceptions	Review expected-behavior rules that reduce repeated known noise.
Sensor Sensitivity	Control the minimum signal strength retained for each sensor.
Process Baselines	Check learning progress, event volume, and baseline freshness.
Fingerprints	Explore aggregated process behavior and compare equivalent sensor roles.

The Console performs scoring and baseline management. This workflow adds no new periodic work to the sensor and does not change sensor capture frequency.

How process baselines work

The Console maintains an independent baseline for each sensor and executable path. Keeping sensor identity in the baseline prevents behavior observed on one host from silently becoming expected on another.

Each baseline can contain these bounded profiles:

Dimension	Evidence represented
Spawn	Child executables launched by the process.
Network	Outbound destinations and ports.
File	Accessed file path groups.
DNS	Queried domains.
Flow	Observed network-flow behavior.
Arguments	Bounded command invocation patterns.
Inbound	Accepted local ports.
Write	File write path groups.
Time	A 24-hour UTC activity distribution.

Baselines are rebuilt automatically. Operators can select Rebuild baselines when an immediate refresh is required. Rebuilding recalculates current observations; it does not bypass drift review for an established baseline.

Learning and maturity

A baseline is learning until it has observations on enough distinct calendar days. The standard learning period is 14 observed days. If analytics retention is configured below 14 days, the effective maturity threshold is capped by that retention window.

High event volume does not graduate a baseline early. A busy process observed for one day is still a one-day baseline. This protects the baseline from treating a short burst, rollout, or concentrated abnormal period as long-term normal behavior.

At least 10 baseline events are required before general novelty scoring can produce a non-zero signal. Learning state is shown explicitly in the UI. Learning records are normally suppressed from the active queue, but selected high-value runtime indicators may remain visible for review. Visibility during learning still does not confirm exploitation.

Interpreting signal strength

General novelty dimensions use the following evidence levels:

Value	Meaning	Evidence requirement
0	Established behavior	Pattern is represented in the baseline.
35	Rare behavior	Less than 2% frequency with at least 200 baseline events.
60	Very rare behavior	At most two observations with at least 50 baseline events.
85	Never observed	No matching baseline observation and at least 10 baseline events.

The main dimensions are combined as follows:

maximum = max(spawn, network, file, arguments)
weighted = spawn * 0.40 + network * 0.25 + file * 0.15 + arguments * 0.20
signal = maximum * 0.65 + weighted * 0.35

Records below 30 are not retained in the anomaly queue. In the Console, values are described as Weak signal, Moderate signal, or Strong signal. They are not vulnerability severity or threat-confidence labels.

Argument indicators can raise the signal for patterns associated with reverse shells, download-and-execute chains, suspicious interpreter usage, or obfuscation. These are passive indicators. Review the exact event and surrounding runtime evidence before reaching a verdict.

Temporal evidence

Temporal scoring applies only to process execution observations with a mature baseline and enough scheduling history. A previously unseen hour can amplify other process-execution evidence, but its standalone contribution is capped. Time-of-day novelty cannot turn an unrelated file or network event into a temporal finding.

Triage an anomaly

Select a row to open the evidence drawer. Review:

1. The executable, sensor, node, event kind, and observation time.
2. The dimensions that contributed to the signal and their explanations.
3. Process, container, Kubernetes, file, network, DNS, or runtime evidence available for the event.
4. MITRE ATT&CK mappings as investigation pivots, not confirmation that a technique succeeded.
5. Learning and suppression state before deciding whether the behavior is actionable.

Use Launch investigation to create or add the evidence to a case. A new investigation starts with a neutral triage severity; it does not inherit anomaly strength as a confirmed incident severity.

Use Mark expected only for behavior you have verified as normal. This creates a persistent rule scoped to the source sensor so that one host's expected behavior does not silence equivalent events fleet-wide.

Anomaly exceptions

Suppression rules hide matched records from the default anomaly queue; they do not delete the original score. Enable Show suppressed and learning scores when reviewing hidden records.

Open Detect > Behavioral Analytics > Anomaly Exceptions to search, create, and review expected-behavior exceptions, their scope, and expiry. See Anomaly Exceptions for the workflow.

Important behavior:

• Rules created from an anomaly retain the source sensor scope.
• Group-scoped users cannot create an unrestricted fleet-wide rule.
• Expired rules are distinguished from active rules.
• A match count that cannot be calculated is shown as unavailable, not as zero.
• Search, filtering, expiry selection, and pagination are applied by the server.

Prefer narrow rules with a documented reason and an expiry when the expected behavior is temporary.

Sensor sensitivity

Sensitivity is a per-sensor minimum signal threshold:

Preset	Threshold	Typical use
Honeypot	0	Retain all scored behavior for a deliberately high-observation sensor.
Default	30	Standard fleet behavior.
Moderate deviation	50	Reduce weaker deviations on a noisy sensor.
Strong deviation	70	Retain strong deviations.
Exceptional deviation	90	Retain only exceptional pattern indicators.

Lower values retain more signals; higher values retain fewer. Sensitivity does not change what the sensor captures. Sensor search and pagination are handled by the server, and only Operators or Administrators can change thresholds.

Material baseline drift

An established baseline must not automatically absorb a material behavior change. During a rebuild, the Console compares the new profile with the active profile using set-distance evidence.

Candidate review is required when a mature baseline crosses these boundaries:

Profile	Review boundary
Spawn or network	30% material change
File or DNS	40% material change

The existing active baseline remains in use while the new complete profile is staged as a candidate. Open Process Baselines to inspect added and removed children, destinations, files, domains, arguments, inbound ports, and write paths.

Candidate states are:

State	Meaning
Review pending	Material change is staged; the active baseline is unchanged.
Candidate rejected	The reviewed candidate was not accepted; the active baseline remains unchanged.
Superseded	A later rebuild produced different candidate evidence or returned within the accepted boundary.

Operators can:

• Approve to atomically promote the complete staged profile.
• Reject to preserve the active baseline and record the decision.

Repeated rebuilds of the same rejected candidate do not create a new review item. A materially different candidate starts a new review lifecycle. Approval and rejection are audited.

Fingerprints and role comparison

Fingerprints summarize process behavior across bounded, server-side aggregates. Search and filters are applied before pagination, so the browser does not download or scan the complete fleet dataset.

Role comparison is corroborating evidence for equivalent systems, not a training source and not a compromise verdict. It uses mature, active stored baselines and requires:

• at least three mature sensors in the role;
• at least three process paths shared across the role;
• a process to appear on at least 60% of peers before it is considered shared.

The Console reports one of these states:

State	Meaning
Insufficient peers	There is not enough mature comparable evidence.
Material deviation	Additional or missing processes cross the bounded comparison threshold.
Variation observed	Differences exist but do not cross the material threshold.
Matches role	No role-level process difference was observed in the comparison.

Use the displayed additional and missing binaries to investigate deployment drift, configuration differences, or unexpected runtime activity. Do not treat a role mismatch alone as malicious.

Scale and data states

Large Behavioral Analytics datasets are processed with server-side scope enforcement, filtering, sorting, aggregation, and pagination:

• anomaly scores: 25 rows per page;
• sensor maturity and sensitivity: 50 rows per page;
• suppression rules: 50 rows per page;
• process baselines: 100 rows per page;
• fingerprints and role comparisons: bounded aggregate pages.

Sensor access scope is applied before query limits. This prevents an allowed sensor from disappearing because unrelated fleet records consumed the page limit.

The UI distinguishes:

• Learning: insufficient observed-day history;
• Active: scored and visible under the selected threshold;
• Suppressed: retained evidence hidden by learning or a matching rule;
• Unavailable: the calculation could not be completed;
• Insufficient peers: role comparison has too little evidence;
• No observations: no matching records exist in the selected scope.

Unavailable evidence is never presented as zero, normal, or healthy.

Roles and permissions

Role	Capabilities
Viewer	View allowed Behavioral Analytics data and evidence.
Analyst	View evidence and launch or update investigations.
Operator	Analyst capabilities plus suppression, sensitivity, rebuild, and candidate-review actions.
Administrator	Operator capabilities across the permitted Console scope.

All reads and actions remain constrained by the user's sensor access scope.

Operational limits

• Behavioral analytics reduces false positives through maturity, bounded rarity rules, sensor scoping, baseline quarantine, and peer corroboration. It cannot guarantee that every deviation is malicious or that every attack is anomalous.
• New sensors and newly observed processes need distinct observed days before their baseline is mature.
• A high-volume first day does not replace a multi-day learning period.
• A shared binary path does not prove that two services have the same role. Role comparison should be used only where the deployment grouping is meaningful.
• Environments with fewer than three mature peers correctly report insufficient evidence rather than manufacturing a comparison.
• Manual suppression and baseline approval are security decisions. Review the evidence and record a clear reason.

Further reading

• Investigations
• Attack Chains
• Anomaly Exceptions
• Alert Inbox and Triage
• AI Assistant