In plain terms: any system you have on the internet can be attacked — but most large organisations cannot list every system they actually have on the internet. Attack Surface Management (ASM) is the discipline of finding all of them, including the ones nobody wrote down. This post explains how that discovery works, what AI actually adds, and why governance under ISO 27001 matters for handling what gets found.
Most enterprise security teams can tell you exactly which servers are in their Configuration Management Database (CMDB) — the official catalogue of approved IT assets, the system every change-management process relies on, the source of truth your auditor expects to see. Far fewer can tell you what is actually resolving on their DNS, responding on port 443, or accepting OAuth callbacks through a vendor portal provisioned during a 2022 M&A deal. The gap between "what we know we have" and "what an attacker can reach" is the attack surface — and in multi-cloud, multi-acquisition enterprises, that gap is wider than almost any organisation expects.
Attack Surface Management (ASM) is the discipline of continuously discovering, inventorying, and prioritising every internet-facing asset an organisation owns or is associated with — whether or not it appears in any internal registry. It is not a vulnerability scan of a list you already maintain. It is a fundamentally outside-in process: start from what an adversary sees, work backwards to what you own. The industry benchmark for day-one discovery is consistent across mature ASM engagements — organisations routinely find 30 to 60 percent more exposed assets than their CMDB records, and a meaningful fraction of those assets are actively exploitable.
Why CMDBs drift — and why it matters under PDPA
CMDBs are maintained by people under deadline pressure. A marketing team spins up a campaign subdomain on a third-party landing page builder and never files a change ticket. An acquired subsidiary keeps its legacy billing portal running because nobody has formally decommissioned it. A vendor publishes an admin portal for a core banking integration and registers it under their own domain — it resolves, it authenticates, it accepts traffic, and it appears nowhere in your asset inventory. GDPR in Europe, the UK Data Protection Act, US state regimes like the CCPA, and PDPA-class laws across Thailand, Malaysia, Indonesia, and Singapore all impose breach-notification obligations that apply regardless of whether the compromised system appeared in your internal records. Regulators do not accept "we did not know it existed" as a defence when personal data is exfiltrated.
The four drift vectors that consistently surface in enterprise ASM engagements are worth naming explicitly:
- Marketing subdomains — campaign pages, microsites, and A/B testing infrastructure provisioned outside IT change control, often with outdated TLS certificates or deprecated dependencies.
- M&A integration endpoints — APIs and portals inherited from acquisitions, frequently running software versions that predate the acquiring company's patch cycle.
- Decommissioned services that still resolve — DNS records pointing to cloud instances that were terminated but whose A records were never cleaned up, or cloud storage buckets that remain publicly accessible after the application was retired.
- Vendor-published portals — third-party operations dashboards for Core Banking, Core Insurance, or Core Telco integrations, registered under a vendor domain, unpatched on the vendor's cycle, and accepting credentials tied to your production environment.
How ASM discovery actually works
ASM discovery is not a port scan of known IP ranges — that approach presupposes you already know the scope. Effective discovery starts from a handful of confirmed anchors (primary domains, known ASN blocks, registered trademarks) and fans out passively through multiple signals simultaneously. The four main data sources are passive DNS, certificate transparency logs, ASN ownership data, and credential-leak feeds.
Passive DNS analysis replays historical resolution data to surface subdomains and IP associations that are no longer active in authoritative records but were used recently enough to indicate a real asset. Certificate transparency logs — the public record of every TLS certificate issued by a trusted CA — expose subdomains the moment a certificate is requested, often before any internal change ticket is raised. ASN ownership data maps the autonomous system numbers registered to an organisation, revealing IP ranges that may host assets not anchored to any known domain. Credential-leak feeds track the appearance of corporate email addresses and service account credentials in breach datasets, flagging the moment an asset becomes exploitable through a compromised identity rather than a software vulnerability.
The assets that hurt you most are the ones that never made it into the CMDB — because nobody filed the ticket, or the vendor published the portal, or the acquisition closed and the IT handover never happened.
What AI actually contributes to triage
A mature ASM engagement for a large enterprise can surface thousands of candidate assets on day one. Without triage, that output is noise. This is where AI adds genuine, measurable value — not in discovery itself, which is a deterministic data-collection problem, but in the three steps that determine what a human engineer actually does next.
The first step is clustering. Assets are grouped by technology stack, subdomain pattern, certificate issuer, hosting provider, and registration metadata. Clustering surfaces likely ownership — the payment-gateway subdomain cluster almost certainly belongs to the fintech integration team, not the corporate IT team — and it makes the triage output legible to the engineers who will own the remediation work.
The second step is scoring. Each finding is evaluated against two public signals: EPSS (Exploit Prediction Scoring System), which gives the probability that a given CVE will be exploited in the wild within the next 30 days, and the CISA Known Exploited Vulnerabilities (KEV) catalogue, which lists CVEs that have already been confirmed as actively exploited. A finding with an EPSS score above 0.4 and a presence in CISA KEV is a different class of risk from a finding with a theoretical CVSS 9.8 that has never appeared in any observed attack chain. AI scoring combines these signals with asset exposure context — internet-facing versus internal, authentication-required versus open — to produce a prioritised work queue rather than a severity histogram.
The third step is remediation drafting. For each high-priority finding, the AI layer generates a structured remediation brief: the specific version or configuration change required, the team most likely to own the asset based on clustering inference, the estimated effort, and the compensating controls available if immediate patching is not feasible. This brief is not a replacement for human engineering judgement — it is the context that makes Human-in-the-Loop review fast enough to be operational rather than performative.
ASM versus vulnerability scanning — the core distinction
Vulnerability scanning takes an asset list as its input. ASM produces the asset list. The two disciplines are complementary, not interchangeable — a biannual penetration test or a weekly Nessus run is only as good as the scope it is given. If an asset is absent from the scope, it is absent from the finding. ASM closes the scope gap continuously, so the vulnerability management programme is working against the real perimeter rather than the one captured in a change-management spreadsheet two quarters ago. The combination — continuous ASM feeding a risk-scored remediation queue into your vulnerability management toolchain — is what most ISO 27001 ISMS asset management controls actually require, even if the standard does not mandate the specific tooling.
ISO 27001 ISMS as the governance anchor
ISO 27001 Annex A controls require organisations to maintain an inventory of assets (A.8.1), classify them by sensitivity (A.8.2), and manage technical vulnerabilities systematically (A.12.6). ASM findings — particularly those involving assets outside the CMDB — are directly relevant to conformity with these controls. Handling ASM output responsibly also requires a governance structure: findings will include sensitive details about exposed credentials, unpatched CVEs in production systems, and occasionally evidence of prior compromise. Without a formal handling procedure backed by an Information Security Management System (ISMS — the policy and process layer that ISO 27001 certifies an organisation against, covering classification, restricted distribution, tracked remediation, and closed-loop verification), those findings can create more legal and regulatory exposure than the vulnerabilities themselves if they are mishandled.
HarmonyX runs ASM engagements under our ISO 27001 ISMS framework. Every finding is classified before it leaves the discovery pipeline, distributed under non-disclosure to named asset owners only, tracked to closure in a managed remediation register, and verified as resolved before the finding record is closed. For clients in regulated sectors — financial services under prudential regulators like the Federal Reserve, the EBA, the FCA, MAS, or BoT; telcos under sector authorities; or cross-border operators subject to multiple national supervisors — that governance layer is not optional; it is what makes the engagement defensible to an auditor.
Shadow IT and the M&A surface expansion problem
Shadow IT is not a culture problem — it is a speed problem. Engineers and business teams provision cloud resources, SaaS integrations, and external services because procurement cycles are slow and the tools are available on a credit card. The result is a persistent class of internet-facing assets that are legitimately owned by the organisation but unknown to its security programme. M&A activity compounds this significantly: due diligence rarely includes a comprehensive ASM pass on the target, and the acquired company's Shadow IT becomes the acquirer's problem at the moment the deal closes.
A focused ASM engagement in the 90 days post-close — or ideally as part of technical due diligence before close — consistently surfaces the highest-severity findings of any stage of an M&A security integration. Unpatched legacy stacks, credential reuse from the pre-acquisition engineering team, misconfigured cloud storage inherited from a startup with no formal security programme: these are the findings that make headlines, and they are almost never visible in a CMDB-scoped vulnerability scan.
What a HarmonyX ASM engagement delivers
Our ASM service runs as a structured engagement rather than a continuous SaaS subscription. The output is designed to feed directly into your existing vulnerability management, ITSM, and ISMS processes — not to replace them with a new platform that requires its own operational overhead.
- Full external asset inventory — discovered from passive DNS, certificate transparency, ASN data, and credential-leak signals, cross-referenced against your CMDB to surface the delta.
- AI-clustered, EPSS + CISA KEV-scored finding report — findings grouped by probable owner and ordered by real-world exploitability, not theoretical severity.
- Remediation briefs — per-finding structured guidance that a team lead can review and assign in a sprint planning session, not a raw CSV dump requiring days of analyst interpretation.
- ISMS-governed findings handling — classification, restricted distribution, tracked remediation register, and closure verification aligned to ISO 27001 A.8 and A.12 controls.
The right time to start is before the breach, not after
ASM findings age badly. A subdomain flagged as low-severity today becomes critical the week a proof-of-concept exploit is published for the framework it runs on. EPSS scores are probability estimates, not guarantees — the CISA KEV catalogue grows by roughly two to five entries per week, and any of those entries could match an asset in your blind spot. The cost of a post-breach forensic engagement, PDPA breach notification, regulatory response, and reputational recovery is orders of magnitude higher than the cost of a proactive ASM engagement. The organisations that treat attack surface visibility as a continuous operational function, rather than a periodic audit deliverable, consistently handle incidents faster, contain them to a smaller blast radius, and demonstrate measurably stronger posture to auditors and insurers.
Talk to us about your exposure
HarmonyX runs structured ASM engagements backed by our ISO 27001 ISMS framework — from initial discovery sprint through to a tracked remediation register your security team can hand directly to an auditor. If your organisation operates across multiple cloud environments, has gone through an acquisition in the last 24 months, or is subject to financial-sector or critical-infrastructure regulatory oversight in any major jurisdiction, the gap between your CMDB and your real attack surface is worth quantifying before someone else does it for you. See how our Attack Surface Management service is scoped at /services/attack-surface-management — or reach out directly to scope a discovery sprint.
