Poxek Research · easm
The next perimeter model needs confidence and time
A future-facing view of external discovery where evidence quality and change history are first-class data.
A perimeter is a changing set of claims
External discovery is built from public traces. DNS names and records, addresses, certificates, registration data, transport behavior, and application responses can reveal useful fragments of an organization's internet-facing presence. The fragments are valuable precisely because they come from different systems with different update paths, but that also makes them easy to overstate.
The future of EASM should not be a larger flat inventory. It should be a perimeter model that represents what was observed, how strongly the observation supports a relationship, and when that support was last checked. In other words, it should treat confidence and time as data rather than decorative labels.
This evidence model follows from the technologies involved. DNS is distributed, cached, and organized around names. Certificate Transparency records the issuance or observation of certificates so certificate-authority activity can be audited. RDAP defines uniform queries for registration information. Each source has a different meaning, scope, and freshness profile. Combining them can improve investigation context; conflating them can create false certainty.
Evidence has a type and a scope
An external signal should be stored with a precise statement of what it supports. A DNS response may support that a resolver returned an A, AAAA, CNAME, MX, or NS record at a particular time. It may not support that the address is exclusively used by one organization or that an application is active. RFC 1034 is explicit that DNS data is distributed through authoritative servers and caches, and resource records carry TTLs that bound cache retention. The correct model stores the response, collection point, and time rather than promoting the result to timeless truth.
Certificate data has another scope. RFC 6962 describes a system for publicly logging certificates and precertificates with auditable proofs. A certificate name can be a strong lead for discovery, especially when it connects to known organizational identifiers. It does not prove that the hostname resolves, serves a current application, belongs to the same legal entity, or has an approved business owner. Certificates can be issued ahead of deployment, retained after retirement, or requested for names managed by a provider.
Registration data adds a third kind of evidence. RDAP standardizes RESTful query patterns for registration information from registries. Its responses can help an analyst understand a public registration object, subject to the access rules and policy of the relevant registry. It is not a universal ownership database. Privacy, resellers, delegated administration, and organizational structure all limit what a registration response can establish.
The record should therefore say "observed certificate name" or "registration relationship returned by this registry" before it says "organization asset." Labels that compress the evidence into one conclusion save interface space but erase the information a reviewer needs when the conclusion is disputed.
Confidence should be explainable
Confidence scores are useful only when a user can inspect their basis. An opaque number such as 86 percent encourages false precision; it gives no clue whether the relationship rests on a direct confirmed mapping, several independent public signals, a historical pattern, or a weak string similarity.
A more defensible model has a small number of explicit states. For example, an identifier can be observed, correlated, reviewed, confirmed, rejected, or unresolved. The state describes the workflow position, while the evidence list explains why it reached that position. A confidence indicator can still help triage, but it should be accompanied by the contributing evidence and the rule or analyst decision that changed it.
This distinction becomes important at scale. A security team may accept an automatically correlated subdomain for review because it is within an approved parent namespace and has recent supporting records. The team should not automatically convert that correlation into a confirmed production asset without a responsible owner or internal source of truth. NIST SP 800-53 CM-8 frames component inventory around accuracy, appropriate granularity, and accountability information. Those requirements point to an organizational decision that public telemetry alone cannot make.
Evidence may also conflict. One source can suggest that an endpoint is associated with a company while another indicates a third-party operator. Instead of forcing an early resolution, the model should retain the conflict, lower the confidence of the claim, and direct it to an appropriate reviewer. Suppressing contradictions is a fast way to produce a clean-looking but unreliable map.
Change history is part of the evidence
Most perimeter questions are really change questions. Did this hostname appear after the approved launch? Did the DNS target move? Did a certificate introduce a new name? Did an endpoint stop responding? A point-in-time snapshot cannot answer those questions without a baseline.
An evidence model should preserve first observation, last observation, material attribute changes, and review events separately. A new certificate name is not the same event as a newly reachable service. A DNS response changing its target is not the same as a new owner confirmation. A record disappearing from collection is not necessarily a decommissioning. These distinctions let operators compare like with like.
Time also constrains action. An old observation can be useful for investigation but unsafe as an automated remediation trigger. A recent but weak correlation may warrant review before any ticket is sent. A confirmed asset with no recent observation can be marked for revalidation rather than silently removed. The model should make freshness visible alongside confidence, not hide both behind a current-state label.
Design implications for an AI-assisted EASM workflow
AI can help organize this evidence: cluster related identifiers, summarize a change sequence, flag missing provenance, and prepare a review packet. Its output should remain a proposal. The system must preserve raw observations, the relationship path, the timestamp, and the human confirmation or rejection that follows. Otherwise an analyst cannot distinguish a supported conclusion from a fluent reconstruction.
An AI-assisted workflow also needs bounded inputs and actions. It should use approved organization seeds, collect only within authorized scope, and avoid treating third-party references as permission for broader enumeration. When a proposed relationship is ambiguous, the correct action may be to wait for an owner review, not to expand collection or raise an incident automatically.
Poxek's EASM direction can be evaluated against this standard: can a reviewer see why the model believes an item is related, what changed, what remains uncertain, and who can resolve it? If the answer is yes, the perimeter model can support exposure validation and SOC investigations without pretending that public evidence is complete organizational knowledge.