DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Building an exposure register from measurement data

#security #zoomeye #routeros #exposure

Building an exposure register from measurement data

Most organisations can produce an exposure count when asked. Far fewer can produce a register that answers the follow-up question, which is why one number is larger than the other and what changed since. The difference is a data model, not more measurements.

The fields that make a measurement reusable

Each observation needs five fields to be reusable: the exact query text, the scope definition, the collection timestamp, the method or sub-type, and the count. Without the query text, no reviewer can confirm that two observations describe the same population. Without the timestamp, no trend can be asserted.
For the RouterOS disclosure of 5 September 2026, a register built on those fields would record observations such as these, all collected against live ZoomEye data on 15 October 2026 with sub_type=all:
| 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 the one most often missing from a register, and it is the one that most often changes a conclusion about whether a fleet is properly filtered.

Linking observations to assets

An exposure register becomes operationally useful when observations can be linked to the organisation's own inventory. That usually happens by network range rather than by device: measure within the ranges the organisation controls, and record the result against the range owner. The link is then recorded once per range rather than once per host.
This is also where the register should record what it cannot cover. Devices behind filtering layers, devices administered by third parties, and devices in ranges that the organisation believes it owns but does not, are all gaps that a register should name rather than silently omit.

Using the register

The primary use is drift detection: compare the same query across dates and investigate any increase. The secondary use is reporting. A count reported without its scope will be read as covering everything, and the first question from any reviewer will be whether the filtering layer was in place when the measurement was taken.

Limits

A register of external observations describes reachability, not vulnerability, and it cannot substitute for a firmware inventory. The published adversary indicators, such as unauthorised configuration changes and unexplained high-privilege accounts, are device-side and belong in a separate evidence log.

Implications

Fix the query text, record the scope and timestamp with every count, and review the register on a schedule. The register is what allows a team to answer, months later, whether the situation improved and by how much.

References

Top comments (0)