Appearance
Compliance
The Compliance section maps runtime sensor evidence to specific controls in four security frameworks. Rather than requiring manual evidence collection, it draws on the same eBPF telemetry, audit events, and policy state that operators already manage. Reports can be generated for any of three time windows and exported as cryptographically signed evidence bundles.
Frameworks
Five framework identifiers are supported:
| Framework identifier | Full name | Controls |
|---|---|---|
cis_benchmark | CIS Controls v8 Benchmark (Telecom Overlay) | 15 |
nis2_directive | NIS2 Directive Article 21 (Telecom Overlay) | 13 |
etsi_security | ETSI NFV-SEC Security Assessment | Varies |
3gpp_ts33117 | 3GPP TS 33.117 Security Assurance | 7 |
o_ran_wg11 | O-RAN WG11 Security Requirements | 9 |
The etsi_security, 3gpp_ts33117, and o_ran_wg11 frameworks are only relevant on deployments with telecom sensors enrolled. CIS and NIS2 apply to any deployment.
Time periods
Each framework report can be computed for one of three windows:
| Period | Hours | Default |
|---|---|---|
last_7d | 168 hours | |
last_30d | 720 hours | Yes |
last_90d | 2,160 hours |
Control statuses
Each control is assessed as one of:
| Status | Meaning |
|---|---|
PASS | Evidence supports the control requirement |
PARTIAL | Evidence partially supports the control |
FAIL | Insufficient evidence or negative indicators present |
INFO | Informational; not scored against the overall percentage |
Overall score = PASS count / (total controls − INFO controls) × 100, rounded to the nearest integer. INFO controls are excluded from the denominator.
Viewing compliance controls
Compliance reports are cached for up to 4 hours for fleet-wide queries. Scoped queries (per-user sensor groups) always compute live.
In the Console, navigate to Compliance and select the framework from the tab bar. Use the Period dropdown to switch between last_7d, last_30d, and last_90d. The page shows the overall_score, pass_count, partial_count, fail_count, and info_count, along with the last_computed_at timestamp and the full controls[] list.
CIS Controls v8 Benchmark (telecom overlay)
15 controls covering asset inventory, configuration, audit logging, behavioral protection, and network monitoring, with telecom-specific extensions for NF role inference and protocol coverage.
| Control ID | Name |
|---|---|
CIS_1_1 | Enterprise Asset Inventory (NF Edition) |
CIS_2_1 | Software Asset Inventory |
CIS_2_7 | Vulnerability Management |
CIS_4_1 | Secure Configuration Monitoring (NF Edition) |
CIS_8_1 | Audit Log Management |
CIS_8_2 | Collect Audit Logs (Telecom Protocol Edition) |
CIS_10_1 | Malware Defenses Deployed |
CIS_10_9 | Behavioral Threat Protection (NF Edition) |
CIS_13_1 | Network Traffic Monitoring (Telecom Protocol Edition) |
CIS_13_3 | Network Traffic Baseline (NF Peer Allowlist Edition) |
CIS_16_1 | Application Software Security |
CIS_16_3 | Vulnerability Acceptance Process |
CIS_TEL_1 | Telecom NF Asset Inventory via Role Inference |
CIS_TEL_2 | Telecom Protocol Audit Coverage |
CIS_TEL_3 | NF Communication Peer Baseline |
Evidence sources: enrolled sensor count, software versions, SBOM scan results, audit log event counts, behavioral anomaly scores, attack chain counts, network monitoring coverage, and telecom NF inventory.
NIS2 Directive (telecom overlay)
13 controls covering Article 21 security measures and telecom-specific addenda for essential entities (Article 3.2(b)) and Article 23 notification obligations.
| Control ID | Article reference | Name |
|---|---|---|
NIS2_A | Art. 21(2)(a) | Risk Analysis and NF Asset Classification |
NIS2_B | Art. 21(2)(b) | Incident Handling and Attack Chain Evidence |
NIS2_C | Art. 21(2)(c) | Business Continuity and NF Availability |
NIS2_D | Art. 21(2)(d) | Supply Chain Security |
NIS2_E | Art. 21(2)(e) | Security in Development and Procurement |
NIS2_F | Art. 21(2)(f) | Effectiveness Assessment |
NIS2_G | Art. 21(2)(g) | Cyber Hygiene and NF Process Baseline |
NIS2_H | Art. 21(2)(h) | Cryptography and SBI Interface Encryption |
NIS2_I | Art. 21(2)(i) | Access Control and Inter-NF Communication |
NIS2_J | Art. 21(2)(j) | NF Authentication Monitoring |
NIS2_TEL_EE | Art. 3.2(b) | Essential Entity Classification and NF Inventory |
NIS2_TEL_AC | Art. 23 | Article 23 Notification Trigger Detection |
NIS2_TEL_NF | Art. 21(2)(i) | Inter-NF Communication Integrity |
The is_essential_entity field in the NIS2 report reflects whether any telecom-role sensors are enrolled.
3GPP TS 33.117 Security Assurance
7 controls mapping eBPF telemetry to the 3GPP SECAS catalogue of general security assurance requirements. Vendor-agnostic: evidence uses observed protocol behavior, not vendor-specific binary names.
| Control ID | Section | Name |
|---|---|---|
3GPP_4_2_3 | §4.2.3 | Runtime Configuration Integrity |
3GPP_4_2_4A | §4.2.4 | Non-Root NF Process Execution |
3GPP_4_2_4B | §4.2.4 | Privilege Escalation Monitoring |
3GPP_4_2_5A | §4.2.5 | NF Communication Peer Allowlists |
3GPP_4_2_5B | §4.2.5 | SBI/NF API Interface Coverage |
3GPP_4_2_6 | §4.2.6 | Security Audit Log Completeness |
3GPP_4_3_1 | §4.3.1 | eBPF Kernel Integrity Verification |
O-RAN WG11 Security
9 controls mapped to O-RAN Alliance WG11 security requirements specifications. Vendor-agnostic: evidence sourced from kernel eBPF telemetry on port and protocol behavior.
| Control ID | Section | Name |
|---|---|---|
ORAN_O1 | WG11 §6.1 | O1 Management Interface Security |
ORAN_O2 | WG11 §6.2 | O2 Infrastructure Interface Security |
ORAN_E2 | WG11 §6.3 | E2 Interface Peer Verification |
ORAN_TIMING | WG11 §6.4 | Timing and Synchronization Integrity |
ORAN_MGMT | WG11 §6.5 | Management Plane Access Control |
ORAN_CUDU | WG11 §7.1 | CU/DU Boundary and F1 Interface |
ORAN_XAPP | WG11 §7.3 | xApp/rApp API Security |
ORAN_KPM | KPM Measurement Data Integrity | |
ORAN_F1E1 | F1/E1 Interface Boundary Enforcement |
Evidence bundles
Evidence bundles are signed snapshots of compliance state at a point in time, suitable for audit submissions and incident notifications.
Bundle types
| Bundle type | Time window | Purpose |
|---|---|---|
nis2_24h | 24 hours | NIS2 Article 23.3 initial incident notification |
nis2_72h | 72 hours | NIS2 Article 23.4 early warning with assessment |
nis2_30d | 30 days | NIS2 Article 23.5 final incident report |
compliance_30d | 30 days | General compliance snapshot (30-day window) |
compliance_90d | 90 days | General compliance snapshot (90-day window) |
Creating a bundle
Requires operator role.
In the Console, navigate to Compliance > Evidence Bundles and click Generate Bundle. Select the bundle type and framework, then confirm. The generated bundle record includes:
bundle_id: stable identifier for retrievaltitle: human-readable bundle titlegenerated_at: timestamp of generationevent_count: number of incidents and attack chains includedcontrol_count: total controls assessed across all included frameworkssignature: Ed25519 signature over the bundle contentsigning_public_key: the Console's policy signing public keysignature_algorithm:Ed25519
Listing and verifying bundles
In the Console, navigate to Compliance > Evidence Bundles to see all generated bundles. Click a bundle row to open its detail, including signature information. Click Verify Signature to confirm the Ed25519 signature is valid against the bundle content.
Compliance score history
In the Console, open any framework's compliance page and click Score History. The chart shows how the overall score has changed over time for the selected framework.
Per-control evidence
In the Console, click on any control row in the compliance table to open its evidence panel. The panel shows the specific events and sensor data that support the control for the selected time period.
Limitations
- All evidence is sourced from sensors enrolled in the Console. Nodes not covered by the Telovix Sensor do not contribute evidence and may reduce scores.
- The 3GPP TS 33.117 and O-RAN WG11 frameworks require sensors with the telecom flavor deployed on relevant nodes. Telecom evidence does not accumulate from standard-flavor sensors.
- Compliance snapshots are cached for up to 4 hours for fleet-wide queries. The
last_computed_atfield in the response indicates when the cache was last refreshed. - Evidence bundles capture state at the moment of generation. They are not automatically updated if the fleet state changes after generation.