CTEM for External Perimeter

I want to discuss a practical challenge that cybersecurity teams in large companies regularly face: protecting the hottest point in the infrastructure – the external network perimeter.

Vulnerability reports are increasing, the attack surface is constantly changing and expanding, there are always not enough hands to mitigate risks, and there is no clear answer on what to prioritize on the external perimeter.

It seems that technical measures are being implemented, various scanners, firewalls, WAFs, and other tools, but in many cases, the problem is not the lack of tools, but the disconnect between identified vulnerabilities and the business value of assets, fragmented handling of data from different protective measures, and the lack of proper synthesis into a single picture of data from both external and internal scanners.

Next, I will explain how to approach this task using the CTEM framework: linking detection results to context and telemetry, obtaining manageable priorities, and ensuring remediation leads to confirmed results through re-verification.

Why specifically the perimeter?

Before moving on to the methodology, it is important to clarify why the external perimeter almost always comes into focus.

The perimeter changes the fastest. New services emerge, configurations are modified, ports are opened and closed, temporary stands and pilots pop up somewhere. And a significant portion of risks arise precisely at the intersection of changes and control.

According to the results of the first half of 2025, our experts at Innostage SOC CyberART recorded a 50% increase in OSINT incidents, nearly reaching 10,000. Moreover, over 70% of these incidents were related to changes at the perimeter: opening ports, changing service configurations, emerging new resources, or modifications to existing information. This is an important signal: the perimeter is often vulnerable not only due to a specific vulnerability but also due to unmanaged changes and weak control over what exactly is exposed externally.

In parallel, the external perimeter experiences constant pressure. In the first quarter of 2025, according to open data, Russian companies faced 801.2 million web attacks, and vulnerability scanning increased to 678 million, accounting for 84% of all web attacks. In practice, this means a simple thing: what is accessible from the outside will be regularly checked, and any vulnerabilities will eventually come into view.

If we look at this together, a simple picture emerges: the external perimeter is rapidly changing, constantly tested by attackers, and regularly becomes an entry point in real incidents. Therefore, periodic reports and one-off remediation campaigns are not enough. A continuous managed cycle is needed that keeps pace with changes, focuses the team on addressing the most prioritized threats, and ensures control over their resolution. This is precisely the task that CTEM fits.

What is CTEM and why does it fit well with the perimeter?

Continuous Threat Exposure Management, CTEM, is a methodology for continuously identifying, assessing, and mitigating threats to a company's digital assets.

Gartner describes CTEM as 5 sequential steps: Scoping, Discovery, Prioritization, Validation, Mobilization.

● Scoping - defining boundaries

● Discovery - data collection

● Prioritization - setting priorities

● Validation - confirming applicability and reducing false positive (FP) rates

● Mobilization - implementing changes and control

The STEM methodology focuses on continuous work with threats rather than mechanical remediation of vulnerabilities.

CTEM as a process: what to do at each step

1. Scoping: defining boundaries

The result of this step is a transparent and up-to-date picture of what we need to protect: what is included in the perimeter, which business systems the perimeter assets belong to, and who is responsible for changes. At this stage:

1) It is determined which types of assets to include in the scope, for example: web, domains, VPN, public APIs, email components;

2) Criteria for criticality are introduced and a scoring scale is developed;

3) Service owners are identified;

4) Threats are modeled and primary business risks are highlighted;

5) The frequency of the scanning cycle is set (for example, weekly/once every two weeks) and the rules for handling exceptions are established.

2. Discovery: we gather exposure

The result of this step is a multifaceted view of our infrastructure: collecting current data on external and internal scanning, data on TI/OSINT intelligence, enriching vulnerabilities with information from external analytical systems. At this stage:

1) The data on assets legitimately placed on the perimeter is updated, the composition of these assets is updated, and updated data is collected from vulnerability scanners;

2) A list of shadow assets (Shadow IT) is formed - new hosts, ports, services. The legitimacy of their placement on the Organization's perimeter is clarified: whether they appeared due to an IT team's mistake or oversight, or perhaps they indicate the activity of an attacker;

3) Scanning of shadow and legitimate assets for vulnerabilities is performed;

4) The attacker's infrastructure is enriched with data from cyber intelligence: phishing domains and infrastructure targeting the organization, fake-boss accounts, indicators of compromise, industry context, and APT.

3. Prioritization: we analyze and prioritize tasks

The result of this step is not a report on vulnerabilities spanning tens of thousands of lines, but a list of priority tasks within one iteration that can realistically be accomplished. At this stage, prioritization of relevant threats is carried out based on the criticality of business assets, taking into account data from external and internal sources as well as cyber intelligence data.

The practical prioritization model in CTEM for the external perimeter involves three layers.

Vulnerability priority = technical context + business context + telemetry

1. Technical context of the vulnerability

● CVSS and type of vulnerability

● Availability of a working exploit

● Relevance according to TI and OSINT,

● Is the vulnerability being exploited now

2. Business context of the vulnerability

● Location of detection: external perimeter, DMZ, internal segment, cloud, contractor infrastructure;

● Accessibility: directly from the internet, via VPN, only from internal networks

● Criticality: what business service supports the vulnerable asset;

● Presence of compensating measures: access restrictions, isolation, additional control, etc.

3. Telemetry

● signs of preparatory activity from attackers (scanning, gathering information about the service);

● attempts to exploit vulnerabilities;

● repeat signals;

● related incidents and alerts (if any).

The essence of such models is that the same vulnerability with the same CVSS can receive different priority depending on the availability of the service, its criticality, and current activity around it.

4. Validation: confirming applicability and reducing the share of FP

The goal is to save the team's time on analyzing false positives and contentious records.

For this purpose, the following is assessed for high-priority vulnerabilities:

● exploitability of the vulnerability and availability of an exploit;

● relevance of the software version, actual configuration of the asset;

● existence of conditions for exploiting the vulnerability and compensating measures.

An optional step at this stage is the use of BAS (Breach and Attack Simulation) to safely confirm specific scenarios of vulnerability exploitation by an attacker.

5. Mobilization: bringing about changes and verifying closure

The result of the step is formed recommendations, executed changes, and confirmation that the risk is indeed reduced:

● formulation of detailed recommendations for threat remediation with playbooks;

● task assignment in ITSM with a designated owner and fixed deadline;

● monitoring the execution of tasks for analysis and threat remediation, tracking SLA;

● re-checking that the threat is indeed eliminated or closed by a compensating measure.

Minimum set of tool classes for CTEM at the perimeter

• Asset, Information System and Service Accounting
  Minimum: asset, owner, environment (production or testing), network segment, criticality.

• ASM for Scanning the External Perimeter
  To see what is actually exposed to the outside and potentially accessible to an attacker, or created by them: domains, subdomains, public IPs, services, shadow assets.

• VM for Identifying Vulnerabilities and Configuration Errors
  To obtain scanning results for assets "from the inside".

• Perimeter Telemetry and SIEM
  WAF logs, firewalls, VPNs, proxies plus correlation and storage in SIEM.

• TI and OSINT
  To separate a multitude of secondary tasks from those that are relevant from the perspective of exploitation by an attacker right now.

• ITSM (IT Service Management) or Ticketing System
  To ensure that tasks actually lead to changes and closure control.

What Should Come Out

If CTEM is functioning successfully in your company, you will have three main artifacts that are updated continuously and cyclically:

● an up-to-date list of external assets and the ability to monitor the emergence of Shadow IT;

● a managed backlog of tasks prioritized according to the 3-layer model;

● closure control: task → change → recheck.

These artifacts are important because they make the process reproducible. Priorities become understandable and repeatable across different teams and branches.

Metrics that Show Progress

To avoid falling into the trap of chasing the number of lines in a report, it is useful to measure not the volume of findings but the manageability and effect.

Appropriate metrics:

- time to close top threats at the perimeter;

- percentage of tasks closed with recheck;

- speed of bringing new external assets found by ASM under control.

These metrics show that CTEM is not about identifying more threats. It is about consistently prioritizing and bringing threat remediation to a confirmed result.

On the outer perimeter, there is usually a lack of scanning and reporting. There is a lack of a combination of three things in one process: what is actually accessible from the outside, what has been identified along this perimeter, and what is visible in telemetry regarding this. As long as these parts exist separately in different data sources, threat priorities become unstable, and closure turns into a mere formal status assignment.

CTEM helps to bring this into a workable scheme. The result that makes sense to strive for looks like this:

● there is an up-to-date list of legitimate external services with defined owners and criticality;

● there is a short list of vulnerabilities in the processing iteration, where the priority is explained by validated threats;

● there is control of closure based on fact through re-verification.

If this is done continuously, the volume of identified issues ceases to be a problem: you understand what you are closing now, why this particular issue, and what effect you will ultimately achieve.