Turning Visibility Into Defense: Connecting the Attack Surface to the Detection Surface

An organization’s Attack Surface and its Detection Surface are inextricably linked—and when understood together, they form a foundation for better cybersecurity decision-making. They help leaders make the most of limited time, budget, and people to reduce the risks that matter most.

We will start here. I’ve created my own definition of the Attack Surface over the last few years after speaking with hundreds of CISO’s and other cyber leaders. As I define it, the Attack Surface is all the computers (workstations, servers, containers, etc.), identities, and cyber-physical assets that a cybersecurity team is responsible for protecting from threats. For brevity, I will just use the word assets for the rest of this article. I want to highlight that “responsibility” is a key point in the definition, as teams may not be responsible for protecting all business assets. Clarity is needed from leadership on what and where to focus. While we're here, I would be remiss to not call out that Public-facing systems are not the full Attack Surface. They’re just the observable tip. The bulk of enterprise digital estates live behind the internet—on-prem, internal networks, cloud private zones, operational environments, unmanaged pockets.

The Attack Surface is related to but not the same as an asset inventory. Your Attack Surface may be most of your inventory, or only a subset, depending on what is considered “attackable” , exposed, or business-critical. With that said, an asset inventory is a critical tool needed to effectively measure your attack surface. Combining your asset inventory with context on threats, vulnerabilities, exposures as well as business function & impact ultimately is what derives your Attack Surface. [I will admit that I sometimes use  Inventory & Attack Surface interchangeably to simplify communication to certain audiences.]

A useful rule of thumb is

Asset Inventory	Attack Surface
List of Assets	Assets that are to be protected
IT-informed	Risk-informed, threat-informed

If the Attack Surface is 

All the assets that an organization is responsible for protecting from threats

then the Detection Surface is your ability to detect the types of attacker behavior (TTPs) that can occur within your Attack Surface. Note that the Attack Surface is the common denominator here. But put simply, the Detection Surface refers to the types of detection technologies (e.g. EDR, NTA, UBA/ITDR, etc.) deployed, along with the detections enabled that cover the types of TTPs that threat actors will use to threaten your Attack Surface. As an example, if you have EDR deployed on 80% of the assets in your Attack Surface, then you have a Detection Surface gap of at least 20% for EDR (but the gap will actually be larger as we will see shortly).

Before we get deeper into the Detection Surface, let’s get a better grounding in the Attack Surface. We will start with how some organizations try to measure it today.

Measuring Your Attack Surface

Just to call it out, most organizations can NOT measure their Attack Surface with reasonable accuracy. According to Gartner, only 17% of organizations can accurately identify and inventory most of their assets. One of the reasons is that Microsoft Excel is the number one tool used to attempt to solve this problem (Arguably the most widely deployed IT & IS tool in existence). Your vulnerability scanner is probably the next most used tool but it’s not fully deployed across all your networks, and lacks a lot of context. For enterprises, ServiceNow CMDB is out of date due to bad hygiene. The better tools of the day are Cyber Asset Attack Surface Management (CAASM) but these are not widespread, and External Attack Surface Management (EASM) only sees the internet facing assets.

Using Excel as an example, it’s easy to understand why most organizations do not have great visibility into their Attack Surface. The majority of teams will log into each of their IT and IS tools, and export the number of assets (which will be different for each tool). Each tool’s perspective on the asset list will get its own column in the spreadsheet. Some unlucky team member(s) then spend a significant amount of time trying to sort & collate all the data into a view where you can see the name of a unique asset (hopefully!), and whether it has device management, EDR, VM assessment, patch management etc. installed. They will find assets that are under device management but do not have EDR installed. They will also NOT find assets i.e. the shadow assets, leaving gaps in the Attack Surface. In a perfect world, we would have 100% deployment of IT management & security software. But we don’t, can’t, and won’t, and this Excel document is out of date in hours or days and there’s still assets that are not under IT management that an employee, or attacker, happily or unknowingly violated your IT policy to deploy for convenience, fun, or malicious use. In sum, at least some gaps in the Attack Surface are common for some of the following reasons:

• Networks can be managed by different teams, departments, and policies

• Each tool has its own perspective & deployment, creating fragmentation of visibility

• Teams only have so much capacity, time and budget; they just do the best they can

• Not all devices can be managed (e.g. virtual appliances, OT, etc.)

At a high-level, this means that organizations pay a lot of money for tools that disagree on the most fundamental point of “how many assets do I own?”. Active Directory really only sees what’s joined to the domain controller. Wiz sees what’s in the cloud, and your patching tool only sees what’s supported by the operating system it can be installed on. These facts create gaps in the Attack Surface, and it’s a lot of work to reconcile them.

At a high-level, this means that organizations pay a lot of money for tools that disagree on the most fundamental point of “how many assets do I own?”

Now, if we can create a reasonable asset inventory, and classify the networks, the assets that live on them, their business function, as well as the vulnerabilities, exposures, configurations, and controls that persist across them, we get closer to having a measurable attack surface. We all know the example of a publicly readable S3 bucket with confidential data, or a public facing server that has a vulnerability that has been issued a CISA KEV. Everyone knows that’s a part of their Attack Surface. But what about an insider threat? Is the workstation in the warehouse that has a bar code scanner, and read & write access to the database that manages the company’s inventory a part of your attack surface? It probably should be, but only you can define your attack surface. And that’s exactly what you should do. This is a fundamental exercise for your team. Use the best inventory you have, map out your organization, and document your “attackable” areas by risk. From there, we can figure out what our level of detection surface coverage should be.

Detection Surface Coverage

Now that we have an understanding of our Attack Surface, we need to get a better grasp on the concept of the Detection Surface. I define the Detection Surface as 

the portion of your Attack Surface where monitoring and detections are in place to identify adversarial behavior.

A fundamental truth is that the Detection Surface is always smaller than the Attack Surface. This is because any Attack Surface gap is automatically a Detection Surface gap. The Detection Surface is comprised of the following components

• The Attack Surface (the denominator)

• Available detection & monitoring technologies e.g. EDR, NTA, ITDR, SIEM, etc.

• The deployment or coverage of those technologies across the Attack Surface

• The detection rules supported and enabled

• The features, configurations, data sources & integrations enabled

Any portion of the Attack Surface where an attacker can fly under the radar due to lack of detection coverage is called a Detection Surface gap.

Slide I developed for R7 marketing content illustrating detection surface components and relationship to attack surface

Let’s use EDR as a specific example, here are several ways that EDR can leave gaps in your Detection Surface.

Gap	Examples
Deployment	Agents not installed everywhere
Architecture	Agents not supported on all assets (virtual appliance, OT, etc.)
Configuration	Disabled features, lack of tuning, add-on features
Evasion	Attackers can bypass EDR - they're not fullproof
Reliability	Network issues, agent crashes, update failures

Gaps are true for any detection technology. Another example is Network Traffic Analysis (NTA), or my preferred term Network Security Monitoring (NSM), where a network sensor device is reading packets from a switch through port mirroring technology such as SPAN, and then running detections on the network traffic. Several Detection Surface gaps can arise, such as network devices not supporting traffic mirroring or high-traffic links overloading network devices or the sensors leading to packet loss, and thus detection gaps. [Early in my career, I brought down a network by turning port mirroring on during peak business hours. It was not fun]

While not perfect, frameworks like MITRE ATT&CK and MITRE D3FEND can help organizations understand their detection surface gaps as they relate to TTPs. These are among the best tools you can use today to measure your Detection Surface, and the good news is that most EDR and SIEM products have some basic level of measurement against these frameworks. Though, they don’t cover some of the detection gaps we outlined above. That’s where we need to leverage our attack surface data to identify those gaps e.g. is EDR deployed, what is the agent status, and when did it get its last update?

Just like you’re not going to have 100% visibility of your Attack Surface, you will not have 100% coverage of your Detection Surface. You will in fact have less, because the Attack Surface is the common denominator, and any gap in it also implies a detection gap.

The goal is not perfection, the goal is alignment with the needs of the business. Prioritizing the most important areas of the Attack Surface aligned to business risk with the most effective detection technology based on your available resources is the right path.

That may mean going light in low-risk areas, while investing more in high-risk areas. It will be specific to each organization. Marrying the Attack Surface with business impact will enable you to make better use of your time, money, and people.