Pilot Checklist

A successful pilot proves visibility, operational fit, resource cost, and rollout safety on representative systems. It should not be limited to confirming that Sensors appear online.

1. Define the pilot

[ ] Name an operational owner and security owner.
[ ] Select representative Linux, container, Kubernetes, and telecom nodes.
[ ] Include at least one busy node and one constrained node.
[ ] Define the expected Standard and Telecom Sensor count.
[ ] Record the Console retention plan: 30 days for Trial or 90 days for paid plans.
[ ] Define success metrics for coverage, alert quality, CPU, memory, delivery, and investigation time.

2. Prepare Console infrastructure

[ ] Self-hosted all-in-one pilot has at least 8 vCPU, 24 GiB RAM, and 250 GiB fast SSD storage.
[ ] Production queue evaluation uses at least the 12 vCPU, 32 GiB RAM, and 500 GiB starting baseline.
[ ] PostgreSQL and ClickHouse are reachable and backed by persistent storage.
[ ] ClickHouse has at least 20% free working space.
[ ] Console DNS, browser TLS, and port 15483 or 443 are reachable.
[ ] Database backups and restore ownership are defined.
[ ] System time is synchronized.

See Requirements before changing these values.

3. Validate Sensor prerequisites

On each node class, verify:

bash

uname -r
test -f /sys/kernel/btf/vmlinux
mountpoint /sys/fs/bpf
uname -m

[ ] Kernel is 5.4 or newer.
[ ] BTF is available.
[ ] Architecture is x86_64 or aarch64.
[ ] VM and bare-metal hosts use systemd.
[ ] Kubernetes permits the privileged DaemonSet and required host mounts.
[ ] BPF LSM is available where enforcement will be evaluated.
[ ] Sensor nodes can reach the Console without inbound firewall rules.

4. Establish a baseline

Before enabling optional capture or enforcement, record for at least one normal operating window:

[ ] Sensor CPU median and P95.
[ ] Sensor memory and restart count.
[ ] Console, PostgreSQL, and ClickHouse CPU and memory.
[ ] ClickHouse daily disk growth.
[ ] Sensor delivery rate, queue depth, drops, and stale count.
[ ] Runtime event and API observation volume.
[ ] Normal alert and finding volume.
[ ] Application, Kubernetes, and telecom workload health.

This baseline is the comparison point for every later policy or capture change.

5. Enroll by deployment type

[ ] Use a one-time token for each persistent VM or bare-metal node.
[ ] Use one cluster token for each Kubernetes cluster.
[ ] Use a fleet token for an ephemeral autoscaling group.
[ ] Assign unique node names and meaningful site, environment, and network tags.
[ ] Verify each Sensor reports the expected architecture, version, flavor, and workload context.
[ ] Revoke unused or exposed enrollment tokens.

6. Validate core workflows

[ ] Live Feed receives current events.
[ ] Runtime Explorer shows processes and connections.
[ ] Process Tree preserves parent and child relationships.
[ ] DNS Activity shows process, query, resolver, and response evidence.
[ ] API Security shows observed applications, endpoints, threats, and visibility state.
[ ] Kubernetes pages show the correct cluster, namespace, workloads, and topology.
[ ] Findings open into evidence with working pivots.
[ ] Alerting and SIEM test deliveries succeed.

For Telecom pilots also verify:

[ ] Expected network functions appear with the correct role.
[ ] RAN, control-plane, and user-plane evidence reflects the test network.
[ ] User equipment appears only when observed signaling evidence supports it.
[ ] Capture lists all eligible interfaces and explicitly reports unavailable coverage.
[ ] SLO and power estimates are labelled correctly as measured or estimated.

7. Assess signal quality

[ ] Review every Critical and High result with the workload owner.
[ ] Classify representative true positives and false positives.
[ ] Verify passive indicators are not described as confirmed compromise.
[ ] Confirm unavailable evidence is not displayed as safe or zero.
[ ] Add narrow suppressions only for understood recurring activity.
[ ] Recheck signal quality after the suppression.

8. Test controlled changes

[ ] Test new runtime protection on one canary Sensor first.
[ ] Keep Runtime Detection in observation mode before creating Runtime Blocks.
[ ] Enable extended API or packet capture only on selected Sensors and for a bounded period.
[ ] Compare CPU, memory, delivery, and application health with the baseline.
[ ] Stop the change immediately if node or workload health regresses.

9. Test upgrades and rollback

[ ] Upgrade one VM or bare-metal Sensor through a canary plan.
[ ] Upgrade one Kubernetes cluster through Helm.
[ ] Verify the Sensor reconnects and visibility resumes.
[ ] Confirm the previous binary or image tag is available for rollback.
[ ] Document who can pause, stop, approve, and roll back an upgrade.

10. Approve scale-out

Before production expansion:

[ ] Project ClickHouse storage from measured daily growth and retention.
[ ] Add at least 25% capacity beyond the measured pilot peak.
[ ] Decide whether Redpanda is required for the production ingestion profile.
[ ] Confirm Console and database monitoring is active.
[ ] Define maintenance windows for Sensor and policy updates.
[ ] Document incident, certificate, token, backup, and restore ownership.
[ ] Obtain application and telecom operations approval.

Pilot exit criteria

The pilot is complete when representative nodes are visible, findings are actionable, delivery is healthy, resource impact is accepted, retention is sized from measured data, and both upgrade and rollback paths have been exercised.

Pilot Checklist ​

1. Define the pilot ​

2. Prepare Console infrastructure ​

3. Validate Sensor prerequisites ​

4. Establish a baseline ​

5. Enroll by deployment type ​

6. Validate core workflows ​

7. Assess signal quality ​

8. Test controlled changes ​

9. Test upgrades and rollback ​

10. Approve scale-out ​

Pilot exit criteria ​

Further reading ​