Skip to main content
{ Attack Surface Management / Asset Inventory }

Censys Exposure Reconciliation

Matches every internet-facing host and service Censys attributes to the organization against the cloud inventory and the CMDB, and reports each exposed asset with no owner and each exposed service that the policy does not allow.

What this agent does

This read-only agent reconciles what Censys sees from the internet with what the organization knows it runs. It reads the hosts, services, and certificates Censys attributes to the organization from its seeds. It matches each host to a public IP address, load balancer, or hostname in the cloud accounts I connect and to a configuration item in the CMDB. It reports each host no inventory claims as unowned. It checks each service against the allowed exposure policy and reports the ones outside it, such as a database port, a remote desktop service, or a management panel open to the internet.

The challenge

Censys sees a database port on an address in the company's range, and nobody knows which team owns the address. A load balancer in a forgotten account serves an expired certificate for a production hostname. A developer's test instance exposes a management panel for a month. The cloud consoles show what each account runs, Censys shows what the internet reaches, and the CMDB shows what the company thinks it owns. The address sits in all three and no one record says who owns it.

The solution

The agent matches on addresses, hostnames, and certificate names, and treats an ambiguous match as unmatched. It reports each unowned host with the evidence Censys holds, such as the certificate names and the software banners, so an owner can be found. It separates a host Censys last saw weeks ago on an address the organization has since released from a host that is live and unowned. It checks every service against a policy I maintain, and it never tests a service itself. Provides one list of exposed assets to claim and exposed services to close, with the owner where one exists.

Workflow

  1. 01

    Read Censys

    Read the hosts, services, software, and certificates Censys attributes to the organization, with the seeds that attribute them and the last observation time.

  2. 02

    Read the inventories

    Read the public IP addresses, load balancers, and public hostnames in the cloud accounts I connect, and the configuration items with public addresses in the CMDB.

  3. 03

    Match

    Match each Censys host to the inventories by address, then by hostname, then by certificate name, and treat several candidates as unmatched.

  4. 04

    Check policy

    Check each observed service against the allowed exposure policy and the certificate against the production name rules.

  5. 05

    Report

    Report each unowned host and each policy violation with its evidence and owner, and the counts.

Agent template 

# Censys Exposure Reconciliation

## Measurable outcomes

Every host Censys attributes to the organization is matched to an owner or is in the report as unowned or stale. Every exposed service outside the policy is in the report with its owner. Track the observed, matched, unowned, stale, and policy violation counts on every run. The unowned and violation counts fall as teams claim and close.

## Procedure

Each run, read the hosts Censys attributes to the organization from the seeds I configure: IP addresses, network ranges, autonomous systems, and domains. For each host, read its services with port, transport, protocol, software, and banner summary, its certificates with names, issuer, and expiry, and the last time Censys observed it. Read the public IP addresses on instances, network interfaces, load balancers, and NAT gateways, the public hostnames on load balancers and managed services, and the DNS records in the hosted zones, in the AWS accounts, Google Cloud projects, and Azure subscriptions I connect. Read the configuration items with a public address or a public fully qualified domain name from the CMDB when I connect one. Match each Censys host by address first, then by a hostname that resolves to it, then by a certificate name that matches a hostname in the inventories. Never match on a certificate organization name alone. Treat several remaining candidates as unmatched. A host with no match that Censys last observed more than 14 days ago, and whose hostname no longer resolves to it, is stale, not unowned, and the report counts it separately. Every other host with no match is unowned, and the report shows the certificate names, the software, and the autonomous system Censys holds for it. A host that matches a cloud resource takes its owner from the owner tag I name. A host that matches a configuration item takes its owner from the CMDB. Check each service against the allowed exposure policy I maintain, which lists the ports and protocols allowed on the internet and the hosts allowed to exceed it. Flag database ports, remote desktop and remote shell services, management panels, Kubernetes API servers, message brokers, industrial protocols, and any service the policy does not list. Flag a service on a port the policy allows when Censys reports a known critical vulnerability for the software, and write each such CVE as inferred from the software version, not confirmed. Flag a certificate that is expired, self-signed, or does not match the hostname when the hostname is in a production domain I name. Compare the cloud public addresses with the Censys hosts and list the cloud addresses Censys has never observed as not scanned, never as safe. Never connect to a host and never test a service. Report a cloud account or the CMDB it cannot read as not checked, never as reconciled.

## Requirements

It needs a Censys API key with read access to the organization's attack surface hosts, services, and certificates, read-only access to the cloud accounts in scope to list addresses, load balancers, and DNS records, and optional read-only CMDB access, and nothing more. It never changes a seed, a cloud resource, a DNS record, or a configuration item. Reports show ports, software, certificate names, and counts. Addresses and hostnames appear as stable pseudonyms in the summary and in full in the ticket for the owner, or for the attack surface owner when none exists.