ATT&CK Analysis: How Asimily Determines Which Vulnerabilities Require Action

Every IoT, OT, IoMT, and IT security team is sitting on a vulnerability queue that is too long to act on. The tools most teams use to prioritize that queue sort by CVSS severity, but CVSS severity is not the same thing as operational risk. CVSS tells you how dangerous a vulnerability is in the abstract. It does not tell you whether an attacker can reach the device, whether the exploit works on the specific firmware version in your environment, or whether the vulnerability represents a realistic risk given how your network is actually configured. The result is a prioritization approach that is systematically wrong for connected device environments, and wrong in the direction that matters most: the devices that are genuinely at risk are buried under devices that score high on paper but carry no realistic path to exploitation.

Asimily’s patented ATT&CK Analysis solves this exact problem – and in competitive evaluations across industries including manufacturing, energy, healthcare, and critical infrastructure, it is the capability that most consistently sets Asimily apart from the competition.

What CVSS Measures and What it Misses

CVSS is a useful standardization tool. It gives security teams and vendors a shared vocabulary for describing vulnerability severity, and for that purpose it works. For operational prioritization, it has a structural limitation: it describes a vulnerability in isolation, not in the context of a specific device, a specific environment, or a specific attacker’s realistic path to exploitation.

A CVSS 9.8 vulnerability on a device with no inbound network connections, sitting behind multiple enforced network boundaries, and running a firmware version that the vulnerability does not affect is not an operational priority. A CVSS 6.2 vulnerability on a device that communicates directly with a SCADA historian, that is running the specific firmware version the exploit targets, and that sits in a network segment an attacker has already demonstrated interest in is an immediate one. In both scenarios, the CVSS score points the security team in the exact wrong direction. 

In environments with IoT, OT, and IoMT devices, the problem is amplified. These devices run proprietary software, use firmware versions with update histories that are opaque to generic databases, communicate over protocols that standard scanners cannot parse, and exist in networks where the topology itself determines whether a vulnerability is exploitable at all. Applying a generic severity model to this population produces a prioritization queue that is, at best, uninformative. At worst, it creates false confidence that the most dangerous devices are being addressed while the real exposures go unmanaged.

Related reading: What is a CVSS Score?

What Asimily’s ATT&CK Analysis Uncovers that Other Methods Miss

ATT&CK Analysis is Asimily’s proprietary methodology for determining whether a vulnerability is actually exploitable on a specific device in the specific network where that device operates. Not whether it could theoretically be exploited on some abstract instance of the affected software stack, but whether an attacker operating in the analyzed environment has a realistic path to successful exploitation.

The analysis evaluates four dimensions simultaneously. First, the specific device: manufacturer, model, firmware version, installed applications, operating system, open ports, and observed configuration. Second, the attack vector required: whether exploitation requires remote access, adjacent network access, or physical presence, and whether those conditions exist in the analyzed environment. Third, exploit availability and reliability: whether a working exploit exists, whether it is reliable in field conditions, and whether it is being actively used by threat actors in the wild. Fourth, the network topology: which devices can reach this device from realistic attacker entry points, and whether the communication patterns observed in the environment would give an attacker the access the exploit requires.

The output is a ranked list of vulnerabilities with a documented reason for every position in the queue. Not a sorted spreadsheet, but an explainable prioritization that a CISO can present to a board, a regulator, or a cyber insurer and defend.

The Data Sources Behind the Analysis

The analytical depth of ATT&CK Analysis depends directly on the breadth and recency of the threat intelligence it draws on. Asimily ingests and continuously updates intelligence from more than 15 sources.

Source	What It Contributes
CISA KEV	Known Exploited Vulnerabilities catalog: the definitive list of vulnerabilities confirmed to be actively exploited in the wild. A CVE’s presence here is one of the strongest signals that a vulnerability carries real operational risk.
NVD	National Vulnerability Database: base vulnerability metadata, CVSS scores, CPE identifiers, and CVE descriptions that serve as the foundational record against which all device-specific analysis is calibrated.
MITRE ATT&CK for ICS	Adversary tactics, techniques, and procedures specifically documented for industrial control systems. This is the reference that contextualizes how attackers operate in OT environments and which techniques are actively used against specific device classes.
ICS-CERT Advisories	US Cybersecurity and Infrastructure Security Agency advisories specific to industrial control systems, covering vulnerabilities across PLC, RTU, HMI, SCADA, and other OT device categories.
Vendor SIRTs	Security Incident Response Team disclosures from device manufacturers across IoT, OT, IoMT, and IT. Vendor advisories frequently contain device-specific context and workarounds that generic vulnerability databases do not capture.
Exploit Databases	Public and commercial repositories tracking working exploit availability, reliability, and observed use. A vulnerability with a reliable, weaponized exploit in active use is categorically different from one that is theoretical.
80+ Vendor IoC Feeds	Indicators of Compromise from more than 80 security vendors, updated continuously. IoC feeds reflect what attackers are actually using in the field, not just what has been disclosed.
Asimily Field Intelligence	Proprietary intelligence derived from 3,000-plus deployed environments across healthcare, manufacturing, energy, critical infrastructure, and financial services. Field data reflects the actual device populations, communication behaviors, and attack patterns that appear in real operational networks rather than in lab conditions.
Vulnerability History to 1990	Asimily maintains a vulnerability index going back to 1990. Legacy OT and IoMT devices frequently run software and firmware that has not been updated in a decade or more. Coverage gaps caused by a device’s age do not exist in Asimily’s analysis.

The combination matters as much as the individual sources. A vulnerability may be absent from CISA KEV but present in a vendor SIRT advisory with active exploitation reported in a specific device class. An exploit may be publicly documented but unreliable against certain firmware versions that Asimily’s field intelligence has profiled. The analysis is a synthesis, not a lookup, and the synthesis is what the patent covers.

Why This Matters For CISOs Who Manage Connected Device Security

For the CISO responsible for the IoT, OT, IoMT, and IT estate, the practical value of ATT&CK Analysis comes down to four things.

An Actionable Queue Instead of an Unmanageable Catalog

A typical enterprise with a significant connected device estate carries hundreds of thousands of CVEs across its device population, many with multiple signals from different cybersecurity services or tools. No team can act on a to-do list with thousands of entries. 

ATT&CK Analysis routinely reduces that population to roughly 1% of devices and vulnerabilities that carry genuine exploitable risk in the analyzed environment. The team works the short list, not the full catalog. Every item on that list has a documented, device-specific, topology-specific reason for being there.

Coverage of the Devices That Conventional Tools Miss

ATT&CK Analysis is built for IoT, OT, and IoMT devices: the assets that cannot run agents, that communicate over protocols conventional scanners don’t parse, and that run firmware versions that generic vulnerability databases have incomplete records for. The vulnerability history to 1990 means a PLC running fifteen-year-old firmware is not invisible to the analysis because it predates a modern vulnerability database. Coverage does not depend on the device fitting a standard IT profile.

A Prioritization Methodology the Organization Can Defend

Exposure management decisions get reviewed by boards, regulators, and cyber insurers. A CISO presenting a list of the ten devices their team addressed this quarter needs to be able to explain why those ten and not others. ATT&CK Analysis provides the documented rationale: this device was prioritized because the vulnerability is confirmed exploitable given this firmware version and this network topology, with an active exploit observed in the wild. That is a defensible explanation. “It scored a 9.8 on CVSS” is not.

Risk Reduction Can Be Modeled Before Any Action is Taken

The Risk Simulator extends ATT&CK Analysis into the remediation planning process. Before a team commits time and resources to a remediation action, the Risk Simulator models the expected risk reduction that action will produce in the specific environment. Teams direct effort toward the actions that return the most risk reduction, not just the ones that address the highest-scoring CVEs.

Why ATT&CK Analysis Matters for Effective Segmentation

Segmentation is the primary mitigation strategy for devices that cannot be patched or reconfigured as a compensating control.  A significant portion of the IoT, OT, and IoMT estate falls into that category. The problem is that segmentation without accurate exploitability data is not an exposure management decision. It is a guess about which devices matter, and guesses in operational networks carry real consequences when they are wrong.

The Segmentation Problem ATT&CK Analysis Solves

Most segmentation projects fail to reach enforcement not because the infrastructure is wrong but because the policy decisions are wrong. Teams do not know which devices genuinely need tighter isolation, which communication paths represent real exposure, and which policy changes would disrupt operations. ATT&CK Analysis provides the answer to the first two questions. Policy Simulation answers the third.

Besides helping organizations subtract risk from their organization, ATT&CK Analysis aids the addition of better defenses. It is the foundation of Asimily’s Segmentation Orchestration capability. Here is the specific chain:

1. ATT&CK Analysis establishes which devices carry exploitable vulnerabilities and which communication paths to those devices represent genuine attack vectors. This is the risk context that makes segmentation decisions precise. A device with a high CVSS score but no exploitable path does not require immediate isolation. A device with a moderate score and a confirmed attack path does. Without this determination, segmentation policy is applied by guesswork or uniformly at scale, neither of which produces defensible outcomes.
2. Policy Auto-Recommendation takes the ATT&CK Analysis output and generates segmentation policies designed to allow complete function and block exploits. The risk profile is built into the recommendation: devices with confirmed exploitable vulnerabilities receive policy recommendations that reflect the specific communication paths those vulnerabilities exploit. The team does not start from a blank slate. They start from a policy that reflects what the devices are actually doing and where the actual risk sits.
3. Policy Simulation validates each recommendation against real observed traffic before anything touches the production network. This is the step that eliminates the fear of deployment that stalls most segmentation programs. The CISO can see exactly which flows a proposed policy would block, confirm that no critical workflow is disrupted, and approve the change with documented evidence of the impact.
4. Continuous Segmentation maintains the policy as the environment changes. As devices receive firmware updates, as new assets join the network, and as ATT&CK Analysis identifies new vulnerabilities in the existing device population, the segmentation posture adapts. The risk intelligence that drove the initial policy continues to drive its maintenance, so enforcement does not decay between quarterly reviews.

The end state is fully realized exposure management: segmentation that isolates the devices that carry real, confirmed, exploitable risk, enforced through the NAC and firewall infrastructure the organization already owns, with every policy decision traceable back to a specific, documented ATT&CK Analysis finding.

Related Reading: Introducing Segmentation Orchestration from Asimily

Patent, Market Position, and What the Record Shows

Asimily holds a US patent on the ATT&CK Analysis methodology for connected device security. The patent covers the approach of evaluating vulnerability exploitability in the simultaneous context of device-specific attributes and network topology, and applying that evaluation across heterogeneous connected device populations. No other platform holds an equivalent patent for this methodology.

In competitive evaluations where ATT&CK Analysis goes head to head with CVSS-based prioritization, generic risk scoring, or manual analyst triage, the difference in output quality is observable in the evaluation itself. Asimily identifies the same environment’s genuine risks with a fraction of the noise. Organizations that have run parallel evaluations consistently find that ATT&CK Analysis surfaces a smaller, more accurate list of priority devices and that the prioritization rationale withstands scrutiny in a way that severity-sorted outputs do not.

The Right Question for Any Exposure Management Platform

Every platform that addresses IoT, OT, IoMT, and IT security will tell you it handles vulnerability prioritization. The question worth pressing is: when it tells you something matters, what is the basis for that determination – and does it really help you more effectively manage exposure? Is it a CVSS score applied uniformly, a third-party risk model that does not know your network, or an analysis that evaluates the specific device, the specific firmware, the specific exploit, and the specific topology in which that device operates?

Asimily’s ATT&CK Analysis exists because we recognized that the connected device estate is fundamentally different from the IT estate, and that risk tools built for standard enterprise IT produce outputs that are confidently wrong when applied to OT, IoT, and IoMT populations. Building the right analysis for those devices required building a different approach to intelligence, device profiling, and a patent-protected methodology that reflects how connected device exploitation actually works.

That methodology is why the 1% of devices and vulnerabilities ATT&CK Analysis surfaces are the right 1% for your team to focus on, and why the security work done on them reduces risk rather than just reducing the length of a queue.