About this program
Attackers map you before they hit you — domains, exposed services, leaked credentials, typo-squat sites, employee data on the dark web. This assessment scores how well you see what they see. Aligned to NIST CSF ID.AM, ISO 27001 A.5.9 + A.8.10, and NIS2 attack-surface obligations.
Controls (13)
-
Do you maintain a complete inventory of owned domains and subdomains, including legacy / acquired ones?
MediumThis control requires the organization to maintain a comprehensive, continuously updated inventory of all Internet-facing domains and subdomains under organizational ownership or control, including those inherited through mergers, acquisitions, legacy systems, and third-party registrations. The inventory must include registration details,…
How to test + evidence
Risk: Subdomain takeover (CNAMEs pointing at decommissioned services) is one of the cheapest, highest-impact attacker wins. Inventory hygiene is the only sustainable defence.
Testing procedure: Pull the domain register and reconcile with registrar accounts (GoDaddy, Cloudflare, AWS Route 53, etc.) and DNS records. Look for orphan subdomains pointing at decommissioned services.
Evidence to collect: Domain register with registrar + owner per domain Registrar account exports DNS zone audit covering all registered domains Sample of recently-discovered orphan subdomains
-
Do you continuously discover internet-facing assets (subdomains, IPs, services, SaaS tenants) automatically?
MediumThis control validates the organization's capability to automatically and continuously identify all internet-facing digital assets, including subdomains, IP addresses, open ports and services, cloud service tenants, and shadow IT. The process involves deploying automated asset discovery tools that scan external…
How to test + evidence
Risk: New external assets appear constantly — marketing landing pages, dev environments, acquired companies. Continuous discovery surfaces them before attackers do.
Testing procedure: Inspect the EASM tool or recon scripts. Pull last 30 days of new-asset alerts. Compare against the inventory.
Evidence to collect: EASM tool subscription / recon tooling Last 30 days of new-asset alerts Investigation tickets for unknown assets
-
Do you regularly check that only intended services are exposed to the internet (open ports / listening services)?
MediumThis control ensures that organizations maintain visibility into internet-exposed services by regularly scanning external-facing IP addresses to identify open ports and active listening services, comparing findings against an authorized baseline, and remediating unauthorized exposures. The process involves automated scanning tools,…
How to test + evidence
Risk: Exposed admin interfaces (RDP, SSH, database ports, hypervisor consoles) on internet-facing IPs are a leading initial-access vector. Daily checks catch accidents within 24 hours.
Testing procedure: Inspect external scan schedule. Pull the last scan and confirm coverage matches the asset inventory. Check that any non-baseline ports trigger investigation.
Evidence to collect: External scan schedule and last results Baseline of expected open ports per asset Sample alerts on new exposed services
-
Are admin panels and management interfaces protected from open-internet exposure (zero-trust, VPN, IP allow-list)?
MediumThis control ensures that administrative interfaces, management consoles, and privileged web portals (e.g., control panels for servers, databases, cloud platforms, network devices) are not directly accessible from the public internet. Protection mechanisms include zero-trust architecture with multi-factor authentication, VPN tunnels…
How to test + evidence
Risk: Public-facing admin interfaces are the headline finding in most breach reports. Universal ZTNA / VPN gating is the gold standard; everything else is a managed risk.
Testing procedure: Run an external port scan looking for management interfaces (3389 RDP, 22 SSH, 8080/8443 admin, 3306 DB, 5432 Postgres, 27017 Mongo, hypervisor consoles 902/443). Verify each result is intentional and protected.
Evidence to collect: External scan with management ports highlighted ZTNA / VPN deployment showing admin panel coverage IP allow-lists per panel
-
Do you monitor certificates (TLS) for expiry, weak algorithms, and certificate transparency logs for new issuances?
MediumThis control ensures that organizations continuously monitor all TLS/SSL certificates in use across their infrastructure for potential security weaknesses and expiration events. Monitoring includes tracking certificate validity periods with automated alerts prior to expiry, scanning for deprecated or weak cryptographic…
How to test + evidence
Risk: CT log monitoring catches malicious issuance for your domains within minutes. Certificate expiry is also the most embarrassing self-DOS — easily preventable with automation.
Testing procedure: Inspect cert monitoring tooling (cert-manager, Let's Monitor, crt.sh queries). Verify alerting is configured for both expiry and unexpected issuance against owned domains.
Evidence to collect: Certificate inventory + expiry dashboard Certificate Transparency log monitoring Sample of alerts triggered
-
Do you monitor for leaked corporate credentials in breach data and paste sites?
MediumThis control involves the continuous monitoring of publicly available breach databases, paste sites (e.g., Pastebin, GitHub Gists), dark web forums, and credential dump repositories for corporate credentials such as email addresses, usernames, and passwords associated with the organization's domains. Organizations…
How to test + evidence
Risk: Most credential-stuffing attacks use leaked credentials from third-party breaches. Domain-wide monitoring is the only way to catch this between annual password rotations.
Testing procedure: Inspect the credential-monitoring service. Verify it covers your primary domain and any acquired/rebranded ones. Trace one recent leak to a forced password reset.
Evidence to collect: HIBP / Recorded Future / SpyCloud subscription Domain coverage list Sample recent leak with reset action
-
Do you monitor the dark web / criminal forums for organisation mentions, employee data, or for-sale access?
MediumDark web and criminal forum monitoring involves continuous or periodic surveillance of hidden marketplaces, paste sites, data breach forums, and underground communities where stolen credentials, corporate data, and network access are traded. Organizations deploy specialized threat intelligence tools, engage managed…
How to test + evidence
Risk: Initial-access brokers list compromised orgs for sale on forums weeks before ransomware hits. Dark-web monitoring is the early-warning sensor that nothing else gives you.
Testing procedure: Inspect the dark-web monitoring contract (Recorded Future, Flashpoint, Cybersixgill, KELA, ZeroFox). Verify keyword coverage includes the company, brand variations, executive names, and key applications.
Evidence to collect: Dark-web monitoring service subscription Keyword / selector coverage list Sample alerts + response
-
Do you scan public code repositories (GitHub, GitLab, paste sites) for leaked secrets attributed to your organisation?
MediumThis control requires systematic monitoring of public code repositories (GitHub, GitLab, Bitbucket), paste sites (Pastebin, GitHub Gists), and other publicly accessible platforms to detect inadvertently exposed credentials, API keys, private keys, certificates, and other secrets belonging to the organisation. Automated…
How to test + evidence
Risk: Developer accidents put AWS keys, database passwords, and API tokens in public repos every day. Tools like GitGuardian alert within minutes — without them, attackers find them via the same scans.
Testing procedure: Inspect the secret-scanning tool (GitGuardian, GitHub secret scanning, TruffleHog). Verify coverage of public repos owned by employees, not just corp orgs.
Evidence to collect: Secret-scanning tool with org coverage Sample alerts in last 90 days Remediation playbook for leaked-secret events
-
Do you monitor for typo-squat / lookalike domains targeting your brand?
MediumTypo-squat and lookalike domain monitoring is a defensive control that continuously scans domain registrations, SSL certificate transparency logs, and DNS zones for domains resembling the organization's legitimate brand names, trademarks, or critical service domains. These malicious domains exploit user typos…
How to test + evidence
Risk: Typo-squat domains drive most successful business-email-compromise. Detecting them at registration and pursuing takedowns dramatically reduces phishing success rate.
Testing procedure: Run dnstwist or equivalent against your primary domain. Cross-reference against your existing register of known-malicious lookalikes. Verify a takedown path exists.
Evidence to collect: Lookalike-domain monitoring service or scripts Register of known typo-squat domains Takedown process / vendor relationship
-
Do you have a process to detect and report active phishing pages impersonating your brand?
MediumThis control establishes a continuous monitoring capability to detect fraudulent websites, phishing pages, and domains that impersonate the organization's brand, trademarks, or digital properties. The process typically involves automated monitoring services, threat intelligence feeds, domain monitoring tools, and manual investigation…
How to test + evidence
Risk: Phishing pages have a half-life measured in hours. Automated detection plus an established takedown vendor cuts customer harm dramatically.
Testing procedure: Inspect the brand-monitoring service (Netcraft, PhishLabs, ZeroFox). Sample 5 takedowns from the last 90 days; verify time from detection to removal.
Evidence to collect: Brand monitoring service contract Takedown process / playbook Sample takedowns with SLA tracking
-
Are SPF, DKIM, and DMARC fully deployed at p=reject across all sending domains?
MediumThis control ensures Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) records are correctly configured and enforced across all organizational email sending domains. SPF authorizes sending mail servers by IP address, DKIM…
How to test + evidence
Risk: p=reject is the only setting that actively prevents domain spoofing. p=none and quarantine still let spoofed mail land — they only generate reports.
Testing procedure: Look up DMARC, SPF, DKIM records via dig for all owned sending domains. Verify p=reject (not none/quarantine) and that DMARC reports are being received and reviewed.
Evidence to collect: DNS records for SPF / DKIM / DMARC per sending domain DMARC report aggregator dashboard (e.g. Valimail, dmarcian) Documented review cadence
-
Do you scan for misconfigured public cloud storage (S3, Azure Blob, GCS) tied to your organisation?
MediumThis control requires the organization to proactively and continuously scan Internet-accessible cloud storage buckets (AWS S3, Azure Blob Storage, Google Cloud Storage) for misconfigurations that expose data publicly or to unauthorized principals. Scanning is typically performed using automated tools that…
How to test + evidence
Risk: Public-bucket leaks remain the #1 cause of "unintentional" cloud breaches. Continuous scanning catches them within hours of misconfiguration.
Testing procedure: Inspect the CSPM tool or run ScoutSuite / Prowler against owned cloud accounts. Verify findings on public buckets are remediated within SLA.
Evidence to collect: CSPM scan reports Public-bucket findings + remediation timeline Cloud account inventory
-
Is there a documented incident process for attack-surface findings (with severity SLAs)?
MediumThis control requires a formal, documented incident response process specifically tailored to security findings identified through attack surface management activities (external asset discovery, exposed service enumeration, vulnerability scanning of internet-facing assets). The process must include defined severity classifications and corresponding…
How to test + evidence
Risk: Generic incident response is too slow for attack-surface findings. Pre-baked playbooks per finding type (and named owners) cut response time from days to minutes.
Testing procedure: Inspect the playbooks for: leaked credentials, exposed admin interface, lookalike domain, public bucket, expired certificate. Verify owner + SLA per type.
Evidence to collect: Per-finding-type playbooks Sample tickets resolved within SLA Severity matrix mapping finding type → priority