Appearance
Runtime Blocks: Guardian Profiles and Policies
Guardian Profiles define the expected behavioral envelope for a specific binary running on a specific sensor. They capture what the process is allowed to spawn, connect to, read, and how it may use capabilities. Guardian Policies are alert and enforcement rules that fire when events deviate from the profile.
Together, profiles and policies implement an allowlist-based confinement model: instead of blocking individual known-bad patterns, they alert or kill when the process behaves outside its documented normal behavior.
Prerequisites
operatorrole- Sensor already enrolled and in
observemode - At least 300 seconds of event history on the sensor for the target binary
Guardian Profiles
A profile is tied to a single target_binary path and optionally to a specific sensor (target_sensor_id) and NF role (target_nf_role). The allowlists define what the binary is permitted to do.
Profile modes
| Mode | What it does |
|---|---|
observe | No active enforcement. Profile is stored but no TracingPolicy is generated. Use this while building the baseline. |
audit | A TracingPolicy is generated and deployed. Deviations from the allowlist trigger Sigkill on the matching process. Use for controlled testing before full enforcement. |
enforce | A TracingPolicy is generated and deployed. Deviations trigger Override (BPF LSM denial) where applicable. Full production enforcement. |
Note: The TracingPolicy YAML is only generated and deployed when mode is audit or enforce. Setting mode to observe returns no policy YAML from the export endpoint.
Profile ID format
Profile IDs use the format gp_ followed by 12 hex characters.
Creating a profile
Requires operator role. In the Console, go to Policies > Guardian Profiles and click New Profile. Provide the target binary path and optional scope fields.
Profile fields:
| Field | Required | Description |
|---|---|---|
name | Yes | Profile label (max 128 characters) |
description | No | Explanation (max 2,000 characters) |
target_binary | Yes | Absolute path of the binary this profile applies to |
target_nf_role | No | Declare the NF role for context |
target_sensor_id | No | Scope to a specific sensor |
mode | No | observe (default), audit, or enforce |
allowed_spawns | No | Binaries this process is permitted to exec |
allowed_files | No | File path prefixes this process is permitted to read/write |
allowed_dst_ports | No | Destination TCP/UDP ports this process may connect to |
allowed_dst_cidrs | No | Destination IP address ranges this process may connect to |
allowed_capabilities | No | Linux capabilities this process may use |
blocked_syscalls | No | Syscalls to deny (used in generate; may not apply in all modes) |
observation_window_hours | No | How many hours of history to use when auto-generating the profile |
Auto-generating allowlists from event history
The Telovix Console can analyze event history from ClickHouse and populate the allowlists automatically. In the Console, go to Policies > Guardian Profiles > [profile] > Generate Allowlists. Set the source sensor and optional window (default: 24 hours) and click Generate.
Requires operator role.
The result populates spawned_binaries, file_path_prefixes, dst_ports, dst_cidrs, and capabilities arrays into the profile's allowlists, and marks the profile auto_generated = true.
Review the generated allowlists before advancing the profile to audit or enforce. Auto-generated profiles may include maintenance or startup behaviors that are legitimate but should not be part of the steady-state envelope.
Updating a profile
In the Console, go to Policies > Guardian Profiles > [profile] and edit the allowlist fields or change the mode using the mode selector.
Exporting a profile as TracingPolicy YAML
In the Console, go to Policies > Guardian Profiles > [profile] > Export. The Console compiles the profile into deployable TracingPolicy YAML and downloads it as a file.
The generated YAML is named guardian-profile-{profile_id}-{mode}.yaml. In audit mode the action is Sigkill; in enforce mode the action is Override (BPF LSM).
In observe mode, the export returns a comment-only file with no active rules.
Comparing two profiles
In the Console, go to Policies > Guardian Profiles > [profile] > Diff and select a second profile to compare against. The diff view shows added and removed entries for each allowlist dimension.
Listing and deleting profiles
In the Console, go to Policies > Guardian Profiles to see all profiles. Select a profile and click Delete to remove it. Requires operator role.
Guardian Policies
Guardian Policies are event-matching alert and enforcement rules associated with a profile. When an incoming heartbeat event matches a policy's conditions, the Console acts immediately.
Policy actions
| Action | What happens |
|---|---|
flag | Stored as a flag match; visible in the Custom Flags view |
alert | Fires an alert into the Console alert inbox |
kill_process | Adds the matching event's PID to the sensor's pending kill queue; delivered at the next heartbeat |
create_investigation | Automatically creates or links an investigation case |
The kill_process and create_investigation actions are evaluated against each incoming heartbeat's event batch. flag and alert are passive records.
Policy matching
Each policy matches on any combination of:
| Match field | Comparison |
|---|---|
match_event_kind | Exact match against the event kind string |
match_process_pattern | Substring match against process_executable |
match_parent_pattern | Substring match against parent_executable |
match_uid | Exact match against the event's UID |
match_dst_port | Destination port (for network events) |
match_dst_ip_prefix | Destination IP prefix (for network events) |
All specified conditions must match (AND logic). Fields left null are not evaluated.
Creating a Guardian Policy
Requires operator role. In the Console, go to Policies > Guardian Profiles > [profile] > Policies and click New Policy.
Policy fields:
| Field | Required | Description |
|---|---|---|
name | Yes | Policy label |
description | No | Explanation |
sensor_id | No | Scope to a specific sensor |
target_group_id | No | Scope to a sensor group |
match_event_kind | No | Event kind to match |
match_process_pattern | No | Process executable substring |
match_parent_pattern | No | Parent executable substring |
match_uid | No | UID to match |
match_dst_port | No | Destination port (string, may include ranges) |
match_dst_ip_prefix | No | Destination IP prefix |
action | No | flag (default), alert, kill_process, or create_investigation |
severity | No | info, warning (default), or critical |
exceptions | No | Process patterns to exempt from this policy |
compliance_tags | No | Compliance control IDs for evidence reports |
Managing policies
In the Console, go to Policies > Guardian Profiles > [profile] > Policies to list, enable, disable, update exceptions, and delete policies.
rApp catalog integration
Guardian Profiles can be linked to rApp catalog entries. When a profile's mode changes, the linked rApp's status updates automatically:
| Profile mode | rApp status |
|---|---|
observe | observing |
audit | profiled |
enforce | enforced |
The rApp catalog tracks binary path, vendor, version, and expected gRPC services alongside the behavioral profile. Policies referencing the rApp binary benefit from this additional context in investigation views.
Recommended workflow
- Create a profile with
mode: observeand set thetarget_binaryto the binary you want to confine. - Run Generate Allowlists after 24–72 hours of normal operation to build the initial allowlists from event history.
- Review the generated allowlists. Remove any entries that represent startup-only behavior not expected in steady state.
- Advance mode to
audit. ReviewSigkillevents in the Console to confirm only unexpected behavior is being matched. Add exceptions if legitimate patterns are being caught. - After at least one deliberate deviation test (unexpected spawn or unauthorized connection), advance to
enforceifauditresults are clean. - Create Guardian Policies with
kill_processorcreate_investigationactions for the highest-risk deviation patterns.
::: note Do not advance from observe directly to enforce. The audit mode with Sigkill action allows you to see what would be blocked before relying on Override denial. Skipping this step risks blocking legitimate workload behavior. :::