Proving Cyber Resilience With CTI - Cyber Threat Intelligence

Siwoo Lee
3 days ago
7 min read

PAGO Gartner Security & Risk Management Summit On Site Report

PAGO attended the 2026 Gartner Security & Risk Management Summit in National Harbor, Maryland, and sharing key insights from the security sessions discussed on site. This report examines From Cyber Threat Intelligence to Proven Cyber Resilience, presented by Lampis Alevizos, and explores how Cyber Threat Intelligence can move beyond threat collection and become a foundation for security decision making and cyber resilience.

*Gartner SRM 2026 "From Cyber Threat Intelligence to Proven Cyber Resilience" by Lampis Alevizos*

"People often feel safer choosing what they already know and can explain than choosing outcomes they cannot predict."

Lampis Alevizos used the 2 urn experiment at the beginning of the session to illustrate this idea.

He applied the concept to cybersecurity decision making and explained that many organizations still evaluate their security posture using indicators that are already visible and easy to explain, such as compliance status or the deployment of security controls.

The session argued that organizations need to move beyond this familiar approach. Cyber resilience begins with understanding how attackers can gain access and move through an environment. Ultimately, resilience is demonstrated when organizations can determine where detection and prevention may fail, which business functions could be affected, and what should be addressed first.

The Limits of Compliance Driven Security

Alevizos pointed out that many organizations still describe their security posture through compliance achievements and the deployment of security controls. These measures are useful for internal reporting and audit purposes. They help explain which security capabilities are in place, which standards have been met, and which areas have improved over time.

However, they do not show how detection and response will perform during a real attack. The fact that MFA is enabled, EDR is deployed, and logs are being collected is important. However, those facts alone do not reveal how an attacker may gain access, how they could move through the environment, or where detection and prevention might fail.

Alevizos explained this through the difference between Urn A and Urn B. Urn A represents information organizations already possess and can readily explain. Examples include heat maps, compliance artifacts, security assessments, and the deployment status of security controls. Urn B represents the areas that must be examined during a real attack. These include adversary behavior, attack paths, and operational uncertainty.

He was not suggesting that compliance reports or security assessments lack value. The key message was that these materials alone cannot determine whether defenses will function during an attack or which business operations may be affected.

Security teams must evaluate more than what controls exist. They must also understand whether those controls actually work when an attack occurs. The questions organizations ask should therefore change.

Instead of stopping at "Are the required security controls deployed?", organizations should ask:

"How could an attacker gain access?"
"Where could detection and prevention fail during the attack?"
"What business functions would be affected if the attack succeeded?"

Only then can organizations determine priorities based on potential business impact and decide what should be addressed first.

CTI: Turning Threat Intelligence Into a Foundation for Decisions

During the session, Cyber Threat Intelligence (CTI) was not described as a process for collecting threat reports or tracking the latest cyber trends. Alevizos explained that CTI should not stop at listing every possible threat. Its purpose is to narrow the focus to the threat actors and attack paths most relevant to the organization and provide evidence that supports decision making.

Not every threat actor and not every threat carries the same level of importance. As a result, CTI should move beyond asking, "What attacks are currently popular?" Organizations should instead ask:

"Which threat actors are most relevant to our industry and business model?"
"How do they gain initial access?"
"Where could detection and prevention fail in our environment?"

Alevizos explained that cyber defense should not begin with an inventory of internal assets or deployed security controls. The starting point should be understanding how attackers gain access, how they move through an environment, and where detection and prevention may fail.

Only after that analysis should organizations return to an internal perspective and decide which security controls matter most, where investments should be made, and what improvements deserve priority.

From this perspective, CTI becomes more than a source of indicators of compromise or threat trend summaries.

It becomes the basis for investigations, response activities, and prioritization decisions. If organizations understand how a specific threat actor gains access, moves through a network, and bypasses controls, that intelligence should be connected to exposed assets, account privileges, and detection telemetry.

The value of CTI is not measured by the amount of information collected.

Its value lies in helping organizations determine which threats should be validated first and which actions should take priority.

Connecting Threat Intelligence to Validation Through TiDE

To connect this focused threat intelligence to real world decision making, Alevizos introduced TiDE.

TiDE, or Threat Informed Defense Effectiveness, is an approach that evaluates defensive effectiveness through threat intelligence. It uses attacker behavior as the basis for validating whether detection and prevention controls function as intended and helps organizations prioritize actions based on those findings.

Alevizos described TiDE through five stages: Identify, Prioritize, Validate, Measure, and Decide.

Organizations first identify the threat actors that matter most and focus on the threats that deserve attention. They then validate whether detection and prevention controls operate effectively against real attacker behaviors, measure the effectiveness of those controls, and use the resulting evidence to determine what should be fixed and where priorities should be placed.

A key theme throughout this process is that the question is not whether security controls and response procedures exist. The question is whether detection and prevention actually work when measured against real attacker behavior. MFA, EDR, log collection, and response procedures are important starting points.

TiDE asks organizations to determine how those controls perform during an actual attack scenario.

The Validate stage is particularly important. Organizations should move beyond confirming what is written in policies and procedures. They should simulate or emulate attacker behavior and verify whether security controls function as expected.

Even when failures are discovered, those results provide valuable insight. They reveal where detection did not occur, where response was delayed, and where operational improvements are required.

TiDE moves risk management away from document based verification and toward validation and decision making based on real attack scenarios.

Its purpose is not to discover weaknesses after an incident occurs. Its purpose is to validate defensive effectiveness before an incident and use those findings to establish action priorities.

Risk Decisions Explained Through Business Outcomes

In the latter part of the session, Alevizos explained that cyber risk decisions should be expressed through business outcomes rather than security tools and controls. He provided several examples of security focused language: "$2 million invested in phishing protection."; "$500,000 invested in SOC expansion."; "Upgrade the XDR platform.". The same investments can be explained differently: "$2 million invested to protect €200 million in online transactions."; "$500,000 invested to reduce recovery time by 60 percent."; "Maintain logistics operations during a cyber incident."

This distinction matters in practice. Security teams often understand why a specific control or platform is necessary. Executives and business stakeholders are typically focused on the operational impact. They want to understand which disruptions are being prevented and which losses are being reduced.

Security investments become more meaningful when organizations explain what is being protected rather than simply describing what is being purchased. This perspective also reinforces the role of TiDE.

The purpose of validating detection and prevention controls is not simply to evaluate security effectiveness. The goal is to determine which business functions require protection first and which actions will have the greatest impact on reducing business risk.

The same principle applies to security operations. Organizations should also understand which assets and accounts are involved and how the activity could affect business operations. Only then can alerts be interpreted as business impact driven action priorities rather than isolated technical events.

Actions Organizations Can Start Tomorrow

Toward the end of the session, Alevizos outlined several actions organizations can begin immediately.

The first step is identifying three threats that are genuinely relevant to the organization. This does not mean creating a list of every security issue. It means selecting the attack scenarios that deserve the most attention based on industry, business model, and external exposure.

Organizations should then identify the threat actors most likely to execute those attacks and map the flow from initial access through business impact. This may include phishing, account compromise, or exploitation of externally exposed systems. The next step is validating where detection and prevention may fail. Organizations should move beyond confirming that security controls appear in policies, procedures, and checklists. They should test whether those controls actually support detection, prevention, and response during realistic attack scenarios.

Finally, organizations should establish priorities. For each scenario, they should determine what should be addressed first and which actions will have the greatest impact on reducing business risk. Alevizos described these activities as a practical starting point rather than a major strategic initiative.

Most organizations already maintain asset inventories, security control inventories, vulnerability lists, and detection content. Whether those resources are connected to real attack scenarios, business impact, and action priorities is a different question. The starting point highlighted during the session was not the addition of new tools. It was changing the order of the questions being asked. Instead of beginning with "What security controls do we have?", you should ask:

"Which threats can realistically affect our business?"
"What business functions would be affected if those attacks succeeded?"
"What should be addressed first?"

Conclusion

Cyber resilience is not automatically achieved by introducing new security products or launching additional programs. It is demonstrated by understanding what works during a real attack, where failures may occur, and which business functions could be affected.

CTI therefore cannot remain an exercise focused solely on collecting more threat information. Organizations should narrow their focus to the threat actors and attack techniques most relevant to their environment, validate defensive effectiveness through approaches such as TiDE, and connect those findings to business impact and action priorities.

This message is closely aligned with the role of an MDR service provider. MDR services detect threats, analyze attacker activity, and support response decisions. The value extends beyond delivering notifications about detected threats. Organizations also need to understand how those threats connect to attack scenarios, which assets and business functions may be affected, and what actions should be prioritized.

The objective is to provide the context needed to determine what should be investigated first and what should be addressed first within limited response windows. The most important question is not "What security capabilities do we have?" The more meaningful questions are: