A method and system for secure threat inference using pilot- based telemetry validation in it and OT environments.

Abstract

A method and system for detecting cyber threats in a zero-trust environment by validating telemetry before using it for threat inference. Observables, such as sensor data or system logs, are received from a monitored information technology (IT) and / or operational technology (OT) environment. Prior to performing an inference process to estimate threat-related parameters, at least some of the observables are validated using one or more independent verification methods, such as physics-based simulation, behavioural analysis, or cross-source correlation. Trust indicators are assigned to the observables based on the validation and used to weight or filter the data during inference. The invention enhances threat detection resilience against falsified or misleading telemetry while preserving flexibility in deployment and data privacy, including optional use of homomorphic encryption and federated learning.

Description

[0001] A METHOD AND SYSTEM FOR SECURE THREAT INFERENCE USING PILOT-BASED TELEMETRY VALIDATION IN IT AND OT ENVIRONMENTS.

[0002] FIELD OF THE INVENTION

[0003] The present invention relates to the field of cybersecurity. More specifically, it describes a method and system for secure, adaptive threat detection in IT (Information Technology) and OT (Operational Technology) environments, wherein a cyber defense engine performs Parameter Inversion (PI) and Convergence to infer hidden threat characteristics from observable telemetry. The invention introduces a novel method for validating sensor data integrity in these processes using physicsbased or multi-source telemetry cross-checks.

[0004] This method has the acronym PILOT (Parallel Inferred Layer Of Trust).

[0005] BACKGROUND

[0006] Cybersecurity systems rely on telemetry — sensor outputs, network traffic data, logs, and other observables — to infer or detect anomalies. However, sophisticated attackers can distort or fabricate telemetry, creating a misleading view of system state. In IT systems, this might include tampering with logs or access records. In OT systems, this may involve spoofed sensors or hijacked PLC logic, simulating “safe” values while physical damage occurs.

[0007] Prior art such as GB2503735.9 (Netsapien) describes how a multi-stage process, including Parameter Inversion and Faster-Than-Real-Time (FTRT) modelling, can be used to predict and defend against threats that are both cyber-digital (IT) and cyberphysical (OT), collectively “cyber threats”. However, it does not disclose how to independently validate the integrity of the encrypted telemetry inputs used in those processes.

[0008] The present invention improves upon that system by introducing a zero-trust validation layer, which cross-references encrypted telemetry data against physicalsystem models, process constraints, or multiple redundant sources to identify spoofed, inconsistent, or falsified sensor outputs.

[0009] SUMMARY OF THE INVENTION

[0010] The invention comprises a method for secure threat detection in IT and OT systems, in which:

[0011] 1. Sensor or log data is ingested by a Parameter Inversion engine, optionally using Homomorphic Encryption (HE) to encrypt the data.

[0012] 2. A physics-aware digital twin or causal inference model simulates expected observables.

[0013] 3. Discrepancies between real and simulated observables are evaluated using loss functions.

[0014] 4. Trust scores are dynamically assigned to each data source.

[0015] 5. If inconsistent or non-physical observables are detected, the system reweights input data during threat inference.

[0016] This system enhances the robustness of PI and Convergence in zero-trust environments; in such cases, AI models operate in ciphertext or abstracted feature space. Homomorphic Encryption is preferred but optional; the system can also operate on unencrypted or pseudonymised observables.

[0017] The invention provides a technical solution to the problem of falsified or untrusted telemetry in cyber-physical or cyber-digital systems by introducing a verification process that improves the accuracy, robustness, and reliability of threat inference and prediction, including in zero-trust environments; this results in a technical effect beyond the mere implementation of an abstract algorithm, and accordingly the invention relates to patentable subject matter.

[0018] Inventive Advantage

[0019] The inventors have recognised that existing cyber threat detection systems often rely on telemetry data without independently verifying its integrity, which createsvulnerability in environments where observables may be falsified, spoofed, or selectively omitted. The disclosed method addresses this problem by introducing a verification layer that evaluates observables using independent reference sources — such as physics-based models, behavioural baselines, or multi-source correlation — prior to their use in inference. This approach enables the system to assign trust indicators to each observable and to apply those indicators during threat inference and prediction. As a result, the invention improves the robustness, accuracy, and resilience of cyber threat detection in zero-trust or adversarial conditions, including deployments that use encrypted or federated data sources. This provides a technical effect beyond routine data processing and represents a novel and inventive contribution over conventional systems.

[0020] DETAILED DESCRIPTION

[0021] 1. OVERVIEW

[0022] The invention builds upon the four-stage architecture introduced in GB2503735.9, which is known as the “main inference pipeline”, and all elements of which are incorporated by reference herein, as required:

[0023] • Stage 1: Parameter Inversion (PI) - infers hidden threat parameters from observable data.

[0024] • Stage 2: Faster-Than -Real -Time (FTRT) Modeling - simulates attack propagation.

[0025] • Stage 3: Convergence - compares model outputs with real-world data to refine predictions.

[0026] • Stage 4: Automated Patch Generation (APG) - creates dynamic countermeasures.

[0027] This invention focuses on the application of physics-verified or behaviour / causality-verified Parameter Inversion and Convergence under zero-trust data conditions, applicable to both IT and OT domains.In one embodiment, the system comprises a Parallel Inferred Layer Of Trust (PILOT), which operates independently of the main inference pipeline. PILOT uses physics-based models, causal inference frameworks, or multi-source sensor validation to assess the plausibility of each incoming observable. It functions as a continuous, parallel process that outputs validation scores or binary trust flags for each data point. These outputs are used optionally by the Parameter Inversion and Convergence stages of the main inference pipeline to suppress, weight, or flag suspect telemetry. PILOT is modular, zero-knowledge compatible, and deployable with or without federated learning or encryption.

[0028] 2. PARAMETER INVERSION WITH SENSOR VALIDATION

[0029] Definition: Parameter Inversion (PI) is a backward-inference method that estimates the unknown causes of observed effects. In cybersecurity, this involves mapping encrypted or abstracted telemetry to a set of latent threat variables (e.g., attack vector, lateral movement, persistence mechanism). The full method is described in GB2503735.9 and is hereby incorporated by reference.

[0030] Enhancement: In this invention, PI does not assume telemetry is truthful. Each observable is validated before use in inference by:

[0031] • Comparing its predicted behaviour against a physics-consistent digital twin (OT).

[0032] • Performing statistical consistency checks against independent data sources (IT).

[0033] • Using time-delayed cause-effect reasoning to identify implausible transitions.

[0034] • Assigning dynamic trust weights to each data channel.

[0035] For example, in an OT system, a temperature sensor reading is not accepted as authoritative unless the inferred heat flow, energy consumption, and actuator states are consistent. In an IT system, a login event is verified against expected user behaviour sequences and system state transitions.3. CONVERGENCE WITH MULTI-MODAL TELEMETRY COMPARISON

[0036] Definition: Convergence, as described in GB2503735.9, is the process by which FTRT simulation outputs are compared to real-world encrypted observables. If divergence is detected, AI models are retrained or adapted.

[0037] Enhancement: This invention introduces a validation mechanism within the convergence loop:

[0038] • Real-world observables (encrypted or not) are validated using physics or causal / behavioural models.

[0039] • Discrepant telemetry is flagged and downweighed in the loss function.

[0040] • Observables are grouped by trust level and source redundancy.

[0041] • Feedback is used to adjust threat inference, even in the absence of plaintext data.

[0042] This ensures that the convergence process is not misled by falsified telemetry and maintains predictive accuracy even in adversarial environments.

[0043] In some embodiments, if observables are missing or assigned a low trust score, the system may rely on values predicted by the digital twin or behavioural model as fallback inputs for inference and convergence.

[0044] 4. OPTIONAL USE OF HOMOMORPHIC ENCRYPTION (HE)

[0045] The system can operate with:

[0046] • Fully encrypted observables (via Homomorphic Encryption).

[0047] • Abstracted or pseudonymised data.

[0048] • Unencrypted telemetry, in controlled environments.

[0049] While HE is preferred for zero-knowledge security, it is not required for the core inventive process of sensor validation. All inference and convergence steps can (optionally) operate on transformed data that does not expose raw customer data.5. APPLICATION TO OT SYSTEMS

[0050] In OT environments, additional validation mechanisms are used:

[0051] • Physics-Aware Models: Simulate flow, inertia, thermodynamics, and control feedback.

[0052] • Time-Lag Analysis: Verify that actuator-sensor response delays match physical expectations.

[0053] • Sensor Triangulation: Use majority voting across redundant encrypted observables.

[0054] • Causal Consistency: Ensure actuator commands produce expected system states.

[0055] If a single sensor reports a safe state but this contradicts physical expectations or cross-modal observables, the data is flagged as potentially compromised.

[0056] 6. APPLICATION TO IT SYSTEMS

[0057] Although many of the illustrative examples provided herein (especially in the physicsbased validation context) are OT-centric, the invention is fully applicable to IT systems as well.

[0058] In IT environments, the equivalent of physics-based validation may include:

[0059] • Causal sequence verification (e.g., login — > config change -> process spawn).

[0060] • Behavioural expectation modelling (e.g., user never accessed that resource before).

[0061] • Multi-source verification (e.g., SIEM logs + firewall + EDR must align).

[0062] • Statistical anomaly modelling (e.g., login time outside expected patterns).

[0063] Thus, the core method of validating potentially compromised observables via external logic applies fully to IT systems, even though the validation source may differ (behavioural rather than physical).7. APPLICATION TO IT AND OT SYSTEMS SIMULTANEOUSLY

[0064] It is also perfectly possible for the skilled practitioner to deploy the system, in one of the Digital Core embodiments, such that the system can simultaneously provide protection for both IT and OT threats, from the same Digital Core. Therefore the system, when deployed in a Digital Core mode, is also suitable for a customer who wishes to simultaneously protect against IT and OT threats.

[0065] 8. PILOT (Parallel Inferred Layer Of Trust)

[0066] The Parallel Inferred Layer Of Trust (PILOT) module provides real-time, independent validation of telemetry data before it is processed by the core threat inference system. PILOT runs in parallel to the Parameter Inversion and Convergence stages and is responsible for assigning a confidence score or binary verification status to each observable.

[0067] PILOT achieves this by evaluating telemetry against preconfigured physical laws (e.g. temperature cannot rise faster than a certain rate in an OT environment) or causal consistency models (e.g. authentication failures must precede privilege escalation in IT). It may optionally ingest outputs from sensor triangulation, timeseries correlation, or digital twin consistency checks.

[0068] Observables with low PILOT scores may be suppressed, down-weighted, or flagged for operator review. The PILOT module may be implemented using interpretable models (e.g. decision trees or rules engines), neural consistency discriminators, or precomputed constraint matrices. It is particularly effective in zero-trust environments where sensor spoofing is common or where external validation of internal events is required.

[0069] Each telemetry source is given a real-time trust score, based on:

[0070] • Cross-modal validationPhysics consistency (OT)

[0071] Behavioural causality

[0072] Historical reliability

[0073] These scores are used during PI and Convergence to weight observables in inference. Trust indicators, as referred to in this disclosure, may include any signal, score, classification, weighting, confidence level, or probabilistic marker derived from internal or external validation of observables. These indicators may be computed using heuristics, rule-based systems, statistical models, machine learning, physics simulations, historical profiles, causal logic, or any combination thereof.

[0074] 9. ORDER AND INDEPENDENCE OF STEPS

[0075] The components of the invention — Parameter Inversion, Convergence, and PILOT — may be implemented independently or in various combinations. Trust indicators produced by the PILOT module may be applied before inference (as filters), during inference (as weights), or after inference (as part of alert refinement or feedback convergence).

[0076] In some embodiments, Convergence may be omitted entirely, and PILOT-based inference is used alone. In others, Convergence operates without PILOT, relying solely on predictive divergence. The system also supports fallback implementations in which trust indicators are calculated but not used unless anomalous conditions are detected.

[0077] Importantly, PILOT operates in parallel to the main inference pipeline and does not require intrusive control or access to raw data; it is zero-knowledge compatible. Its use enhances accuracy and resilience but is not strictly required for the system to function.

[0078] Any method that derives trust indicators by validating telemetry using physics-based, behavioural, causal, or statistical models — whether used directly or indirectly during inference — shall be deemed to fall within the scope of this invention.10. PILOT-BASED INFERENCE

[0079] The following examples illustrate how the PILOT architecture supports trust-scored inference under real-world threat conditions: we disclose two threat scenarios (one for IT, one for OT) and specifics on how they could be dealt with by the method of the invention. The list of potential IT and I or OT threat scenarios is too large to disclose, and this is assumed to be understood, and the following are simply for illustrative purposes only.

[0080] Example Use Case 1 (IT): Detecting Syscall Manipulation Using PILOT-based Inference

[0081] Context

[0082] In a zero-trust enterprise network, a host-based intrusion detection system (HIDS) monitors system calls made by applications and processes. A malicious process attempts to hide its presence by hooking or overriding syscall return values, such as masking 'open', 'read', or 'readdir' results to prevent its own files and processes from being seen by AV tools or the kernel audit system.

[0083] Falsified Observable

[0084] The observable provided to the system (e.g. via auditd or Sysmon) claims:

[0085] " No suspicious processes are running. File paths are clean."

[0086] But this observable is falsified — the malware has patched syscall handlers using 'LD_PRELOAD', 'ptrace', or direct memory patching, and is hiding its own activity. Verification Step (Trust Validation)

[0087] Netsapien performs independent verification using multiple techniques:

[0088] 1. Cross-source correlation:

[0089] - Compares syscall logs against unfiltered kernel telemetry (e.g. low-level memory access traces, page faults, or I / O latency anomalies).

[0090] 2. Behavioural baseline deviation:

[0091] - Uses past behavioural models (e.g., sequence of system calls during startup) anddetects divergence in frequency / ordering of calls.

[0092] 3. Causal consistency model:

[0093] - If a file should exist due to a previous known action (e.g., process spawn or log write), but does not appear in current logs, a causal inconsistency is flagged.

[0094] These methods assign a low trust score to the syscall-related observables.

[0095] Trust Indicator Example (Pseudocode)

[0096] def evaluate_trust(syscall_trace, kernel_trace, historical_profile):

[0097] trust_score = 1.0 # start fully trusted

[0098] if mismatch_with_kernel_trace(syscall_trace, kernel_trace):

[0099] trust_score *= 0.5

[0100] if behavioural_deviation(syscall_trace, historical_profile):

[0101] trust_score *= 0.6

[0102] if breaks_causal_chain(syscall_trace):

[0103] trust_score *= 0.4

[0104] return trust_score

[0105] Inference Step

[0106] The system’s threat model (e.g., a Bayesian threat graph or GNN) attempts to infer whether lateral movement, process injection, or privilege escalation is occurring.

[0107] Because the syscall observables are low-trust, the model:

[0108] - Downweights or excludes them,

[0109] - Relies more on trusted signals like outbound traffic anomalies, memory allocation patterns, or timing discrepancies,

[0110] - Infers a high-likelihood of stealthy persistence or rootkit-like behaviour.

[0111] Convergence Loop

[0112] Later, a kernel log from a hardware monitor (e.g., IOMMU logs or Trusted Execution Environment) reveals unauthorized memory patching.The model adjusts confidence retroactively — reinforcing the detection and increasing the alert level.

[0113] ML Integration (Optional)

[0114] For behavioural validation, the system may use an LSTM model or transformer trained on syscall sequences from known-good apps:

[0115] import torch.nn as nn

[0116] class SyscallLSTM(nn.Module):

[0117] def __init__(self, input_dim, hidden_dim, output_dim):

[0118] super(SyscallLSTM, self).__init__()

[0119] self.lstm = nn.LSTM(input_dim, hidden_dim, batch_first=True)

[0120] self.fc = nn.Linear(hidden_dim, output_dim)

[0121] def forward(self, x):

[0122] lstm_out, _ = self.lstm(x)

[0123] last_out = lstm_out[:, -1,:]

[0124] return self.fc(last_out)

[0125] # Output = probability distribution over known syscall sequences

[0126] Result

[0127] Even though the syscall logs were falsified, Netsapien detects:

[0128] - The falsification itself (via independent validation), and

[0129] - The probable malicious intent (via inference + convergence),

[0130] Leading to an alert or mitigation action — without relying on raw syscall integrity.

[0131] Example Use Case 2 (OT): Detecting Sensor Spoofing in a Military Drone Using PILOT-based Inference

[0132] Context

[0133] A military surveillance drone operates autonomously using onboard sensors for navigation and targeting. These include GPS, IMU (inertial measurement unit), thermal imaging, and radar. During a reconnaissance mission, the drone is targetedby an adversary attempting to mislead it by spoofing its GPS signals to trigger a deviation or denial-of-service behaviour.

[0134] Falsified Observable

[0135] The GPS module reports that the drone is at its expected coordinates with stable signal strength and heading.

[0136] However, the GPS signal has been spoofed by an attacker using a portable SDR (software-defined radio), causing the reported location to be subtly incorrect. As a result, the drone unknowingly drifts off-course or misattributes a false positive target.

[0137] Verification Step (Trust Validation)

[0138] Netsapien, embedded onboard the drone’s secure telemetry processor, independently validates the GPS observable using:

[0139] 1. IMU Cross-check:

[0140] - Compares GPS-derived position deltas with inertial movement from the IMU. Inconsistencies in acceleration vs. location trajectory raise suspicion.

[0141] 2. Thermal / Radar Consistency:

[0142] - Matches observed terrain contours from radar / thermal imaging against expected maps from the drone’s mission plan. Terrain mismatch suggests positional fraud.

[0143] 3. Timing & Jitter Analysis:

[0144] -Analyses microsecond-level timing drift in GPS signals to detect spoofing signatures or inconsistent clock sources.

[0145] These methods reduce the trust indicator associated with the GPS observable.

[0146] Trust Indicator Example (Pseudocode)

[0147] def evaluate_gps_trust(gps_data, imu_data, terrain_match, signal_stability): trust = 1.0

[0148] if not matches_inertial_path(gps_data, imu_data):

[0149] trust *= 0.5

[0150] if terrain_match < 0.6:

[0151] trust *= 0.4if signal_stability_is_anomalous(gps_data):

[0152] trust *= 0.7

[0153] return trust

[0154] Inference Step

[0155] The system performs a threat inference to determine whether sensor spoofing or environmental drift is likely.

[0156] Using a threat graph or GNN trained on sensor fusion anomalies, the model:

[0157] - Downweights the GPS readings,

[0158] - Elevates importance of IMU, radar, and thermal sources,

[0159] - Infers a medium-to-high likelihood of GPS spoofing with potential hostile intent. Convergence Loop

[0160] Upon further drift or observation mismatch, the drone’s convergence engine refines the threat assessment and initiates:

[0161] - Logging and transmission of spoofing report,

[0162] - Dynamic re-tasking (e.g., altitude change or switch to IMU-based navigation), - Optional fallback to hardened time-source or terrain-matching algorithm.

[0163] ML Integration (Optional)

[0164] A recurrent sensor fusion model (e.g., Transformer or LSTM) is used to predict what the GPS location *should* be based on inertial movement and past location history:

[0165] class SensorFusionPredictor(nn. Module):

[0166] def __init__(self):

[0167] super().__init__()

[0168] self.lstm = nn.LSTM(input_size=6, hidden_size=64, batch_first=True)self.fc = nn.Linear(64, 3) # Predict x, y, z

[0169] def forward(self, x):

[0170] out, _ = self.lstm(x)

[0171] return self.fc(out[:, -1,:])# Discrepancy from GPS value informs trust degradation.

[0172] Result

[0173] Despite the falsified GPS observable, Netsapien’s embedded system detects:

[0174] - The telemetry inconsistency (via cross-validated trust inference),

[0175] - The likely spoofing intent,

[0176] - And initiates response actions autonomously — ensuring mission integrity under adversarial conditions.

[0177] MATHEMATICAL FORMALISMS AND ALGORITHMS

[0178] The following will be disclosed in this Algorithm Annex (see next section):

[0179] • Bayesian Inference for Parameter Attribution

[0180] • Graph Neural Networks for Threat Propagation Prediction

[0181] • Homomorphic Loss Functions for Encrypted Convergence

[0182] • Dynamic Trust Re-weighting Function

[0183] Validated pseudocode will be included to demonstrate the sufficiency of the invention and its implementation by a skilled person. The invention does not require the development of new Al techniques but applies known models (GNNs, Bayesian Trees, PID physics simulation) in a novel integration for zero-trust telemetry validation.

[0184] The pseudocode examples provided in this disclosure are illustrative only and may require adjustment to syntax, indentation, or formatting in accordance with the requirements of specific programming languages or execution environments. Such modifications fall within the routine capabilities of a skilled practitioner and do not affect the substance of the disclosed algorithms or their implementation.

[0185] ADVANTAGES OF THE INVENTION

[0186] • Enables secure, encrypted cyber defense with verifiable sensor data• Detects spoofed or manipulated telemetry using external cross-checks

[0187] • Works in both IT (cyber-digital) and OT (cyber-physical) environments

[0188] • Maintains accuracy in Parameter Inversion and Convergence even when data is adversarial

[0189] • Complies with zero-trust, zero-knowledge principles without relying on raw data from logs etc

[0190] ALGORITHM ANNEX

[0191] 1. PARAMETER INVERSION (PI)

[0192] 1.1 Mathematical Formalism

[0193] Let:

[0194] • 풪 = {o1, o2, ..., on} be the set of observed (optionally encrypted) telemetry.

[0195] • ℋ = {h1, h2, ..., hm} be the set of hidden threat parameters to infer.

[0196] • Each observable cy

[0197]

[0198] C9 may be partially trustworthy.

[0199] • Each hidden parameter hjis a variable representing: attack origin, vector, intent, etc.

[0200] We model the system as a Bayesian network:

[0201]

[0202] Where:

[0203] ■ / ’(’W) = Prior on threat scenarios (from training data).

[0204] • P(풪|ℋ) = Likelihood of observing this telemetry if scenario ℋ is true.

[0205] • P(풪) = Evidence (normalizing constant).

[0206] Inference is computed using Bayesian belief propagation, or for real-time use, an incremental Bayesian update.1.2 Algorithm (Pseudocode)

[0207] def bayesian_inference(prior_probs, likelihood_matrix):

[0208] """

[0209] Performs Bayesian parameter inversion.

[0210] Args:

[0211] prior_probs: List of prior probabilities for each threat hypothesis. likelihood_matrix: Matrix where L[i][j] = P(o_i | h_j)

[0212] Returns:

[0213] posterior: Updated probability for each threat hypothesis.

[0214] import numpy as np

[0215] prior = np.array(prior_probs)

[0216] likelihood = np.array(likelihood_matrix)

[0217] unnormalized = prior * np.prod(likelihood, axis=0)

[0218] posterior = unnormalized / np.sum(unnormalized)

[0219] return posterior

[0220] 1.3 Trust Weighting of Observables

[0221] Each observable oiis assigned a trust score

[0222]

[0223] e [0,1],

[0224] The modified likelihood then becomes:

[0225]

[0226] Where Pnull(oi) is the baseline noise distribution.

[0227] 1.4 Graph Neural Network (GNN) for Lateral Movement Prediction

[0228] Let:

[0229] G = (V, E) be the graph of network assets.Each node v ∈ V has features xvfrom observables.

[0230] The GNN learns a function:

[0231]

[0232] Where:

[0233] fl

[0234] • hv(l)is the node embedding at layer l,

[0235] 풩(v) are the neighbors of v,

[0236] • σ is an activation function (e.g., ReLU),

[0237] ■

[0238]

[0239] are trainable weights,

[0240] This allows prediction of attacker paths or node risk scores.

[0241] 2. CONVERGENCE

[0242] 2.1 Convergence Loss Function

[0243] Let:

[0244] • ôi= predicted observable (from FTRT model),

[0245] • oi= real-world observable (encrypted or abstracted).

[0246] • τi= trust score for observable oi.

[0247] Loss function:

[0248]

[0249] Where Dist is a similarity measure (e.g., cosine distance, squared error, encrypted Euclidean).2.2 Federated Reinforcement Learning

[0250] Each client c maintains local model parameters θc. After convergence loss is computed locally:

[0251]

[0252] Then, model updates Δθcare encrypted and aggregated:

[0253]

[0254] 3. DYNAMIC TRUST MODEL

[0255] 3.1 Trust Score Update

[0256] Each observable has a decaying trust score:

[0257]

[0258] Where:

[0259] • α ∈ [0,1] is a forgetting factor.

[0260] • fconsistencyis a consistency function (e.g., binary match, physics-based plausibility).

[0261] 3.2 Pseudocode for Trust Update

[0262] def update_trust_score(prev_score, predicted, observed, alpha=0.8):

[0263] Updates trust score based on current consistency.

[0264] def consistency(pred, obs):return 1.0 if abs(pred - obs) < threshold else 0.0

[0265] score = alpha * prev_score + (1 - alpha) * consistency(predicted, observed) return score

[0266] 4. FURTHER EXAMPLES

[0267] 4.1 OT Use Case: Physics-Aware Time Lag

[0268] If actuator A sends a command at time to, and sensor B reports effect at d7, define:

[0269] Δtmeasured= t1− t0, Δtexpected= fphysics(A,B)

[0270] If (mod) | Δtmeasured− Δtexpected| > ε, mark oias potentially falsified.

[0271] 5. Al TRAINING DATA & MODEL STRUCTURE

[0272] • Input features: abstracted or encrypted representations of events (e.g., login failure vector, anomalous port use).

[0273] • Labels: threat category, propagation path, source attribution.

[0274] • Models used:

[0275] o Graph Neural Networks for attack propagation.

[0276] o Bayesian classifiers for attribution.

[0277] o PILOT-based loss functions for convergence.

[0278] SYSTEM IMPLEMENTATION

[0279] 1. SYSTEM ARCHITECTURE AND IMPLEMENTATION METHODS

[0280] The invention may be implemented as a combination of software modules, Al models, encrypted data pipelines, and simulation frameworks. Implementation mayoccur in an on-premise system, as a cloud-hosted platform, or in hybrid form depending on operational needs and regulatory environment.

[0281] In some embodiments, the system could be deployed within fixed network infrastructure. In other embodiments, the system may be installed onboard a mobile platform, which may be manually operated or autonomous, including but not limited to platforms such as: a vehicle; vessel; aircraft; drone; weapon system; missile; launcher for a propelled device, projectile or powered vessel; orbital satellite; or robotic system, where it operates as a self-contained unit for cyber threat detection and inference. The system may receive observables from onboard sensors, controllers, or data buses, and process them locally using embedded Al models, optionally with support for federated updates or encrypted communication with external platforms. This allows secure inference and response even in air-gapped, intermittent, or zero-connectivity environments.

[0282] In further embodiments, the invention is deployed as a module, service, or embedded logic block within a third-party cybersecurity product. For example, the system may be integrated into an existing security information and event management (SIEM) system, extended detection and response (XDR) platform, Endpoint detection and response (EDR) platform, or security orchestration and automation (SOAR) engine. In OT environments, the system may be installed within a programmable logic controller (PLC), sensor, edge node, or industrial gateway. In such cases, the validation of observables, assignment of trust indicators, and threat inference processes may be performed internally by the host product, with or without external coordination. This enables localised, low-latency inference and trust scoring at the point of data collection or response, and supports embedded or field-deployed security appliances.

[0283] The above examples of mobile platforms and embedded systems is not intended to be exhaustive and all such platforms or systems with those characteristics are claimed.

[0284] 1.1 Core Components

[0285] 1. Encrypted Telemetry Collector (ETC):• Optional Homomorphic Encryption (HE) module for encrypting observables before transmission.

[0286] • Example libraries:

[0287] o Microsoft SEAL

[0288] o IBM HELib

[0289] o Zama Concrete

[0290] o PALISADE

[0291] o OpenMined PySyft / CrypTen

[0292] 2. Trust-Aware Parameter Inversion Engine (TPIE):

[0293] • Uses Bayesian inference and GNN models (e.g., PyTorch Geometric or TensorFlow GNN).

[0294] • Integrates trust scoring and external verification modules.

[0295] • Can be containerized using Docker / Kubernetes for distributed deployment.

[0296] • Runs on CPU or GPU depending on scale.

[0297] 3. Digital Twin + Physics Kernel (for OT):

[0298] • Simulates system behaviour for cross-validation of observables.

[0299] • Implemented using simulation frameworks such as:

[0300] o Modelica

[0301] o MATLAB Simulink

[0302] o OpenModelica

[0303] o Python-based simulators (SciPy, NumPy for PID, flow, heat models)

[0304] 4. FTRT Engine and Convergence Validator:

[0305] • Predictive simulation engine using abstracted digital twins (coarse-grained graphs).

[0306] • Periodically compares encrypted predictions with encrypted telemetry. • Updates AI weights using federated learning (e.g., Flower FL, TensorFlow Federated).

[0307] 5. Dynamic Trust Engine (PILOT):• Calculates and updates trust scores.

[0308] • Maintains a ledger of telemetry behavior over time.

[0309] • May use Redis, PostgreSQL, or similar lightweight state storage.

[0310] 6. Optional APG (Automated Patch Generation) Module:

[0311] • Pre-generates mitigation actions based on inferred threat patterns.

[0312] • For IT: modifies firewall policies, endpoint configurations, and access control rules.

[0313] • For OT: generates PLC logic changes or actuator constraints.

[0314] • Built using automation engines like Ansible, SaltStack, or in-house scripts.

[0315] The above components (1) to (6) are collectively called the “Digital Core” and may be deployed in a number of modes.

[0316] 1.2 Deployment Options: Digital Core

[0317] In embodiments, the Digital Core may deployed in many ways, including but not limited to any of the following (these three options are provided purely for illustrative purposes, other deployment would be known to a skilled practitioner).

[0318] Option A: On-Premises Appliance

[0319] • Deployed as a hardened server or virtual machine inside secure network zones.

[0320] • All HE occurs locally; no raw data leaves site.

[0321] Option B: Federated SaaS Model

[0322] • Lightweight telemetry agent runs on-site.

[0323] • Only encrypted observables and encrypted model updates are shared.

[0324] • All simulation and convergence occur in the cloud.

[0325] Option C: Hybrid DeploymentFTRT and patch generation in cloud; PI and convergence on-prem.

[0326] Suitable for air-gapped OT environments with occasional upload windows.

[0327] 2. EXAMPLES OF APPLICABLE THREATS

[0328] The following is a non-exhaustive list of cyber threats to which this invention may be applied:

[0329] 2.1 IT Threat Examples

[0330] • Credential stuffing attacks on login endpoints

[0331] • Phishing-based credential theft and lateral movement

[0332] • Zero-day exploits (e.g., CVE-2023-23397, Log4Shell)

[0333] • Command-and-Control (C2) beaconing from infected machines

[0334] • Ransomware with lateral propagation (e.g., WannaCry, Ryuk)

[0335] • Insider attacks masked as normal administrative activity

[0336] • Supply chain attacks via compromised software dependencies

[0337] • Data exfiltration via encrypted outbound channels

[0338] • API abuse and logic-layer attacks on cloud services

[0339] • Session hijacking via poisoned cookies or token theft

[0340] 2.2 OT Threat Examples

[0341] • Sensor spoofing in ICS / SCADA (e.g., faked flow or pressure readings)

[0342] • PLC hijacking (e.g., logic bomb inserted into Siemens S7 controller)

[0343] • Actuator manipulation to cause unsafe physical states

[0344] • Replay attacks using old sensor telemetry

[0345] • Spoofing of navigational or locational data (e.g., in a warship, guided missile, weapons launch system)

[0346] • Hijacking or spoofing of IOT sensors in the built environment (e.g., fire detection, fire safety, evacuation, fire-door actuation, sprinkler activation, HVAC system operation, bio-aerosol, Indoor Air Quality, water quality)

[0347] • Fieldbus protocol manipulation (Modbus, OPC-UA, DNP3)

[0348] • Cross-domain malware targeting HMI or safety controllers• Timing attacks that exploit system lag (e.g., Stuxnet-class threats) • Misuse of legitimate commands to trigger unsafe sequences

[0349] • Energy systems overload via malicious control logic

[0350] • Water treatment process poisoning via misconfigured control valves

[0351] This list is not exhaustive. The system is applicable to any cyber threat in which observable telemetry (digital or physical) may be partially or fully compromised.

[0352] BRIEF DESCRIPTION OF DRAWINGS

[0353] The drawings are examples of system architecture, purely for illustrative purposes.

[0354] Figure 1: a schematic diagram of where the Digital Core could be deployed in relation to sensors (third-party) already deployed within an IT or OT environment.

[0355] Figure 2: a schematic diagram of a high-level architecture for Cloud-SaaS and On-Premise deployments.

[0356] Figure 3: a schematic diagram of a high-level architecture for a Federated AI learning deployment.

[0357] SKILLED PRACTITIONER & DOCTRINE OF EQUIVALENTS

[0358] All examples, processes, algorithms, deployment models, and technologies disclosed herein are by way of example only. Variations, alternatives, and functionally equivalent techniques may be known to a skilled practitioner in the art of cyber-physical security, Al systems, encryption, or network simulation.

[0359] Accordingly, all such equivalents and variations are expressly included within the scope of this invention. The invention is defined by its claims, which cover the core ideas of:

[0360] • Secure Parameter Inversion using non-trusted observables,Convergence driven by external validation of telemetry consistency, and A zero-trust architecture that operates on encrypted or abstracted data.

[0361] These methods may be implemented using various tools, frameworks, or designs consistent with this disclosure.

[0362] Although specific embodiments have been described in detail, it will be understood by those skilled in the art that various modifications, substitutions, and alterations may be made without departing from the scope of the invention as defined by the claims. For the avoidance of doubt, the scope of protection is intended to extend to all variants which achieve substantially the same result in substantially the same way, even if not expressed in identical terms to those used in the claims, unless the context clearly indicates otherwise.

Claims

AMENDED CLAIMSreceived by the International Bureau on 19 August 2026 (19.08.26)CLAIMS1. A computer-implemented method for validating telemetry for use in cyber-threat inference in one or more of: an information technology system; an operational technology system; or a cyber-physical system, wherein the method validates whether telemetry should be relied upon by a cyber-threat inference process and wherein the telemetry may be unreliable due to one or more of: cyber manipulation; spoofing; falsification; inconsistency; selective omission; missing observables; delay; non-physical behaviour; implausible transitions; low trust in a telemetry source; sensor-source unreliability; or signal unreliability, the method comprising: receiving from one or more telemetry sources, one or more observables purporting to represent one or more of: cyber-layer data; physical-process measurements; system events; control actions; or state-transition information;performing parallel to, in advance of or during the action of a main inference pipeline, a telemetry validation process that is independent of at least one original source of the one or more observables;generating, by the telemetry validation process, a reference state, expected observable, or consistency reference from one or more reference sources that are independent from at least one original source of an observable being validated;comparing at least one of the received observables with the reference state, expected observable, or consistency reference to determine whether, or to what extent, a state or state transition represented by the at least one received observable is consistent with an expected, plausible, physically consistent, causally consistent, behaviourally consistent, statistically consistent, or operationally constrained state or state transition of the system; generating, from the comparison, one or more trust indicators for at least one of: the received observables; telemetry sources; data channels; or state transitions, wherein the one or more trust indicators indicate whether, or to what extent, any of the foregoing can be treated as reliable for use by the main inference pipeline; andusing the one or more trust indicators, before or during processing by the main inference pipeline, to determine a degree of reliance which can be placed on the subject of the trust indicator and communicating data relating to the determined degree of reliance to any of: the main inference pipeline; an operator review interface; or a system configured to generate an alert, adjust inference, or initiate a mitigation action.

2. The method of claim 1, wherein the reference state, expected observable, or consistency reference is generated using a physics-based or physics-consistent digital twin representing expected physical behaviour of the system.

3. The method of claim 1, wherein the reference state, expected observable, or consistency reference is generated using a causal model, behavioural model, historical behavioural profile, or model of expected digital or system state transitions.

4. The method of any preceding claim, wherein the telemetry validation process comprises cross-source or multi-source comparison of observables obtained from two or more independent telemetry sources.

5. The method of any preceding claim, wherein the telemetry validation process comprises determining whether an observed event, sequence of events, state, or state transition is consistent with an expected causal, behavioural, temporal, statistical, operational, or physical relationship.

6. The method of any preceding claim, wherein the reference state, expected observable, or consistency reference is generated using one or more of: physical constraints; operational constraints; causal relationships; dependencies; functional constraints; pre-computed constraint information; or expected response characteristics of the system.

7. The method of any preceding claim, wherein the telemetry validation process comprises one or more of: causal sequence verification; behavioural consistency analysis; statistical consistency analysis; historical-profile comparison; sensor triangulation; time-series correlation; time-lag analysis; digital-twin consistency checking; or multi-modal telemetry validation.

8. The method of any preceding claim, wherein at least part of the telemetry comprises one or more of: system logs; authentication events; access-control events; process events; network events; endpoint telemetry; security-system outputs; controller data; actuator data; sensor measurements; physical-process measurements; or data-bus information.

9. The method of any preceding claim, wherein at least part of the telemetry is encrypted, abstracted or pseudonymised, and wherein the telemetry validation process is performed without requiring access to plaintext raw telemetry.

10. The method of any preceding claim, wherein the telemetry validation process is performed after at least part of the main inference pipeline has generated an inference output, and wherein the one or more trust indicators are used to refine, reweight, validate, suppress, escalate, or otherwise adjust the inference output, an alert output, a mitigation action, or a convergence process.

11. The method of any preceding claim, wherein the one or more trust indicators condition input data applied to an inference process configured to infer one or more hidden threat characteristics, threat parameters, threat states, attack vectors, propagation paths, persistence mechanisms, compromised system states, or other representations of a cyber threat.

12. The method of any preceding claim, wherein the one or more trust indicators are dynamically updated over time in dependence upon subsequently received telemetry, and wherein at least one trust indicator comprises a decaying or historically weighted trust score.

13. The method of any preceding claim, wherein, when one or more observables are missing or are assigned a trust indicator representing insufficient reliability, the method uses, in place of or in addition to the one or more observables, one or more values predicted or inferred from a digital twin or behavioural model.

14. A computer-readable medium comprising executable instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any of claims 1 to 13.

15. A system configured to perform the method of any of claims 1 to 13.

16. The system of claim 15, comprising processing circuitry configured to receive telemetry comprising one or more of: system logs; authentication events; network telemetry; endpointtelemetry; security-system outputs; controller data; actuator data; sensor measurements; physical-process measurements; or data-bus information.

17. The system of claim 15 or claim 16, implemented at least partially in an on-premises computing environment comprising one or more processors located within, or communicatively linked to, an information technology, operational technology, or cyber-physical environment being monitored.

18. The system of any of claims 15 to 17, implemented at least partially in a cloud-computing or hybrid computing environment comprising remotely hosted computing resources communicatively linked to an information technology, operational technology, or cyber-physical environment being monitored.

19. The system of any of claims 15 to 18, implemented at least partially in an embedded host device or system integrated with, or communicatively coupled to, an information technology, operational technology, or cyber-physical system, wherein at least part of the telemetry validation process, generation of the one or more trust indicators, or cyber-threat inference is performed by the embedded host device or system.

20. The system of any of claims 15 to 19, wherein the system is implemented in, integrated with, or communicatively coupled to one or more of: a cyber-security device or system; a mobile platform; a road vehicle; an autonomous vehicle; a vessel; an aircraft; an unmanned aerial vehicle or drone; a robotic system; a weapon system; a Programmable Logic Controller; a sensor; an edge node; or an industrial gateway.[0001]STATEMENT UNDER ARTICLE 19(1) PCT[0002]The claims have been amended following consideration of the International Search Report and Written Opinion.[0003]Amended Claim 1 more precisely defines the telemetry-validation architecture disclosed in the application. In particular, the claim now expressly defines a telemetry-validation process performed parallel to, in advance of, or during the action of a main cyber-threat inference pipeline and independent from at least one original source of an observable being validated.[0004]The validation process generates a reference state, expected observable, or consistency reference from one or more reference sources independent from at least one original telemetry source. A received observable is compared with that reference to determine whether, or to what extent, the state or state transition represented by the observable is consistent with an expected or permissible state or transition of the monitored system.[0005]The comparison produces a trust indicator concerning an observable, telemetry source, data channel or state transition. The trust indicator is then used to determine the degree of reliance that the main inference pipeline may place upon its subject.[0006]The amendment therefore clarifies the distinction between using telemetry as input for detecting an anomaly in a monitored system and independently validating whetherthe state represented by that telemetry can itself be relied upon for subsequent cyber-threat inference.[0007]The International Search Report cited WO 2024 / 077271 A2 in relation to the claims as originally filed. The amended Claim 1 defines the independent telemetry-validation and reliance-determination architecture described above more expressly than original Claim 1, which was principally formulated in terms of a physics-based or physics-consistent digital twin. The amended claim is not restricted to a digital twin and reflects the application's disclosure of physical, causal, behavioural, statistical, operational and multi-source consistency references, and the fundamental aspect of the invention being the validation of ingested telemetry against a source which is independent of that telemetry, in parallel with, in advance of, or during the action of a main inference pipeline.[0008]In the context of amended Claim 1, the cited prior art concerns inference from telemetry, whereas the amended claim defines an independent validation process for determining the degree of reliance that may be placed upon telemetry before or during its use by a main inference pipeline.[0009]Dependent Claims 2-13 define particular implementations of this architecture in cyber-digital, operational-technology and cyber-physical environments, as well as the use of the validation after inference to improve weighting and feedback. Claims 14-20 define corresponding computer-readable-medium, system and deployment embodiments.[0010]No amendment to the description or drawings is made under Article 19.[0011]Firesapien Technologies Ltd.

Images