Skip to main content

Pro audit program · v1.0.0

Attack Surface & Digital Footprint

What does the internet know about your organisation that you don't? 5 minutes.

  • Attack Surface & Digital Footprint target area
  • — framework
  • 13 controls in this program
  • Cyentrix Cyentrix Trusted Author
Sign in to run → Back to library

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)

  1. Do you maintain a complete inventory of owned domains and subdomains, including legacy / acquired ones?

    Medium

    Do you maintain a complete inventory of owned domains and subdomains, including legacy / acquired ones?

    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

  2. Do you continuously discover internet-facing assets (subdomains, IPs, services, SaaS tenants) automatically?

    Medium

    Do you continuously discover internet-facing assets (subdomains, IPs, services, SaaS tenants) automatically?

    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

  3. Do you regularly check that only intended services are exposed to the internet (open ports / listening services)?

    Medium

    Do you regularly check that only intended services are exposed to the internet (open ports / listening services)?

    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

  4. Are admin panels and management interfaces protected from open-internet exposure (zero-trust, VPN, IP allow-list)?

    Medium

    Are admin panels and management interfaces protected from open-internet exposure (zero-trust, VPN, IP allow-list)?

    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

  5. Do you monitor certificates (TLS) for expiry, weak algorithms, and certificate transparency logs for new issuances?

    Medium

    Do you monitor certificates (TLS) for expiry, weak algorithms, and certificate transparency logs for new issuances?

    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

  6. Do you monitor for leaked corporate credentials in breach data and paste sites?

    Medium

    Do you monitor for leaked corporate credentials in breach data and paste sites?

    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

  7. Do you monitor the dark web / criminal forums for organisation mentions, employee data, or for-sale access?

    Medium

    Do you monitor the dark web / criminal forums for organisation mentions, employee data, or for-sale access?

    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

  8. Do you scan public code repositories (GitHub, GitLab, paste sites) for leaked secrets attributed to your organisation?

    Medium

    Do you scan public code repositories (GitHub, GitLab, paste sites) for leaked secrets attributed to your organisation?

    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

  9. Do you monitor for typo-squat / lookalike domains targeting your brand?

    Medium

    Do you monitor for typo-squat / lookalike domains targeting your brand?

    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

  10. Do you have a process to detect and report active phishing pages impersonating your brand?

    Medium

    Do you have a process to detect and report active phishing pages impersonating your brand?

    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

  11. Are SPF, DKIM, and DMARC fully deployed at p=reject across all sending domains?

    Medium

    Are SPF, DKIM, and DMARC fully deployed at p=reject across all sending domains?

    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

  12. Do you scan for misconfigured public cloud storage (S3, Azure Blob, GCS) tied to your organisation?

    Medium

    Do you scan for misconfigured public cloud storage (S3, Azure Blob, GCS) tied to your organisation?

    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

  13. Is there a documented incident process for attack-surface findings (with severity SLAs)?

    Medium

    Is there a documented incident process for attack-surface findings (with severity SLAs)?

    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