Zero Trust Expansion
Zero Trust Expansion pillar — policies, findings, playbooks, active responses history, SUDO policies and executions, SELinux, and policy violations.
Zero Trust Expansion provides the deeper Zero Trust surface beyond the v3.0 Zero Trust Enforcement pillar's signals / drift / SUDO / file-monitoring views. Where Zero Trust Enforcement is the day-to-day analyst surface (signals to triage, drift events to investigate, findings to clear), Zero Trust Expansion is the program-management surface — where policies are defined, playbooks are authored, response history is reconciled, and policy violations are reviewed across longer audit windows.
Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.
The expansion pillar is used by detection engineers maintaining the rule library, incident-response leads reviewing playbook performance, and policy owners tracking compliance with the tenant's Zero Trust posture over time. It is the layer below the day-to-day analyst surface — a step closer to the program-level questions of "are our policies working?" rather than the per-event questions of "what should I do about this signal?"
Policies
The Policies page is the authoritative library of Zero Trust policies defined for the tenant. Each policy bundles a match expression (the signal types, drift categories, or behavioral patterns it applies to), a scope (which environments / tags / servers are in scope), and an action set (alert, suppress, escalate, or execute a playbook).
Policies are versioned. Each edit produces a new version with a diff against the previous version, the editing identity, and the effective date. Older versions remain visible — operators can compare a current policy against the policy that was in effect at the time of a historical event. This versioning is what gives the Zero Trust expansion its program-management posture: policies are not just configuration, they are decisions over time.
Per-policy fields:
Name
Operator-supplied, human-readable identifier
Description
Free-text intent and rationale
Match expression
Signal type, drift category, or behavioral pattern this policy applies to
Scope
Environment / tag / server set the policy is in effect for
Action
Alert, suppress, escalate, or playbook reference
Approver
Identity that approved the policy edit
Effective from / until
Optional time window for the policy
A policy that is suppressing every signal of a category for an extended window is, in practice, a documented decision to accept that category as out of scope. Suppressions are first-class evidence (visible in Compliance Expansion and in compliance reports).
Findings
Findings in Zero Trust Expansion is the aggregated, deduplicated view across signals, drift events, and behavioral anomalies. It is a meta-view: where Zero Trust Enforcement's Findings page is the analyst's queue (paginated, severity-filtered, focused on what needs work now), the Expansion Findings view is the program view — open / suppressed / acknowledged counts by category, week-over-week trend, and the per-policy effective rate.
Operators use the Expansion Findings view to answer questions like:
Which categories of findings are growing or shrinking week over week?
What proportion of findings are being suppressed (and is that proportion changing)?
Which servers / environments produce the most findings per server (an indicator of a policy that may be too broad)?
Which findings have been open longest, and is there a pattern to those that don't get cleared?
These are program-health questions, not per-event triage questions. The Findings view in this pillar is built around answering them.
Playbooks
Playbooks are scripted response actions defined for the tenant. Each playbook bundles a trigger (which signal type / severity / scope fires it), a sequence of containment actions (isolate host, kill process, disable account, revoke session, etc.), and a guardrail set (dry-run mode, maximum scope, required-approval threshold).
Playbook execution is gated. A playbook that, if executed at full scope, would affect more than a configurable number of servers must be approved by a designated approver before running. A playbook configured in dry-run mode logs what it would have done without taking action. Both gates exist to prevent a playbook with too-broad scope from causing a fleet-wide outage as a containment side effect.
Per-playbook fields:
Trigger
Signal match condition + severity floor
Action sequence
Ordered list of containment steps
Scope cap
Maximum number of servers / accounts the playbook can affect per execution
Dry-run
If on, log-only; no real action taken
Required approver
Optional identity that must approve execution if scope cap is exceeded
Cooldown
Minimum time between executions for the same trigger
Playbook configuration involves safety controls; review the Active Response documentation before configuring playbooks in production environments.
Active responses history
Active responses history is the audit record of every playbook execution: when it ran, what triggered it, what action sequence was executed, which servers were affected, what response codes came back from the target hosts, and whether the run completed or aborted (and why).
Each history entry is fully inspectable — full action sequence, full target list, full per-target outcome. This is the surface where an operator answers "did the playbook actually contain the threat?" and "did the playbook side-effect anything we did not intend?" Both are answers the program owner needs across a quarter, not just at the moment a single playbook fires.
History entries are immutable and timestamped — they are evidence of response actions taken.
SUDO policies
SUDO policies is the program-level companion to the v3.0 Zero Trust Enforcement's SUDO Policies analysis page. The v3.0 page surfaces real-time analysis of SUDO rule patterns (shell escape vectors, wildcard abuse, privilege escalation paths). The Expansion SUDO Policies page is the policy-versioning and policy-coverage surface: which SUDO patterns are explicitly approved, which are flagged for review, and how the approved set has evolved.
Operators use Expansion SUDO Policies to:
Document approved SUDO patterns at the tenant level (e.g., "rules of the form
%deploy ALL = NOPASSWD: /usr/bin/systemctl restart <deploy-svc>are explicitly approved")Track exceptions — SUDO rules that match a flagged pattern but have an approved exception with a documented reason
Measure policy compliance — what percentage of SUDO rules across the fleet match an approved pattern, what percentage have documented exceptions, and what percentage are unreviewed
SUDO executions
SUDO executions in Zero Trust Expansion is the long-window execution view: aggregated and trend-analyzed SUDO execution events. The day-to-day per-event execution audit lives in the Audit pillar (see Audit). The Expansion SUDO executions view is the meta-view: rate of executions per server, per invoker, per command pattern; growth or decline over the audit period; outlier execution events that don't match an approved pattern.
This is the surface a privileged-access program owner uses to answer "is the program working?" — meaning are sudo executions trending in the direction the policy expects, and are exceptions being documented as policy requires?
SELinux
SELinux in Zero Trust Expansion provides the policy-program view of SELinux posture across the fleet. The day-to-day SELinux status surface (which servers are enforcing, which are permissive, which are disabled) lives in Zero Trust Enforcement. The Expansion view tracks the program metrics: percentage of servers in enforcing mode, denial event rate per server (with abnormally high rates surfacing as candidates for policy refinement), policy-version drift, and the proportion of servers running the tenant's approved SELinux policy bundle.
This view is most relevant for tenants where SELinux is a load-bearing control (e.g., FedRAMP environments, healthcare environments) and where the program owner needs to track policy adoption over time as part of the audit posture.
Policy violations
Policy violations is the catch-all for events that violate one or more defined policies. It deduplicates across the underlying surfaces — a single event might appear as a signal in Zero Trust Enforcement, a drift event in Config Drift, and a finding in Findings, but in Policy violations it is a single row tied to the policy or policies it violated.
Each policy violation row carries:
The policy (or policies) violated
The originating event(s)
The scope (server / environment) where the violation occurred
The action taken (alert, escalation, playbook execution)
The status (open, acknowledged, resolved, suppressed)
Policy violations is the most useful view for the program owner answering "are we enforcing our policies, and where are we not?" — and for the auditor asking "show me every violation of policy X in the audit period, with the response that was taken." It is the surface where Zero Trust as a program (rather than as a set of detection rules) becomes legible.
Data sources
Zero Trust Expansion draws on:
Policy definitions (operator-authored, versioned in the console)
Playbook definitions (operator-authored, with safety controls)
Active response execution history (produced by playbook runs)
Signal / drift / behavioral telemetry from the rest of the Zero Trust surface (Zero Trust Enforcement)
SUDO execution audit (shared with Audit pillar)
SELinux policy state (collected by the agent where SELinux is enabled)
No external sources feed Zero Trust Expansion. All inputs originate either from agent telemetry or from operator-supplied policy / playbook definitions.
Module gating
Zero Trust Expansion is part of the Zero Trust module. Subscription gating documented in console — playbook execution, active response history retention, and policy versioning depth may vary by tier. Policies, Findings (aggregated), SUDO policies, SUDO executions, SELinux, and Policy violations are all available where the Zero Trust module is present.
Cross-references
Related Concepts: Zero Trust Enforcement (the v3.0 day-to-day surface this pillar expands), Audit (SUDO execution audit detail), Active Response (playbook safety model)
Related How-to: Respond (notification rules and integration targets for playbook outputs)
Related: Console | Zero Trust Enforcement | Active Response | Audit | Glossary
Last updated
Was this helpful?