Systems and methods for identifying, analyzing, and mitigating cybersecurity risk
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- DENEXUS INC
- Filing Date
- 2026-01-30
- Publication Date
- 2026-08-06
Smart Images

Figure US2026013340_06082026_PF_FP_ABST
Abstract
Description
[0001] Docket No. 2970063-000001-W01
[0002] Filed: January 30, 2026 International Patent Application for:
[0003] SYSTEMS AND METHODS FOR IDENTIFYING, ANALYZING, AND MITIGATING CYBERSECURITY RISK
[0004] RELATED APPLICATIONS
[0005] This application claims priority to US Application No. 63 / 751,610, filed January 30, 2025.
[0006] TECHNICAL FIELD
[0007] Embodiments are described herein relating to protection of computer software, systems and networks from cybersecurity threats.
[0008] INCORPORATION BY REFERENCE
[0009] Each patent, patent application, and / or publication mentioned in this specification is herein incorporated by reference in its entirety to the same extent as if each individual patent, patent application, and / or publication was specifically and individually indicated to be incorporated by reference.
[0010] BACKGROUND
[0011] Computer security is the protection of computer software, systems and networks from threats that can lead to unauthorized information disclosure, theft or damage to hardware, software, or data, as well as from the disruption or misdirection of the services they provide.
[0012] The significance of the field stems from the expanded reliance on computer systems, the Internet, and wireless network standards. Its importance is further amplified by the growth of smart devices, including smartphones, televisions, and the various devices that constitute the Internet of things (IoT). Cybersecurity has emerged as one of the most significant new challenges facing the contemporary world, due to both the complexity of information systems and the societies they support. Security is particularly crucial for systems that govern large-scale systems with far-reaching physical effects, such as power distribution, elections, and finance.Docket No. 2970063-000001-W01
[0013] Filed: January 30, 2026 A cybersecurity vulnerability refers to a flaw in the structure, execution, functioning, or internal oversight of a computer or system that compromises its security. Most vulnerabilities are documented in the Common Vulnerabilities and Exposures (CVE) database. An exploitable vulnerability is one for which at least one working attack or exploit exists. Actors maliciously seeking vulnerabilities are known as threats. There is a need to efficiently and automatically map vulnerabilities to attack techniques and to build financial loss risk profiles based on probabilities of successful incursions.
[0014] BRIEF DESCRIPTION OF THE FIGURES
[0015] Figure 1 illustrates a workflow for mapping CVEs to risk proposition, under an embodiment.
[0016] Figure 2 illustrates an Al model to automate CVE to MITRE ATT@CK mapping, under an embodiment.
[0017] Figure 3 shows CVE to monetary loss diagram, under an embodiment.
[0018] Figure 4 shows CVE to monetary loss diagram, under an embodiment.
[0019] Figure 5 shows construction of an Enterprise Dataset, under an embodiment.
[0020] Figure 6 shows construction of an ICS Dataset, under an embodiment.
[0021] Figure 7 shows represents the relationships between MITRE ATT& CK Initial Access Vectors., under an embodiment.
[0022] Figure 8 shows a model architecture for automatic mapping of CVE to Technique, under an embodiment.
[0023] Figure 9 shows model training metrics, under an embodiment.
[0024] Figure 10 shows model training metrics, under an embodiment.
[0025] Figure 11 exhibits an architecture for training a model to predict techniques using CVEs as input, under an embodiment.
[0026] Figure 12 illustrates MITRE ATT& CK techniques along the x-axis and the number of CVEs mapped to MITRE ATT& CK techniques along the y-axis, under an embodiment.
[0027] Figure 13 shows dashboard results of model application in an enterprise environment, under an embodiment.
[0028] Figure 14 shows examples of Regular Expressions used to determine whether a CVE belongs to the 'Denial of Service* or " CSRF" types, under an embodiment.Docket No. 2970063-000001-W01
[0029] Filed: January 30, 2026
[0030] Figure 15 shows dashboard results of model application in an ICS environment, under an embodiment.
[0031] Figure 16 shows CVE and asset properties within a networked environment, under an embodiment.
[0032] Figure 17A provides information on attack pathways, under an embodiment.
[0033] Figure 17B provides information on attack pathways, under an embodiment.
[0034] Figure 18 provides information on attack pathways, under an embodiment.
[0035] Figure 19A provides information on attack pathways, under an embodiment.
[0036] Figure 19B provides information on attack pathways, under an embodiment.
[0037] Figure 20 shows a customer CVE table, under an embodiment.
[0038] Figure 21 shows workflow for computing CVE scores, under an embodiment.
[0039] Figure 22 shows workflow for computing probability of exploitation with respect to a particular technique, under an embodiment.
[0040] Figure 23 shows a technique by CVE table and corresponding probability of exploitation, under an embodiment.
[0041] Figure 24 graphs progressive probability of exploitation across a series of CVEs, under an embodiment.
[0042] Figure 25 provides information on attack pathways, under an embodiment.
[0043] Figure 26 illustrates probabilities relating to attacks, under an embodiment.
[0044] Figure 27 shows a CVE to MITRE ATT& CK mapping for use in modeling and mitigating risk of attack exploitations, under an embodiment.
[0045] Figure 28 shows a stylized attack path of a technique, under an embodiment.
[0046] Figure 29 shows an example of an absorbing Markov Chain, under an embodiment. Figure 30 shows MITRE ATT& CK ICS techniques used in past attacks, under an embodiment.
[0047] Figure 31 provides information on attack pathways, under an embodiment.
[0048] Figure 32 shows an example of a branching random walk, under an embodiment.
[0049] . Figure 33 shows use of CAPEC parent-child relationships to derive additional links that are not directly available in the CAPEC dataset, under an embodiment.Docket No. 2970063-000001-W01
[0050] Filed: January 30, 2026 Figure 34 shows an example of CVE-NVD / CWE / CAPEC / TT chain, under an embodiment.
[0051] Figure 35 shows an enterprise dataset comprising 149 unique CWEs, 177 unique CAPECs, 14 MITRE Tactics, and 188 MITRE Techniques, under an embodiment.
[0052] Figure 36 shows a process for building a CVE to Technique training dataset in an ICS environment, under an embodiment.
[0053] Figure 37 shows a process for building a CVE to Technique training dataset in an ICS environment, under an embodiment.
[0054] Figure 38 shows a process for building a CVE to Technique training dataset in an ICS environment, under an embodiment.
[0055] Figure 39 shows a process for building a CVE to Technique training dataset, under an embodiment.
[0056] Figure 40 shows an ICS dataset comprising 211 unique CWEs, 249 unique CAPECs, 12 MITRE Tactics, and 59 MITRE Techniques, under an embodiment.
[0057] Figures 41 A and 41B show the data table used for CVE-2023-2882, under an embodiment.
[0058] Figure 42 shows number of CVEs per CWE, under an embodiment.
[0059] DETAILED DESCRIPTION
[0060] RVBM Technical Details
[0061] Figure 1 illustrates a workflow for mapping CVEs to risk proposition, under an embodiment.
[0062] Figure 2 illustrates an Al model to automate CVE to MITRE ATT@CK mapping, under an embodiment.
[0063] DeNexus RBVM STEP BY STEP
[0064] DeNexus RBVM (Risk Based Vulnerability Management) is a unique platform that truly enables cyber risk-based vulnerability management. It enriches the information about vulnerabilities identified by tools in a network by incorporating the characteristics of the assets and business processes in which they are located. Additionally, it provides accurate information on the exposure these vulnerabilities represent within a potential cyber-attack path. As shown in FigureDocket No. 2970063-000001-W01
[0065] Filed: January 30, 2026 1, the process begins with Vulnerability Discovery and concludes with the Remediation Recommendation System (RRS), utilizing Al-powered DeNexus proprietary tools throughout. When vulnerability data from industrial facilities is input into the system, it generates a detailed analysis of the financial impact of cyber risks associated with specific vulnerabilities. This analysis helps decision-makers estimate the return on investment for patching plans and / or provides recommendations on which vulnerabilities to remediate or eliminate, considering budget constraints.
[0066] The core of the system consists of three Al-powered, proprietary DeNexus tools:
[0067] 1. AI-CVE2TTs: The DeNexus engine that performs the Automatic Mapping of Vulnerability Information to Adversary MITRE ATT& CK Techniques.
[0068] 2. DeRISK URMS: The DeNexus modeling system provides a comprehensive quantification of financial cyber risk on a per-unit basis.
[0069] 3. DeRISK MRS: The DeNexus Recommendation System enables the evaluation of patching strategies, supporting informed decision-making.
[0070] Figure 3 shows CVE to monetary loss diagram, under an embodiment.
[0071] Figure 4 shows CVE to monetary loss diagram, under an embodiment.
[0072] BACKGROUND
[0073] DeNexus RBVM STEP BY STEP
[0074] 1.0 DeNexus AI-CVE2TTs
[0075] 1.1 Data Acquisition
[0076] 1.1.1 From NIST NVD
[0077] 1.1.2 From CWE
[0078] 1.1.2 From CAPEC
[0079] 1.1.4 From MITRE
[0080] 1.2 Data Preparation
[0081] 1.2.1 Enterprise Dataset
[0082] 1.2.2 ICS Dataset
[0083] 1.3 Modeling
[0084] 1.3.1 Enterprise Model settings
[0085] 1.3.2 ICS Model settings
[0086] 1.4 Output / ResultsDocket No. 2970063-000001-W01
[0087] Filed: January 30, 2026 1.4.1 Enterprise Mapping
[0088] 1.4.2 ICS Mapping
[0089] 2.0 DeRISK CRQ (Cyber Risk Quantification)
[0090] 2.1 Data Acquisition
[0091] 2.1.1 From Inside (Sensors)
[0092] 2.1.2.1.2 From First.org
[0093] 2.1.2.1.3 From MITRE
[0094] 2.2 Data Preparation
[0095] 2.2.1 Super Attack Pattern
[0096] 2.2.2 Vulnerability Score per TT
[0097] 2.3 Modeling
[0098] 2.3.1 Q Probabilities
[0099] 2.3.2 APA Module
[0100] 2.4 Output / Results
[0101] 2.4.1 Probability of Success
[0102] 2.4.2 Financial (Expected) Loss
[0103] 3.0 DeRISK MRS (Mitigation Project Builder MPB)
[0104] 3.1 Data Acquisition
[0105] 3.1.1 Risk Baseline
[0106] 3.1.2 Cost / Time
[0107] 3.2 Data Preparation
[0108] 3.2.1 Project or Program
[0109] 3.3 Modeling
[0110] 3.3.1 Expected Loss estimation with Project
[0111] 3.4 Output / Results
[0112] 3.4.1 Risk Reduction / ROI calculation
[0113] GLOSSARY
[0114] 1.0 DeNexus AI-CVE2TTsDocket No. 2970063-000001-W01
[0115] Filed: January 30, 2026 Identifying vulnerabilities that are actively exploited by the attackers and understanding how a vulnerability can enable the attacker at each stage of the attack life cycle is critical for vulnerability assessments.
[0116] 1.1 Data Acquisition
[0117] • Data used by the CVE2TTs mapping tool
[0118] o Data acquisition using DeNexus scripts
[0119] o Data stored in the DeNexus data lake
[0120] Table 1. Mitre Data
[0121] 1.1.1 From NIST NVD 1.1.2 From CWE 1.1.2 From CAPEC 1.1.4 From MITRE
[0122] • Owner: MITRE • Owner: MITRE
[0123] • ATT& CK:
[0124] • CAPEC: Common
[0125] • Owner: MITRE Adversarial Attack Pattern
[0126] • Owner: NIST • CWE: Common Tactics,
[0127] Enumerations and
[0128] • NVD: National Weakness Techniques and Classifications
[0129] Vulnerability Enumeration Common (CAPEC™)
[0130] Database (CWE™) Knowledge
[0131] • Data:
[0132] • Data: • Data:
[0133] • Data: o CAPEC List
[0134] o CVE List o List of
[0135] o CWE List o Mapping from
[0136] o CVE Techniques in o Mapping CAPEC to the Enterprise Description
[0137] from CWE MITRE Matrix o Mapping from to Capec Technique.
[0138] CVE to CWE o List of This mapping
[0139] • Updated weekly Techniques in • Updated daily only involves
[0140] • Internal the ICS Matrix • Internal the Enterprise
[0141] References: • Updated: as References: matrix.
[0142] o Mitre - released by
[0143] • NIST • Updated weekly
[0144] CWES MITRE
[0145] • Internal Reference:
[0146] • Internal Reference: o Mitre - Capecs
[0147] o Mitre - Tactics
[0148]
[0149] 1.2 Data PreparationDocket No. 2970063-000001-W01
[0150] Filed: January 30, 2026 • The objective is to generate the datasets of pairs of vulnerabilities (CVEs) and MITRE ATT& CK techniques. One dataset is obtained for the Enterprise matrix and another one for the ICS matrix.
[0151] • The dataset can be used to train a Machine Learning model that predicts which MITRE ATT& CK techniques can be exploited due to the existence or presence of a vulnerability.
[0152] • Enterprise matrix: X% of the CVEs can be mapped to a technique using external data sources (described above)
[0153] • ICS matrix: X% of the CVEs can be mapped to a CAPEC using external data sources (described above). DeNexus has created a proprietary mapping from CAPEC to ICS Techniques
[0154] 1 Enterprise Dataset
[0155] • We chained the databases as follows CVE-NVD / CWE / CAPEC / TTs to obtain data on vulnerability pairs and techniques for the Enterprise CVE2TTs training dataset.
[0156] Figure 5 shows construction of an Enterprise Dataset, under an embodiment
[0157] 2 ICS Dataset
[0158] • The chain used for Enterprise lacks a connection from CAPEC to ICS Techniques, and it is known for being an incomplete mapping in some cases.
[0159] • We built this threat database for ICS with expert knowledge about how a CAPEC is related to ICS techniques and how some Enterprise techniques relate to ICS techniques.
[0160] • The main input for the CAPEC-TECH mapping was the description of the CAPEC.
[0161] DeNexus experts linked the CAPEC to tactics and tagged them with a quality label (see below). Some specific work to refine the training dataset using Twin techniques between Enterprise and ICS matrices:
[0162] o Twin association of the technique T0890: Exploitation for Privilege Escalation (ICS) with tactic TA0004: Privilege Escalation (Enterprise).
[0163] o Twin association between Remote Services, External Remote Services, Exploitation of Remote Services, Internet Accessible Device and Exploit Public- Facing Applications. If one of them inherits all.
[0164] • Our threat dataset for ICS is updated daily for the latest vulnerabilities and updates on information of the existing ones.
[0165] Figure 6 shows construction of an ICS Dataset, under an embodimentDocket No. 2970063-000001-W01
[0166] Filed: January 30, 2026 Mapping CAPEC to TECH (only ICS)
[0167] Matching Methods aligned with Quality label:
[0168] • Perfect - manually mapped by SME (subject matter expert)
[0169] • Good - manually mapped by SME and quality assigned is Good.
[0170] • Medium - manually mapped by SME and quality assigned is medium. Less than Good, better than Poor.
[0171] ® Poor - manually mapped by SME but relationship is very poor match.
[0172] » Inherited - it is like above, but now takes into account the CAPEC hierarchy and includes other CAPECs based on parent / child relationships.
[0173] 1.3 Modeling
[0174] • Once we have the training datasets, we develop a Machine Learning model to identify MITRE ATT& CK techniques that can potentially be exploited with each vulnerability for both Enterprise and ICS matrices. This mapping between vulnerabilities and MITRE ATT& CK techniques is critical to estimating the probability of success (or causing impact) of a cyberattack.
[0175] • The problem we solve is a text classifier. We use the description of the CVE to infer the MITRE ATTA&K techniques associated with a given vulnerability. The input of the model is the description and the type of the CVE.
[0176] • Furthermore, the problem is a multi-class and multi-label one. That is,
[0177] o There are more than two techniques (multi-class) and,
[0178] o A CVE can be mapped to one or more techniques (multi-label).
[0179] • For each matrix, we use a deep learning model using natural language processing (NLP) techniques.
[0180] • The methodology is:
[0181] o The model uses the descriptions and the type of vulnerability as inputs. o Input Description.
[0182] ■ The descriptions are transformed by a FastText pre-trained word embedding model. FastText was developed by Facebook Al Research which was trained on the Wikipedia corpus.
[0183] ■ The word representation is fed into one block of LSTM layers, o Input Type.Docket No. 2970063-000001-W01
[0184] Filed: January 30, 2026 ■ Using the description, the CVEs were classified in 13 types.
[0185] ■ The missing types (CVEs without type) were completed with a neural network model using the description as input.
[0186] o The result of the block of LSTM layers is fed into a block of dense layers for final classification. The objective function is a cross-entropy loss.
[0187] o The output is a vector of logit ratios that are used to obtain the final classification probabilities.
[0188] • We train two models separately for ENT and ICS to reduce the number of classification classes and the complexity of the model, since we expect ENT and ICS data of different natures.
[0189] Figure 8 shows a model architecture for automatic mapping of CVE to Technique, under an embodiment.
[0190] 1.3.1 Enterprise Model settings
[0191] • Mapped CVEs in the training dataset: 55785
[0192] • Train / Test ratio: 80 / 20
[0193] • Number of epochs: 13
[0194] • Execution time: 13h approx.
[0195] 1.3.2 ICS Model settings
[0196] • Mapped CVEs in the training dataset: 67971
[0197] • Train / Test ratio: 80 / 20
[0198] • Number of epochs: 11
[0199] • Execution time: 15h approx.
[0200] Figures 9 & 10 comprise metrics for ICS data, under an embodiment.
[0201] 1.4 Output / Results
[0202] 1.4.1 Enterprise Mapping
[0203] • DeNexus has a tool (dashboard) where one can explore the results of CVE2TTs for Enterprise techniques.
[0204] o Number of CVEs per Techniques
[0205] o Number of Techniques per CVEDocket No. 2970063-000001-W01
[0206] Filed: January 30, 2026 o Number of CVEs vs Mean CVSS over time
[0207] o Number of CVEs vs Mean EPSS over time
[0208] Figure 12 illustrates MITRE ATT& CK techniques along the x-axis and the number of CVEs mapped to MITRE ATT& CK techniques along the y-axis.
[0209] Figure 13 shows number of CVEs per CAPEC's type and vulnerability's type.
[0210] 1.4.2 ICS Mapping
[0211] • DeNexus has a tool (dashboard) where one can explore the results of CVE2TTs for ICS techniques.
[0212] o Number of CVEs per Techniques
[0213] o Number of Techniques per CVE
[0214] o Number of CVEs vs Mean CVSS over time
[0215] o Number of CVEs vs Mean EPSS over time
[0216] Figure 15 illustrates the number of CVEs per CWE’s type and vulnerability’s type.
[0217] 2.0 DeRISK CRQ (Cyber Risk Quantification)
[0218] DeRISK URMS estimates the potential financial loss resulting from cyber incidents. It is a three-module modeling system that uses machine learning algorithms and data analytics to answer the question What is the probability that a loss of a certain size or greater will occur in a given year?
[0219] • To quantify the risk derived from the vulnerabilities that an organization or site has on its networks we use the DeRISK modeling system.
[0220] • The DeRISK’ s engine is composed of three modules: (a) NoA: Number of Attack Attempts, (b) APA: Attack Path Algorithm, and (c) LEI: Loss Event Impact.
[0221] • The output of the CVE2TTs is an input of APA.
[0222] • APA is the subsystem within DeRISK that simulates how a cyber incident can spread within a facility or between facilities. As such it is at the heart of DeRISK.
[0223] APA is part of the DeRISK engine.
[0224] 2.1 Data Acquisition
[0225] • APA is powered by inside-out data, cyber threat intelligence data and the security posture of the organization.
[0226] 2.1.1 From Inside (Sensors)
[0227] Source: Telemetry from the DeRISK clientDocket No. 2970063-000001-W01
[0228] Filed: January 30, 2026 • Data:
[0229] o Vulnerabilities in assets. List of vulnerabilities by asset, identified by the Intrusion Detection System (IDS). Vulnerabilities information, that is contextualized for each organization using information about the asset where the CVE was located.
[0230] o Asset information (Purdue level and CVEs) provided by the IDS. The Purdue model is a structural model for industrial control system (ICS) security that concerns segmentation of physical processes, sensors, supervisory controls, operations, and logistics. Purdue Levels include Level 0 Physical Process, Level 1 Basic Control, Level 2 Supervisory Control, Level 3 Manufacturing Operations, Level 3.5 Demilitarized Zone (DMZ), Level 4 Enterprise Network, and Level 5 Enterprise / Corporate IT
[0231] Note that the same CVE can exist in different assets. Given an asset, this asset belongs to a single purde level, and this asset may or may not have vulnerabilities, if it does, it may have one or more.
[0232] o Network communications This data tells us who talks to who at an assets level.
[0233] Link-related data typically describes the characteristics of network connections observed by the system, including source and destination IP addresses and ports, the protocol used, timestamps, and session duration. It also captures traffic metrics such as packet and byte counts, connection states, and TCP flags. o Maturity level per security control, automatically retrieved from the IDS and / or informed by the organization. When possible, a representation of a defender organization’s ability to detect, respond or mitigate against each ATT& CK technique based on security controls. For some cases, the security maturity information is provided directly by the facility’s owner. The maturity scale depends on the framework. For example, Not initiated, Partial, Risk-Informed, Repeatable, Adaptive.
[0234] At this point the maturity level of the controls are filled by the customer as part of the questionnaire. The maturity scale depends on the framework. For example, a NIST CSF maturity level describes how well an organization has adopted and embedded the Cybersecurity Framework into its day-to-day operations.Docket No. 2970063-000001-W01
[0235] Filed: January 30, 2026 Practically, teams use two related ideas to express maturity: the CSF Implementation Tiers (1–4) and organization-specific maturity scales that map similar capabilities into more granular levels.
[0236] The maturity level is the scale of the Cybersecurity Frameworks (NIST CSF, IS027001, etc) SCOTT (further described below) is the “DeNexus Cybersecurity Framework” and the concept of the Maturity level is the same for all frameworks. Tier 1 — Partial: Security activity is mostly ad hoc. Controls and processes exist in pockets but aren’t consistent or coordinated across the organization. Tier 2 — Risk Informed: Teams understand risk and make decisions with risk in mind, but practices vary by business unit and are not yet enterprise- wide. Tier 3 — Repeatable: Policies, processes and controls are formalized and applied consistently. Governance and reporting are stable and measurable.
[0237] Tier 4 — Adaptive: The organization continuously monitors threats, learns from incidents, and adjusts protections; automation and analytics support proactive improvements.
[0238] • Updated: daily
[0239] 2.1.2 From First.org
[0240] • Source: first.org
[0241] • Data:
[0242] o Exploit Prediction Scoring System (EPSS) values.
[0243] This is a known value for each CVE. Sometimes when a new CVE appears, the EPSS takes a few days to be released.
[0244] o Common Vulnerabilities and Exposures (CVEs) catalog including their Common Vulnerability Scoring System (CVSS).
[0245] • Updated: Daily
[0246] 2.1.3 From MITRE
[0247] • Source: MITRE ATT& CK
[0248] • Data:
[0249] • Tactics and Techniques. Information from disclosed cyber incidents, analyzed in detail by the cybersecurity community. Those incidents are mapped to the MITRE ATT& CK TTPDocket No. 2970063-000001-W01
[0250] Filed: January 30, 2026 and identify the possible attack flows that an aggressor can follow within the organization.
[0251] The super pattern is the same for all organizations. In other words, nodes and edges are the same. Of course, for each organization, the likelihood of moving to one node or another may vary depending on the vulnerabilities and security controls of the company or facility.
[0252] An asset may or may not have vulnerabilities. If it does, it may have one or more. Given a vulnerability, this vulnerability can be exploited through one or more techniques.
[0253] There is one common list of vulnerabilities which may be vulnerable to an Enterprise Technique or an ICS techniques. In other words, an Enterprise Tactic / Technique may attack those vulnerabilities in a particular way, and an ICS Tactic / Technique may attack those same vulnerabilities in a particular way. In a single attack, may both ICS tactics / techniques and Enterprise tactic / techniques be used along the path.
[0254] o List of Software
[0255] • Updated: as released by MITRE
[0256] Figure 16 shows CVE and asset properties within a networked environment, under an embodiment.
[0257] 2.2 Data Preparation
[0258] • APA uses a simplified representation on how a cyber-attack can propagate and cause an impact: a reduced attack path or kill chain.
[0259] • An attack path is a set of steps. APA simulates the sequence of compromise, infiltration, persistence, and impact incident steps into a facility by an attacker, with lateral movement between logical units of assets.
[0260] As shown in Figure 19A, it appears that “infiltration” and “persistence” include multiple phases. Figure 19A shows two “infiltration” phases TAO 104 and TAO111.
[0261] TAO104 corresponds to TO807, TO821, TO858, TO853, TO871, TO874, TO834, and TO863. TAO 104 represent a tactic “infiltration” along an attack pathway. TA807 represent one of the techniques corresponding to this tactic. The TA0104 / TA807 combination corresponds to a CVE / CWE of a particular asset in the organization.Docket No. 2970063-000001-W01
[0262] Filed: January 30, 2026 So the infiltration tactic may take the following path: TAO104 / T0807 (which attacks a vulnerability of an asset) -> TAO111 / TO874 (which attacks a vulnerability of an asset). And then the attack path proceeds to the persistence tactic.
[0263] • To succeed, the attacker must complete all the stages. To surpass a stage a technique must be used
[0264] • To use a technique, three conditions must be taken into account: the protections or security controls, the vulnerabilities, and the degree of specialization of the attacker (the actor)
[0265] • APA requires:
[0266] o The potential attack paths a threat actor can use or follow to achieve its objective.
[0267] This input is the Super Attack Pattern.
[0268] o The probability of exploiting a MITRE ATT& CK technique using vulnerabilities.
[0269] This input is the Vulnerability Score per TT.
[0270] o The probability of overcoming each stage of the attack. This input is obtained with the Q-probability module.
[0271] 1 Super Attack Pattern
[0272] •:target: The objective of the Super Attack Pattern building is to be able to analyze and simulate all the possible paths that any attack may take.
[0273] • It leverages past incident information available in MITRE ATT& CK knowledge base to determine the attack paths seen in the past and the possible attack paths, as suggested by the evidence, may occur.
[0274] • The Super Attack Pattern (DnXSAP) is a directed acyclic graph (DAG) of MITRE ATT& CK techniques following our proprietary tactic-based kill chain.
[0275] • DnXSAP connects the Initial Access Vector of a cyber-attack with a set of possible infection and propagation vectors, a set of cyber impacts, and other attack stages that attackers usually do during a cyber-attack. The infection and propagation vectors, cyber impacts, and other attack stages are based on observed pieces of malware from MITRE. In addition, the Initial Access and Impact techniques of some pieces of malware are enriched with our in-house threat database and methodology.
[0276] • We build two DnXSAPs for each MITRE matrix ENT and ICS.Docket No. 2970063-000001-W01
[0277] Filed: January 30, 2026 o Considering the MITRE ENTERPRISE matrix, the super pattern has 9.63e12 possible attack paths
[0278] o Considering the MITRE ICS matrix, the super pattern has 9.99e6 possible attack paths
[0279] Figure 17A provides information on attack pathways, under an embodiment.
[0280] Figure 17B provides information on attack pathways, under an embodiment.
[0281] Figure 18 provides information on attack pathways, under an embodiment.
[0282] Figure 19A provides information on attack pathways, under an embodiment.
[0283] Figure 17B shows how we build the combination of techniques we use to simulate an attack path. We simulate known paths ([1] in violet and [2] green) and feasible paths for future attacks ([3] and [4]). (side note: This is a simplified representation of an attack path - just 3 tactics or steps and 9 techniques or nodes)
[0284] Figure 18 is simplified representation of the super pattern as a directed acyclic graph with 9 nodes (techniques) and 7 tactics, grouped into 3 steps (DnX calls them “redtax” or RT). In this image we have 2 paths. The path in red reaches the final step so it ends as success. The path that starts in red and ends in green has not reached the final step, so it is a failure. In other words, this image is meant to show how, after selecting the combination of techniques as explained in Figure 17B, we apply the concept of directed acyclic graph. The boxes in the image show groups of techniques, not groups of assets.
[0285] Figure 19A shows the resulting super pattern using all the Techniques in the MITRE ICS Matrix vl3. Each edge represents a feasible combination of techniques an attacker can use (again, we refer to Figure 17A and 17B to remember how we identify the edges). With the edges in this image one can have tens of trillons of attack paths. All those combinations are simulated in our modeling system.
[0286] The super pattern is the “full set of potential attack paths any organization can suffer” it is unique for all organizations. When we use the information from an organization we obtain a customized probability of success. In other words, there is no super pattern per organization, the super pattern is the same for all organizations. In other words, nodes and edges are the same. Of course, for each organization, the likelihood of moving to one node or another may vary depending on the vulnerabilities and security controls of the company or facility. The super pattern can be applied at the asset level, however in this representation we do not include assetDocket No. 2970063-000001-W01
[0287] Filed: January 30, 2026 information. It is just a picture showing how the MITRE techniques can be used in cyber-attack, (side note, every time MITRE updates its knowledge base, we update the super pattern)
[0288] As a side note, for illustration purposes here, the representation for the super pattern using the MITRE Enterprise Matrix vl3 looks like:
[0289] Figure 19B shows all attack paths in a super attack pattern.
[0290] 2.2.2 Vulnerability Score per TT
[0291] •:target: Calculate an aggregated score or probability of exploiting a MITRE ATT& CK technique using vulnerabilities
[0292] The process is:
[0293] o Step 1: Compute the customized CVSS per CVE. The CVSS environmental score of a CVE is enriched with the Purdue Level of the affected assets.
[0294] Based on the rules provided for asset classification, the mappings for Asset Value (AV) and Managed Asset Value (MAV) are as follows:
[0295] Flagged "in network": Both MAV and AV are set to Network.
[0296] Not in network - Level 0: MAV is Physical (e.g., direct I / O, sensors), AV is Local.
[0297] Not in network - Levels 1-2: Both are Local (e.g., local controllers, PLC).
[0298] Not in network - Levels 3-3.5: Both are Adjacent (e.g., supervisory control / HMI). Not in network - Levels 4-5: Both are Network (e.g., enterprise / site business network)
[0299] The customized CVSS per CVE is computed using the Common Vulnerability Scoring System Version 3.0 Calculator
[0300] o Step 2. Estimate a vulnerability score per CVE using its enriched CVSS and EPSS. This is obtained as CVE Score = 0.1 x CVSS x EPSS.
[0301] o Step 3. Estimate a vulnerability score per Technique. This is obtained as Probability of exploiting at least one CVE per technique.
[0302] • The mapping CVE2TT2 is used is Step 3, as it determines which CVEs are linked to each Technique.
[0303] As seen in Figure 20, the purdue value in the vector string is “modified” to be a “MAV: L” value based on the asset purdue level of 2. The vector provides the input for the calculator described in step one above. The purdue level is not in the vector string of theDocket No. 2970063-000001-W01
[0304] Filed: January 30, 2026 vulnerability. The purdue level is an attribute from the asset that has the vulnerability. We are using the purdue level to modify the CVSS. The approach only modifies purdue level as explained below. All the other variables are as in the vector string of the CVE. In other words, the approach does not modify the other attributes. The values of the modified vector provide the input for the calculator described in step one above.
[0305] This is how we introduce the purdue level in the CVSS Calculator:
[0306] If the asset is flagged as “in network,” call it Network for both AV and MAV.
[0307] If it is not:
[0308] • Level 0 — ► MAV = Physical, AV = Local
[0309] • Levels 1-2 — Local for both
[0310] • Levels 3-3.5 — Adjacent for both
[0311] • Levels 4-5 — Network for both
[0312] Figure 21 shows workflow for computing CVE scores, under an embodiment.
[0313] Figure 22 shows workflow for computing probability of exploitation with respect to a particular technique, under an embodiment.
[0314] Figure 23 show a technique by CVE table and corresponding probability of exploitation, under an embodiment.
[0315] Figure 24 shows the probability that a technique is exploited.
[0316] Figure 25 illustrates an example of the ICS supper pattern where the color of the nodes in red (or darkest shade greyscale) are the techniques with the highest probability of exploiting these techniques using some vulnerabilities in the system.
[0317] 2.3 Modeling
[0318] 2.3.1 Q Probabilities
[0319] • Target: Q probs provide information about the probabilities of 'advancing' in an attack path. Advancing is understood as using techniques to overcome tactics and stages in an attack path.
[0320] • The probability of surpassing a technique is calculated based on three scores:
[0321] vulnerabilities, actors, and security controls.
[0322] • The combination of techniques that can be used in an attack is not random. An attack flows through the MITRE techniques, as provided by the Super Attack Pattern (see above), reaching stages successively until an impact or failure conditions are reached.Docket No. 2970063-000001-W01
[0323] Filed: January 30, 2026 • That is, we have hundreds of billions of possible attack paths to simulate. The Q probabilities become smaller as the security of the facility becomes stronger, making things worse for a successful Monte Carlo experiment.
[0324] • Having and not having vulnerabilities affects the probabilities of the technique. The fewer vulnerabilities the lower the probabilities of the technique. Therefore, if a facility does not have vulnerabilities the probability of success is lower than if you have vulnerabilities.
[0325] • The process is:
[0326] o Step 1: The model independently computes a marginal exploitation probability for each identified MITRE ATT& CK technique (including techniques coming from the CVE2TT mapping). At this stage, we do not simulate attack paths and we do not consider the order of techniques in a path. The goal is to translate three dimensions — vulnerability exposure, actor capability, and defensive posture — into a single probability of success for each technique in isolation. These per- technique probabilities are then used as inputs in Steps 2 and 3, where the attackpath structure is introduced and attack propagation is simulated over the graph. Accordingly, compute the probability of exploitation of a technique using:
[0327] ■ (a) vulnerability score per technique (see above),
[0328] ■ (b) the threat actor score obtained for those actors that can act against the organization (the attacker / adversary) (The threat actor score is a normalized numeric indicator in the range [0, 1] that represents the effective capability of a threat actor to execute attack techniques against a specific organization. It does not model the likelihood that the actor will attack; it models the relative competence of the actor if they attempt to exploit a technique. Mathematically, the actor score is built as a weighted aggregation of normalized components (for example: (i) activity / recency of observed operations, (ii) capability based on goals and sophistication, and (iii) targeting alignment with the organization’s sector and geography). Each component is normalized to [0, 1] and then combined (typically via a weighted sum) into a single scalar. This scalar is then used in the non-linearDocket No. 2970063-000001-W01
[0329] Filed: January 30, 2026 exploitation-probability function as a factor that increases or decreases the probability of success depending on the attacker’s skill).
[0330] In the model, the actor represents a specific threat entity, as defined in the threat intelligence sources used (for example, actors identified in ETDA or equivalent datasets). That is, the threat actor score is computed per actor, not as an abstract average over all possible attackers.
[0331] Any aggregation, when present, occurs at the analysis level, not in the definition of the score itself. For example, the model may evaluate multiple actors that are relevant for a given scenario (industry, region, or attack type) and later combine their results, but each actor retains its own capability score. In all cases, the actor score summarizes the effective capability of the attacker, not the attacker’s identity label or the likelihood of intent to attack.
[0332] The threat actor score is defined in an operational way and is computable by one with knowledge in cybersecurity and risk modeling. It is constructed as a composite, normalized indicator in the range [0,1], derived from multiple components that capture different dimensions of the actor’s offensive capability.
[0333] In general terms, the computation follows these steps:
[0334] 1. Observable components are defined for each actor, for example:
[0335] o Activity / recency: a continuous measure reflecting how recent and frequent the actor’s attributed operations are.
[0336] o Capability / sophistication: an indicator of the technical complexity of techniques and objectives historically associated with the actor.
[0337] o Targeting alignment: the degree of overlap between the actor’s typical sectors and geographies and those of the organization being assessed.
[0338] . Each component is normalized to the [0,1] range using relative scaling within a reference universe of actors.
[0339] 3. The components are aggregated using a weighted combination to produce a single scalar score.Docket No. 2970063-000001-W01
[0340] Filed: January 30, 2026 As a conceptual example, an actor with high recent activity, advanced techniques, and a historical focus on the energy sector would receive a high score when assessing an organization in that sector, while the same actor would receive a lower score when assessing an organization outside its usual target profile. This value is then used directly as an input to the exploitation-probability function, modulating technique success based on attacker capability.
[0341] ■ (c) the security posture of the organization (the defender) (Security posture represents the effectiveness and maturity of defensive controls relevant to each technique, expressed as a continuous value in the range [0, 1], It reflects how well the organization can prevent, detect, or mitigate the execution of a specific technique. This value is obtained through the SCOTT framework, which translates security controls from common standards (e.g., NIST CSF, IEC 62443, ISO 27001) into technical indicators linked to MITRE ATT& CK techniques. Control maturity levels are aggregated and transformed into a technique-specific score, which acts in the model as a factor that reduces the exploitation probability.
[0342] Security posture is defined in a systematic and operational way and can be computed by one knowledgeable in cybersecurity. It is expressed as a continuous score in the range [0,1], computed per technique, representing the effectiveness and maturity of relevant defensive controls.
[0343] The computation process is as follows:
[0344] Defensive controls relevant to each technique (prevention, detection, and response) are identified based on widely used standards such as NIST CSF, IEC 62443, or ISO 27001. Each control is assessed in terms of maturity or effectiveness, using discrete or continuous scoring scales.
[0345] These maturity levels are aggregated and transformed through the SCOTT framework, which maps controls and maturity levels to technique-aligned scores consistent with MITRE ATT& CK.
[0346] As a conceptual example, an organization with multifactor authentication, continuous monitoring, and automated response capabilities for credentialDocket No. 2970063-000001-W01
[0347] Filed: January 30, 2026 abuse would obtain a high security posture score for credential access techniques, whereas an organization with partial or manual controls would obtain a lower score. In the model, higher security posture values reduce the exploitation probability of the corresponding technique.
[0348] Step 2: Select an attack path from the Super Attack Pattern
[0349] Step 3: Simulate the attack path using the probabilities from Step 1
[0350] Step 4a: Repeat Steps 2 and Steps 3 until convergence (The more simulations we run, the more the result stabilizes and the closer it gets to the "real" value we're trying to estimate. Convergence does not mean that we have exhaustively enumerated or simulated every possible attack path. In this context, convergence means that after repeating Steps 2 and 3 via Monte Carlo simulation, the aggregated metrics of interest stop changing materially when additional iterations are added. In other words, the probabilistic estimator becomes numerically stable. Convergence indicates statistical stability of the results, not full coverage of the combinatorial space of paths)
[0351] The idea behind convergence is that:
[0352] The more simulations we run, the more the result stabilizes and the closer it gets to the "real" value we're trying to estimate.
[0353] Convergence does not mean that we have exhaustively enumerated or simulated every possible attack path. In this context, convergence means that after repeating Steps 2 and 3 via Monte Carlo simulation, the aggregated metrics of interest stop changing materially when additional iterations are added. In other words, the probabilistic estimator becomes numerically stable. Convergence indicates statistical stability of the results, not full coverage of the combinatorial space of paths.
[0354] For example, if you run several times the same simulation, we obtain similar results, where similar results are that the difference between them is lower than a threshold or the percentage of the difference between them are lower than the threshold.
[0355] Step 4b: Use exact calculations for Q
[0356] Step 5: Summarize resultsDocket No. 2970063-000001-W01
[0357] Filed: January 30, 2026 This method may be used to simulate a success probability for each and every possible attack path in the super attack pattern. For each step along a particular attack path, the simulation uses the probability of exploiting a technique using / ?, i.e. probability of success of a technique in the presence of a vulnerability. As a simple example, assume only three attack paths in the super attack pattern. Also assume that P(Ai) is the probability p of success of technique Ai in the presence of a vulnerability.
[0358] Path 1: AI- B2-^C3: Probability of successfully traversing the path is
[0359]
[0360] n B±A Q) = PQ4J x P^Bj) x p(Q)
[0361] Path 2: Ai- B2- C3: Probability of successfully traversing the path is
[0362] P(A2n B2n c2) = P(A2) X P(B2) XPC2)
[0363] Path 3: Ai- B2" C3: Probability of successfully traversing the path is
[0364] P(A3n B3n c3) = P(A3) X P(B3) X p c3)
[0365] Conditional on a specific path being selected in a simulation run, the probability of successfully traversing it is computed as the product of the exploitation probabilities of the techniques in that path, under the standard assumption of conditional independence between successive technique attempts.
[0366] P(path) = P(A_i) * P(BJ) * P(C_k)
[0367] where each P comes from Step 1 and already incorporates actor, vulnerabilities, and controls. This computation is used to evaluate sampled path realizations during simulation, although the final model output is expressed as aggregated progression probabilities over the graph Note that the model is not designed to return a final success probability for each individual attack path as a primary output. During simulation, specific paths are sampled and evaluated, but the goal is not to characterize each route one by one. Instead, the model estimates aggregated attack-progression probabilities over the technique graph starting from an initial point (e g., an initial access vector), integrating branches and success / failure outcomes at each technique. In practice, it answers questions like: “What is the probability that an attack entering here reaches this stage or node in the graph?”, which is more useful for risk than producing a full list of per-path probabilities.
[0368] The Q-score is not defined as the probability of a single path succeeding, and it is not computed as a closed-form “at least one full path succeeds” union over paths. The Q-score is defined over the graph: it is the probability that an attack progresses through the Q-graph from anDocket No. 2970063-000001-W01
[0369] Filed: January 30, 2026 initial state (e.g., an IAV) to an impact state before being absorbed by a failure / blocking state. Mathematically, this corresponds to an absorption probability in a stochastic process (an absorbing Markov chain formulation), where each technique is a state with an associated success probability (from Step 1) that determines whether the process progresses or stops.
[0370] Q = P(reach_impact_before_failure | start_state = IAV)
[0371] Computation: the Q-score can be estimated via Monte Carlo as the fraction of simulations that reach impact:
[0372] Q_hat = (# sims that reach impact) / (total # sims) (each simulation corresponds to an independent stochastic realization of the attack process over the Q-graph. In each simulation, the traversal of the graph (i.e., the effective path followed) is generated randomly based on the per-technique success probabilities defined in Step 1. As a result, different simulations may follow different paths, terminate at different states, or reach the impact state).
[0373] or computed exactly using the standard absorbing Markov chain formulation (fundamental matrix and absorption probabilities). The estimator Q hat is computed by aggregating the outcomes of all simulations, as the fraction of simulations that reach an impact state before being absorbed by a failure or blocking state. That is, Q_hat is a Monte Carlo estimate of the absorption probability into the set of impact states, and it converges to the theoretical value of Q as the number of simulations increases.
[0374] Note that understanding a probability of a successful attack from an actor is highly valuable information. In view of a high probability over an acceptable threshold, an enterprise can increase its security score. Under an embodiment, the enterprise may increase its security score using knowledge of the SCOTT framework which translates security controls from common standards (e.g., NIST CSF, IEC 62443, ISO 27001) into technical indicators
[0375] Q-scores also incorporate techniques without explicit vulnerabilities. In those cases, the technique success probability is evaluated using a “no-vulnerability” base probability driven by actor capability and security posture (and the function parameters). This allows modeling techniques such as phishing, credential abuse, or operational mistakes without relying solely on CVEs. In short: the model is not asking “which path wins”; it is asking “what is the probability the attack gets here and produces impact”.
[0376] An attach path may proceed along a series of assets where there is no explicit vulnerability in at least one of those assets. An attack path may include techniques or assets forDocket No. 2970063-000001-W01
[0377] Filed: January 30, 2026 which no explicit vulnerability has been identified. In those cases, the vulnerability component does not increase the probability of success of the technique, and the model uses the novulnerability base probability, which is driven by actor capability and security posture. This is equivalent to treating the vulnerability factor as neutral (i.e., no increase due to vulnerabilities), not to assuming certainty of success, but rather to delegating the probability entirely to the attacker-defender balance.
[0378] An attack path may include techniques or assets for which no explicit vulnerability has been identified. In such cases, the vulnerability component does not increase the probability of success; that is, it acts neutrally, and the model uses the probability without vulnerabilities given by the actor, etc.
[0379] Attack paths are not exhaustively enumerated. Instead, attack progression is simulated stochastically over the attack graph. Each simulation represents one realization of the stochastic process, not an enumeration of all possible paths. In each simulation, transitions between techniques occur probabilistically according to the per-technique success probabilities defined in Step 1. As a result, a given simulation may follow a different path, stop at an intermediate state, or reach an impact state.
[0380] Each simulation begins from an initial access vector (IAV), sampled according to the definition of the attack pattern. From that initial point, the attack propagates through the graph following probabilistic transitions. Whether a given simulation reaches an impact state depends on the realized sequence of successes and failures along that propagation.
[0381] Each simulation begins at the IAV and propagates through the graph via probabilistic transitions depending on the success probabilities of each technique. Each simulation represents a stochastic realization of the attack process and can follow a different path, stop along the way, or reach an impact state.
[0382] The Q-score is defined at the graph level, not per node. It represents the probability that an attack starting from an initial state reaches any impact state before being absorbed by a failure or blocking state. While per-technique probabilities are used internally to guide propagation, the reported Q-score is a global measure associated with the initial condition and the full attack pattern, not a node-level metric.Docket No. 2970063-000001-W01
[0383] Filed: January 30, 2026 sigmoid(pO_sigmoid_x_scale ■ a) — 0.5
[0384] p0(a) = pO_lin_rate ■ a + pO_sigmoid_y_scale - — - 1- pO_y_offset (equation 1)
[0385] sigmoid(pinf_sigmoid_x_scale ■ a) — 0.5
[0386] Pinf(a) = pinf_lin_rate ■ a + pinf_sigmoid_y_scale - — - 1- pinf_y_offset (equation 2) 1. a' = fa■ a
[0387] 2. ssat= min (max(s, s;),
[0388] 5— fs 'Ssat
[0389] 4. r = rations', a')
[0390] 5. r' = min(r, ar■ a + n0)
[0391]
[0392] 6- Pnovuin = (Po “ Pinf) *ratio+ Pint
[0393] 7. p v + (l v) * pnovuin
[0394] Steps 1-5 modify the raw ratio score (a / a+s). Steps 1-5 transform and calibrate the raw attacker-defender balance before it is used to compute the no-vulnerability base probability. These steps apply scaling, saturation, and bounding to the original ratio a / (a + s), in order to control sensitivity, avoid extreme behavior, and ensure stable and interpretable probabilistic results.
[0395] Step 4. ratio (s', a') = (a' / a'+s'). The ratio function is evaluated using the transformed quantities a' and s', and corresponds to the normalized balance a’ / (a' + s'). This value represents the relative dominance of attacker capability versus defensive posture after applying the scaling and saturation mechanisms.
[0396] Step 6. The term ratio refers to r' computed in Step 5. The ratio term used in the novulnerability base probability corresponds to the bounded ratio value obtained after Step 5. Step 5 imposes an upper bound on the ratio based on the calibration parameters, and the resulting value is used consistently in Step 6 to compute the no-vulnerability base probability.
[0397] This is the function used to evaluate the probability of exploitation of a technique in an organization or network given:
[0398] a the actors score, and
[0399] s: the security controls score,Docket No. 2970063-000001-W01
[0400] Filed: January 30, 2026 v: the vulnerability score.
[0401] The function models the probability of successfully exploiting a technique as a function of three normalized variables, all in the range [0, 1], with the expected monotonic behavior (a and v increase probability; s reduces it):
[0402] a (actor score): a continuous scalar in [0, 1] capturing the actor’s effective capability against the organization. It is obtained by aggregating normalized components (activity / recency, capability, and sector / geography alignment) into a single scalar, typically via a weighted sum. s (security score): a continuous scalar in [0, 1] capturing the maturity / effectiveness of controls relevant to the technique. It is obtained via the SCOTT framework, which maps controls and maturity levels to MITRE ATT& CK techniques and aggregates them into a technique-level score. Higher s implies lower exploitation probability, with saturation at high maturity.
[0403] v (vulnerability score): a continuous scalar in [0, 1] capturing exploitable exposure associated with known vulnerabilities mapped to the technique. It is obtained by aggregating per-CVE signals (e.g., contextual severity and exploitability) and combining them into a single technique-level value. Higher v increases exploitation probability and determines how much weight the vulnerability component has in the final probability.
[0404] To define a nonlinear function that represents the chances for an actor to exploit a technique in the presence / absence of vulnerabilities and the maturity of the security controls in place, we need extra parameters to represent levels of saturation and different behaviors in different regions:
[0405] ■■ fs security factor
[0406] - fa threat actor factor
[0407] si: security score saturation level on the left
[0408] sr: security score saturation level on the right
[0409] s sat: Saturation of security. This defines the range in which security is moving effectively.
[0410] ratio: it is a function defined by a / (a+s)
[0411] a r: Threat rate
[0412] a 0: Threat baseline
[0413] - p 0: Probability control point at s=0Docket No. 2970063-000001-W01
[0414] Filed: January 30, 2026 p {inf}: Probability control point at s=inf
[0415] ~ p {novulns}. Probability of success of a technique without vulns. The original ratio is rescaled and displaced to the meet with the cut point and asymptote.
[0416] - p Probability of success of a technique in the presence of vulnerabilities
[0417] In addition to a, s, and v, the function includes shape / calibration parameters. These are not client-observed inputs; they are model parameters used to control sensitivity, saturation, and bounds, ensuring stable and interpretable behavior across the full [0, 1] range. Their role is twofold: (i) rescale the relative contribution of attacker and defender and (ii) set control points and asymptotes to avoid trivial or extreme probabilities.
[0418] In copyable notation, the conceptual core is an attacker-defender balance:
[0419] ratio = a / (a + s)
[0420] From this, a no-vulnerability base probability p novuln is constructed and rescaled to respect the control points pO and p inf:
[0421] p novuln = (pO - p int) * ratio + p_inf
[0422] Finally, vulnerabilities (v) are combined to obtain the final probability p:
[0423] p = v + (1 - v) * p_novuln
[0424] Integrated interpretation of parameters:
[0425] f_a and f_s rescale the influence of a and s (relative sensitivity).
[0426] The parameters f a and f_s are scale factors defined at the model level and determined by DeNexus. They are not client-observed inputs and are not empirically measured from the organization. Their purpose is to control the relative sensitivity of the exploitation probability to changes in attacker capability (a) and defensive posture (s).
[0427] From a mathematical perspective, f a and f_s rescale a and s before their relative balance is evaluated, ensuring that incremental changes in either dimension have a controlled and stable impact on the resulting probability. These parameters are set to guarantee reasonable behavior of the function across the full [0, 1] range, avoiding excessively steep slopes or nearly flat responses.
[0428] As an example, increasing f a results in a model that is more sensitive to differences between attackers (for instance, more clearly separating low-capability actors from advanced persistent threats), while increasing f_s results in a model where incremental improvements in security have a stronger impact on reducing exploitation probability.Docket No. 2970063-000001-W01
[0429] Filed: January 30, 2026 s_l, s_r, and s_sat define saturation regions for s (where additional changes have limited effect).
[0430] The parameters s i, s r, and s sat are saturation parameters defined at the model level and determined by DeNexus. They are not derived from client data; instead, they are set to define the regions in which the security posture has an effective impact on the exploitation probability.
[0431] Mathematically, these parameters delimit an interval of s values within which variations in security produce meaningful changes in probability. Below s_l and above s_r, the function enters saturation regions where additional decreases or increases in security have a limited effect. This allows the model to represent diminishing returns of security investment and prevents unrealistic behavior at extreme values.
[0432] For example, s_r may be set such that beyond a certain level of defensive maturity, further improvements reduce the probability only marginally, reflecting the fact that perfect security does not exist.
[0433] a r and a_0 limit the slope and set a minimum baseline effect of the actor.
[0434] The parameters a r and a_0 are calibration parameters defined by DeNexus and do not correspond to observed client values. Their role is to control the contribution of the actor to the exploitation probability.
[0435] The parameter a r limits the maximum slope associated with the actor effect, preventing highly capable actors from producing extreme probabilities. The parameter a_0 defines a minimum baseline contribution of the actor, reflecting that even low-capability actors may have a non-zero chance of success against simple techniques or weak defenses.
[0436] These parameters are established to ensure numerical stability and probabilistic plausibility, rather than to represent a directly observable quantity.
[0437] pO (control point at very low security) and p_inf (asymptotic lower bound at very high security) anchor plausible upper and lower probability limits.
[0438] The values pO and p inf are obtained from the balance between attacker capability and security posture using the defined equations for the no-vulnerability base probability and the technical parameters from the table. These parameters act as control points that anchor plausible upper and lower bounds for the exploitation probability.Docket No. 2970063-000001-W01
[0439] Filed: January 30, 2026 Specifically, pO defines the probability of success in the limit of very low security, while p_inf defines the asymptotic minimum probability in scenarios of very high security. Together, they ensure that the function remains bounded and avoids trivial or extreme probabilities.
[0440] In general, the scale and saturation parameters (f_a, f_s, s_l, s_r, s_sat, a_r, a_0, pO, p_inf) are model design parameters defined by DeNexus. They do not represent observed or measured values from a specific organization; their purpose is to control the sensitivity, bounds, and asymptotic behavior of the probability function, ensuring stable and interpretable results across the full [0, 1] range.
[0441] Conceptually, these parameters allow the model to express reasonable assumptions about the attacker-defender relationship. For example, increasing f a makes the model more sensitive to differences in attacker capability, so that highly sophisticated actors maintain higher success probabilities under the same defensive posture. Similarly, the saturation parameters associated with s define ranges beyond which additional increases in security maturity lead to progressively smaller reductions in exploitation probability, reflecting diminishing returns on security investment.
[0442] As an illustrative example, for the same technique and the same organization, a low-capability actor and a high-capability actor may exhibit similar success probabilities at very low levels of security maturity, but diverge significantly at intermediate levels. At very high levels of security maturity, both probabilities converge toward a lower bound defined by p_inf This behavior does not arise from client-specific data, but from the mathematical structure of the model and the calibration parameters that govern it.
[0443] Taken together, these parameters do not introduce new risk assumptions; rather, they make explicit and controllable the assumptions required to translate heterogeneous scores for actor capability, defensive posture, and vulnerabilities into coherent operational probabilities.
[0444] This acts as the link between scoring (a, s, v) and operational probability, producing bounded, smooth, and coherent probabilities.
[0445] Figure 26 is obtained with the following values and the equations above.
[0446] Table 2. Parameters
[0447] param value
[0448] p0_sigmoid_x_scale 10.000
[0449]
[0450] Docket No. 2970063-000001-W01
[0451] Filed: January 30, 2026 pO_sigmoid_y_scale 1.000
[0452] pO lin rate 0.000
[0453] pO_y_offset 0.000
[0454] pinf_sigmoid_x_scale 0.000
[0455] pinf_sigmoid_y_scale 0.000
[0456] pinf lin rate 0.100
[0457] pinf_y offset 0.125
[0458] s_threshold 0.000
[0459]
[0460] Under this embodiment, the s_ threshold is not used The parameter s threshold is an implementation-level parameter that can be used to introduce additional thresholds in the evaluation of security posture. Its presence does not alter the conceptual design of the function, and its use depends on the specific implementation configuration. Its inclusion allows for future extensions without modifying the core conceptual formulation.
[0461] The table parameters (e.g, p0 si oid x scale, pO sigmoid y scale, pO list rate, p0 y offset, pint' lin rate, pinf y offset, s threshold) are implementation-level parameters of the same underlying conceptual design. They are not client inputs and they are not measured values from the organization. They control curvature, offsets, and transition behavior (sigmoid plus a linear component) needed to numerically realize control points like pO and p inf and the saturation behavior. In other words: the conceptual parameters describe what we want the function to do (saturation, bounds, asymmetry), and the table parameters describe how that behavior is implemented in a specific functional form (sigmoid + linear terms), without introducing new assumptions.
[0462] One knowledge in cybersecurity and mathematics can understand how to establish these parameters based on their role within the function, since all of them are implementation-level parameters that control curvature, slopes, and transition points of the probability, rather than observed system inputs.
[0463] For clarity, the role, scale, and effect of each parameter are summarized below:
[0464] * pO_sigmoid_x_scale: dimensionless parameter controlling the steepness of the sigmoid transition around pO. Larger values produce sharper transitions; smaller values smooth the change.Docket No. 2970063-000001-W01
[0465] Filed: January 30, 2026 • pO sigmoid y scale: controls the vertical amplitude of the sigmoid component associated with pO. Increasing it strengthens the nonlinear contribution around low- security regimes.
[0466] • pO lin rate: slope of the linear term associated with pO, controlling residual behavior when the sigmoid saturates.
[0467] • p0_y_offset: vertical offset of p0, adjusting the baseline probability in very low-security scenarios.
[0468] • pinf sigmoid x scale: controls the sigmoid transition into the high-security asymptotic regime Larger values concentrate the transition into a narrower range.
[0469] • pinf sigmoid y scale: controls the amplitude of the sigmoid component around p_inf • pinf lin rate: slope of the linear term in the high-security regime, determining how the probability approaches the lower bound.
[0470] • pinf y offset: sets the vertical offset of the lower asymptotic bound p inf.
[0471] • s_threshold: threshold above which the security score starts to have an effect on the function. Increasing it delays the effective impact of defensive maturity.
[0472] Taken together, these parameters allow an expert reader to configure the function to reflect different assumptions about saturation, diminishing returns, and probabilistic bounds, without introducing new conceptual hypotheses
[0473] The parameter values shown in the table were used directly to generate Figure 26. The figure illustrates the behavior of the function under that specific configuration and serves as a sensitivity and calibration visualization of the model.
[0474] Figure 26 shows how the no-vulnerability base success probability (p novuln) changes as security maturity increases, under different attacker-defender balance scenarios. The x-axis represents increasing defensive maturity, and the y-axis represents the resulting probability. The curves illustrate a non-linear decrease with diminishing returns (security saturation) and show that more capable actors maintain higher residual success probabilities even under mature defenses (attacker-defender asymmetry). The figure is a sensitivity / calibration visualization of the function behavior, not an organization-specific result.
[0475] Figure 27 shows a CVE to MITRE ATT& CK mapping for use in modeling and mitigating risk of attack exploitations, under an embodiment.
[0476] Figure 28 shows a stylized attack path of a technique, under an embodiment.Docket No. 2970063-000001-W01
[0477] Filed: January 30, 2026 Figure 29 shows a markov chain representation of the attack path shown in Figure 28, where RT_2 corresponds to compromise, RT_3 corresponds to infiltration, RT_4 corresponds to persistence RT 5 corresponds to internal reconnaissance, and RT 6 corresponds to lateral movements. The figure shows potential pathways from start to failure or impact.
[0478] Figure 30 shows MITRE ATT& CK ICS techniques used in past attacks, under an embodiment.
[0479] 2.3.2 APA Module
[0480] • Target: Estimate the probability of an attack attempt being successful in causing impact or a loss event. That is, estimate how many attacks will progress from the access vector (IAV - first step of the attack) to impact (last step of the attack).
[0481] • An attack path is a set of steps. APA simulates the sequence of compromise, infiltration, persistence, and impact incident steps into a facility by an attacker, with lateral movement between logical units of assets.
[0482] • To simulate how a cyber-attack can propagate, and cause an impact on an organization, APA uses:
[0483] o network topology: a simplified but realistic representation of its OT network based on the different operational levels. It works with one site or multiple sites of the same organization, it this second case it is called multisite APA. o as much as evidence data from inside-out (IDS) combined with outside-in data (vulnerabilities, assets, traffic, etc.)
[0484] o Attack steps represented in the cyber-attack taxonomy (source: ). An attack a is a tuple of an entry point combination EC and a sequence of attacked nodes AN: • The process:
[0485] o Step 0: use Q-probs
[0486] o Step 1: run thousands of iterations of the algorithm that simulates the propagation of the incidents
[0487] o Step 3: summarize results
[0488] • The APA core is a branching random walk over a directed, weighted, cyclic graph Figure 31 illustrates different paths originating from a single IAV, under an embodiment. Figure 32 shows an example of a branching random walk, under an embodiment.
[0489] 2.4 Output / ResultsDocket No. 2970063-000001-W01
[0490] Filed: January 30, 2026 2.4.1 Probability of Success
[0491] • APA output is the estimation of the probability of success in each facility per Initial Access Vector
[0492] 2.4.2 Financial (Expected) Loss
[0493] • APA output, integrated (in combination) with the output of the other two DeRISK models is used to estimate the full expected loss distribution per Initial Access Vector given the characteristics and security posture of the organization.
[0494] 3.0 DeRISK MRS (Mitigation Project Builder MPB)
[0495] • MPB allows the assessment of risk reduction within the context of customizable cybersecurity improvement projects. The residual risk resulting from those projects is compared to the current assessment to help from the before and after expectations.
[0496] • MPB is a What-if Scenario Simulator tool that enables the user to assess the potential benefits of implementing a Project.
[0497] • A mitigation project in RBVM is a patching program. That is the MRS-Project Builder is used to estimate the risk reduction that can be obtained from the implementation of a (predefined) patching program.
[0498] • For patching program we mean to “eliminate” vulnerabilities from the system, so the probability of exploitation of certain techniques should be reduced, diminishing the probability of success of a cyber-attack.
[0499] • There is no limitation in the system to evaluate projects that combine the increase of maturity levels for selected Security Controls with patching programs
[0500] • So, MPB provides new and relevant information to support the decision-making with regards the future investments based on performance or financial KPIs.
[0501] 3.1 Data Acquisition
[0502] MRS requires two main ingredients: (a) The baseline scenario to compare with, and (b) the cost in dollars and man-hours needed for the patching program under evaluation.
[0503] 3.1.1 Risk Baseline
[0504] • This is the output of the DeRISK loss calculation engine with the facility’s actual data 3.1.2 Cost / Time
[0505] • This information depends on the program. It is used for ROI calculations. Specifically:
[0506] o TimeDocket No. 2970063-000001-W01
[0507] Filed: January 30, 2026 o Budget
[0508] o Man-hours
[0509] 3.2 Data Preparation
[0510] 3.2.1 Project or Program
[0511] • This is the stage when the data of the project is prepared as input of the modeling system 3.3 Modeling
[0512] 3.3.1 Expected Loss estimation with Project
[0513] • Step 1: Run the Unit Risk calculation with the new vulnerability scenario or settings. • Step 1: Compare the change in the Expected Loss Metrics.
[0514] 3.4 Output / Results
[0515] 3.4.1 Risk Reduction / ROI calculation
[0516] The output has two parts:
[0517] • Risk Reduction or changes in the Loss distribution due to the patching program
[0518] • ROI of the patching program
[0519] GLOSSARY
[0520] 1. NoA Number of Attack Attempts
[0521] 1. APA Attack Path Algorithm
[0522] 1. LEI Loss Event Impact
[0523] 1. MRS Mitigation Recommendation System
[0524] 1. MPB Mitigation Project Builder
[0525] • Q-prob Q probabilities module
[0526] . SAP Super Attack Pattern
[0527] . IAV Initial Access Vector
[0528] . CVE Common Vulnerabilities and Exposures -. CWE Common Weaknesses Enumeration
[0529]
[0530] Docket No. 2970063-000001-W01
[0531] Filed: January 30, 2026 Common Attack Pattern Enumerations and
[0532] CAPEC
[0533] Classifications
[0534] Adversarial Tactics, Techniques and
[0535] MITRE ATT& CK
[0536] Common Knowledge
[0537] IDS Intrusion Detection Systems
[0538] ICS Industrial Control Systems
[0539] OT Operational Technology
[0540] NVD National Vulnerability Database
[0541] CSF Cyber Security Framework
[0542] URMS Unit Risk Modeling System
[0543] EL Expected Loss
[0544] ROI Return on Investment
[0545] PAMS Portfolio Accumulation Modeling System
[0546] SCOTT Security Controls for OT DeNexus Tool
[0547] IT Information Technology
[0548] TTs MITRE ATT& CK Techniques
[0549] National Institute of Standards and
[0550] NIST
[0551] Technology
[0552]
[0553] Docket No. 2970063-000001-W01
[0554] Filed: January 30, 2026 CVE2TTs: An Al tool to map vulnerabilities tie and cyber-attack techniques Identifying vulnerabilities that are actively exploited by the attackers and understanding how a vulnerability can enable the attacker at each stage of the attack life cycle is critical for vulnerability assessments.
[0555] CVE2TTs: An AI tool to map vulnerabilities tie and cyber-attack techniques
[0556] 1. Background
[0557] • The MITRE Corporation, a non-profit organization, has made significant contributions to the development and maintenance of cybersecurity knowledge bases, earning widespread adoption within the community. One of its most prominent efforts is ATT& CK (Adversarial Tactics, Techniques, and Common Knowledge), a widely recognized taxonomy that catalogues threat actor behaviors. At the core of the ATT& CK model are techniques — specific actions adversaries use to achieve their objectives, which are organized under broader tactical goals. The primary purpose of ATT& CK is to classify adversary behavior, enhancing the ability to detect advanced intrusions post-compromise.
[0558] • Software vulnerabilities (CVEs) are pivotal in facilitating cyber intrusions. Identifying vulnerabilities actively exploited by attackers and understanding their role in enabling adversaries at various stages of the attack path is essential for effective cyber risk management.
[0559] • CVE stands for Common Vulnerabilities and Exposures. The CVE database is owned and maintained by the MITRE organization and is a collection of records detailing each of these vulnerabilities.
[0560] • Vulnerabilities can allow attackers to gain direct access to a system or network, execute code, install malware, and access internal systems to steal, destroy, or modify sensitive data. If undetected, an attacker could pose as a superuser or system administrator with full access privileges.
[0561] • The classification of a CVE in the ATT& CK taxonomy is low, while the volume of disclosed vulnerabilities is not decreasing. In this context, organizations lack a concrete approach to prioritize CVEs based on their role in the attack chain and the financial losses they may entail in case of a successful attack (reaching the impact phase)Docket No. 2970063-000001-W01
[0562] Filed: January 30, 2026 • DeNexus’ DeRTSK™ Platform is the only evidence-based, data-driven platform that translates OT cyber risk exposures and vulnerabilities into business metrics such as the financial impact of potential cyber events.
[0563] • DeRISK engine is a three-module modeling system. One of them, the Attack Path Algorithm (APA), aims to estimate the probability of success of an attacker causing an impact on an organization.
[0564] • DeRISK APA uses vulnerability information obtained from telemetry sensors installed in assets. This information, combined with threat data and the organization's security profile, is the key to determining the likelihood of an organization experiencing a successful cyber-attack.
[0565] • In short, APA simulates attack paths. An attack vector is a set of MITRE techniques.
[0566] Vulnerabilities can be exploited by using a technique to progress along an attack path. Thus, it is necessary to know which vulnerabilities can be exploited and for which techniques. DeNexus AI-CVE2TTs is the solution that answers this question.
[0567] • The goal of DeNexus is to automate the process and improve the quality of the output of the CVE2TTs mapping that DeRISK uses, for both matrices of MITRE ATT& CK, filling the gap that currently exists in this field.
[0568] State of the art / Related work
[0569] • DeNexus' AI-CVE2TTs aims to represent the practical exploitation of vulnerabilities, linking specific software vulnerabilities (CVE entries) to known adversary behaviors. This information is important, as it bridges the gap between vulnerabilities in software and how attackers might exploit them in real-world scenarios.
[0570] • Despite its relevance in cybersecurity management, there is no unique knowledge base to use. Several proposals have been published on how to obtain this map. Some of them are:
[0571] o Academia:
[0572] ■ MITRE Ingenuity
[0573] ■ Waseda University
[0574] ■ MIT (BRON)
[0575] ■ SMET: Semantic Mapping of CVE to ATT& CK and Its Application to Cybersecurity | SpringerLinkDocket No. 2970063-000001-W01
[0576] Filed: January 30, 2026 ■ CVE2ATT& CK: BERT-Based Mapping of CVEs to MITRE ATT& CK Techniques
[0577] o Private vendors:
[0578] ■ SECURIN: mitre-mapping-of-cisa-kevs-and-its-challenges
[0579] ■ VULCAN: MITRE ATTACK framework Mapping techniques to CVEs | Vulcan Cyber
[0580] ■ BALBIX: Automatic Mapping to the MITRE ATT& CK Framework | Balbix
[0581] • Note that none of those proposals apply their algorithm to the techniques of the MITRE ATT& CK ICS Matrix. They only work with the Enterprise matrix.
[0582] • For completeness, DeNexus uses both MITRE ATT& CK matrices, so neither of the above approaches covers the primary use case, which is to simulate all possible attack paths an attacker can follow when executing an attack.
[0583] 1.2 Purpose of this work
[0584] • In this work, we propose a Two-Layer Neural Network model to automatically map CVE's to ATT& CK techniques. We address the problem of lack of labels for this task, by leveraging the available information for the Enterprise matrix, in combination with subject matter expert knowledge for the ICS matrix. We evaluate the approach with the dataset containing the full list of CVEs. Using the proposed model, we mapped all the CVE records to all the ATT& CK techniques from both matrices Enterprise and ICS. • The main output of this work is a system that leverages deep learning algorithms that use vulnerability descriptions, vulnerability types, and MITRE technique descriptions to link CVEs to MITRE techniques in both matrices, Enterprise and ICS.
[0585] • The system retrieves information from public databases regularly and retrains the algorithms to update the mapping tool.
[0586] 2. Dataset development
[0587] The main objective is to generate two datasets of pairs of CVEs and MITRE ATT& CK techniques (CVE_i, Technique_j), one for each matrix, to be used for training Machine Learning algorithms for identifying which MITRE ATT& CK techniques can be exploited due to the existence or presence of a vulnerability.Docket No. 2970063-000001-W01 Filed: January 30, 2026 2.1 Data Sources
[0588] The data is obtained from the following public databases:
[0589] Table 3. Mitre Data
[0590] Information
[0591] Owner Source main value Update provided
[0592] NIST:
[0593] National
[0594] Institute CVE: Common. CVE List
[0595] NVD: National
[0596] of Vulnerabilities and Exposures, • CVE Description Vulnerability Daily Standard a global identifier to each • CWE to CVE
[0597] Database
[0598] s and vulnerability. Mapping
[0599] Technolo
[0600] gy
[0601] MITRE CWE: Common. CWE List
[0602] Security-related flaws in
[0603] Corporati Weakness • CWE to CAPEC Daily architecture, design, or code.
[0604] on Enumeration Mapping
[0605] Attack Patterns: A naming of
[0606] a relational concept linking to
[0607] . CAPEC List
[0608] a Technique (parent) and / or
[0609] . CAPEC to MITRE MITRE Weakness (child). Relates to
[0610] Techniques
[0611] Corporati CAPEC: abstract how and why (Tactic Daily Mapping for
[0612] on and Technique) of an attack
[0613] Enterprise Matrix objective and / or to abstract
[0614] only
[0615] “where” (Weakness) target of
[0616] the attack
[0617]
[0618] Docket No. 2970063-000001-W01 Filed: January 30, 2026 Techniques: Means of
[0619] achieving a tactical objective,
[0620] • List of Techniques ATT& CK: organized by Tactic, the row As MITRE in the Enterprise Adversarial Tactics, elements of the ATT& CK released Corporati Matrix
[0621] Techniques and matrix. by on • List of Techniques Common Knowledge Tactics: Tactical objectives. MITRE in the ICS Matrix
[0622] The columns of the ATT& CK
[0623] matrix.
[0624]
[0625] 2.2 Building the Training Dataset for Enterprise
[0626] • As shown in Figure 5, each CVE is linked to none, one or more CWE following the mapping provided by NIST. Then, each CWE is linked to none, one or more CAPECs using the mapping provided by MITRE. Then, using another MITRE mapping, each CAPEC is linked to none, one or more MITRE ATT& CK Enterprise techniques.
[0627] • In the last step (CAPEC-TECH) more links than the ones provided by MITRE could be derived from inheriting them from an ancestor CAPEC. Our process can leverage the CAPEC parent-child relationship to derive additional links that are not directly available on the CAPEC dataset (See Figure 33). However, the training dataset uses only direct links, i.e., no inheritance is used.
[0628] • In other words, we chained the databases as follows CVE-NVD / CWE / CAPEC / TTs to obtain data on vulnerability pairs and techniques for the Enterprise CVE2TTs training dataset. One example, for CVE-2024-39010, is shown in Figure 34.
[0629] • This procedure allows us to map 56199 out of 270105. That is 20% of the vulnerabilities database is directly mapped to an Enterprise technique from MITRE ATT& CK. The resulting dataset has 149 unique CWEs, 177 unique CAPECs, 14 MITRE Tactics and 188 MITRE Techniques (see Figure 35) A 20% mapping is sufficient for training a CVE to Technique predictive model for any given CVE in the Enterprise environment. In other words, 56199 samples were enough to train a model with high complexity to obtain good results.Docket No. 2970063-000001-W01
[0630] Filed: January 30, 2026 • It is worth pointing out that this dataset-building process is run daily as new CVEs are listed in the database.
[0631] 2.3 Building the Training Dataset for ICS
[0632] • The chain used for Enterprise lacks a connection from CAPEC to ICS Techniques. Very recently CAPEC created a view of patterns applicable to ICS (CAPEC-703), but unfortunately, the CAPECs of that view do not map to any ICS technique.
[0633] • To mitigate the issues above, particularly the lack of a link to ICS techniques. We built a threat database for ICS with expert knowledge about how a CAPEC is related to ICS techniques and how some Enterprise techniques relate to ICS techniques.
[0634] • With this CAPEC-TECH mapping for ICS, we were able to chain CVE- NVD / CWE / CAPEC / TTs as the Enterprise case (See Figure 6).
[0635] In the process of building the CVE-TECH dataset for ICS some preparation work was performed in 4 steps (see Figure 36) (Note that each box set forth in Figure 36 Each box above contains some categories of the elements of the dataset in their title. We use those categories to create the best criteria to select the training dataset).
[0636] The CWE hierarchy as defined by NIST:
[0637] Pillar: The highest level in the hierarchy. It represents broad security domains or categories.
[0638] Class: A general type of weakness within a pillar. It groups related weaknesses by common traits.
[0639] Base: A more specific weakness type under a class. It describes a distinct vulnerability pattern.
[0640] Variant: The most detailed level. It refers to a particular instance or context of a base weakness
[0641] The CWE hierarchy as defined by NIST:
[0642] ■ Pillar (e.g., CWE-664: Improper Control of a Resource)
[0643] ■ Class (e.g., CWE-400: Uncontrolled Resource Consumption) ■ Base (E.g., CWE-779: Logging of Excessive Data)
[0644] VariantDocket No. 2970063-000001-W01
[0645] Filed: January 30, 2026 Pillar: The highest level in the hierarchy. It represents broad security domains or categories. Mapping vulnerabilities to Pillar is discouraged by MITRE.
[0646] Class: A general type of weakness within a pillar. It groups related weaknesses by common traits. Mapping vulnerabilities to Classes is discouraged by MITRE.
[0647] Base: A more specific weakness type under a class. It describes a distinct vulnerability pattern.
[0648] Variant: The most detailed level. It refers to a particular instance or context of a base weakness
[0649] o Step 1: Analyze the hierarchy of CWEs provided by NIST
[0650] o Step 2: Analyze the hierarchy of CAPEC provided by MITRE
[0651] o Step 3: Build a proprietary mapping from CAPEC to ICS Techniques. The main input for the CAPEC -TECH mapping was the description of the CAPEC.
[0652] DeNexus experts linked the CAPEC to tactics and tagged them with a quality label (see Figure 36)
[0653] o Step 4: Define a criterion to set the sample with acceptable quality to be part of the training dataset (see Figure 37)
[0654] Figure 37, row / column labeled 4102 provides the following information
[0655] ■ CWE type exclude Pillar and Class - This is the filter that is applied to remove CWEs. For the highest quality match, we want to exclude the most broad and generic CWE types.
[0656] ■ CAPEC type exclude Meta - This is the filter applied to remove CAPECs that are not suitable for A-High quality level.
[0657] ■ CAPEC to ICS technique by SMEs - OT cyber experts were consulted the manually match CAPECs to ICS techniques, as well as assign their own subjective quality rating. Those they’ve assigned ‘good’ or better labels are suitable for A-High quality level.
[0658] Figure 37, row / column labeled 4104 provides the following information
[0659] ■ CWE type exclude Pillar and Class - This is the filter applied to remove CWEs that are not suitable for B-Medium quality level.Docket No. 2970063-000001-W01
[0660] Filed: January 30, 2026 ■ CAPEC type exclude Meta - This is the filter applied to remove CAPECs that are not suitable for B-Medium quality level.
[0661] ■ CAPEC to ICS technique by SMEs - OT cyber experts were consulted the manually match CAPECs to ICS techniques, as well as assign their own subjective quality rating. Those they’ve assigned ‘medium’ or better labels are suitable for B-Medium quality level.
[0662] Figure 37, row / column labeled 4108 provides the following information Twin Technique between ATT& CK for Enterprise and ICS
[0663] ■ Remote Services - DeNexus is able to use the existing mapping developed by MITRE for the ATT& CK for Enterprise framework, they have not developed such a mapping for the ATT& CK for ICS framework. Where both ATT& CK for Enterprise and ICS have the same Technique names (i.e., Remote Services) they are considered twins. Any mappings to Remote Services technique in ATT& CK for Enterprise are inherited to Remote Services under ATT& CK for ICS. In short, a twin technique Remote Service is identified in Enterprise and ICS. For every mapping of a CVE to a Remote Services technique (enterprise), this same CVE is mapped to the same technique in the ICS environment.
[0664] ■ Enterprise Tactic “Privilege Escalation” to ICS Technique T0890 - Similar to the explanation above, there are duplicate ENT TACTIC to ICS TECHNIQUE in both ATT& CK for Enterprise and ICS.
[0665] The ENTERPRISE TACTIC TA0004 “Privilege Escalation” is inside the ICS matrix as the TECHNIQUE T0890 “Exploitation for Privilege Escalation”. The ICS matrix is much more simple than ENTERPRISE. This is the reason that in ICS the privilege escalation is only represented in one technique instead a full tactic as is in Enterprise. The Enterprise tactic is much more developed, whereas the ICS tactic has very few techniques. Any mappings to ATT& CK for Enterprise are inherited for ATT& CK for ICS under the same Technique name of ‘Privilege Escalation’.Docket No. 2970063-000001-W01
[0666] Filed: January 30, 2026 Figure 37, row / column labeled 4110 provides the following information ■ Maintain CAPEC-63 mapping to T0890 at Medium quality (don’t downgrade to poor) - Technique T0890 ‘Exploitation for Privilege Escalation’ is a very broad label in ATT& CK for ICS, whereas it has been expanded into much granular techniques in ATT& CK for Enterprise. The OT Cyber expert decided that CAPEC-63, which is a Standard attack pattern in the CAPEC hierarchy, would be broadly assigned T0890. The Twin Technique approach described above (and below) triggers a CAPEC-63 mapping to T0890 in ICS. However, if the expert had downgraded the CAPEC-63 mapping to T0890 to poor, then the mapping would indeed not occur at that point. The OT expert examines / grades all the CAPEC to ICS technique mappings generated by the twin technique approach. This review is performed by the expert who decided to maintain this one at medium. This was a reviewing of that grade after fist steps of validation. The mapping of CAPEC-63 to T0890 is then maintained at Medium quality.
[0667] Figure 37, population column provides the following information.
[0668] ■ What does the population number in the population column mean? - There are >940 weaknesses defined in CWE, >550 patterns in CAPEC, >80 distinct techniques in ATT& CK for ICS. This population value is the quantity of CVEs that match this filtering criteria (from a total population, at the time, of >270000), used for AI training.
[0669] • Additionally, specific work was done to refine the training data set using twin techniques (that is, techniques that appear in both matrices) between the Enterprise and ICS matrices. That is, for those techniques that appear in both matrices, we used the mapping used in the Enterprise case, overwriting the SME recommendations. This Twin Association was applied as follows:
[0670] o The technique T0890: Exploitation for Privilege Escalation (ICS) with tactic TA0004: Privilege Escalation (Enterprise). - The Privilege Escalation tactic in Enterprise has 14 primary techniques and 31+ sub-techniques, meanwhile thisDocket No. 2970063-000001-W01
[0671] Filed: January 30, 2026 same tactic is represented as one technique in ATT& CK for ICS. Where existing data matches a CVE to MITRE ATT& CK TA0004 Privilege Escalation, it is inherited by T0890 in ICS (as it is much less defined and generalized). At that point, if a CVE maps to the Enterprise tactic (i.e, to one of its 12 techniques), then that CVE to tactic / technique combination (enterprise) also maps to that one ICS technique. T0890 is ICS TECHNIQUE and TA0004 ENT TACTIC.
[0672] Remote Services, External Remote Services, Exploitation of Remote Services, Internet Accessible Device and Exploit Public-Facing Applications. If one of them inherits all.
[0673] Figure 7 represents the relationships between MITRE ATT& CK Initial Access Vectors. Although not widely documented by MITRE, there are implied relationships between them that are used. A ‘Remote Service’ is also an ‘External Remote Service’ if you include those where the attacker is external to the company network. An ‘External Remote Service’ is also an ‘Internet Accessible Device’ if the attacker is external, but specifically on the Internet. An ‘Internet Accessible Device’ is also ‘Exploit Public-Facing Application’ if the application also has a CVE vulnerability. This figure shows the relationship between these access vectors (green boxes), and those on the right-side are more granular & specific than those on the left-side.
[0674] Using T0866 (Exploitation of Remote Services) as an example, CVE that leverages this technique includes CVE-2017-0144 (MS17-010 EternalBlue targeting SMBvl service), employed by WannaCry / NotPetya ransomware. When WannaCry executes it sends a malicious payload to an open TCP / UDP port, on a remote computer (aka., a Remote Service), that allows it to exploit the CVE-2017-0144 vulnerability. In order to exploit, it doesn't matter if the remote attacker is across the Internet (ie., Exploit Public-Facing Application) or the SMB server is exposed to the Internet (ie., Internet Accessible Device), or if it is accessed from an external network (i.e., External Remote Services), or within the same network (i.e., Exploitation of Remote Services). All we know is that SMB is active, which is a Remote Service, and the actual attacker's network location isDocket No. 2970063-000001-W01
[0675] Filed: January 30, 2026 not known, nor is it relevant for training the CVE2TT model. As any source-attack scenario is plausible for a network-borne attack (e.g., Internet, External, or local), then all applicable access vectors are inherited (i.e., Remote Services, External Remote Services, Exploitation of Remote Services, Internet Accessible Device and Exploit Public-Facing Applications). Given the relationships shown in Figure 7 (and described above), the technique CVE-2017-0144 is mapped to the following: Remote Services Technique, External Remote Services Technique, Internet Accessible Device and Exploit Public-Facing Applications Technique • As a final refinement, as the CAPEC hierarchy can be applied to both MITRE matrices., we leverage the CAPEC parent-child relationship to derive additional links that are not directly available on the CAPEC dataset, as we did for the Enterprise case (See Figure 38).
[0676] o Figure 38 shows an example CAPEC hierarchy on the left (i.e., CAPEC-122:
[0677] Privilege Abuse; CAPEC- 1: Accessing Functionality Not Properly Constrained by ACLs; CAPEC-180: Exploiting Incorrectly Configured ACLs; CAPEC-681: Exploitation of Improperly Controlled Hardware SIDs). On the right are MITRE ICS techniques (i.e., T0859: Valid Accounts; T0890: Exploit for Privilege Escalation) that have twins in the Enterprise framework (i.e. T1078 Valid Accounts; TA0004 Privilege Escalation). This means that because CAPEC- 1 (child) maps to T0890, then CAPEC-122 (parent) also maps to T0890. o Where relationships do not exist between Technique and CAPEC Standard / Detailed patterns, we may be required to query higher in the CAPEC hierarchy to find an abstract match (versus a specific one).
[0678] • One example, for CVE 2023-882, can be found in Figure 39.
[0679] This procedure allows us to map 108699 out of 270105. That is 40% of the vulnerabilities database is directly mapped to an ICS technique from MITRE ATT& CK. The resulting dataset has 211 unique CWEs, 249 unique CAPECs, 12 MITRE Tactics and 59 MITRE Techniques (see Figure 40). A 40% mapping is sufficient for training a CVE to Technique predictive model for any given CVE in the ICS environment. In other words,Docket No. 2970063-000001-W01
[0680] Filed: January 30, 2026 108699 samples were enough to train a model with high complexity to obtain good results.
[0681] • It is worth pointing out that this dataset-building process is run daily as new CVEs are listed in the database.
[0682] Mapping CAPEC to TECH (only ICS)
[0683] Matching Methods aligned with Quality label:
[0684] • Perfect - manually mapped by Subject Matter Expert.
[0685] • Good - manually mapped by SME and quality assigned is Good.
[0686] • Medium - manually mapped by SME and quality assigned is medium. Less than Good, better than Poor.
[0687] • Poor - manually mapped by SME but the relationship is very poor match.
[0688] • Inherited - it is like above, but now takes into account the CAPEC hierarchy and includes other CAPECs based on parent / child relationships.
[0689] DENEXUS uses this parent-child relationship for our SMEs to check the coherence of CAPEC / ICS mapping, as the CAPEC hierarchy can be applied to both MITRE matrices. This CAPEC parent-child relationship is useful because we can use information from a nearest, more abstract ancestor CAPEC related to a general aspect of the specific CAPEC under evaluation. Thus, we can have general information on the specific CAPEC under evaluation to see if the mapped technique makes sense. A high-abstraction CAPEC is a more general CAPEC that doesn’t depend on specific details or specific technology, which sometimes can be used to map a group of related CAPECs. The definition of each abstraction level is provided in the CAPEC Glossary.
[0690] 2.4 Vulnerability types
[0691] • Along with the vulnerability description, the CVE type is used in the mapping algorithm.
[0692] (Note: This decision was made after several test runs which showed us that using the CVE type as input significantly improves classification accuracy).
[0693] • Since no public data source provides the type, we use a classification of 16 types: (1) Overflow, (2) Input validation, (3) Bypass, (4) Gain privilege, (5) Denial of service, (6) Information leak, (7) Directory traversal, (8) SQL Injection, (9) Execute code, (10)Docket No. 2970063-000001-W01
[0694] Filed: January 30, 2026 Cross-site scripting (XSS), (11) XML external entity (XXE) injection, (12) File inclusion, (13) Memory Corruption, (14) Cross-site request forgery (CSRF), (15) Server-side request forgery (SSRF); and (16) Open redirect.
[0695] Under an embodiment, we have a ML model to fill the missing data about vulnerability type, so each CVE has at least one type. The total number of vulnerability types is 16. We use regular expressions to identify the vulnerability type per each CVE. However, using regular expressions not all CVE are filled. In order to complete the remaining vulnerability types we trained a ML model to predict them. The input of this ML model are the descriptions of the CVE and the output are the vulnerability types (16 classes). The vulnerability types are inputs for the ENT model and ICS model as we explained. The table contains four columns that together define how to detect the likely vulnerability type from a CVE description: vulnerability_type specifies the security category that the rule is trying to identify (such as Denial of Service, SQL Injection, or XSS);
[0696] option1_first_clause and option1_second_clause are optional keywords that must both appear in the CVE description for the rule to match (when present), allowing for more specific two-part patterns; and option2_clause provides an alternative single keyword that can independently trigger a match when found in the description. In short, the option1 clauses define a more precise “AND-condition” rule, while option2 offers a simpler “OR- condition,” and each row represents one way to classify a CVE description into its corresponding vulnerability type.
[0697] Table 4. Information required for assigning CVEs to vulnerability types.
[0698] vulnerability_type option1_first_clause option1_second_clause option2_clause Denial of service bomb server kernel panic Denial of service flood finger dos
[0699] Denial of service redirect system (dos
[0700] Denial of service (none) host ddos
[0701] Denial of service (none) (none) down
[0702] Denial of service (none) (none) crash
[0703] Denial of service (none) (none) kill
[0704]
[0705] Docket No. 2970063-000001-W01
[0706] Filed: January 30, 2026 vulnerability_type option1_first_clause option1_second_clause option2_clause Denial of service (none) (none) death
[0707] Denial of service (none) (none) core dump Execute code (none) (none) execut
[0708] Execute code (none) (none) run
[0709] Execute code (none) (none) hijack
[0710] Execute code (none) (none) inject
[0711] Overflow (none) (none) overflow Overflow (none) (none) stack-based Memory Corruption disclos object flood
[0712] Memory Corruption heap (none) memor Memory Corruption kernel (none) corrupt Memory Corruption store (none) (none) Memory Corruption file (none) (none) Memory Corruption data (none) (none)
[0713] Sql Injection (none) (none) sql
[0714] Cross site scripting site script XSS
[0715] (XSS)
[0716] Cross site scripting -site (none) (none)
[0717] (XSS)
[0718] Directory traversal write file finger redirection Directory traversal read path finger recursive Directory traversal list director transvers Directory traversal move lateral lateral Directory traversal (none) (none) transfer Bypass pass information bypass
[0719] Bypass data (none) (none)
[0720] Bypass file (none) (none)
[0721] Bypass command (none) (none)
[0722]
[0723] Docket No. 2970063-000001-W01
[0724] Filed: January 30, 2026 vulnerability_type option1_first_clause option1_second_clause option2_clause Bypass code (none) (none)
[0725] Bypass token (none) (none)
[0726] Bypass (none) (none) authenticat Information leak read information discover Information leak access account decrypt Information leak gain file to authenticate Information leak obtain resource unauthoriz Information leak get message (none) Information leak divulge permission (none) Information leak list (none) (none) Information leak (none) (none) hijack Information leak (none) (none) leak
[0727] Gain privilege gain permission privileg
[0728] Gain privilege get access elevat
[0729] Gain privilege obtain admin escalat
[0730] Gain privilege (none) (none) root
[0731] Gain privilege (none) (none) unauthoriz Gain privilege (none) (none) increase
[0732] Gain privilege (none) (none) higher-level Cross-site request (none) (none) forgery
[0733] forgery (CSRF)
[0734] Cross-site request (none) (none) csrf
[0735] forgery (CSRF)
[0736] File inclusion access file overwrite
[0737] File inclusion disclos director craft
[0738] File inclusion modif code transfer
[0739] File inclusion inclus (none) (none)
[0740]
[0741] Docket No. 2970063-000001-W01
[0742] Filed: January 30, 2026 vulnerability_type option1_first_clause option1_second_clause option2_clause Server-side request server (none) forgery
[0743] forgery (SSRF)
[0744] Server-side request (none) (none) ssrf
[0745] forgery (SSRF)
[0746] Server-side request (none) (none) (none)
[0747] forgery (SSRF)
[0748] Input validation (none) (none) xss
[0749] Open redirect (none) (none) redirect
[0750] XML external entity (none) (none) xxe
[0751] (XXE) injection
[0752] XML external entity (none) (none) xml
[0753] (XXE) injection
[0754] XML external entity entity (none) inject
[0755] (XXE) injection
[0756]
[0757] We use regular expressions to identify the vulnerability type per each CVE. However, using regular expressions not all CVE are filled. In order to complete the remaining vulnerability types we trained a ML model to predict them. The input of this ML model are the descriptions of the CVE and the output are the vulnerability types (16 classes). The vulnerability types are inputs for the ENT model and ICS model as we explained. CVE to Vulnerability Type
[0758] Overview & preprocessing
[0759] The model a multi label text classifier that assigns one or more vulnerability types to CVE descriptions. The pipeline lowercases all text, removes diacritics with unidecode, and strips any non alphabetic characters via regex ([^A-Za-z]+ → ' '). Tokenization uses a Keras Tokenizer configured with num_words= 10,000 (most frequent terms) and sequences are left padded / truncated to max_length=200 using pad sequences. Word representations come from FastText (wiki.en) vectors loaded the pretrained embeddingDocket No. 2970063-000001-W01
[0760] Filed: January 30, 2026 with embedding size = 300. An embedding matrix of shape (vocab_size + 1, 300) is constructed by looking up each token’s FastText vector and will be used to initialize a frozen embedding layer.
[0761] Targets & data splitting
[0762] The target column vulnerability _type is a list of labels per CVE (multi label). All unique labels are collected to determine output len (number of classes). Labels are integer encoded with LabelEncoder, and then converted to a multi hot matrix using MultiLabelBinarizer. The dataset is split 80 / 20 into train / test. For model selection, the training set undergoes 5 fold cross validation).
[0763] Model architecture & training
[0764] The classifier is a stacked LSTM implemented in Keras’ Sequential API.
[0765] Architecture (in order):
[0766] 1. Embedding: Embedding(input_dim=vocab_size+1, output_dim=300, weights=[embedding_matrix], input_length=200, trainable=False); this injects the FastText knowledge and keeps it frozen.
[0767] 2. LSTM #1: LSTM(units=64, return_sequences=True, dropout=0.2, recurrent_dropout=0.2); applies Keras defaults for internal activations (tanh for the cell, sigmoid for the gates).
[0768] 3. LSTM #2: LSTM(units=64, return_sequences=False, dropout=0.2, recurrent_dropout=0.2).
[0769] 4. Output: Dense(output_len, activation='sigmoid') to support independent per class probabilities for multi label classification.
[0770] The loss is binary cross entropy averaged over classes, optimized with Adam. Training uses batch_size=100 and up to 100 epochs with Early Stopping on val_loss (patience=3, restore_best_weights=True). The same architecture is trained within each CV fold; then a final run is performed on the full training / test split. Finally, the number of epochs used to train the final production model on all data is set to the best epoch discovered by early stopping in the held out validation run. Sigmoid function applies only to the output layer.
[0771] Evaluation, thresholding & persistenceDocket No. 2970063-000001-W01
[0772] Filed: January 30, 2026 Predictions are continuous probabilities per class. To choose an operating point, the notebook sweeps thresholds in [0.00, 0.99] (step=0.01) and selects the one maximizing Fl. Using this best cutoff, probabilities are binarized and mapped back to class names to compute: precision, recall, and Fl.
[0773] • To assign to each vulnerability a list of vulnerability types from a set of 16 possible types, we look for regular expressions in their description. Note that a vulnerability can have one or more vulnerability types assigned. The regular expressions were chosen by the DeNexus SME after analyzing the description of the CVEs. (See Figure 14)
[0774] • for a couple of examples.
[0775] • The resulting vulnerability types per CVEs were compared with the list provided by cvedetails.com (Note: we do not use the cvedetails information because it is a non-free database).
[0776] • For those CVEs without a vulnerability type, we trained a model, so all the CVEs were assigned to at least, one type. Details are provided in section 3.
[0777] Figure 14 illustrates examples of Regular Expressions used to determine whether a CVE belongs to the “Denial of Service” or “CSRF” types.
[0778] 2.5 The database of pairs (CVE i; Technique k)
[0779] DENEXUS How the information is linked together is explained in Sections 2.2 and 2.3. Section 2.5 describes the structure of the final data table
[0780] • In short, the training dataset is composed by the CVE information (CVE ID and description), the vulnerability types, and the linked MITRE ATT& CK techniques for Enterprise and ICS.
[0781] • We manage two main tables (a) the CAPEC-ICS TECHNIQUE mapping produced by the DeNexus SMEs and (b) the chain CVE / CWE / CAPEC / TECHNIQUE.
[0782] • The CAPEC-ICS TECHNIQUE is our proprietary database which is a table with the following columns:
[0783] o Columns capec_id and technique_id with the pair CAPEC, Technique ID. o Column source indicating that the origin of the above pair is proprietary. o Column quality with one quality value as described above.Docket No. 2970063-000001-W01
[0784] Filed: January 30, 2026 o Column tree_level_inheritance with the hierarchy level number. It’s an integer from 0 to inf. A value of 0 means no inheritance or a direct link, >1 means it’s an inherited link derived from an ancestor of the CAPEC at the level specified. For instance, 1 is a parent, 2 is a grandparent, etc.
[0785] • The data structure used to store each CVE-NVD / CWE / CAPEC / ATT& CK chain contains the following columns:
[0786] o The columns cve_id, cwe_id, and capec_id represent the sub-chain CVE- NVD / CWE / CAPEC (without the ATT& CK part). They are IDs of a CVE, a CWE, and a CAPEC, respectively. The CWE is related to the CVE by the NVD- CVE database. The CAPEC is related to the CWE by the CWE database. o The technique_id column represents ENTERPRISE or ICS Technique from the MITRE ATT& CK database as mapped by the CAPEC database. It is an ID. o The capec_technlque_source column contains information about the origin of the CAPEC / ATT& CK link.
[0787] o The capec technique quality column is the quality value of the CAPEC / ATT& CK link as given in our proprietary database.
[0788] o The capec technique tree level inheritance column is the hierarchy level number from our proprietary database from which the CAPEC / ATT& CK link was derived.
[0789] • Figure 41A and 41B the data table used for CVE-2023-2882 (for details on this CVE visit: NVD - CVE-2023-2882)
[0790] • It is important to note that the CVE-NVD / CWE / CAPEC subchain, without the ATT& CK part, is the same regardless of whether we are using ICS or Enterprise.
[0791] • Databases CAPEC and CAPEC-ICS TECHNIQUE are used to build the last link of the chain CVE-NVD / CWE / CAPEC / ATT& CK.
[0792] • Finally, to generate our final training dataset, we filter better-than-poor-quality links and direct links (non-inherited). In other words, we use (a) perfect, medium, and good links, and (b) links where tree_level_inheritance = 0.Docket No. 2970063-000001-W01
[0793] Filed: January 30, 2026 • A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to publicly known cybersecurity vulnerabilities. It provides a standardized way to reference and track vulnerabilities across different security databases and tools.
[0794] • A CWE (Common Weakness Enumeration) is a standardized list of common software and hardware weaknesses that can lead to security vulnerabilities. It provides a structured way to categorize and identify these weaknesses, allowing for better understanding, detection, and prevention.
[0795] • CAPEC stands for Common Attack Pattern Enumeration and Classification. It's a catalog of known cyberattack patterns used by cyber security professionals to prevent attacks. • MITRE ATT& CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally accessible knowledge base of adversary tactics and techniques based on real- world observations. It provides a common language for defenders to have conversations about emerging threats and develop effective defensive strategies.
[0796] • Linking CVEs to attack techniques is crucial for effective vulnerability management. By understanding how vulnerabilities can be exploited, organizations can prioritize remediation efforts, develop targeted defenses, and simulate realistic attack scenarios. This proactive approach strengthens security posture, reduces risk, and improves overall cybersecurity resilience.
[0797] • The CVE attributes are those used in this work, namely the description and the type as described above.
[0798] CVE2TTs Classification Model
[0799] Introduction
[0800] • Once we have the training datasets, we develop a Machine Learning system to assign MITRE ATT& CK techniques to CVEs. This information is critical to estimate the probability of success of a cyber-attack in a facility.
[0801] • The task at hand involves building a text classifier, specifically formulated as a multiclass, multilabel text classification problem. The classification targets correspond to ATT& CK techniques. It qualifies as a multiclass problem because the number of possible classes exceeds one, and as a multilabel problem because a single vulnerability can be associated with multiple techniques simultaneously.Docket No. 2970063-000001-W01
[0802] Filed: January 30, 2026 • We train two models with identical architectures, each dedicated to the Enterprise and ICS MITRE techniques. This approach accounts for the differing characteristics of the training datasets for the two matrices and addresses the challenge of having relatively few training samples compared to a large number of labels (techniques). As of the latest updates, the MITRE ATT& CK framework includes 191 techniques in the Enterprise matrix and 103 techniques in the ICS (Industrial Control Systems) matrix. Together, they total 294 unique techniques across these two domains. Considering Enterprise and ICS separately can help to reduce the number of dimensions and improve performance.
[0803] • Our system is built around a hybrid architecture that integrates multiple neural network components to process two distinct types of input: textual data related to CVEs and tabular features describing vulnerability categories. This dual-input framework allows the algorithms to simultaneously extract rich contextual information from text descriptions and leverage structured insights from categorical attributes, enabling a more comprehensive analysis.
[0804] • In addition, we have an ancillary model to assign each CVE to one or more vulnerability types, using the CVE description.
[0805] Note again that multiclass means that the models predict more than two techniques. Multilabel means that one vulnerability could be mapped to more than one technique at the same time.
[0806] 3.2 Dataset preprocessing
[0807] • The data set obtained with the methodology described in section 2 is very unbalanced.
[0808] That is, there is a large difference in label representation. The label representation is the number of samples seen for a label. In this case, we have an imbalance problem that can lead to an algorithm that cannot predict or miss underrepresented techniques. This occurs in both the Enterprise and ICS cases. However, no treatment or intervention was necessary to balance the data because the classification results have more than acceptable performance.
[0809] • To train the models we only consider vulnerabilities that have a description, a type, and associated techniques.
[0810] 3.3 ModelingDocket No. 2970063-000001-W01
[0811] Filed: January 30, 2026 1 Summary
[0812] • We initially transform our textual input into a neural network-compatible format using pre-trained FastText embeddings. These embeddings form the linguistic base of our model, converting words into dense vectors that encapsulate semantic relationships. The use of FastText embeddings is particularly beneficial, as they effectively handle out-of- vocabulary words, a frequent issue in the dynamic field of cybersecurity terms.
[0813] • Next, the embedded text is processed through two stacked Long Short-Term Memory (LSTM) layers, each with 64 units and incorporating dropout mechanisms (both standard and recurrent) at a rate of 0.2 to mitigate overfitting.
[0814] • A significant innovation in our model is the combination of tabular vulnerability-type information with processed textual data. After the LSTM layers derive features from the text, we concatenate this output with the input related to vulnerability types. This integration enables the model to evaluate both the text-rich descriptions and the structured categorical data concurrently, offering a holistic view of each vulnerability. • Subsequently, the merged features traverse a sequence of dense (fully connected) layers:
[0815] two dense layers having 1024 and 512 units respectively, both utilizing Rectified Linear Unit (ReLU) activation functions. These layers are responsible for extracting high-level features from the combined data. The final layer employs a sigmoid activation function to produce probabilities for each TTP category, with the number of units in this layer matching the TTP categories we aim to predict. The model returns a probability for each class, and we use a cutoff probability to determine an association. We have optimized this cutoff probability that maximizes the fl score. In summary, from this k-fold cross validation process, we obtain optimal cutoff probability and number of epochs. These optimal parameters are used to train the final model on the whole dataset, which will be finally used in production for predicting the techniques of new vulnerabilities that are disclosed daily.
[0816] • Figure 11 exhibits the model architecture of the final system. Sections 3.3.2 to 3.3.4 provide technical details on this architecture.
[0817] 2 Text Processing and Input PipelineDocket No. 2970063-000001-W01
[0818] Filed: January 30, 2026 • The model begins with a comprehensive text preprocessing pipeline that transforms raw vulnerability descriptions into a format suitable for deep learning analysis. All text is first converted to lowercase to ensure consistency. The system then applies to the Unicode library to normalize special characters and remove accents, followed by a regular expression filter that retains only alphabetic characters, replacing all other characters with spaces. This cleaning process ensures that the model focuses on the semantic content rather than syntactic variations.
[0819] • After cleaning, the text undergoes tokenization using a vocabulary limited to the 10,000 most frequent words. Each tokenized sequence is then padded or truncated to a fixed length of 200 tokens, which accommodates most vulnerability descriptions. Sequences shorter than 200 tokens are padded with zeros at the end, while longer sequences are truncated to maintain the most relevant initial content.
[0820] 3 Word Embedding Layer
[0821] • The first major component of the model is a word embedding layer that utilizes pretrained FastText embeddings. These embeddings, developed by Facebook Al Research and trained on the Wikipedia corpus, map each word to a 300-dimensional vector space that captures semantic relationships between words. The FastText model's ability to handle out-of-vocabulary words through sub word information makes it particularly suitable for technical text that may contain specialized terminology.
[0822] 4 Neural Network Architecture
[0823] • The core of the model consists of a carefully designed neural network architecture that processes the embedded text sequences through multiple specialized layers:
[0824] • The first layer is an LSTM (Long Short-Term Memory) network with 64 units that process the sequence of word embeddings. This LSTM layer includes dropout and recurrent dropout rates of 0.2 to prevent overfitting and is configured to return sequences for further processing. The dropout mechanisms randomly deactivate 20% of units during training, forcing the network to learn more robust features.
[0825] • A second LSTM layer, also with 64 units and matching dropout rates, follows the first but is configured to return only its final output. This layer distills the sequenceDocket No. 2970063-000001-W01
[0826] Filed: January 30, 2026 information into a fixed-size representation that captures the relevant features from the entire vulnerability description.
[0827] • At that point, the output of the second LSTM is concatenated with the encoded vulnerability types. Vulnerability types and techniques were converted to a binary array (one-hot encoded), previously.
[0828] • Following the LSTM layers, the network incorporates two dense layers that progressively refine the extracted features. The first dense layer contains 1024 units and employs a Rectified Linear Unit (ReLU) activation function, allowing it to learn complex non-linear relationships in the data. This is followed by a second dense layer with 512 units, also using (ReLU) activation, which further refines the feature representation.
[0829] • The final output layer contains one unit for each MITRE ATT& CK technique being predicted and uses a sigmoid activation function. This configuration allows the model to make independent predictions for each technique, treating the problem as a multi-label classification task where multiple techniques can be associated with a single vulnerability.
[0830] 3.4 Experiments
[0831] 3.4.1 Training strategy
[0832] For the training process, we split the dataset in a training dataset and a validation dataset. In addition, using the training dataset we use a 5-Fold Cross Validation. Cross-validation is a resampling technique used to evaluate machine learning models by partitioning the dataset into multiple subsets (folds). It helps assess the generalizability of the model on unseen data by ensuring that every data point gets a chance to be in the test set while maintaining a training set for learning. The main advantages of 5-fold cross-validation include reduced bias, as the entire dataset is used for both training and validation, lowering the risk of overfitting or underfitting. It also reduces variance by ensuring each data point is used for validation once and for training multiple times, leading to a more comprehensive assessment of model performance.
[0833] Additionally, averaging the results across five folds provides more reliable and stable performance metrics compared to a single train / test split. Finally, we train the model with the entire dataset with the best number of epochs obtained before using the Early Stopping.Docket No. 2970063-000001-W01
[0834] Filed: January 30, 2026 Training Methodology and Validation (in addition to details already provided above) The training process employs a sophisticated approach using 5-fold cross-validation to ensure robust model performance. The dataset is first split into training and validation sets. The training set is then further divided into five folds, with the model being trained five times, each time using four folds for training and one for validation.
[0835] During training, the model optimizes a binary cross-entropy loss function, which is well-suited for multi-label classification problems. The training process employs early stopping to prevent overfitting by monitoring the validation performance and stopping when no improvement is observed for a specified number of epochs.
[0836] 3.4.2 Evaluation and Optimization
[0837] • For evaluation, we split the dataset into training and test subsets. Following good practices in machine learning, we have trained the model using k-fold cross-validation in the training dataset. From this, we have selected the model that optimizes fl metric. During the evaluation, we also calculate precision, recall, fl, true positive percentage, and false negative percentage metrics for multilabel classification. The model returns a probability for each class, and we use a cutoff probability to determine an association. We have optimized this cutoff probability that maximizes the fl score. In summary, from this k-fold cross-validation process, we obtain optimal cutoff probability and number of epochs. These optimal parameters are used to train the final model on the whole dataset, which will be finally used in production for predicting the techniques of new vulnerabilities that are disclosed daily.
[0838] • Model performance is evaluated using three key metrics: precision, recall, and Fl -score.
[0839] While all metrics are monitored, the Fl -score serves as the primary optimization target when determining classification thresholds. This choice balances the trade-off between precision and recall, ensuring that the model provides both accurate and comprehensive predictions.
[0840] • The model's output consists of probability scores for each MITRE ATT& CK technique.
[0841] These scores are converted to binary predictions using optimized thresholds determined through Fl -score maximization, allowing for flexible adjustment of the precision-recall trade-off based on specific use case requirements.Docket No. 2970063-000001-W01
[0842] Filed: January 30, 2026 Classifier System Module Precision Recall Fl-Score Classifier of CVEs to ENTERPRISE techniques v20241001 0.78 0.79 0.78 Classifier of CVEs to ICS techniques v20241001 0.88 0.88 0.88 Classifier of CVEs to Vulnerability Type v20241001 0.94 0.92 0.93
[0843]
[0844] 3.5 Results
[0845] • Figure 42 shows the number of CVE per CWE, number of CVEs per CAPEC, and number of CVEs per Technique.
[0846] 3.5.1 Enterprise Mapping
[0847] • DeNexus has a tool (dashboard) to explore the results of CVE2TTs for Enterprise techniques.
[0848] o Number of CVEs per Techniques
[0849] o Number of Techniques per CVE
[0850] o Number of CVEs vs Mean CVSS over time
[0851] o Number of CVEs vs Mean EPSS over time
[0852] 3.5.2 ICS Mapping
[0853] • DeNexus has a tool (dashboard) to explore the results of CVE2TTs for ICS techniques.
[0854] o Number of CVEs per Techniques
[0855] o Number of Techniques per CVE
[0856] o Number of CVEs vs Mean CVSS over time
[0857] o Number of CVEs vs Mean EPSS over time
[0858] 4. Conclusions
[0859] In this work, DeNexus addresses the challenge of automatically mapping CVEs to ATT& CK techniques by framing it as a multi-label text classification problem and presenting a two-layer neural network model to solve it. What sets this approach apart is its application to both the Enterprise and ICS matrices of MITRE ATT& CK, bridging a significant gap in the analysis of CVEs concerning ICS-specific techniques. This achievement was made possible throughDocket No. 2970063-000001-W01
[0860] Filed: January 30, 2026 DeNexus's meticulous effort in creating and labeling a comprehensive dataset for ICS techniques, making this system capable of effectively working across both matrices. The output of this system is a critical input for quantifying the potential financial loss an organization can face due to the vulnerabilities in its network.
[0861] We want to highlight:
[0862] • The value of the system is the approach used to solve the problem, to have a full understanding of the vulnerabilities in the attack path. This is not a Machine Learning exercise. Success is not measured by the highest precision obtained.
[0863] • The system works with all the listed CVEs and all the Techniques in the MITRE ATT& CK knowledge base. An alternative embodiment filters the CVEs and the list of techniques before training their models
[0864] • The system is 100% automated and can be updated in a daily basis
[0865] • We built a proprietary CAPEC-ICS mapping.
[0866] • We built a training dataset of CVE-ICS mapping using the NVD database, the MITRE threat databases, and the proprietary CAPEC-ICS mapping.
[0867] • We built a training dataset of CVE-ENTERPRISE, which is based solely on the publicly accessible NVD and MITRE threat databases.
[0868] • We developed a classifier model for mapping CVE to ICS, trained on the CVE-ICS mapping dataset. The model architecture is based on a deep learning model for NLP. This model allows generalization to other CVEs not classified in the dataset, which includes newly published CVEs.
[0869] • We developed a classifier model for CVE to ENTERPRISE, trained using the CVE-ENT dataset and using the same architecture of the classifier model for mapping CVE to ICS. This model also allows generalization to other CVEs not classified in the dataset, including recently published CVEs.
[0870] • We developed a classifier model for the type of CVE. It’s also based on a deep learning model for NLP.
[0871] • Our evaluation results are encouraging, We show that the proposed system performs well in the absence of labels in the training dataset:Docket No. 2970063-000001-W01
[0872] Filed: January 30, 2026 o CVE type classifier performs well, which suggests that in most of the cases, the CVE descriptions contain sufficient information for identifying the correct type. o CVE2TTs classifiers perform well. During the validation stage of the training process, the performance seems good, which suggests it is capable of identifying patterns in the training dataset.
[0873] o However, it is found that some CVE descriptions are too vague and short in the sense that they clearly don’t provide any information about the type or the techniques it could cause.
[0874] • Our future work will focus on the following areas:
[0875] o Investigate the quality of the model over time. New CVE types appear over time and it almost surely impacts in the model performance.
[0876] o Investigate how much the CVE types weigh in the prediction of the model.
[0877] A method is described herein comprising under an embodiment one or more applications running on at least one processor for providing receiving software vulnerability information of a networked environment, wherein the software vulnerability information includes a plurality of network common vulnerabilities and exposures (CVEs) of the networked environment, wherein each CVE of the plurality of network CVEs exists in one or more network assets of the networked environment, wherein each CVE comprises an identification number, a description, a vulnerability type, and a vulnerability score, providing the software vulnerability information for each CVE of the plurality of network CVEs as input to a predictive model wherein the predictive model associates each CVE with at least one technique, wherein each technique is exploitable to attack the corresponding one or more network assets, receiving a plurality of attack patterns for the networked environment, wherein each attack pattern comprises a pathway of attack pattern techniques, wherein each attack pattern technique is exploitable to attack at least one underlying attack pattern asset of the plurality of attack pattern techniques, wherein the at least one underlying attack pattern asset includes the one or more network assets, using the plurality of attack patterns, the plurality of network CVEs, and the vulnerability scores to compute an aggregate probability of an actor’s successful attack on the networked environment.
[0878] In embodiments, training the predictive model comprises building a first and second training dataset using an attack database.Docket No. 2970063-000001-W01
[0879] Filed: January 30, 2026 In embodiments, the attack database comprises information for use in assessing security threats to networked environments, wherein the networked environments include the networked environment.
[0880] In embodiments, the attack database information comprises a real time database of all known CVEs.
[0881] In embodiments, the attack database information comprises a real time database of all known Common Weakness Enumerations (CWEs).
[0882] In embodiments, the attack database information comprises a real time database of all known Common Attack Pattern Enumerations and Classifications (CAPECs).
[0883] In embodiments, the attack database information comprises a real time database of all known enterprise techniques, wherein the known enterprise techniques include the at least one network technique.
[0884] In embodiments, the attack database information comprises a real time database of all known industrial control systems (ICS) techniques, wherein the known ICS techniques include the at least one network technique.
[0885] In embodiments, the attack database information associates the known CVEs and the known CWEs.
[0886] In embodiments, the attack database information associates the known CWEs and known CAPECs.
[0887] In embodiments, the attack database information associates the known CAPECS and the known enterprise techniques.
[0888] In embodiments, the building the first training dataset comprises using the attack database information to generate a network CVS to enterprise technique mapping.
[0889] In embodiments, the network CVS to enterprise technique mapping includes a mapping of the plurality of network CVEs to at least one CWE of the known CWEs.
[0890] In embodiments, the network CVS to enterprise technique mapping includes a mapping of each of the at least one CWE to at least one CAPEC.
[0891] In embodiments, the network CVS to enterprise technique mapping includes a mapping of each of the at least one CAPEC to at least one enterprise technique.Docket No. 2970063-000001-W01
[0892] Filed: January 30, 2026 In embodiments, the building the second training dataset comprises using the attack database information to generate a network CVS to ICS technique mapping.
[0893] In embodiments, the network CVS to ICS technique mapping identifies identically named enterprise techniques and ICS techniques in the attack database.
[0894] In embodiments, any mapping of the at least one network CVE to an identically named enterprise technique is inherited by the identically named ICS technique.
[0895] In embodiments, the network CVS to ICS technique mapping identifies an enterprise tactic with a corresponding single twin ICS technique of the same, wherein the enterprise tactic includes enterprise techniques of the known enterprise techniques.
[0896] In embodiments, any mapping of the at least one network CWE to a technique of the twin enterprise tactic is inherited by the twin ICS technique.
[0897] In embodiments, the first dataset comprises enterprise CVE descriptions and enterprise techniques of the network CVE to enterprise mapping.
[0898] In embodiments, the second training dataset comprises enterprise CVE descriptions and ICS techniques of the network CVE to ICS mapping.
[0899] In embodiments, the predictive model comprises an enterprise model and an ICS model. In embodiments, the training the enterprise and ICS models comprises tokenizing corresponding CVE descriptions of the first and second training datasets into corresponding enterprise and ICS sequences.
[0900] In embodiments, the training the enterprise and ICS models comprises converting the vulnerability types of the first and second training databases into corresponding enterprise and ICS vulnerability type binary arrays (one-hot encoded).
[0901] In embodiments, the training the enterprise and ICS models comprises converting techniques of the first and second training databases into corresponding enterprise and ICS binary arrays (one-hot encoded).
[0902] In embodiments, the training the enterprise and ICS models comprises applying a FastTextTM word embedding to the corresponding tokenized enterprise and ICS sequences to produce corresponding enterprise and ICS word representations.Docket No. 2970063-000001-W01
[0903] Filed: January 30, 2026 In embodiments, the training the enterprise and ICS models comprises applying a first Long Short-Term Memory (LSTM) model to the corresponding enterprise and ICS word representations.
[0904] In embodiments, the first LSTM model comprises a dropout rate and a recurrent dropout rate of 0.2.
[0905] In embodiments, the training the enterprise and ICS models comprises applying a second Long Short-Term Memory (LSTM) model to corresponding enterprise and ICS outputs of the first LSTM model.
[0906] In embodiments, the second LSTM model comprises a dropout rate and a recurrent dropout rate of 0.2.
[0907] In embodiments, the training the enterprise and ICS model comprises concatenating enterprise and ICS outputs of the second LSTM model with corresponding enterprise and ICS vulnerability type binary arrays.
[0908] In embodiments, the training the enterprise and ICS models comprises applying a first dense layer to the corresponding concatenated enterprise and ICS outputs.
[0909] In embodiments, the first dense layer comprises 1024 units and applies a Rectified Linear Unit (ReLU) activation function.
[0910] In embodiments, the training the enterprise model comprises applying a second dense layer to enterprise and ICS outputs of the first dense layer, wherein the second dense layer comprises 512 units and applies a Rectified Linear Unit (ReLU) activation function.
[0911] In embodiments, training the enterprise and ICS models comprises applying an output layer to enterprise and ICS outputs of the second dense layer, wherein the output layer assigns enterprise and ICS CVEs to one or more corresponding enterprise and ICS techniques.
[0912] In embodiments, the dense layer implements a sigmoid activation function.
[0913] In embodiments, an attack pattern technique probability of exploiting each attack pattern technique along each pathway of the plurality of attack patterns, wherein each CVE of the plurality of network CVEs exists in one or more of the at least one underlying attack pattern asset.Docket No. 2970063-000001-W01
[0914] Filed: January 30, 2026 In embodiments, when a CVE of the plurality of network CVEs exists in an attack pattern asset underlying an attack pattern technique, the attack pattern technique probability is computed at least in part using a vulnerability score the of the particular CVE.
[0915] In embodiments, the method computes a pathway probability for each pathway of successfully exploiting each attack pattern technique along the pathway using corresponding attack pattern technique probabilities.
[0916] In embodiments, an asset comprises a physical or digital component of the networked environment.
[0917] Under an embodiment, DENEXUS uses other model architecture based on BERT. BERT is a Transformers model developed by Google AI Language. We finetune the model on the training dataset with a multiclass, multilabel classification head. The objective function is a cross-entropy loss. The NN framework is PyTorch and Hugging Face Transformers library.
[0918] Computer networks suitable for use with the embodiments described herein include local area networks (LAN), wide area networks (WAN), Internet, or other connection services and network variations such as the world wide web, the public internet, a private internet, a private computer network, a public network, a mobile network, a cellular network, a value-added network, and the like. Computing devices coupled or connected to the network may be any microprocessor controlled device that permits access to the network, including terminal devices, such as personal computers, workstations, servers, mini computers, main-frame computers, laptop computers, mobile computers, palm top computers, hand held computers, mobile phones, TV set-top boxes, or combinations thereof. The computer network may include one of more LANs, WANs, Internets, and computers. The computers may serve as servers, clients, or a combination thereof. The systems and methods for identifying, analyzing, and mitigating cybersecurity risk can be a component of a single system, multiple systems, and / or geographically separate systems. The systems and methods for identifying, analyzing, and mitigating cybersecurity can also be a subcomponent or subsystem of a single system, multiple systems, and / or geographically separate systems. The components of systems and methods for identifying, analyzing, and mitigating cybersecurity risk can be coupled to one or more other components (not shown) of a host system or a system coupled to the host system.Docket No. 2970063-000001-W01
[0919] Filed: January 30, 2026 One or more components of the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and / or a corresponding interface, system or application to which the systems and methods for identifying, analyzing, and mitigating cybersecurity risk is coupled or connected includes and / or runs under and / or in association with a processing system. The processing system includes any collection of processor-based devices or computing devices operating together, or components of processing systems or devices, as is known in the art. For example, the processing system can include one or more of a portable computer, portable communication device operating in a communication network, and / or a network server. The portable computer can be any of a number and / or combination of devices selected from among personal computers, personal digital assistants, portable computing devices, and portable communication devices, but is not so limited. The processing system can include components within a larger computer system.
[0920] The processing system of an embodiment includes at least one processor and at least one memory device or subsystem. The processing system can also include or be coupled to at least one database. The term “processor” as generally used herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASIC), etc. The processor and memory can be monolithically integrated onto a single chip, distributed among a number of chips or components, and / or provided by some combination of algorithms. The methods described herein can be implemented in one or more of software algorithm(s), programs, firmware, hardware, components, circuitry, in any combination.
[0921] The components of any system that include the systems and methods for identifying, analyzing, and mitigating cybersecurity risk can be located together or in separate locations. Communication paths couple the components and include any medium for communicating or transferring files among the components. The communication paths include wireless connections, wired connections, and hybrid wireless / wired connections. The communication paths also include couplings or connections to networks including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, interoffice or backend networks, and the Internet. Furthermore, the communication paths include removable fixed mediums like floppy disks, hard disk drives, and CD-ROM disks, asDocket No. 2970063-000001-W01
[0922] Filed: January 30, 2026 well as flash RAM, Universal Serial Bus (USB) connections, RS-232 connections, telephone lines, buses, and electronic mail messages.
[0923] Aspects of the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and corresponding systems and methods described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and corresponding systems and methods include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and corresponding systems and methods may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc.
[0924] It should be noted that any system, method, and / or other components disclosed herein may be described using computer aided design tools and expressed (or represented), as data and / or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, logic component, transistor, layout geometries, and / or other characteristics. Computer-readable media in which such formatted data and / or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and / or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and / or instructions by carrierDocket No. 2970063-000001-W01
[0925] Filed: January 30, 2026 waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and / or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data and / or instruction-based expressions of the above described components may be processed by a processing entity (e.g., one or more processors) within the computer system in conjunction with execution of one or more other computer programs.
[0926] Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
[0927] The above description of embodiments of the systems and methods for identifying, analyzing, and mitigating cybersecurity risk is not intended to be exhaustive or to limit the systems and methods to the precise forms disclosed. While specific embodiments of, and examples for, the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and corresponding systems and methods are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the systems and methods, as those skilled in the relevant art will recognize. The teachings of the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and corresponding systems and methods provided herein can be applied to other systems and methods, not only for the systems and methods described above. The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the systems and methods for identifying, analyzing, and mitigating cybersecurity risk and corresponding systems and methods in light of the above detailed description.
Claims
Docket No. 2970063-000001-W01Filed: January 30, 2026 CLAIMS1. A method comprising,one or more applications running on at least one processor for providing,receiving software vulnerability information of a networked environment, wherein the software vulnerability information includes a plurality of network common vulnerabilities and exposures (CVEs) of the networked environment, wherein each CVE of the plurality of network CVEs exists in one or more network assets of the networked environment, wherein each CVE comprises an identification number, a description, a vulnerability type, and a vulnerability score;providing the software vulnerability information for each CVE of the plurality of network CVEs as input to a predictive model wherein the predictive model associates each CVE with at least one technique, wherein each technique is exploitable to attack the corresponding one or more network assets;receiving a plurality of attack patterns for the networked environment, wherein each attack pattern comprises a pathway of attack pattern techniques, wherein each attack pattern technique is exploitable to attack at least one underlying attack pattern asset of the plurality of attack pattern techniques, wherein the at least one underlying attack pattern asset includes the one or more network assets;using the plurality of attack patterns, the plurality of network CVEs, and the vulnerability scores to compute an aggregate probability of an actor’s successful attack on the networked environment.
2. The method of claim 1, wherein training the predictive model comprises building a first and second training dataset using an attack database.
3. The method of claim 2, wherein the attack database comprises information for use in assessing security threats to networked environments, wherein the networked environments include the networked environment.
4. The method of claim 3, wherein the attack database information comprises a real time database of all known CVEs.Docket No. 2970063-000001-W01Filed: January 30, 20265. The method of claim 4, wherein the attack database information comprises a real time database of all known Common Weakness Enumerations (CWEs).
6. The method of claim 5, wherein the attack database information comprises a real time database of all known Common Attack Pattern Enumerations and Classifications (CAPECs).
7. The method of claim 6, wherein the attack database information comprises a real time database of all known enterprise techniques, wherein the known enterprise techniques include the at least one network technique.
8. The method of claim 7, wherein the attack database information comprises a real time database of all known industrial control systems (ICS) techniques, wherein the known ICS techniques include the at least one network technique.
9. The method of claim 8, wherein the attack database information associates the known CVEs and the known CWEs.
10. The method of claim 9, wherein the attack database information associates the known CWEs and known CAPECs.
11. The method of claim 10, wherein the attack database information associates the known CAPECS and the known enterprise techniques.
12. The method of claim 11, wherein the building the first training dataset comprises using the attack database information to generate a network CVS to enterprise technique mapping.
13. The method of claim 12, wherein the network CVS to enterprise technique mapping includes a mapping of the plurality of network CVEs to at least one CWE of the known CWEs.Docket No. 2970063-000001-W01Filed: January 30, 2026 14. The method of claim 13, wherein the network CVS to enterprise technique mapping includes a mapping of each of the at least one CWE to at least one CAPEC.
15. The method of claim 14, wherein the network CVS to enterprise technique mapping includes a mapping of each of the at least one CAPEC to at least one enterprise technique.
16. The method of claim 15, wherein the building the second training dataset comprises using the attack database information to generate a network CVS to ICS technique mapping.
17. The method of claim 16, wherein the network CVS to ICS technique mapping identifies identically named enterprise techniques and ICS techniques in the attack database.
18. The method of claim 17, wherein any mapping of the at least one network CVE to an identically named enterprise technique is inherited by the identically named ICS technique.
19. The method of claim 18, wherein the network CVS to ICS technique mapping identifies an enterprise tactic with a corresponding single twin ICS technique of the same, wherein the enterprise tactic includes enterprise techniques of the known enterprise techniques.
20. The method of claim 19, wherein any mapping of the at least one network CWE to a technique of the twin enterprise tactic is inherited by the twin ICS technique.
21. The method of claim 20, wherein the first dataset comprises enterprise CVE descriptions and enterprise techniques of the network CVE to enterprise mapping.
22. The method of claim 21, wherein the second training dataset comprises enterprise CVE descriptions and ICS techniques of the network CVE to ICS mapping.
23. The method of claim 22, wherein the predictive model comprises an enterprise model and an ICS model.Docket No. 2970063-000001-W01Filed: January 30, 202624. The method of claim 23, wherein the training the enterprise and ICS models comprises tokenizing corresponding CVE descriptions of the first and second training datasets into corresponding enterprise and ICS sequences.
25. The method of claim 24, wherein the training the enterprise and ICS models comprises converting the vulnerability types of the first and second training databases into corresponding enterprise and ICS vulnerability type binary arrays (one-hot encoded).
26. The method of claim 25, wherein the training the enterprise and ICS models comprises converting techniques of the first and second training databases into corresponding enterprise and ICS binary arrays (one-hot encoded).
27. The method of claim 26, wherein the training the enterprise and ICS models comprises applying a FastText™ word embedding to the corresponding tokenized enterprise and ICS sequences to produce corresponding enterprise and ICS word representations.
28. The method of claim 27, wherein the training the enterprise and ICS models comprises applying a first Long Short-Term Memory (LSTM) model to the corresponding enterprise and ICS word representations.
29. The method of claim 28, wherein the first LSTM model comprises a dropout rate and a recurrent dropout rate of 0.2.
30. The method of claim 29, wherein the training the enterprise and ICS models comprises applying a second Long Short-Term Memory (LSTM) model to corresponding enterprise and ICS outputs of the first LSTM model.
31. The method of claim 30, wherein the second LSTM model comprises a dropout rate and a recurrent dropout rate of 0.2.Docket No. 2970063-000001-W01Filed: January 30, 202632. The method of claim 31, wherein the training the enterprise and ICS model comprises concatenating enterprise and ICS outputs of the second LSTM model with corresponding enterprise and ICS vulnerability type binary arrays.
33. The method of claim 32, wherein the training the enterprise and ICS models comprises applying a first dense layer to the corresponding concatenated enterprise and ICS outputs.
34. The method of claim 33, wherein the first dense layer comprises 1024 units and applies a Rectified Linear Unit (ReLU) activation function.
35. The method of claim 34, wherein the training the enterprise model comprises applying a second dense layer to enterprise and ICS outputs of the first dense layer, wherein the second dense layer comprises 512 units and applies a Rectified Linear Unit (ReLU) activation function.
36. The method of claim 35, wherein training the enterprise and ICS models comprises applying an output layer to enterprise and ICS outputs of the second dense layer, wherein the output layer assigns enterprise and ICS CVEs to one or more corresponding enterprise and ICS techniques.
37. The method of claim 36, wherein the dense layer implements a sigmoid activation function.
38. The method of claim 1, computing an attack pattern technique probability of exploiting each attack pattern technique along each pathway of the plurality of attack patterns, wherein each CVE of the plurality of network CVEs exists in one or more of the at least one underlying attack pattern asset.Docket No. 2970063-000001-W01Filed: January 30, 2026 39. The method of claim 38, wherein when a CVE of the plurality of network CVEs exists in an attack pattern asset underlying an attack pattern technique, the attack pattern technique probability is computed at least in part using a vulnerability score the of the particular CVE.
40. The method of claim 39, computing a pathway probability for each pathway of successfully exploiting each attack pattern technique along the pathway using corresponding attack pattern technique probabilities.
41. The method of claim 40, wherein an asset comprises a physical or digital component of the networked environment.