What is Attack Surface?

NIST's glossary, quoting SP 800-53 Rev. 5, defines it as "the set of points on the boundary of a system, a system component, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, component, or environment." Exits count as much as entries. An outbound path that lets data leave is part of the surface, which is why OWASP describes it as the points "where an attacker could get into a system, and where they could get data out."

A SOC needs a working version of that definition. Each part of the surface has a typical way in, and each way in writes to a log you probably collect already.

Types of attack surface and the telemetry that watches each one

There is a physical surface too (USB ports, consoles, the server room). CVSS gives it its own attack vector value, Physical, but in most SOCs it shows up as little more than a device-control alert.

The table describes the boundary. Once an attacker holds one account or one host, the internal surface takes over: every share, admin protocol and service that account can reach. OWASP warns that the internal attack surface is likely to be different from the external one and that some users have a lot of access. Zero trust designs shrink that internal part by making each internal request authenticate as if it came from outside.

Attack surface vs attack vector

The surface is the set of places an attacker could try. The vector is the route actually used through one of them. A VPN appliance on the internet belongs to your surface; the authentication-bypass CVE someone exploits on it is the vector. Patch the CVE and that vector closes, but the appliance stays on the surface until the next bug. Decommission the appliance and every vector that ran through it goes with it.

CVSS puts the vector on a scale. In CVSS v4.0 the Attack Vector metric has four values, and severity is higher "the more remote (logically, and physically) an attacker can be":

A Network-vector CVE on a server with no inbound path from the internet is still a problem. It is a different emergency from the same CVE on a host the internet can reach, and the next query tells the two apart.

Map the external surface from your own logs

Defender for Endpoint flags an onboarded device as internet-facing in two ways: a Microsoft external scan connected to it over TCP (or found it reachable over UDP), or the device's own network telemetry recorded incoming connections from the internet. A host or enterprise firewall rule that allows inbound internet traffic can also get a device flagged. The flag lands in the DeviceInfo table as the boolean IsInternetFacing, with the scan details in AdditionalFields. Join it with DeviceTvmSoftwareVulnerabilities and you get the exposed machines with what is unpatched on each.

// Internet-facing devices and their known CVEs, worst first (Defender XDR advanced hunting)
let exposed = DeviceInfo
| where Timestamp > ago(7d)
| where IsInternetFacing
| summarize arg_max(Timestamp, *) by DeviceId
| extend Reason = extractjson("$.InternetFacingReason", AdditionalFields, typeof(string)),
    ScannedIp = extractjson("$.InternetFacingPublicScannedIp", AdditionalFields, typeof(string)),
    ScannedPort = extractjson("$.InternetFacingPublicScannedPort", AdditionalFields, typeof(int))
| project DeviceId, Reason, ScannedIp, ScannedPort, ExposureLevel, AssetValue;
DeviceTvmSoftwareVulnerabilities
| lookup kind=inner exposed on DeviceId
| lookup kind=leftouter (DeviceTvmSoftwareVulnerabilitiesKB
    | project CveId, CvssScore, IsExploitAvailable) on CveId
| summarize CVEs = dcount(CveId),
    Cvss9Plus = dcountif(CveId, todouble(CvssScore) >= 9.0),
    WithPublicExploit = dcountif(CveId, IsExploitAvailable == true),
    ExploitableCves = make_set_if(CveId, IsExploitAvailable == true, 10),
    Software = make_set(SoftwareName, 10)
    by DeviceName, OSPlatform, Reason, ScannedIp, ScannedPort, ExposureLevel, AssetValue
| order by WithPublicExploit desc, Cvss9Plus desc, CVEs desc

The JSON keys come from Microsoft's own "find all devices that are internet-facing" query, and the columns from the schema pages of the three tables. SOCSimulator has not run this query against a live tenant. Before you trust the output:

• Run it in Defender XDR advanced hunting, not in Sentinel. Microsoft says the vulnerability management tables are not ingested into Sentinel, which accepts queries that reference them and returns no results.
• An empty result does not mean an empty surface. Only Windows devices onboarded to Defender for Endpoint can currently be identified as internet-facing. Linux web servers, network appliances and SaaS tenants will never show up here.
• The tag expires. If a device has no new events for 48 hours the internet-facing tag is removed, so a server that was exposed last week can be missing today.
• Reason says which path flagged the device: an external scan reached it, or it received incoming communication from the internet.
• AssetValue is yours to set (Low, Normal by default, or High), and ExposureLevel comes from the device's exposure score.

For any device on the list, the InboundExternalNetworkEvents("<DeviceId>") function returns its last seven days of incoming connections from public IP addresses.

How exposure changes the priority of the same alert

Simulated example generated by SOCSimulator Research. Host names, counts and ports are invented; the column names are Microsoft's.

Two alerts arrive ten minutes apart with the same title: the IIS worker process w3wp.exe started cmd.exe. Both servers run the same line-of-business web app.

On WEB01 the likely story is exploitation from the internet, so containment comes first and the WAF logs around the alert time give you the source. APP07 cannot have taken that request straight from the internet. If another internal host sent it, you are not looking at initial access any more; you are looking at someone already inside, moving between servers. Low exposure moved the alert down the patch queue and left the investigation as deep as before.

The same table catches the opposite mistake. A server the CMDB lists as internal that shows up with IsInternetFacing true, because a firewall rule allows inbound internet traffic, is a finding in its own right. Open a ticket for the rule even if the alert that sent you there turns out to be a false positive.

Attack surface analysis

OWASP's Attack Surface Analysis Cheat Sheet gives a method you can run on one application in an afternoon. List every path for data and commands into and out of the application and the code that protects those paths, plus the valuable data it handles (secrets, keys, personal data) and the controls around that data. Overlay the types of users who can reach each point, and look hardest at the two extremes: unauthenticated anonymous users and highly privileged admins. Then group the attack points by risk (external-facing or internal-facing), count how many of each type exist, and review a sample of each type.

Counting is what makes the analysis repeatable. When the count for a type changes (a first SSH listener open to the internet, a new unauthenticated API route), the risk profile changed and somebody should look. OWASP also points to two formal measures: Michael Howard's Relative Attack Surface Quotient at Microsoft, and a Carnegie Mellon metric that sums entry and exit points, channels (TCP and UDP ports, RPC endpoints, named pipes) and untrusted data elements, weighted by damage potential against attacker effort.

Attack surface management (ASM)

ASM is the continuous version of that inventory. It has to be continuous because the inventory drifts every time someone deploys something. External ASM works outside-in. Microsoft Defender EASM starts from "discovery seeds" (assets you confirm are yours) and recursively follows observed connections to infrastructure you own but may not have listed. It discovers domains, IP address blocks, hosts, email contacts, autonomous system numbers and Whois organizations, and marks each asset as recent or historic. The Defender for Endpoint tag from the query is the inside-out half, and it only sees machines that run the sensor. Microsoft Security Exposure Management puts endpoints, cloud resources and external attack surfaces into one view.

ASM and vulnerability management answer different questions. Vulnerability management finds and fixes flaws on the assets you know about. ASM finds the assets you did not know about, which matters because a host nobody listed never gets scanned for CVEs.

The SOC uses ASM output in two moments. When a new CVE is published, "do we expose this product?" gets answered from the inventory in minutes instead of a scan cycle. When discovery turns up an unknown host, the first job is finding its owner; the vulnerability ticket comes after.

Reducing the attack surface

• Remove what nobody uses. Retired test servers, stale DNS records and legacy protocols each take every vector that ran through them when they go.
• Keep admin interfaces off the internet. Put RDP, SSH and management consoles behind a VPN or ZTNA.
• Close the identity gaps. Require MFA on every internet-facing sign-in, and remove OAuth apps and service accounts that have no owner.
• Time-box vendor access. Give vendor accounts access for the length of the job and log every session, instead of leaving a standing account that nobody reviews.
• Review inbound firewall rules against the internet-facing list. A rule that exists only to "make it work" is surface.

Microsoft's attack surface reduction (ASR) rules are a narrower thing with a similar name: Defender for Endpoint rules that block behaviors malware commonly uses on Windows devices, such as Office apps creating child processes. They shrink the endpoint surface and do nothing about an exposed VPN gateway.