Compliance

Overview

Eon Insights evaluates captured traffic and certificate data against a set of compliance frameworks, each with its own scored rule set. Rules and frameworks are defined in YAML (configs/compliance/frameworks.yaml and configs/compliance/rules.yaml), seeded into ClickHouse on first startup, editable afterwards through the dashboard or the /api/compliance/rules API, and reloadable from YAML at runtime without a restart.

Frameworks

Six frameworks ship by default:

Framework	Display name
`PCI-DSS`	PCI DSS v4.0
`NIST SP 800-52`	NIST SP 800-52 Rev 2
`GDPR`	GDPR Article 32
`HIPAA`	HIPAA Security Rule
`NIS2`	NIS2 Directive
`DORA`	Digital Operational Resilience Act (EU financial sector)

Each framework starts from a base score of 100. Rules are additive deductions: every triggered rule subtracts its configured weight from that framework’s score (clamped at 0). The resulting score maps to a status:

Score	Status
≥ 95	compliant
80–94	partial
< 80	non-compliant

Rules

The default rule set ships 26 rules across the six frameworks (PCI-DSS: 3, NIST SP 800-52: 5, GDPR: 3, HIPAA: 3, NIS2: 4, DORA: 8), built from 11 distinct finding types:

Finding type	Checks for
`deprecated_tls`	TLS versions below 1.2 (or below 1.1, depending on the framework) in use
`weak_cipher`	Cipher suites classified `insecure` or `weak` in the `ciphersuites` reference table
`non_aead`	Non-AEAD cipher modes (CBC) instead of GCM/CCM/ChaCha20-Poly1305
`quantum_vulnerable`	Key exchange using RSA, ECDHE, or DHE (not post-quantum/hybrid)
`small_key`	Certificates with RSA keys under 2048 bits
`self_signed`	Self-signed certificates
`expiring_cert`	Certificates expiring within 30 days
`expired_cert`	Certificates already expired
`sha1_cert`	Certificates signed with SHA-1
`weak_ssh`	SSH connections with weak key exchange, cipher, or MAC algorithms
`weak_ipsec`	IPsec connections with weak encryption, PRF, integrity, or DH group

Each rule record (internal/rules.Rule) carries:

rule_expression — a boolean expression evaluated against the evaluation context (see below), e.g. "Ctx.DeprecatedTLSCount > 0"
finding_type, severity (critical/high/medium/low), requirement (a citation into the framework, e.g. “Article 9.2” or “164.312(e)(1)”), recommendation — the text shown in a finding
weight and is_critical — how much the rule deducts from the score, and whether it counts toward criticalFindings
count_query — the ClickHouse query used to compute how many hosts/ certificates/connections are affected, for display

How evaluation works

GET /api/compliance/stats (backed by internal/insights/compliance.go) runs on a rolling 30-day window by default:

Fetch aggregate metrics from ClickHouse into an EvaluationContext (counts of deprecated-TLS hosts, weak-cipher hosts, weak SSH/IPsec connections, small-key/self-signed/expiring/expired/SHA-1 certificates, quantum-vulnerable connections, and non-AEAD usage).
For each enabled framework, evaluate every enabled rule’s expression against that context using the Grule rule engine. A rule that fails to parse falls back to a hardcoded finding-type check so a malformed custom expression can’t silently disable a whole framework.
For each triggered rule, run its count_query to get the affected host/certificate/connection count, deduct its weight from the framework’s score, and record it as a finding (deduplicated across frameworks that share the same finding type).
Compute PQC (post-quantum cryptography) readiness stats separately: total vs. quantum-vulnerable connections, unique “critical” hosts (quantum-vulnerable key exchange), high-priority hosts (>100 quantum-vulnerable connections), and hosts already using PQC/hybrid key exchange (Kyber, ML-KEM, X25519Kyber in the negotiated cipher/key-exchange name).

GET /api/compliance/findings/{type} returns up to 100 individual connection or certificate records behind a given finding type, for drill-down from the dashboard’s summary view.

Managing rules

The dashboard’s Compliance Rules page (and the underlying /api/compliance/frameworks and /api/compliance/rules endpoints) let you view, create, edit, and delete individual rules and see which framework(s) they belong to. Changes take effect immediately — creating, updating, or deleting a rule reloads the in-memory rule engine from ClickHouse.

To reset the rule set back to what’s defined in the YAML files (adding new rules and updating existing ones by name, without touching custom-created rules):

POST /api/compliance/reload?from_yaml=true

Without from_yaml=true, the same endpoint just reloads the engine’s in-memory frameworks from whatever is currently in ClickHouse (useful after a change made directly in the database).

Dashboard