Building an exposure register from measurement data

To construct an exposure register from measurement data, organisations typically can generate an exposure count, but fewer can create a detailed register that answers follow-up questions about the difference in numbers and what has changed over time. This difference stems from a data model rather than additional measurements. For an observation to be reusable, it must include five fields: the precise query text, scope definition, collection timestamp, method or subtype, and count.

Without the query text, reviewers cannot verify that two observations refer to the same population. Similarly, without a timestamp, trends cannot be established. A register built on these fields might document observations like the following, all gathered from live ZoomEye data on 15 October 2026 using the sub_type=all parameter: "|" Query | Scope | Count | Date | "-" "-" "-" "-" | "app= MikroTik RouterOS " | global, product fingerprint | 938980 | 2026-10-15 | "app= MikroTik RouterOS " && port= 22 | global, SSH reachable | 505545 | 2026-10-15 | "app= MikroTik RouterOS " && port= 22 && country= HR | Croatia, SSH reachable | 3284 | 2026-10-15 | "app= MikroTik RouterOS " && port= 22 && is_ipv6=true | global, IPv6 SSH reachable | 148 | 2026-10-15 | The IPv6 row is often absent from a register and frequently alters conclusions about whether a fleet is correctly filtered.

Linking observations to an organisation's inventory makes the exposure register operationally useful. This is typically done based on network ranges rather than individual devices, with the results recorded against the range owner. The register should also record what it cannot cover, such as devices behind filtering layers, those administered by third parties, or devices in ranges that the organisation believes it owns but does not.

The primary use of the register is to detect drift by comparing the same query across different dates and investigating any increases. The secondary use is reporting, where a count without its scope is misleading as it may be interpreted as covering everything. A reviewer's first question would be whether the filtering layer was in place when the measurement was taken.

While a register of external observations describes reachability, it cannot replace a firmware inventory. Published adversary indicators, such as unauthorized configuration changes and unexplained high-privilege accounts, are device-side issues and should be recorded separately in an evidence log. To improve the register, focus on fixing the query text, recording the scope and timestamp for every count, and regularly reviewing the register. This allows a team to answer, months later, whether the situation has improved and by how much.