Skip to content

Elastic Dashboard: Device and Endpoint Crypto Inventory

The per-device lens on the fleet — a searchable, exportable inventory of what cryptography each individual source host and destination service is actually negotiating.

See Dashboards Overview for shared conventions, color palette, and data source details.

Purpose

The other dashboards in this suite answer aggregate questions — how many connections, what percentage, which algorithms are trending. This is the only dashboard built to enumerate individual endpoints rather than summarize across them. It exists because crypto remediation is ultimately a per-device activity: someone has to know that this specific host is still negotiating a classical-only cipher, and hand that off to a ticketing system.

At enterprise scale (100,000–500,000+ devices), building a complete Cryptographic Bill of Materials (CBOM) by hand is not feasible — this dashboard is the automated, continuously-updated alternative. It's the reference view for asset managers and network engineers who need to answer "what is device X actually doing?" rather than "what percentage of the fleet is doing it?"

Panels

Panel Type What It Shows
Unique Source Host Count KPI (custom Vega) Approximate distinct count of source.ip in the time window — the size of the device population covered by this inventory.
Unique Destination Host Count KPI Approximate distinct count of destination.ip — the scope of services being inventoried.
PQC Adoption Rate KPI Percentage of connections where pqc.quantum_safety is Secure — the same headline metric as Fleet Posture, shown here for device-inventory context.
Device Posture Inventory Table Data table Top 500 source.ip values, sorted by vulnerable-connection count, with total/vulnerable/secure counts, top cipher, top key exchange group, and remediation priority per device. Paginated, CSV-exportable.
Device Risk Distribution Vertical bar chart Unique device count (cardinality(source.ip)) per pqc.assessment.remediation_priority tier — sizes each remediation wave in device counts, not connection counts.
Destination Service Crypto Profile Data table Top 200 destination.ip + destination.port pairs with connection count, top cipher, top key exchange group, and top quantum-safety status per service.
Client Advertised PQC Groups Horizontal bar chart Top 20 pqc.handshake.client_hello.supported_groups values — identifies PQC-capable clients even when the negotiated connection ended up classical.
Key Exchange Group Usage per Source Segment Stacked bar chart Top 20 source.ip values on the x-axis, stacked by negotiated key exchange group — highlights which hosts or segments lag in PQC adoption.

Why Unique Source Host Count is a custom visualization

This KPI is built as a custom Vega panel rather than a standard Kibana Lens metric. A plain cardinality aggregation on source.ip needs a tuned precision_threshold to stay accurate past tens of thousands of unique values, and this panel also needs to combine counts across both the standard enterprise index and an agentless data stream. Every other panel on this dashboard is a standard Lens visualization — this is the only exception, and it's the one place where Splunk-side mirroring of this dashboard would need custom handling rather than a like-for-like panel translation.

Data Schema

Field Description
source.ip Primary device identifier (client side of the TLS handshake). Drives the Unique Source Host Count, Device Posture Inventory Table, Device Risk Distribution, and Key Exchange Group Usage panels.
destination.ip / destination.port Identify the destination service. Drive the Unique Destination Host Count and Destination Service Crypto Profile panels.
pqc.quantum_safety Drives the PQC Adoption Rate KPI and the per-device/per-service safety breakdowns.
pqc.assessment.remediation_priority Drives Device Risk Distribution and appears as a column in the Device Posture Inventory Table.
pqc.handshake.client_hello.supported_groups Client-offered key exchange groups — drives the Client Advertised PQC Groups panel, used to spot PQC-capable clients being downgraded by a server.
pqc.handshake.server_hello.key_share.group Negotiated key exchange group — drives Key Exchange Group Usage per Source Segment and the "top KEX group" columns in both tables.
tls.cipher Appears as the "top cipher" column in both inventory tables.
host.name Optional enrichment field for device hostname when available; source.ip remains the primary identifier since hostname is not always populated.

Reading the Dashboard

  • The Device Posture Inventory Table shows the top 500 devices by vulnerable count, not all devices. In a fleet of 100,000+ devices, that table is a triage view. Use the CSV export for complete enumeration when building a full CBOM or a bulk remediation ticket batch.
  • Cardinality KPIs are approximate at high scale. The Unique Source/Destination Host counts use approximate distinct-value counting; treat them as accurate to within a small margin at very high device counts rather than exact figures.
  • Filter by subnet to scope the view. Use KQL in the Kibana filter bar (for example, source.ip: 10.10.*) to narrow every panel to a specific VLAN, subnet, or asset group.
  • Client Advertised PQC Groups vs. negotiated groups tells you where the blocker is. If a host shows up frequently in Client Advertised PQC Groups but its connections are still classified Vulnerable, the client is PQC-capable and the destination server is the thing blocking adoption — cross-reference with Algorithm Migration Tracker's Client-Server PQC Gap Analysis panel.

Back to Elastic Dashboards Overview