CTEM Phase 2: Discovery - The Age of Attack Surface Management

…………………………A list of assets is not enough…………………………………

Discovery and it’s River-flow theory

Scoping is where we choose the river and map its course Discovery is where we step into the water.

And once you’re in, the real questions begin. How deep does it run beneath the surface metrics? And what’s living below the surface that no one accounted for forgotten assets, shadow systems, abandoned subdomains, legacy exposures still breathing?

This is the phase where assumptions die.

From the shore, the river looks manageable. From inside it, you realize the truth: some currents pull sideways, some downward, some straight into chaos.

That’s exactly what Discovery does to an organization’s security posture.

It exposes what exists, not what’s documented. It reveals what’s reachable, not what’s intended. It surfaces what attackers see, not what defenders hope is true.

This phase is tool-heavy but thought-governed.

Tools like Attack Surface Management, scanners, telemetry feeds, and cloud discovery engines act as sonar probing depth, mapping movement, detecting life beneath the surface. But without judgment, without context, without intent, that sonar turns into noise.

Get the balance wrong, and Discovery collapses and protect nothing.

Get it right, and Discovery becomes the moment the organization finally understands its own river where to build dams, where to redirect flow, and where not to step at all.

What Discovery Truly Means in CTEM

Discovery in CTEM is not asset enumeration. It’s about producing decision ready path.

In traditional security programs, discovery ends once assets are listed and scans complete. In CTEM Discovery is more guided.

Discovery in CTEM is the process of establishing factual, continuously updated visibility into everything that exists within the scoped environment and determining which of those exposures actually matter within the defined threat scope.

Assets are noise. Exposure is signal. Discovery exists to convert one into the other.

This is why Discovery sits between Scoping and Prioritization. If Discovery is weak, prioritization becomes guesswork dressed up as rigor. At its core, Discovery converts assumptions into evidence.

Most organizations believe they know their environment:

• These are our domains
• These are our cloud accounts
• These are our applications

Discovery exists to challenge all of that.

Discovery Is Not Asset Counting

Counting assets does not create security. Understanding exposure does.

Attackers do not exploit what's in the list. They exploit what exists, what’s reachable, and what’s trusted without justification.

Effective Discovery collapses internal assumptions by exposing:

• Assets with no clear ownership.
• Services exposed without business approval.
• Trust relationships that contradict architectural design.
• Risk that quietly reappears after remediation.

To do this correctly, CTEM Discovery focuses on four non-negotiables:

Existence: What truly exists, not what CMDBs claim, not what tickets remember, not what teams think survived the last migration. Assets that still respond, still resolve, still authenticate exist, regardless of ownership.

Reachability: An asset that exists but is unreachable is irrelevant to attackers. An asset that is reachable even unintentionally is immediately relevant. Discovery measures attack paths, not architecture diagrams.

Relationship: Assets do not live in isolation. Discovery maps how domains connect to cloud services, how SaaS ties into identity, how forgotten systems still trust production credentials. This is where single “low-risk” assets quietly become pivot points.

Change: Discovery is not a one-time action. New subdomains, temporary infrastructure, shadow SaaS, and misconfigured APIs appear continuously. If Discovery is static, it is already outdated.

This is why Discovery in CTEM is continuous by design, not periodic by habit.

Why Discovery Can No Longer Be Manual

Manual discovery still has value for interpretation, context, and architectural understanding.

As the organization scale, it is difficult to map, Resources are created according to business requirement hence exposures persist unintentionally, and configurations drift without explicit ownership. A discovery model based on human cadence cannot maintain accurate visibility under these conditions and the process dependent on periodic human effort is always late.

This reality is what forced Attack Surface Management (ASM) into the center of CTEM Discovery.

Not as a replacement for thinking but as the only mechanism for maintaining continuous, evidence-based visibility at scale.

Which leads to the core truth of this phase:

No prioritization can fix blind discovery. No validation can secure unknown exposure. No mobilization can respond to assets that were never truly seen.

Discovery is where CTEM becomes operational not because tools run, but because of the visibility, And that visibility comes from ASM.

Why ASM Exists in Discovery

Discovery in CTEM must operate on the same timeline as change and change is continuous.

Attack Surface Management (ASM) is the discipline of continuously identifying, validating, and maintaining an authoritative inventory of all assets, identities, services, and trust relationships that are reachable within an organization’s operational boundary.

Its sole objective is accuracy of visibility not risk scoring, not prioritization, and not remediation.

In the Discovery phase of CTEM, ASM functions as a truth engine: it answers what exists, what is reachable, how it is exposed, and under what trust context at this moment, not at last scan.

ASM enforces visibility by detecting drift, shadow assets, temporary infra, misaligned ownership, and unintended exposure across cloud, on-prem, SaaS, identities, and third-party dependencies allowing Discovery to maintain an up-to-date representation of what is reachable, trusted, and externally or internally visible at any given point in time.

Within CTEM, ASM does not assess risk or assign priority. Its function in Discovery is to ensure that visibility remains current, comprehensive, and verifiable.

Why Multiple ASMs Exist: EASM, IASM, and CAASM

External Attack Surface Management (EASM) focuses on assets and services accessible from outside the organization. This includes internet-facing infrastructure, public APIs, externally resolvable domains, and unmanaged endpoints. EASM focuses on everything an attacker can touch without credentials.

EASM answers one question: Where can the attacker start?

Fact: Most ransomware intrusions do not begin with malware. They begin with exposed services RDP, VPNs, misconfigured load balancers, or forgotten cloud endpoints.

Internal Attack Surface Management (IASM) addresses exposure after initial access. It evaluates internal service reachability, trust relationships, identity permissions, and lateral movement potential. IASM is critical for understanding how low-impact entry points can escalate into high-impact compromise. IASM assumes the attacker is already inside.

IASM answers the 2nd question: If entry happens here, how far can it spread?

Fact: In multiple high-impact breaches, attackers spent weeks moving laterally using valid credentials, not exploits. IASM is the only layer that reveals this silent expansion.

Cyber Asset Attack Surface Management (CAASM) functions as a correlation layer. It does not discover assets independently but aggregates data from cloud platforms, identity providers, vulnerability scanners, and endpoint systems. CAASM enables Discovery to associate assets with identities, permissions, vulnerabilities, and configurations, allowing exposure to be analyzed as connected paths rather than isolated findings. CAASM does not scan. It connects.

CAASM answers the most curious question: Which exposure actually matters?

Fact: Most organizations already have the data needed to understand exposure but it is fragmented. CAASM turns scattered data into decision.

Attackers do not respect tooling boundaries as they:

• Enter externally (EASM)
• Expand internally (IASM)
• Exploit relationships between assets, identities, and permissions (CAASM)

Running Discovery with only one perspective produces false confidence. hence one weak point becomes infra risk

ASM Limitations and the Role of Discovery Governance

ASM provides visibility but it cannot determine business impact or evaluate architecture intent behind the creation. It also cannot independently distinguish between acceptable exposure and unintended risk. that will require human interference and the respective application owner.

Discovery governance compensates for these limitations by applying context, scope boundaries, and decision criteria to ASM output.

Discovery in Practice: When ASM Finds a Weak Link

A real Discovery program must continuously separate three different realities:

• Exposure that is accidental,
• exposure that is required,
• Exposure that hides behind business logic but still expands risk beyond necessity.

Most security programs fail Discovery because they stop at identification and never interrogate intent.

The CyberArk SMB case demonstrates what correct CTEM Discovery looks like in practice.

The Case Study: CyberArk SMB Exposure Detected During ASM Discovery

During CTEM Phase 2, ASM identified a recurring exposure pattern across the environment. A large number of Windows servers were observed with inbound SMB port open. These servers were actively receiving SMB connections from a central system, and that central system itself allowed both inbound and outbound SMB communication.

From an ASM only perspective, the signal was clear. The pattern indicated a bidirectional connectivity, a concentration of trust around a single node, and the use of a protocol with a history of exploitation, lateral movement, and ransomware propagation.

At this stage, the finding appeared High severity. And technically, ASM was correct.

What ASM Correctly Identified

ASM revealed a genuine attack surface condition. It exposed how many systems were dependent on SMB, how trust relationships converged around a single component, and how bidirectional communication existed where attackers would expect to find it. It also highlighted the presence of a high number of server that, if compromised, could influence a wide portion of the environment.

In Discovery terms, ASM answered the right question: These systems can communicate in ways attackers actively exploit.

That is not noise. That is signal.

What ASM Cannot Understand on Its Own

What ASM cannot determine is intent.

In this case, the central system identified by ASM was not a legacy server or misconfigured host. It was a CyberArk CPM/PSM component. The SMB exposure existed because CyberArk pre-requisite.

CPM and PSM initiate outbound SMB connections to managed Windows systems to perform password rotation, credential injection, and session brokering. The target servers must accept inbound SMB connections for these workflows to function. This trust relationship is documented it is requirement to the PAM operations.

ASM sees the risk created by that trust. It cannot see the business reason behind it.

That distinction is the responsibility of Discovery, not tooling.

Where Discovery Moves into Refinement

Discovery did not stop at confirming that the SMB exposure was legitimate. It went further and asked a harder question: is this exposure scoped to the minimum required for the business function to operate?

ASM data showed that SMB was open bidirectionally not only on CPM and PSM, but also on the managed target servers. While bidirectional SMB is required on CPM and PSM to initiate connections and receive responses, the same requirement does not exist for the target systems.

Target servers do not initiate SMB sessions toward CyberArk components. They receive connections. They respond within established sessions. They do not need to send outbound SMB traffic under normal PAM operation.

Discovery made this risk visible.

The conclusion was precise and defensible. CPM and PSM retained inbound and outbound SMB access as required for policy enforcement and session management. Target servers, however, were restricted to inbound only SMB. Outbound SMB connection was closed.

This change did not disrupt CyberArk functionality. It reduced exposure.

If a target server were compromised, it could no longer initiate SMB based lateral movement. It could not be used to pull data outward over SMB or pivot to peer systems. The trust path remained functional but no longer expanded beyond its intended direction.

This is not vulnerability remediation. This is exposure minimization through intent.

Why This Is a Discovery Success, Not a False Positive

Nothing ASM reported was wrong. The exposure existed. The risk was real.

What Discovery did was transform that raw signal into usable intelligence. It forced validation of PAM design, surfaced hidden dependencies, clarified radius, and exposed where it exceeded necessity.

Most importantly, it turned an implicit trust relationship into an explicit exposure

Discovery did not eliminate SMB. It eliminated unjustified connection.

That is CTEM operating at maturity. The organization now understood the real question:

If infra is compromised by SMB, what systems are immediately exposed?

At the End Tools Alone Fail the Discovery

If ASM operated without human judgment, PAM architectures would be flagged as insecure, business teams would resist, and security would lose credibility. Worse, exposure would remain poorly understood because no one would own the decision.

Discovery requires tooling for visibility, architecture knowledge for context, and human judgment to determine necessity.

After this stage, ignorance is a choice. What you carry from the river is intentional.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Na yat likhitaṁ tadevāsti, na yad dṛṣṭaṁ tadeva satyam। Yatra mārgaḥ sulabho bhavati, tatra āpad svayameva jāyate॥ ~(What is written is not necessarily what exists. What is seen is not necessarily the truth. Wherever a path is easily accessible, there danger arises on its own.) — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —