Analyzing the Security Threat Posed by an Intelligent Internet-of-Things System with Split Analytic Functions

Abstract

In the context of intelligent Internet-of-Things (IoT) systems, security can be viewed as preserving symmetry among trusted entities, accurate physical observations, and secure digital interactions despite adversarial threats. Analyzing the security of analytic functions in intelligent IoT systems is vital because these systems process sensitive data and make critical real-time decisions. Evaluating their security prevents data theft, stops malicious model manipulation, and protects physical infrastructure from dangerous cyber–physical attacks. Research on the security of layered intelligent IoT architecture focuses on identifying vulnerability points across physical, network, edge/fog, and cloud intelligence layers to design scalable, artificial intelligence-driven, and resource-aware defense mechanisms. This paper provides a security analysis of an intelligent IoT system architecture with split analytic functions based on their time criticality. By identifying the system’s main analytics components and interfaces, we distinguish attack surfaces, analyze the main threats and security controls, and propose security solutions that mitigate the risk. We formally modeled the threat of an insecure peering connection between analytics components to describe the attack flow. To model the attack scenarios, we considered three attacker profiles (low, medium, and high) and calculated the total risk for each. The results show that the log-normal firewall configuration offers high resistance to low-capability attackers but can collapse under 17.2 h against advanced threats. Security teams face a severe reduction in detection time, with windows shrinking from a median of 12.7 days to just 33 h when defending against high-capability attackers. Furthermore, we provide a brief sensitivity analysis examining the effects of key distribution parameters on the TTC results.

1. Introduction

An intelligent IoT (Internet of Things) system combines physically connected devices with artificial intelligence (AI). It uses sensors, machine learning, and data analysis to collect information, make smart choices, and act on its own without requiring human assistance every time [1]. Intelligent IoT systems are used in many areas, including healthcare, smart cities, industrial manufacturing, safe transportation systems, and connected cars [2]. They make smart choices automatically, spot patterns early to prevent machine breakdowns or fix issues before they worsen energy efficiency, enhance security, and provide convenience through automated control and remote management [3,4,5,6,7].

Architectural frameworks for intelligent IoT systems are structured blueprints defined by layers such as physical, network, data processing, and application, integrating artificial intelligence and edge computing to process data. These layers collaborate to collect data, move them safely, process them with smart tools, and show users useful results [8,9,10,11,12].

Separating time-sensitive (TS) analytic functions and applications from time-tolerant (TT) ones in an intelligent IoT system is important for three main reasons: meeting strict latency deadlines, ensuring high system reliability, and optimizing the network and computing resource use [13,14,15]. The TT analytic functions can be mapped to a cloud-based logical unit (a TT intelligent controller (TTIC)), which manages non-real-time, policy-driven, or delay-tolerant tasks, including asynchronous data aggregation and batch processing, policy-driven optimization and long-term control, machine learning model training, fault tolerance, and state recovery. It operates at relaxed time scales (seconds, minutes, or offline epochs) where minor transmission or processing delays do not compromise IoT system safety or core operations. The TTIC hosts TT applications (ttApps), which do not require real-time operation and are used for non-urgent tracking and reporting. They provide added-value services related to intelligent IoT system optimization and operation. Examples of ttApps include optimization of long-term scheduling, capacity planning, energy dispatch, and systemic efficiency rather than instantaneous split-second control. The TS analytic functions may be mapped to an edge-based logical unit (a TS intelligent controller (TSIC)), which ensures that high-priority, safety-critical, or motion-control data streams are processed, scheduled, and delivered within strict, bound latency windows. It performs deterministic traffic scheduling and time synchronization, real-time data acquisition and processing, intelligent closed-loop decision making, actuation, and low-latency command execution. TSIC hosts TS applications (tsApps) that require instant data processing, require very low network delays, fail if messages arrive late, and are used in live safety or control tasks. Examples of tsApps include factory robots, self-driving cars, and patient monitors.

Security is vital for intelligent IoT systems because these connected networks handle private data, control physical infrastructure, and rely on automated decisions. Without strong protection, a single weak device can expose an entire network to cyberattacks [16,17,18,19]. Intelligent IoT systems use machine learning (ML) that can malfunction or make dangerous errors if incoming data are fake or have been tampered with. Securing IoT devices and systems prevents costly crashes, ransomware attacks, and shutdown events that stop daily work. To achieve security symmetry, strong controls must be applied across all architectural layers and interconnected components because even one weak element can compromise the overall IoT system.

This article studies the security aspects of an intelligent IoT system with split analytic functions and applications on the basis of their time-criticality. The attack surface of analytic functions includes the TS intelligent controller, TT intelligent controller, the interface between them, and analytic applications. On the basis of threat modeling, we propose security defenses and solutions to mitigate risk. A detailed formal threat model was designed using Meta Attack Language (MAL), with defense assets and defense steps as well as probabilistic distributions for attack steps. This model is used for attack simulations to provide a realistic quantitative measure of effort, time delay, and likelihood of success for an attacker to breach designated system assets and bypass deployed defenses.

The main contributions of this study are as follows:

• We conducted a security analysis by modeling the security threats in an intelligent IoT system architecture with split analytic functions on the basis of their time-criticality. Contrary to existing studies, we identified security threats related to the time-tolerant functions, time-sensitive functions, the interface between them, and applications for each functional group in detail.
• We systemized security methods that address the threats identified in each functional group and propose two solutions that mitigate the majority of the threats identified. We explain the role of each actor in security-related procedures.
• We consider a specific threat and provide a formal MAL threat model with defenses and time-to-compromise probabilistic distributions. In addition, we performed quantitative risk calculations via simulation.

The rest of the article is structured as follows: First, we present related work and outline this study’s novelty. Next, we conduct an analysis of partitioning analytical processes in intelligent IoT architectures, followed by security threat modeling regarding analytic functions and identification of the main threats and security controls. We formally describe the threats related to untrusted peer connections between analytic components and discuss the simulation results regarding calculating the estimated time or effort an attacker needs to successfully breach, exploit, or gain unauthorized access to a specific system, network, or component. Before providing our conclusions, we discuss security operations that should focus on proactive, automated disruption tailored to the adversary’s capabilities and align our operational recommendations and conclusions with simulation-based evidence, explicitly acknowledging validation limitations.

2. Materials and Methods

2.1. Related Works

The main security threats to the data-processing and analytics layer in intelligent IoT systems include data poisoning, adversarial ML attacks, and unauthorized data leakage. The authors of [20] comprehensively analyzed the Industrial IoT security panorama, including attack-vector categorization, countermeasure evaluations, and a summary of future challenges. In [21], the authors identify critical security vulnerabilities and privacy risks and analyze their impact on data acquisition, transmission, storage, and inference across AI-driven IoT ecosystems. The authors of [22] present a comprehensive classification of IoT-specific threats. In [23], the authors analyze key IoT security vulnerabilities and propose defense mechanisms, such as AI and blockchain, to secure networked frameworks. The authors of [24] comprehensively review layered IoT security vulnerabilities and explore advanced defense techniques, including blockchain, ML, and fog/edge computing, for securing resource-constrained environments. In [25], a comparative evaluation of different feature selection methods using the XGBoost algorithm is provided, and it is demonstrated that a reduced data feature set can detect low-rate distributed-denial-of-service (DDoS) attacks in IoT networks without significantly reducing classification performance. The authors of [26] propose a reactive, autoencoder-based defense framework for industrial IoT systems with intrusion detection mechanisms that mitigate adversarial ML attacks without extensive retraining. In [27], an enhanced security framework that integrates ML and blockchain is presented. The authors of [28] contribute a comprehensive review that classifies AI-driven privacy solutions in IoT ecosystems and maps future challenges, while the authors of [29] provide an exhaustive evaluation of IoT security challenges and technologies published between 2021 and 2025, offering strategic recommendations for building more cohesive and adaptive security architectures. The authors of [30] provide a layer-wise analysis of IoT security vulnerabilities and AI-driven mitigation strategies.

The main security solutions for the data-processing and analytics layer in intelligent IoT systems are end-to-end data encryption, AI-driven anomaly detection, and federated learning. These mechanisms protect sensitive telemetry, stream-processing pipelines, and big-data analytical engines from compromise. Protection of data using mechanisms like AES-256 encryption, hashing algorithms, and secure enclaves is discussed in [31]. In AI-driven anomaly detection in intelligent IoT systems, ML is used to spot unusual patterns, device failures, and security threats. Key methods include Isolation Forests, LSTM (Long Short-Term Memory) autoencoders, and federated learning. These tools analyze real-time data streams to maintain network health and safety. Isolation Forests quickly isolate outliers by randomly selecting feature split values, making them ideal for fast, low-overhead anomaly detection [32,33]. LSTM autoencoders, as deep learning models, are tailored for sequential time-series sensor data that flag deviations from learned baseline behaviors [34,35]. Federated learning enables distributed IoT nodes to collaboratively train a shared global model while keeping raw, sensitive user data locally stored on device for privacy [36,37].

In this paper, we outline security requirements and controls for the TTIC, the TSIC, the interfaces between them, and intelligent applications. We focus on threats, including misconfigurations, unauthorized access, data breaches, and distributed denial-of-service (DDoS) attacks, as well as security controls such as access management, data encryption, and DDoS mitigation. We map security principles such as authentication, confidentiality, and access control to specific security requirements. Furthermore, we focus on specific threats, provide a formal threat model with defenses and probability distributions, calculate time-to-compromise (TTC), quantify attacker effort, and assess defense success rates.

2.2. Split Analytic Functions in Intelligent IoT System Architectures

Splitting-time-tolerant analysis based on rapid time-sensitive control creates a stable IoT network by dividing operational duties. It involves cloud infrastructure and localized edge computing. Older network designs combined long-range data analysis and rapid scheduling into monolithic control units. This approach created severe computational pressure and tied IoT operators to specific equipment vendors. Heavy AI training, extensive historical databases, and large-scale data evaluations require a centralized cloud environment, so combining them with real-time operations strains the system. Achieving response times measured in mere milliseconds requires edge-computing infrastructure that is both highly localized and designed for minimal latency. Splitting these analytic functions enables resource-intensive applications to run in regional data centers while fast, lightweight, real-time applications run directly on local edge devices. This split ensures efficient resource use and strong system stability.

In our previous research, we proposed separating analytical processes in an intelligent architecture [13]. While TS loops manage near-real-time operational adjustments, the TT loops process non-real-time background tasks and analysis. This separation enables decentralization of the control logic, preventing bottlenecks found in traditional centralized traffic management and improving response times for mission-critical tasks. Figure 1 illustrates the proposed separation.

Figure 1. Proposed intelligent IoT system framework: High-priority mission-critical actions take precedence over data-intensive analytics.

In the intelligent IoT system architecture, the TT intelligent controller (TTIC) is a logical function within the Management and Orchestration (MO) framework that optimizes IoT system operations on a slower, non-real-time schedule (taking over one second). The TTIC trains and updates AI and ML models while sending high-level policy instructions to guide applications running in the faster intelligent controller (the TSIC). TSIC is a logical function that quickly manages and improves IoT system parts using detailed data and connections with IoT devices, and it can also use ML to train and update models.

Both the TTIC and TSIC host modular software applications. ttApps are applications that run on the TTIC to manage, automate, and optimize IoT systems on a timescale of one second or longer. tsApps run on the TSIC to provide fast, data-driven optimization and control in time spans of between 10 milliseconds and 1 s. Smart IoT automation functions properly because ttApps and tsApps cooperate. While tsApps manage rapid, immediate, local device adjustments, ttApps provide intelligent planning that connects these fast processes to domain-wide, long-range goals.

The interface between the TTIC and TSIC (the TT–TS interface) is intent-based: a user states a high-level goal or outcome instead of manually executing step-by-step commands. The TT–TS interface acts as a vital link between time scales by connecting the TTIC and TSIC through three key services. TTApps use the policy management service to provide goal-driven guidelines related to IoT system performance to tsApps. The Enhancement information service provides sApps with deeper context so that TS control loops can make smarter decisions and supplies the training and inference datasets required by ML models running at the TSIC. Finally, the ML model management service moves newly trained, verified ML model weights or inference pipelines from heavy TTIC compute zones to local TSIC execution engines.

In modern IoT systems with split intelligent analytic functions and applications, security should be symmetrical across TT functions, TS functions, ttApps, tsApps, and the interfaces between them; i.e., authentication, authorization, encryption, monitoring, and trust evaluation must be enforced consistently regardless of where computation occurs.

The next section analyzes security threats to the TTIC, the TSIC, the applications that run on them, and the TT–TS interface.

2.3. Security Threat Modeling for Analytics Function

To model the threats, we used the security threat modeling framework STRIDE, created by Microsoft, which classifies computer security risks into six core categories: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege [38]. Spoofing is a cyber trick wherein a bad actor hides their real identity and pretends to be a trusted person, company, or computer. Tampering means changing, damaging, or interfering with something in a secret, improper, or illegal way. Repudiation means denying performance of an action without proof (violating non-repudiation). Information disclosure involves exposing confidential information to unauthorized users (violating confidentiality). Denial of service (DoS) means disrupting or degrading the availability of service to legitimate users (violating availability). Elevation of privilege is a cybersecurity concept in which a user or application acquires higher access rights than intended, such as a standard user becoming an administrator. As noted in [39], the threat can be defined as any condition, situation, or occurrence that can negatively affect a company or group’s daily activities, core purposes, operational duties, public standing, or overall reputation, as well as physical or digital holdings and individual people, by utilizing a digital network or computer framework to gain illegal entry, cause total ruin, leak private data, alter records, or block system availability. Furthermore, it encompasses the likelihood that an adverse actor or origin point can exploit a specific weakness or flaw within that computer architecture to achieve a successful breach.

The identified threats directed at the TTIC, TSIC, ttApps, tsApps, and TT–TS interface are as follows:

TTIC orchestration DoS: An attacker who penetrates the TTIC compromises core orchestration functions to crash the system or slow down IoT system operations by exploiting software flaws or weak access controls to flood system resources, corrupt data models, or stop critical control loops. This can halt intelligent policy management, delay data analytics, and overload the underlying MO system. A service outage stops legitimate ttApps from running or communicating, while a performance drop negates automated tuning and leads to high latency or dropped connections. This threat is a DoS and impacts TTIC availability.

IoT device tracking in the TTIC: An attacker gains access to the TTIC through the MO platform to access sensitive IoT device-tracking information, leading to information disclosure. This threat is a form of information disclosure and impacts TTIC confidentiality.

Compromised data integrity in the TTIC: A hacker breaks into the TTIC via the MO platform to corrupt or change data, such as altering policies to send fake instructions to the TSIC. This threat is of a type of tampering and impacts the integrity of the TTIC and TSIC.

Unauthorized access to databases in the TSIC: Within the TSIC, internal repositories house critical and confidential IoT device and network data, including historical network states, operational configurations tied to IoT devices, data flows, unique identifiers, and the intricate associations linking these elements. Positioned directly above these data storage systems is a common data interface (CDI) that serves as the primary facilitator for tsApp interaction and retrieval. The TSIC requires robust security protocols to ensure that any tsApp attempting entry is properly authenticated and restricted to only those database segments for which explicit access rights have been granted. This threat can be categorized as tampering or information disclosure and impacts the TSIC’s integrity and confidentiality.

API security and authentication in the TSIC: TSIC application programming interfaces (APIs) are software pathways that let microservice tsApps talk to the TSIC platform. They handle tsApp registration, data access, and control commands. APIs can be hacked, stolen, or forced offline by heavy cyberattacks. Because they act like software bridges, bad actors can try to break them to stop services or steal private messages. This threat is a form of spoofing, and it impacts the TSIC and TT–TS interface.

API security and authorization in the TSIC: Without proper authorization from API producers, API consumers—including malicious tsApps—can exploit the system to launch several types of attacks. First, they can abuse or steal services and information by requesting and obtaining data from the platform, potentially leading to data leaks regarding sensitive network or IoT device information (thus corresponding to information disclosure). Second, unauthorized consumers can negatively impact overall IoT system performance by executing malicious policies over IoT nodes (corresponding to tampering and elevation of privileges). Finally, they can flood the platform with highly resource-demanding operations, ultimately causing a DoS attack. The threats impact the TSIC and TT–TS interface.

Conflicting applications: Conflicting ttApps and tsApps can harm intelligent IoT systems accidentally or intentionally, causing performance degradation or shutting down the system. Because applications may originate from multiple distinct commercial suppliers, there is a significant risk that separate ttApps or tsApps will make contradictory choices simultaneously on the same IoT device. Such clashes occurring between multiple applications manifest in different forms. For example, different applications demand alterations to an identical configuration parameter or to separate configuration parameters that yield opposing results, or they can demand alterations to separate configuration parameters that do not display any clear opposing consequences yet ultimately lead to a general decline in IoT system efficiency, operational volatility, and other system instabilities. Resolving these clashes is extremely challenging because the underlying interactions and correlations between the parameters remain completely undetectable. This threat is a type of DoS attack that impacts the availability of ttApps and tsApps.

Vulnerabilities in applications: Any ttApp or tsApp might contain security flaws due to, e.g., security misconfiguration (e.g., enabled but unnecessary protocols), weak or misconfigured authentication and authorization, or a backdoor intentionally inserted in the application by a trusted source. If malicious actors discover a ttApp or tsApp that they can exploit, they can interrupt the IoT system’s service and possibly seize control of a different application, the TTIC, or the TSIC. The real outcomes can differ. Security misconfiguration maps to Tampering, Information Disclosure, and Elevation of Privilege. Weak authentication and authorization relate to Spoofing and Elevation of Privilege. Backdoors in trusted ttApps or tsApps injected by a malicious application result in Elevation of Privilege and Tampering. These threats impact the Authenticity, Integrity, Confidentiality, Availability, and Authorization of tsApps and ttApps.

Malicious applications deployed on the TTIC or TSIC: Dangerous applications might originate from untrusted providers on purpose or have trusted origins that secretly contain hidden backdoors. When attackers discover malicious ttApps deployed on the TTIC, they can disrupt active IoT system services and potentially gain control over other ttApps or the entire TTIC, including AI and ML training, policy management, and IoT system configuration tuning. Harmful tsApps might enter TSIC to disrupt IoT system services or compromise data privacy across IoT devices and the IoT system. These rogue applications aim to alter, damage, or illegally access critical system operations and user information. This threat scenario spans all six categories of the STRIDE threat-modeling framework (spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege), and it impacts the TTIC, the TSIC, ttApps, and tsApps.

Internal man-in-the-middle surveillance at the TT–TS interface: This security risk involves unauthorized surveillance via a harmful program that monitors messages transmitted across the connection link between the TTIC and the TSIC. An internal rogue user can exploit this vulnerability to access the communication data, enabling agents behind a man-in-the-middle (MitM) attack to view private system rules. Classified under the information disclosure threat category, this issue directly compromises data privacy by breaching confidentiality. The negative impact is contained within three specific areas: the TTIC, the TSIC, and the physical or logical TT–TS connection link that binds them.

Malicious software intercepts and alters TTIC-to-TSIC traffic: This security vulnerability involves a tampering event wherein an unauthorized insider intercepts data transmissions across the interface between the TT and TS intelligent controllers. By executing an MitM exploit, the malicious actor manipulates or inserts unauthorized operational rules into the communications. This unauthorized modification directly compromises data integrity, forcing the TSIC to process and accept harmful or compromised policy directives. The physical and logical components impacted by this threat include TTIC, the TSIC, and the connecting interface itself.

Untrusted peering connection between TTIC and TSIC: Weak mutual authentication over the TT–TS interface enables vulnerabilities such as spoofing, which allows a malicious TTIC or TSIC to establish an unsecured peering relationship. This threat scenario impacts TTIC and TSIC and results in authenticity failures.

Security failures in TSIC ML data workflows: Within the TSIC, internal databases hold accumulated historical information gathered from IoT devices and IoT network components. This archived information is used to train various ML models operating within the TSIC environment. Furthermore, specific ML-driven tsApps can gather real-time streaming information directly from IoT devices and use it to train their ML models or generate practical inferences. ML data pipelines often comprise multiple distinct ML models that draw on one or more data sources for both training and inference generation. Security failures in ML data workflows could be the result of poisoning of ML training data due to compromised IoT devices, compromised database(s) with historical data used for ML model training, compromised interfaces of the TSIC allowing an attacker to alter training data, or a potential vulnerability existing in the tsApp that is involved in the ML data workflows. A software vulnerability (such as a buffer overflow, remote code execution, or an injection flaw) in the tsApp can allow an attacker to bypass security controls, granting them unauthorized privileges that allow them to alter the pipeline logic (tampering), steal sensitive data (information disclosure), crash the tsApp (denial of service), or gain control over the host system (elevation of privilege). A compromised IoT node could send corrupt or malicious telemetry data back to the TTIC and the TSIC. Because the IoT node is compromised, it spoofs legitimate IoT network behavior. Injecting bad data directly alters the integrity of the training dataset, a classic tampering threat aimed at manipulating the behavior of the final ML model. A compromised IoT device injects malicious or anomalous signaling data into the network. It spoofs the behavior of a normal user device to bypass basic network filters. This corrupts the historical dataset, constituting data tampering that degrades or biases model inferences. If an attacker gains unauthorized access to the TSIC databases, they can read the historical IoT device and system data, leading to information disclosure (violating user privacy). Furthermore, they can modify, delete, or inject fake historical records, constituting a direct tampering attack on data at rest that undermines future model training. An intruder compromising the TT–TS interface must bypass authentication, which typically involves spoofing a legitimate network entity or executing an elevation-of-privilege attack. Once inside the interface, their specific goal—altering data in transit to manipulate tsApp models—poses a major tampering threat.

Changing ML models within the TSIC: Some tsApps can hold ML models that use online training or reinforcement learning. The binary footprint of the ML models can be modified during runtime. Compromises of ML models embedded in tsApps could result from a vulnerability in the tsApp or security weaknesses in APIs exposed by the tsApp. Other tsApps can use ML models stored in the database, external file system, or storage. They can perform online training of ML models, ensuring that the tsApp binary footprint remains unmodified. Compromises of ML models stored in the database or external storage could result from a vulnerability in the tsApp that allows database updates or from weak database authentication and authorization. Additionally, the database itself may possess security gaps. Missing or weak authentication and authorization controls grant attackers easy access to the stored models, which they then modify. The TT–TS interface delivers model updates from the TTIC to the TSIC. If compromised, unauthorized sources can inject altered parameters, causing erratic model behavior and faulty predictions. Relying on these flawed outputs for critical business operations can lead to catastrophic choices. Attackers can also extract confidential data built into the model during training. These threats are mapped to all six categories of the STRIDE threat-modeling framework (spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege).

The next subsection describes security controls that can be designed to protect the confidentiality, integrity, and availability of the TTIC, the TSIC, the TT–TS interface, ttApps, and tsApps.

2.4. Security Controls and Risk Mitigation Solutions

A robust and intelligent IoT architecture requires bilateral cryptographic trust to be maintained between all interconnecting nodes. To establish this symmetrical security posture, both endpoint entities must execute mandatory mutual authentication to validate device identities, continuously verify the cryptographic integrity of all transmitted data payloads to detect unauthorized tampering, and strictly enforce congruent, interoperable security policies across the network fabric.

Both the TTIC/ttApps and the TSIC/tsApps prioritize strong security measures, including zero-trust principles, controlled service access, mutual authentication, and resource limitations. Key focus areas include identity management, secure communication between components, and software integrity. Specifically, TSIC/tsApps require continuous authentication, TLS encryption, and strict container isolation, with OAuth 2.0 and role-based access control governing access.

The TT–TS interface security requirements include confidentiality, integrity, replay protection, and mutual authentication and authorization. These requirements can be met using applicable security controls like mutual TLS and Open Authorization (OAuth) 2.0 authentication [40]. The key security requirements for ML workflows focus on model integrity, data protection, and access control. Applicable controls feature mutual TLS for interface protection, differential privacy to prevent data leaks, and vendor application signing.

To address platform-specific risks, one possible solution consists of implementing a complete lifecycle verification process for applications. This includes secure onboarding procedures, followed by deployment on the TTIC and TSIC. The critical steps involve validating digital signatures to ensure authenticity and thorough testing conducted by the application’s service provider, culminating in the publication of the application in a secure catalog.

To address or reduce the risks associated with certain preceding threats, a potential remedy entails securely integrating applications into and launching them on the TSIC and TTIC environments. Applications operate as software units onboarded on the MO platform, deployed on the TSIC or TTIC framework, and later registered in the TSIC or TTIC. Throughout every phase of an application’s lifecycle, security checks must be enforced to confirm that the software derives from a certified application solution provider and that its integrity has been strictly preserved.

Figure 2 illustrates the tsApp registration procedure.

Figure 2. The tsApp secure registration procedure.

The onboarding procedure for an application in the MO platform starts with a request from the application solution provider (ASP), who digitally signs the application. The request is sent to the service provider (SP), who inspects the digital signature to verify code completeness, carries out structural schema checks and any mandatory functional evaluations, and then adds their own digital signature to the application package. The MO platform then releases this signed application into the catalog for visibility.

The next phase of the tsApp lifecycle is deployment on the TSIC. The deployment procedure starts when a request to place one or more new tsApps into the TSIC is sent to the MO platform. The MO platform matches the required TSIC settings and tells the Cloudified Function Management services, which handle the full software lifecycle, to start the setup and assign the correct cloud space inside the TSIC. Once the setup is finished, the management service tells the MO platform and provides a special deployment ID. The MO platform saves this ID in its application register.

To address identified threats related to the database content, the TSIC uses the OAuth 2.0 authorization framework to manage permissions and data security within its Common Data Interface (CDI). In this setup, the CDI functions as the resource server, tsApps act as client applications, and the Security function within the TSIC serves as the Authorization server. The adopted OAuth 2.0 standard allows external third-party applications, such as tsApps, to gain controlled access to specific HTTP services [41]. This access can be granted either by operating on behalf of an authenticated user through a synchronized approval process or by allowing the application to authenticate independently using its own credentials.

Figure 3 illustrates the tsApp registration process for access to the common database in the TSIC.

Figure 3. A tsApp receives a database token during onboarding and registers with Common Data Interface.

The secured database access for each tsApp is provided on the basis of the tsApp role. The APS defines role-based permissions using a database token and assigns it before tsApp onboarding, and the SP verifies it. The token determines the data’s granularity and allows operations. Before the tsApp can use the database, it must register with the CDI and pass a new security check. In this extra check, a database token is used to grant the right role, set up permissions, and send a final registration reply. The tsApp starts by sending a registration request to the CDI to acquire database access inside the TSIC. When the CDI receives this request, it asks the security function to check the client. The security function checks the database token from the tsApp and matches it with a token the SP has already verified. Once this check works, the security function gives the tsApp a role based on the token rules. Afterwards, the security function sends an answer back to the CDI. If the security check works, the CDI works with the database to set up the correct access rules for the tsApp based on its new role. Next, the CDI sends a registration reply to the tsApp. This reply tells the tsApp whether registration has succeeded or failed.

Table 1 shows the security controls applied against the risk of the threats described. The security controls are consistent with those adopted by NIST [42,43].

Table 1. Security controls for analytic functions in an intelligent IoT system.

Threat Name	Security Controls
TTIC orchestration DoS	Identity and Access Management, Logging
IoT device tracking in the TTIC	Encryption of Data at Rest, Identity and Access Management, Logging
Compromised data integrity in the TTIC	Integrity protection for Data at Rest, Identity and Access Management, Logging
Unauthorized access to databases in the TSIC	Identity and Access Management, Encryption for Data at Rest, Integrity Protection for Data at Rest
API security and authentication in the TSIC	TLS, PKI, X.509, OAuth 2.0, Identity and Access Management
API security and authorization in the TSIC	Data Encryption, Security Configuration Validation
Conflicting applications	Identity and Access Management, Logging
Vulnerabilities in applications	Identity and Access Management, Logging, Data Protection
Malicious applications deployed on the TTIC or TSIC	Identity and Access Management
Internal man-in-the-middle surveillance on TT–TS interface	Encryption of Data in Motion using TLS
Malicious software intercepts and alters TTIC to TSIC traffic	Integrity, Protection of Data in Motion using TLS
Untrusted peering connection between TTIC and TSIC	TLS, PKI, X.509 Certificates, Certificate Management, Logging
Security failures in TSIC ML data workflows	Integrity Protection for Data at Rest, Encryption for Data at Rest, Identity and Access Management
Changing ML models within the TSIC	Integrity Protection for Data at Rest, Digital Signatures, Configuration Validation, Identity and Access Management, Encryption for Data at Rest, Logging

3. Results

3.1. Formal Threat Modeling

The Meta Attack Language (MAL) can model system parts (assets), structural links between different assets (associations), specific actions an attacker tries to perform (attack steps), and safety controls that change how difficult an attack step is to complete (defenses). Attaching time-to-compromise (TTC) values enables probabilistic threat modeling and quantitative risk calculation [44,45].

As an example, we modeled the “Unsecure peering connection between TTIC and TSIC” threat. The MAL model of this threat contains two categories.

Figure 4 shows the MAL code for the Controllers category.

Figure 4. MAL code of the Controllers category.

The Controllers category contains two assets, TTIC (line 2) and TSIC (line 3), which model peer-spoofing attacks. Each asset allows an attacker to move from a compromised state to unauthorized peering through an exponential time distribution. Three attack steps are defined: | compromise (lines 3 and 10) is a starting attack step that triggers the next phase; | peerSpoof (lines 5 and 12) is the action step where the asset spoofs a peer; and ttTsInterface.unauthorizedPeering is the final target step reached after a successful spoof (lines 7 and 14). The attack time is modeled as Exponential (0.05), and the average time to complete the peer-spoofing attack is 20 h (1/exponential value) (lines 6 and 13).

Figure 5 shows the MAL code for the Infrastructure category.

Figure 5. MAL code of the Infrastructure category.

The Infrastructure category contains three assets.

The TT_TS_Interface asset (line 18) organizes security risks for the TT–TS interface with an attack graph. One of the possible attack steps consists of an unauthenticated peer attempting to communicate over the interface: |unauthorizedPeering (line 19). This step triggers firewall.inspectTraffic (line 20), which routes the traffic straight into the associated firewall asset’s inspectTraffic attack step. The firewall may drop or block malicious traffic, overload and crash from connection exhaustion, or become compromised. Another attack step is |authenticityCompromise (line 21), which indicates that the authenticity of the interface has been totally compromised (e.g., a rogue gateway is now fully trusted). If authenticity is negated, the attacker can move laterally in two directions simultaneously, attempting to compromise both the ttic and tsic controllers (line 22).

The AuthenticationGateway asset (line 24) defines a physical or logical component in the system architecture that handles access control, where #mutualMtlsEnabled on line 25 and #tokenValidation (line 27) are Boolean defenses set by the system designer. One attack step representing a direct cryptographic or software bypass attack against the gateway is | bypassAuthentication (line 29), where ttc = Gamma (2.0, 0.01) (line 30) uses a Gamma distribution to model a high-effort, complex exploit that takes a long time to develop (on average, 200 h). If bypassed, the attacker achieves unauthorizedPeering at the interface (-> ttTsInterface.unauthorizedPeering, line 31). Another possible attack is | authenticatePeers (line 32), where the attacker tries to normally pass through or trick the peer authentication system. The defense gating is represented by [mutualMtlsEnabled && tokenValidation] (line 36). This attack can only proceed if the condition inside is true. Here, the attacker faces the full defense: both mTLS and token validation must be enabled for this specific attack step’s logic to apply (meaning they have to break both, though since no TTC is specified here, it acts as an immediate pass-through if they somehow manage to satisfy the conditions or if it is a fallback path; i.e., this step models the attacker successfully overcoming both active defenses to compromise authenticity). A separate attack step handling the scenario where security is weak is | authenticatePeersBypassed (line 35), which consists of conditions concerning the absence of proper security, namely, [!mutualMtlsEnabled || !tokenValidation] at line 36; i.e., if mTLS is missing (!) OR (||) token validation is missing, this step is activated. The core of the step is the immediate breach of the attacker, and therefore the TTC is set to the very same instant (ttc = Instant, line 37). The breach is an authenticity compromise affecting the interface.

The Firewall asset (line 40) represents the security component modeled with deep packet inspection, wherein #deepPacketInspection defense is turned on (line 41). One possible attack step is | inspectTraffic (line 43), wherein the attacker tries to sneak traffic past the firewall inspection. This step is active if DPI is enabled ([deepPacketInspection], line 44). Bypassing DPI requires high variability and effort, modeled here via a LogNormal distribution (ttc = LogNormal (4.5, 0.8), line 45). If the attacker bypasses the DPI firewall, they advance to the authentication gateway (-> authGateway.authenticatePeers, line 46). The step at line 48, | inspectTrafficNoDpi, is activated when DPI is disabled (!deepPacketInspection, line 49). Traffic flows through with no defensive delay (ttc = Instant, line 50). The attack flows directly to the gateway (-> authGateway.authenticatePeers, line 51).

Four asset associations link different system components to a single target interface. They connect a TTIC unit (line 52), a TSIC unit (line 53), a Firewall (line 54), and an AuthenticationGateway (line 55) to the same TT_TS_Interface instance. The TTIC asset connects directly to the TT_TS_Interface. The TSIC asset also connects to this interface. These links show how the two units share or use the interface to communicate within the system. The Firewall secures the TT_TS_Interface to protect the connection. The AuthenticationGateway authenticates the interface by ensuring only allowed users or systems can access it.

The MAL code of associations is shown in Figure 6.

Figure 6. MAL code of associations.

3.2. Simulation Setup and Risk Calculation

Time to compromise (TTC) is the estimated time it takes for an attacker to successfully breach a specific system or asset. To obtain the numerical results of the TTC simulation, we used mal-toolbox (via PyPI), which is a core Python version 3 package (pip install mal-toolbox) designed to ingest raw .mal file declarations. It handles full MAL compilation, builds explicit attack graphs from the asset instance models, and provides the algorithmic framework required to programmatically calculate short-path traversals and global TTC timelines across the graph nodes [46].

Because calculating analytical convolutions, products, and complementary products across nested, large-scale architectures is mathematically intractable, we used repeated random sampling to generate the exact values.

MAL assesses the quantitative risk of the attacker’s progression as a stochastic process via TTC distribution assessment. It uses probability densities to represent attacker capabilities [47,48]:

• Exponential (0.05) (mean = 1/λ = 20 h): This is assigned to peerSpoof. To execute peerSpoof, the attacker has already compromised either the TTIC or the TSIC. They are inside the trusted boundary. Once an attacker has control of a controller node, initiating an unauthenticated peering session requires minimal work to discover. A mean of 20 h balances the time it takes an attacker to map the local network stack, locate the target peer IP/port over the TT–TS interface, and craft the initial malformed handshake parameters.
• Gamma (2.0, 0.01) (mean = α/β = 200 h): This is assigned to AuthenticationGateway bypass. The multi-stage hurdle α = 2.0. A dedicated authentication gateway cannot be bypassed with a single trick. The attacker must execute at least two major operational phases: (1) extracting or forging valid session metadata/tokens from memory and (2) subverting or misusing the identity verification framework at the session layer. The rate factor β = 0.01. Each distinct phase is assigned an expected duration of 100 h (1/β). This reflects the high complexity of subverting modern, zero-trust cryptographic gateways relative to basic network firewalls, ensuring that bypassing the gateway remains a significant roadblock for standard cybercriminals.
• LogNormal (4.5, 0.8): This is assigned to bypassing deep packet inspection (DPI) in the Firewall. The scale parameter μ = 4.5, and the median time e^μ is 90 h. Bypassing deep packet inspection (DPI) in an industrial firewall requires the attacker to meticulously reverse-engineer the proprietary control-plane protocols running over the TT–TS interface. They must format their malicious peering payloads such that they mimic legitimate traffic perfectly. The shape parameter σ = 0.8. This introduces significant variance. If the firewall rules are rigidly locked down, the timeline stretches toward the 90th percentile (250+ h) because the attacker must iteratively test payload evasion techniques blindly, without tripping defensive alerts.
• Instant: When a defense is disabled (e.g., #deepPacketInspection = False), the model assigns a value of Instant (TTC = 0). This reflects the absolute binary nature of structural risk: if there is no firewall inspecting payloads, automated malicious peering packets travel at line-speed across the physical medium, offering the defender zero window for detection or response.

The architectural design transitions from a simple interface attribute into a connected, multi-layered micro-perimeter defense system, featuring the Firewall and AuthenticationGateway assets. The AuthenticationGateway asset handles validation at the application and session layers, applying an AND composition logic framework that combines mutual TLS enablement and token validation. For this mechanism to successfully disrupt an attacker’s progression toward compromising authenticity, both defensive controls must remain valid at the same time. The network-level defense layer is established through the Firewall asset, which functions as an active bottleneck utilizing conditional logic based on deep packet inspection. When DPI remains active, an attacker must invest substantial time in carefully examining protocol payloads to smuggle malicious control headers past the checkpoint.

The execution of the attack graph involves the following steps:

• Initial entry: The adversary secures an initial foothold by successfully compromising either the TTIC or TSIC.
• Identity propagation: The attacker begins identity spoofing using the peerSpoof method, taking an amount of time based on an exponential probability curve of 0.05.
• Defense evaluation: The attacker reaches the Firewall, where MAL checks if DPI is turned on; an active Firewall delays the attacker’s timeline using a LogNormal curve, while an inactive Firewall moves the attacker right away to the AuthenticationGateway.
• Target compromise: The gateway checks the security rules, and if both mutual TLS and tokens are missing, the attacker instantly compromises authenticity and triggers a complete loss of integrity in both control systems (ttic.compromise and tsic.compromise).

To mathematically model attacker capabilities and calculate the probability densities for the TTC, we use specific statistical parameters that reflect the attacker’s skill level, access, and resources [48]. The three primary attacker tiers—Script Kiddie (low capability), Cybercriminal (medium capability), and Advanced Persistent Threat ((APT) high capability)—are mapped below to the statistical distributions used in the MAL specification [49,50].

Table 2 summarizes the models of different types of attackers.

Table 2. Models of the different types of attackers.

Attacker Type	Distribution	Parameters	MTTC (Hours)	Description
Script Kiddie (Low Capability)	Exponential	λ = 0.01	100	Relies on automated, untargeted scanners.
Cybercriminal (Medium Capability)	Exponential	λ = 0.05	20	Utilizes known exploit kits and scripts.
APT (High Capability)	Exponential	λ = 0.20	5	Rapidly deploys customized automation to hijack the peer-negotiation phase.
Script Kiddie (Low Capability)	Log-Normal	μ = 6.5, σ = 1.2	1366.4	High friction; lacks packet-crafting skills and mostly fails.
Cybercriminal (Medium Capability)	Log-Normal	μ = 4.5, σ = 0.8	124	Moderate speed; requires research and configuration evasion techniques.
APT (High Capability)	Log-Normal	μ = 2.5, σ = 0.4	13.2	Highly efficient; uses pre-engineered or zero-day evasion methods.
Script Kiddie (Low Capability)	Gamma	α = 4.0, β = 0.005	800	Gets stuck on architectural nuances and must complete many trial-and-error steps.
Cybercriminal (Medium Capability)	Gamma	α = 2.0, β = 0.01	200	Methodically eliminates authentication checks one layer at a time.
APT (High Capability)	Gamma	α = 1.0, β = 0.05	20	Multi-stage defense collapses due to stolen certificates or supply chain compromises.

The exponential distribution assumes a constant, memoryless exploit rate (λ), where the Mean Time to Compromise (MTTC) is 1/λ; i.e., higher λ values compress the timeline, representing a faster attack. The Log-Normal distribution models complex technical barriers (like bypassing the Firewall via deep packet inspection). It uses a scale parameter (μ) and a shape/variability parameter (σ). The Gamma distribution models attacks requiring a sequential multi-step effort (like bypassing the multi-factor AuthenticationGateway). It uses a shape parameter (α, the number of steps required) and a rate parameter (β).

Table 3 summarizes the quantitative simulation input.

Table 3. Summary of the quantitative simulation input.

Attacker Capability Tier	Attack Vector Type	Distribution	Parameter 1	Parameter 2	Expected MTTC
Low (Script Kiddie)	peerSpoof	Exponential	λ = 0.01	—	100.0 h
Medium (Cybercriminal)	peerSpoof	Exponential	λ = 0.05	—	20.0 h
High (APT)	peerSpoof	Exponential	λ = 0.20	—	5.0 h
Low (Script Kiddie)	Firewall Bypass	Log-Normal	μ = 6.5	σ = 1.2	1366.4 h
Medium (Cybercriminal)	Firewall Bypass	Log-Normal	μ = 4.5	σ = 0.8	124.0 h
High (APT)	Firewall Bypass	Log-Normal	μ = 2.5	σ = 0.4	13.2 h
Low (Script Kiddie)	Auth Bypass	Gamma	α = 4.0	β = 0.005	800.0 h
Medium (Cybercriminal)	Auth Bypass	Gamma	α = 2.0	β = 0.01	200.0 h
High (APT)	Auth Bypass	Gamma	α = 1.0	β = 0.05	20.0 h

The results of the TTC simulations—broken down by individual step metrics and total execution windows—were computed via 100,000 statistical trial iterations.

Table 4 shows the MTTC and critical probability milestones.

Table 4. Sequential step breakthrough timelines.

Attacker Tier and Step	Distribution Model	Mean (Hours)	P10 (Hours)	P50/Median	P90 (Hours)
Low Tier (Script Kiddie)
1. peerSpoof	Exponential (λ = 0.01)	99.60	10.50	69.44	228.50
2. Firewall Bypass	Log-Normal (μ = 6.5, σ = 1.2)	1366.63	143.86	665.38	3095.07
3. Auth Bypass	Gamma (α = 4.0, β = 0.005)	800.43	347.75	735.11	1339.32
Medium Tier (Cybercriminal)
1. peerSpoof	Exponential (λ = 0.05)	20.05	2.14	13.92	46.11
2. Firewall Bypass	Log-Normal (μ = 4.5, σ = 0.8)	123.39	32.08	89.56	249.99
3. Auth Bypass	Gamma (α = 2.0, β = 0.01)	199.55	52.83	167.58	388.46
High Tier (APT)
1. peerSpoof	Exponential (λ = 0.20)	5.02	0.53	3.47	11.53
2. Firewall Bypass	Log-Normal (μ = 2.5, σ = 0.4)	13.19	7.30	12.18	20.36
3. Auth Bypass	Gamma (α = 1.0, β = 0.05)	19.94	2.11	13.72	45.90

We used different percentiles (P₁₀, P₅₀, and P₉₀) in risk analysis and threat modeling to describe the probability distribution of times specifically, how long it will take an attacker to compromise a target system (TTC).

P₁₀ means that there is a 10% probability that the attacker will compromise the system in this amount of time or less, and it represents the highly skilled, lucky, or optimistic attacker scenario. It measures the system’s vulnerability to rapid exploitation. If the target’s P₁₀ is very low (e.g., a few minutes), an attacker who gets lucky or has advanced zero-day tools can breach the target almost instantly.

P₅₀ means that there is a 50% probability that the attacker will compromise the system in this amount of time or less. It is the median or most likely amount of effort required. Half of the simulated attacks succeeded faster than this time, and half took longer.

P₉₀ means that there is a 90% probability that the attacker will compromise the system in this amount of time or less. It represents the defensive upper bound. It captures scenarios where the firewall or deep packet inspection successfully dragged out the attack, requiring the adversary to expend immense amounts of effort, change tactics, or experience significant delays.

By combining the time required for each stage of the attack (peer negotiation, firewall traversal, and authentication) sequentially, we can calculate the total risk for each of the three adversary profiles, as illustrated in Table 5.

Table 5. The TTC across three distinct attacker profiles.

Attacker Profile	Mean Total Time	P10 (Fast Breach)	P50 (Median Time)	P90 (Slow Breach)
Low-Capability Profile	2266.65 h (~94.4 Days)	837.46 h (~34.9 Days)	1653.53 h (~68.9 Days)	4063.77 h (~169.3 Days)
Medium-Capability Profile	342.99 h (~14.3 Days)	149.67 h (~6.2 Days)	305.98 h (~12.7 Days)	580.53 h (~24.2 Days)
High-Capability Profile	38.15 h (~1.6 Days)	17.16 h (~0.7 Days)	32.99 h (~1.4 Days)	65.67 h (~2.7 Days)

To provide a brief sensitivity analysis examining the effects of key distribution parameters on the TTC results, we ran three more simulations with different parameter values of the distributions. Three new stochastic simulations were run using 100,000 iterations to analyze different infrastructure states and attacker combinations. The simulation parameters are explained below.

Simulation A (hardened micro-perimeter): High actor capability but exceptionally mature defensive configurations.

• peerSpoof: Exponential (λ = 0.10)—Mean: 10 h
• Firewall Bypass: Log-Normal (μ = 5.5, σ = 0.5)—Mean: ~277.5 h
• Auth Bypass: Gamma (α = 5.0, β = 0.005)—Mean: 1000 h

Simulation B (degraded/misconfigured controls): A standard actor leveraging a completely decayed security environment.

• peerSpoof: Exponential (λ = 0.50)—Mean: 2 h
• Firewall Bypass: Log-Normal (μ = 1.5, σ = 0.3)—Mean: ~4.7 h
• Auth Bypass: Gamma (α = 1.2, β = 0.1)—Mean: 12 h

Simulation C (volatile perimeter/high uncertainty): Moderate defenses exhibiting massive variability in exploitation difficulty.

• peerSpoof: Exponential (λ = 0.02)—Mean: 50 h
• Firewall Bypass: Log-Normal (μ = 3.5, σ = 1.5)—Mean: ~100.1 h
• Auth Bypass: Gamma (α = 2.5, β = 0.02)—Mean: 125 h

Table 6 presents the TTC results of the three simulation scenarios.

Table 6. TTC results of the stochastic simulations explained above.

Simulation Scenario	Step 1 Mean (peerSpoof)	Step 2 Mean (Firewall)	Step 3 Mean (AuthGtw)	Total Path Mean (MTTC)	P10 (Fast Breach)	P50 (Median)	P90 (Slow Breach)
Sim A (+5% Friction)	10.48	370.08	1105.83	1486.39	871.34	1418.94	2192.51
Sim B (−5% Decay)	1.91	4.32	10.86	17.09	7.11	14.36	30.73
Sim C (+5% Variance)	47.74	134.16	137.29	319.19	113.33	240.63	530.35

The compounding non-linear returns observed when comparing the hardened scenarios show that a minor five-percent increase in core defense configuration values yields an outsized fifteen-point-four-percent expansion in total mean system survival time, which shifts the window from one thousand two hundred eighty-seven hours up to one thousand four hundred eighty-six hours and underscores the substantial value of layered security policies. Conversely, the aggressive collapse trajectory identified under a five percent-defense-decay condition shrinks the median security response window from fifteen point eight hours down to fourteen point three hours, meaning security teams monitoring the TT–TS interface lose over an hour of absolute reaction time from small environmental anomalies. Finally, the log-normal volatility tail demonstrates that introducing a five-percent parameter swing into an already highly volatile environment pushes the ninetieth percentile out from four hundred fifty-nine hours to five hundred thirty hours, proving that highly uncertain network environments create severe tracking inconsistencies for security personnel.

4. Discussion

The log-normal configuration of the firewall creates an exceptionally unpredictable environment when facing an adversary with low capabilities. While the standard duration for a breach sits at approximately 665 h at the fiftieth percentile, a deployment with high structural resilience can push the ninetieth-percentile boundary out past 3095 h.

When evaluating exposure against an advanced persistent threat, the shared defensive perimeter can collapse rapidly and severely. There is a 10% likelihood that a sophisticated adversary can compromise all three micro-segmented boundaries, progressing from an isolated, unpeered asset to a state of total authenticity compromise, in less than 17.2 h.

Security operation centers monitoring the interface between the trust zone and the transit zone require specific defensive buffers, with a median window of about 12.7 days to identify irregular behavior from a typical cybercriminal before cross-peering authentication is completely compromised. However, this available timeframe contracts drastically to a mere 33 h when the organization is forced to defend against an advanced threat group.

The effective protection of intelligent IoT systems includes the transition of security operations from a reactive approach (cleaning up after attacks) to a proactive one (disrupting attacks before they begin). The strategic objective is to complete the entire security lifecycle compassing all necessary checks and defenses—before an attacker can gain access. If the combined time required for detection and response exceeds the attacker’s timeline, a major security breach becomes highly probable.

High-performance defenses target advanced threat actors. When an APT attacks, human intervention is a barrier. High-performance actors use modern, sophisticated, and well-organized cyberattacks, and if the warning relies on human response, the attacker has already won. For immediate detection (<1 h), security information and event management and endpoint detection and response systems should use high-quality behavioral analytics to flag anomalies immediately. For rapid containment (<4 h), security orchestration, automation, and response playbooks should be used. If an endpoint exhibits any APT lateral movement behavior, the system should automatically isolate the machine from the network, revoke the user’s active tokens, and block associated IP addresses on the firewall without waiting for human approval. By segmenting the intelligent IoT system and placing assets in isolated micro-zones, APTs cannot move freely. This forces them to take more visible, time-consuming actions, pulling them out of their fast 17-h schedule and into a slower range where there is more time to react.

Medium-capacity defenses target organized cybercriminals and ransomware groups. Cybercriminals move at a deliberate pace, typically looking to deploy ransomware or steal data within a week of intrusion. Their main advantage is time asymmetry: they often launch attacks on Friday nights, long weekends, or holidays when security guards are off duty. For continuous detection (<24 h), each intrusion must be triaged and verified before the next day. For decisive containment (<48 h), once an intrusion is confirmed, an incident response must be initiated immediately. This includes, among other things, terminating active malicious processes and rotating compromised active credentials. Since these attackers can breach a system in 6.2 days (P10), critical external fixes must be deployed within 72 h of their release. Otherwise, it creates an open invitation for mid-level actors. Low-capacity defenses target Script Kiddies and automated vulnerability scanners.

Low-capacity actors rely on public exploitation tools, automated internet-wide scans, and basic phishing kits. They lack the skills required to navigate complex networks easily. Their progress is slow and cumbersome, giving defenders a massive time advantage. For basic detection (<3 days), a standard daily review of security logs and alert queues can catch these attackers. They leave chaotic trails (such as many failed registrations attempts or obvious malware signatures) that readily trigger basic firewall and antivirus alerts. For structured containment (<2 days), remediation can follow standard operating procedures because there is no immediate threat of rapid lateral movement. By maintaining strict automation for high-level threats, hundreds of hours can be saved.

To reduce IoT platform-specific risks, as shown in Section 2.4, we designed a complete lifecycle verification process for onboarding, deploying, and registering IoT applications on the TTIC and TSIC environments. Security checks have to be enforced at every stage to validate digital signatures and confirm that the software originates from a certified provider. The process culminates in thorough testing by the service provider and the publication of the application in a secure catalog to ensure its integrity is strictly preserved.

The second solution presented in Section 2.4 proposes the use of the OAuth 2.0 authorization framework to manage permissions and mitigate IoT database threats. Within this architecture, the Common Data Interface acts as the resource server, IoT applications function as client applications, and the TSIC security module operates as the authorization server. This solution enables intelligent IoT applications to securely access specific HTTP services, either by operating on behalf of an authenticated user or via independent authentication with their own credentials.

The quantitative simulation evidence establishes a clear directive for securing the cross-domain control environment. Because network-level firewalls act merely as delay mechanisms rather than absolute barriers against sophisticated adversaries, deploying mutual TLS alongside hardware-backed token validation at the authentication gateway layer is imperative. This cryptographic configuration establishes an enforced logic gate that halts threat propagation, which is vital given that advanced actors can breach unsegmented perimeters within a tight timeline. Furthermore, because a highly capable threat actor can compromise the entire path in less than a day, detection and response metrics must operate on a sub-hour cadence rather than relying on standard daily log reviews. For standard cybercriminal threats, ensuring deep packet inspection is active provides an expected operational buffer of nearly two weeks, giving incident response teams a realistic window in which to isolate anomalous peering handshakes before authenticity is fully compromised.

Strategically, the analysis demonstrates that weak mutual authentication on the interface creates a single point of failure that symmetrically endangers both real-time and non-real-time controllers. Perimeter defenses fail to offer robust protection on their own, delaying highly capable attackers by only half a day. Consequently, while the architecture is highly resilient against low-capability scanners, resource allocation must shift away from basic network hardening and focus heavily on enforcing strict identity verification at the session layer.

These conclusions must be qualified by several mathematical and structural limitations inherent to the modeling framework. The simulation treats each sequential attack step as stochastically independent, meaning it fails to account for scenarios where a compromised controller leaks cryptographic materials that would cause downstream defense distributions to collapse rapidly. Additionally, the TTC parameters represent generalized empirical estimates rather than vendor-specific vulnerabilities, and the model evaluates defenses as binary switches without capturing partial misconfigurations, human operational errors, or physical tampering.

5. Conclusions

Security analysis of analytic functions in intelligent IoT systems is important to stop data leaks, prevent system hacks, and ensure reliable decisions. When time-sensitive analytics and time-tolerant analytics are separated, the task becomes complicated because of strict timing constraints, mixed data dependencies, and resource asymmetry. In such systems, the attack surface is larger because of new components and interfaces.

In this paper, we studied threats in such architectures and proposed security controls that could mitigate the risk. Threat modeling in intelligent IoT systems—where analytical functions are categorized into time-sensitive and time-tolerant types—helps identify critical safety risks, define the boundaries of data flows, and prioritize the implementation of rapid protective measures. It ensures real-time safety functions are not slowed down by heavy security checks while securing delayed data storage.

In our future research, we plan to conduct sensitivity analysis and develop comparative defense scenarios to assess the robustness of the findings and align operational recommendations and conclusions with simulation-based evidence, explicitly acknowledging validation limitations.