Zero Trust Enforcement

Zero Trust Enforcement surfaces security signals and configuration drift events with full identity context, and provides privilege analysis tools for validating the principle of least privilege.

Signals

Signals are security-relevant events collected from monitored servers and enriched with identity context at ingestion time. Each signal carries an identity_risk_level badge (critical, high, medium, or low) drawn from the identity profile of the account involved. When enrichment_version is 1 or greater, full identity context is present on the signal.

The signal row displays the associated MITRE ATT&CK technique ID alongside the event summary. This mapping allows you to correlate observed behavior with known adversary techniques without leaving the Signals view.

Identical signals collected within a deduplication window appear as a single entry with an occurrence count. This reduces noise from high-frequency events while preserving accurate event totals.

The response_status and available_actions fields indicate whether a response playbook matches this signal type. When a matching playbook exists, a containment action can be triggered from the signal. Playbook configuration and active response execution are covered in the Active Response documentation.

Config Drift

Config Drift tracks changes to seven component types across your fleet: Account, Group, Sudo, SSH, SSHD, SSH Key, and PAM. Each change event is enriched with attribution data so you can identify who made the change.

Attribution fields:

• attributed_username — the username detected making the change, identified via eBPF openat syscall correlation at the time of the file modification

• attribution_confidence — confidence level of the attribution: high, medium_same_path, medium_multi_path, low, or unknown

• attributed_uid — the UID of the attributed user at event time

• attributed_loginuid — the Linux Audit LoginUID, which survives sudo escalation and identifies the original logged-in user even when changes are made through privilege elevation

• attributed_process — the process name that opened the modified file

Each drift event includes a risk_impact_summary describing the security relevance of the change, and a recommendations array with suggested remediation steps.

Status lifecycle: Drift events progress through: New → Active → Investigating → Acknowledged → Resolved. Events can also be Suppressed with an optional expiration date, after which they return to Active status if the condition persists.

SUDO Policies

SUDO Policies analyzes sudo rule configurations across your fleet to identify privilege escalation paths and unsafe rule patterns. The sidebar label is SUDO Policies (uppercase SUDO).

Shell escape vector enumeration: Flags sudo rules where the allowed command is an interactive editor (such as vi, vim, nano, or emacs), a pager (less, more), or an interpreter (python, perl, ruby, bash) that enables an interactive shell escape. A user with a rule allowing vi effectively has unrestricted root access.

Wildcard abuse detection: Flags sudo rules that use ALL for the command or host specifications, or that use dangerous glob patterns such as trailing * that could be exploited to match unintended binaries.

Single-hop privilege escalation path analysis: Traces what accounts can reach through a single sudo hop. This surfaces unexpected privilege chains — for example, a service account with a narrowly scoped sudo rule that transitively enables root access through a wildcard or escape vector.

File Monitoring

File Monitoring provides fleet-wide visibility into file system changes: file creates, modifications, deletes, renames, and permission changes across all monitored paths.

Each event includes process attribution with a confidence level:

• HIGH — captured at syscall time via eBPF kernel tracing; the process was identified at the moment of the file operation

• MEDIUM — identified via /proc lookup after the event; the process was still running when attribution was attempted

• LOW — the process had exited before attribution could be completed; fallback identification only

SHA-256 hash changes distinguish content modifications from metadata-only updates such as timestamp or permission changes. A hash change confirms that file content was altered.

Exfiltration alert detection flags suspicious data movement patterns — for example, when a monitored process reads a file in a watched path and subsequently writes to an unmonitored location, indicating potential data staging or exfiltration.

File Monitoring watch paths and file patterns are configured under Settings > File Monitoring.

SELinux

SELinux provides policy audit and violation detection for servers with SELinux enforcement enabled. LinuxGuard collects SELinux policy evaluations and surfaces denials and policy anomalies alongside the identity context of the processes involved. Use this view to identify processes operating outside their expected security domain.

Playbooks and Active Responses

Playbooks defines automated response rules. Each playbook specifies a signal match condition and a corresponding containment action — for example, isolating a host or blocking an account when a specific signal type is detected with a severity threshold.

Active Responses shows in-flight and historical response command execution, including command status, target server, triggering signal, and execution timestamps.

Note: Active response configuration requires the Zero Trust module and involves safety controls described in the Active Response documentation. Review the Active Response documentation before configuring playbooks in production environments.

Findings

Findings is a paginated list of security findings aggregated across your fleet. Filter by severity (Critical, High, Medium, Low) and by finding category to focus on specific risk areas. A severity breakdown summary at the top of the page shows the distribution of findings across the fleet at a glance.

---

Related: Console | Identity Intelligence | Active Response | Security Architecture | Glossary