Building a Repeatable Public-Sector Exposure Baseline
Everything useful about external exposure work reduces to repeatability. A one-off measurement answers a question once; a documented baseline answers it every month, and the comparison is where the value sits.
Estonia’s September 2026 report from the Riigi Infosüsteemi Amet (RIA) provides the motivation: DDoS against multiple public-service sectors, more than 86 million requests against the national authentication service, a health-data breach at a dental IT processor, and an e-bookstore intrusion via an unpatched flaw. Four different failure modes in one month, all involving systems that were reachable.
The baseline specification
A baseline that can be handed to another team has five parts.
Scope. The country, industry, organisation, domain set or network range being measured.
Query. The exact query string, recorded verbatim.
Unit. Whether the count refers to domain assets, hosts, services or certificate matches.
Date and time zone. Measurements are only comparable within a consistent window.
Interpretation limits. A one-line note on what the count does not establish.
Estonia’s numbers, expressed in that form, look like this.
country="EE" && industry="government"
Exposure: 263 matching assets (industry-classified, 2026-10-14 UTC)
country="EE" && service="https" && is_domain=true
Exposure: 21,335 domain assets (2026-10-14 UTC)
country="EE" && port="443"
Exposure: 135,740 assets (hosts answering on port 443, 2026-10-14 UTC)
country="EE" && service="ssh"
Exposure: 98,788 matching assets (2026-10-14 UTC)
Written this way, each line can be re-run by someone who was not involved in producing it.
Choosing the layers to baseline
Public-sector exposure has several layers, and a practical baseline covers four of them without attempting to cover everything.
- Sector scope. The narrow, classified slice used for prioritisation — for Estonia, government-industry assets at 263.
- Web presence. Domain assets serving HTTPS, at 21,335.
- Reachable services. Everything answering on the main service ports, illustrated by 135,740 assets on port 443.
- Administrative surface. Non-web protocols, illustrated by 98,788 SSH matches.
The web and administrative layers answer different questions and frequently diverge. Reviewing only the first produces an inventory that omits a large share of inbound-capable systems.
Operating the baseline
A baseline becomes useful when it runs without a project manager.
- Fix a cadence. Monthly for the narrow scope, quarterly for the broad layers.
- Version the scope definition. Record changes rather than adjusting queries quietly.
- Attribute before prioritising. A count that cannot be mapped to owners cannot produce work.
- Track removals, not just additions. Decommissioned systems that remain reachable are a control failure.
- Re-measure after remediation. Confirmation is part of the fix.
Common mistakes
Changing the query between measurements. This produces an incomparable series and is the single most common way baselines lose their value.
Summing overlapping counts. Domain, host and service counts overlap; adding them yields a number with no referent.
Treating visibility as vulnerability. An indexed asset is not a compromised asset, and the September report does not claim host-level compromise at the DDoS-targeted sites.
Ignoring the non-web layer. Administrative exposure rarely appears in incident reporting and therefore rarely appears in reviews.
What the September evidence supports
RIA’s report establishes incident facts and effects, not asset counts. The measurements in this analysis were taken externally in mid-October 2026 and describe a standing condition rather than the state of Estonian infrastructure during the attacks.
The transferable conclusion is procedural: incidents recur across sectors and causes, the reachable estate is knowable in advance, and a baseline written down properly is the mechanism that makes that knowledge usable when the next incident arrives.
Where ZoomEye fits
ZoomEye provides reproducible queries across country, industry, service, port, certificate and title fields, with counts that can be recorded and compared. For public-sector exposure work, that supports the four-layer baseline above without requiring access to internal systems, and it keeps the external picture current between incident-driven reviews.
References
- Riigi Infosüsteemi Amet, “September küberruumis: andmelekked ja häired riigi e-teenustes”, https://ria.ee/uudised/september-kuberruumis-andmelekked-ja-haired-riigi-e-teenustes
- ZoomEye, https://www.zoomeye.ai/
ZoomEye Query Notes
Counts collected 2026-10-14 UTC with sub_type=all:
| Query | Unit | Matching assets |
|---|---|---|
country="EE" && industry="government" |
industry-classified assets | 263 |
country="EE" && service="https" && is_domain=true |
domain assets | 21,335 |
country="EE" && port="443" |
assets answering on port 443 | 135,740 |
country="EE" && service="ssh" |
assets exposing SSH | 98,788 |
Units differ by row, counts overlap, and none of these figures is evidence of vulnerability, exploitation or compromise. They describe internet-visible assets at query time, not the state of Estonian infrastructure during the September 2026 incidents.
Top comments (0)