Digital Twin: A Comprehensive Survey of Security Threats

Digital Twin: A Comprehensive Survey of Security Threats Article in IEEE Communications Surveys & Tutorials · September 2022 DOI: 10.1109/COMST.2022.3171465 CITATIONS READS 40 822 2 authors: Cristina Alcaraz Javier Lopez University of Malaga University of Malaga 99 PUBLICATIONS 3,004 CITATIONS 394 PUBLICATIONS 9,355 CITATIONS Some of the authors of this publication are also working on these related projects: SMOG – Security Mechanisms for fOg computinG View project UBISEC View project All content following this page was uploaded by Cristina Alcaraz on 25 August 2022. The user has requested enhancement of the downloaded file. Digital Twin: A Comprehensive Survey of Security Threats C. Alcaraz and J. Lopez Computer Science Department, University of Malaga, Campus de Teatinos sn, 29071, Malaga, {alcaraz, jlm}@lcc.uma.es Abstract Industry 4.0 is having an increasingly positive impact on the value chain by modernizing and optimizing the production and distribution processes. In this streamline, the digital twin (DT) is one of the most cutting-edge technologies of Industry 4.0, providing simulation capabili. ties to forecast, optimize and estimate states and configurations. In turn, these technological capabilities are encouraging industrial stakeholders to invest in the new paradigm, though an increased focus on the risks in. volved is really needed. More precisely, the deployment of a DT is based on the composition of technologies such as cyber-physical systems, the Industrial Internet of Things, edge computing, virtualization infrastruc. tures, artificial intelligence and big data. However, the confluence of all these technologies and the implicit interaction with the physical counter. part of the DT in the real world generate multiple security threats that have not yet been sufficiently studied. In that context, this paper ana. lyzes the current state of the DT paradigm and classifies the potential threats associated with it, taking into consideration its functionality lay. ers and the operational requirements in order to achieve a more complete and useful classification. We also provide a preliminary set of security recommendations and approaches that can help to ensure the appropriate and trustworthy use of a DT. Keywords: Digital Twin, Cybersecurity, Industry 4.0. Introduction New information technologies (ITs) are being incorporated as part of the au.tomation, production and distribution of products and services, following the objectives originally pursued by Industry 4.0. Among the cutting-edge Indus.try 4.0 technologies, the digital twin (DT) is one of the most prominent. The original concept of DT originated in 1970 when the National Aeronautics and Space Administration (NASA) required physical components to be monitored for aerospace missions (e.g. the Apollo 13 spacecraft) in order to diagnose problems and provide proven solutions [1]. Nonetheless, that way of simulating real-world systems does not accurately describe the more current DT concept, which is much more than just a virtualization system [2,3]. The DT concept, as it is understood today, was introduced by Michael Grieves during his executive course on product life-cycle management (PLM) [4], and later in [5]. In line with the idea presented there, a DT is generally con.ceived as the grouping of “machines (physical and/or virtual) or computer-based models that are simulating, emulating, mirroring or twinning the life of a phys.ical entity” [1]. There also exist other similar definitions, such as “a system that couples physical entities to virtual counterparts, leveraging the benefits of both the virtual and physical environments to the benefit of the entire system” [6], “an integrated multiphysics, multiscale, probabilistic simulation of an as-built vehicle or system that uses the best available physical models, sensor updates, fleet his.tory, etc., to mirror the life of its corresponding flying twin” [7], “a computerized model of a physical device or system that represents all functional features and links with the working elements” [3], and “a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity” [8]. Figure 1: DT work spaces The purpose of a DT is therefore to characterize physical assets through digital assets using specification-based techniques [9–12], mathematical models [13,14] and application programming interfaces (APIs) , all of which run on servers and/or virtualized resources (e.g. virtual machines (VMs), containers and virtual networks), with the main aim being to anticipate errors, variations and relevant deviations that may change a system’s natural behavior. In turn, these servers are connected to the physical world in order to interact with real-world components. For that reason, Grieves associates a DT with three main spaces (see Figure 1, based on [4] and ): • Physical space: comprises the real-world operational technologies (OTs) such as sensory devices, actuators and controllers (e.g. remote terminal units (RTUs) and programmable logic controllers (PLCs)). • Digital space: represents physical assets through the use of digital assets capable of simulating states, conditions and configurations, and of making decisions regarding the physical space [2]. • Communication space: connects the physical and digital spaces, allowing the DT to interfere in the production operations through information flows and processes. With regard to the communication space, Grieves stresses in [4] and [5] the importance of bidirectional interfaces in the DT; i.e. data from physical assets are processed by digital assets, while the latter create new useful information that may be sent back to the physical space. The result is a digital thread between the physical and the virtual spaces . Some examples of this com.munication are: (i) a DT synchronizes its models with respect to its physical counterpart in order to guarantee consistency in the production process (e.g. to build scenarios with equivalent contextual parameters such as humidity, tem.perature and pressure); (ii) a DT receives information from the physical world and compares it with its own processed information, which is particularly useful for detecting anomalies and intrusions; and (iii) a DT establishes configuration rules and parameters in order to change the behavior of a physical asset. Specifically, it is this kind of communication that differentiates a DT from traditional simulators. A DT connects to the physical world and follows granular and accurate representations of it through customized models (e.g. by imple.menting the logic of a device and its parameters such as time, position, location, processes, functions, geometrical shapes, etc. [6]). In contrast, a conventional simulator does not integrate such specialized models that give a detailed rep.resentation of the particular characteristics of the physical world and establish bidirectional interfaces between spaces. To further clarify such differences and highlight the characteristics of a DT, Kritsinger et al. identify in [2] three variants of mirroring systems, classifying them as: digital model, an isolated system without automatic connection to the real world; digital shadow, a system with an automated one-way communication between the physical space and the virtual space; and digital twin, a system with bidirectional and automatic connection between both spaces. Figure 1 shows an example of a DT. This DT characterizes the behavior of an aircraft turbine in the real world, where information from physical assets (for instance, sensor data) is collected and sent to the DT in order to trigger the simulation model. Similarly, digital assets may establish configurations and execute commands that can change the state of the physical counterpart, either to maintain, optimize, or improve the operational performance of its components. In order to achieve the above, a DT must be able to integrate algorithms, technologies and communication systems that together can represent states and make decisions to automatically act on the physical assets when necessary. This rationale is considered in , where Minerva et al. bring the concepts of the DT closer to the Internet of Things (IoT) in order to enhance the interaction among spaces and among technologies. These technologies range from cyber.physical systems (CPS) to industrial IoT (IIoT) and edge computing, and make use of artificial intelligence (AI) and big data (BD) techniques. This tech.nological heterogeneity also means that the design of a DT can vary greatly, ranging from a simple DT system composed of virtual resources running within a server connected to smart devices, to more complex designs whose logic can be spread throughout the entire system with support on the edge of the network. These DT designs can be applied to represent different application scenarios with different levels of complexity : (i) a product, a single DT observing the operation of a physical asset; (ii) a process, an observation of a larger context such as a production/assembly line; and (iii) a system, a set of product and process models used to characterize a complex network or an industrial facility. So far, there are several use cases that have already shown the practical value of the aforementioned designs, whether for industrial applications (cf. Table 1 and ), smart city scenarios , disaster management or military settings . This practical aspect is also underlined by Gartner in its annual ranking of strategic technologies, placing the DT paradigm among one of the top ten strategic technologies: fourth position in 2018 and 2019 , and first position in 2020 . Such a trend is also highlighted by a market study , which confirms that the size of the DT market, initially valued at $3.1 billion in 2020, is expected to reach $48.2 billion by 2026. This interest from different private and public economic sectors has also at.tracted the attention of scientific experts, who have devoted considerable effort to applying DT technology to aspects related to automation and engineering. However, cybersecurity issues have not been sufficiently explored yet, which be.comes a problem for two main reasons: (a) DTs are considered to be critical systems, given that they take part in automation processes [5]; and (b) they also contain pieces of intellectual property which represent the digital copy of the physical world . Obviously, these two aspects are of great interest to ad.versaries who may attempt to corrupt an organization’s business model, harm its reputation or cause irreparable damage, particularly in the case of critical in.frastructures. Moreover, when considering a general DT scenario, we also notice that an adversary may harm the DT not only from the physical space, but also from the digital space in order to take control of the underlying infrastructure and its physical assets. Clearly, the attack surface varies greatly because the DT paradigm is based on the interconnection of two worlds through communication systems, technologies and algorithms. Therefore, the main aim of this paper is to survey the high number of po.tential threats associated with the DT paradigm, which requires carrying out Table 1: Some examples of the use of the DT paradigm Industry DT Use cases Oil and gas [25,26] Furnaces/preheat train/pipelines /wells Refinery Gas turbine (SGT-A65) fleet Electrical energy [14,31] [32,33] Power plant/wind turbines Power electronic converters CPS for power systems Microgrid Smart Grid (Petro-)chemical [34,35] Chemical plant/reactors Production control Water [12,36] Water treatment systems Manufacturing [39,40] Chassis welding lines Pneumatic cylinder lines Manufacturing operations and control Safety of human operators Automotive [44,45] Privacy leakage Baking system Autonomous vehicles and driving Healthcare [40,47] CT scanner for MRI Remote surgery and control Robot surgical machines Transportation Engine blades (GE90) for Boeing 777/train, called Trip Optimizer Tracking of individuals at airports research into the different technologies involved in the paradigm from the per.spective of the three work spaces identified above. However, a research work of this kind would not be complete unless we take into account the concep.tualization in layers of a digital twin, as proposed in and , which is similar to entity-based abstraction as given by the ISO 23247-Part 2 (the first DT standard for manufacturing scenarios). As shown in Figure 2, each layer establishes a set of essential services (e.g. data dissemination and acqui.sition, synchronization, data modeling, simulation, representation) provided by multiple interfaces, technologies and computation systems. In fact, because the integration of these technologies and computation systems also entails serious security risks, in this paper we perform a classification of the threats according to those layers of functionality and their corresponding technologies. Moreover, because a DT is considered a critical system that can be of great interest to adversaries, particularly when used in critical infrastructures, the fulfillment of its operational requirements must be considered in order to carry out more thorough and useful research into threats. For instance, the lack of integrity or unavailability of essential data and resources in the data dissemina.tion layer (corresponding to the physical and communication spaces) may have an unforeseen effect on the synchronization services, as well as on the quality of DT simulations in terms of accuracy and granularity. This effect can, in turn, lead to invalid decisions (automatic or manual) in the final services provided by the DT, modifying the behavior of the observed physical assets (products, pro.cesses or systems). Additionally, security gaps in the technological deployment corresponding to the digital space may generate an impact on the reliability and security of the DT. Attackers can: (i) increase significant computational overheads to limit the simulation processes; (ii) manipulate and forge relevant information to violate the fidelity and granularity of the representation mod.els; and (iii) take control of physical assets from the digital space to exfiltrate sensitive information. Moreover, in the event that the operations of a critical system heavily depend on the simulation services of the DT for maintenance, op.timization and resilience, the consequences of an eventual attack would then be devastating, leading to the disablement and interruption of essential resources and services of cyber-physical elements. On the basis of the above, the rest of the paper is structured as follows: Section 2 adds preliminary concepts concerning the DT paradigm, identifying the main layers of functionality and the technologies associated with these layers. Section 3 comprises the operational requirements of the DT, which are essential to study given that the DT operation may be profoundly affected by potential threats, especially when the DT technology is used in critical infrastructures. These threats, analyzed in detail in Section 4, are classified according to (i) the technologies that can be part of a DT and (ii) the layers of functionality on which the DT can be based. In Section 5, we describe an initial set of security approaches that need to be considered in order to use DTs in more trustful and protected scenarios. Finally, Section 6 outlines the final remarks and future work. Figure 2: A four layer-based digital twin 2 Functional layers and enabling technologies In order to abstract the layers of functionality of the DT paradigm addressed in this paper, we take into account the conceptualization presented in and . For our research, we have identified four layers of functionality, which are presented in Figure 2 and described as follows: • Layer 1 . data dissemination and acquisition. Captures the dynamics from the physical space and prepares the control instructions for the phys.ical assets. • Layer 2 . data management and synchronization. Normalizes and en.riches heterogeneous multi-source data, allowing essential Layer 3 services to be executed. As the digital and physical space must cooperate with each other, network management and synchronization services must be considered . • Layer 3 . data modeling and additional services. Specifies states, behavior and geometric shapes through digital models . Within this layer, it is also possible to add additional services to provide maintenance and monitoring, cybersecurity and diagnostic tasks. • Layer 4 . data visualization and accessibility. Allows end users, entities and processes (e.g. supply chain management (SCM), enterprise resource planning (ERP), manufacturing execution systems (MESs) and other DTs) to visualize simulation results from digital models in order to make deci.sions regarding physical assets. Therefore, the difference between layers relies on the level of processing of data in the DT and on the technologies involved. Specifically, measurement and control values corresponding to real-world assets are typically captured and pro.cessed by Layer 1 devices that are deployed close to the physical assets. Those captures allow the DT and its models to synchronize with respect to the physical counterpart and initiate simulation processes to produce a more detailed and accurate understanding of the real world scenario. Precisely, the technologies involved in the interpretation of data and its representation are usually deployed at Layers 2-4, where all the DT logic and its simulation processes are developed. In order to better understand how all these layers work together, the following subsections explore the enabling technologies that are used in each of them. 2.1 Layer 1: Data dissemination and acquisition Among the existing technologies used to “perceive” the physical space, CPS and IIoT are the most common . The former was originally coined in 2006 as “engineered systems that are built from, and depend upon, the seamless inte.gration of computation and physical components” ; i.e. embedded systems combining computation, networking and physical processes such that the latter may impact on computational results, and vice versa. This results in a closed loop among sensors-controllers-actuators, in which the controllers are able to synchronously compute states of the real world and execute command and con.trol (C&C) instructions to change the behavior of the real world. In contrast, IIoT is a useful technology for environments where (autonomous and smart) devices need to connect to the Internet, without the need for synchronous com.munications among them or a closed-loop communication with the real world. Their networks, mainly driven by specific TCP/IP-based services, can be de.ployed in a distributed or in a decentralized manner, allowing them to produce and consume a large volume of data . In both CPS and IIoT, the interaction between elements is carried out in part thanks to automation protocols, which can be proprietary (e.g. JavaTM message service (JMZ) ) or standardized (e.g. Modbus ). In the literature, there is already a plethora of related work analyzing the intrinsic features of these protocols ( [59, 60, 60–62, 62–67]), as well as their relevance from a research standpoint . These works also show that not all protocols provide support for TLS (transport layer security), as is the case of WirelessHART , WI-PA and ZigBee PRO ), whose connections can be performed via gateways, brokers or front-ends (e.g. RTUs/PLCs) . In , Rubio et al. provide a comprehensive study of this aspect and classify the diverse IIoT infrastructures according to hardware (HW) and software (SW) constraints, protocols (also cf. ) and data exchange. The interconnection of digital twins as part of the IIoT ecosystem has also been considered in and , stressing the benefits of inter-and intra-twin communication. This type of connectivity is also considered in , where the authors show the main technologies used to enable digital transformation through the DT, while using existing communication systems such as long range wide area networks (LoRaWANs), time sensitive networking (TSN) and cellular networks. For the latter, Huawei , Ericsson and Spirent display their own business portfolios for cellular network-based manufacturing environments. Also, in , Viswanathan and Preben explore in depth the role of 6G technology to carry out the digital transformation using the DT paradigm. Their analysis highlights how the new era of cellular communication can benefit the connection between the physical space and the digital space, guaranteeing a more precise and synchronous update between both worlds. 2.2 Layers 2-4: Modeling, representation and visualiza.tion Most DT approaches [81–85] are designed to concentrate the core of their main computation on powerful devices whose computational logic may reside on a server or be spread throughout the system. In our research, we consider com.puting infrastructures based on edge, fog and cloud, mainly for their processing and storage capabilities, which differentiate them from traditional standalone servers. In other words, through these infrastructures, a DT would be able to run interesting complex data analytics and represent models without affecting the automation and control processes , in addition to fostering the agile connectivity between the DT’s spaces and components [84,85]. The computing infrastructures may establish a hierarchical computation based on three levels: cloud, fog and edge. Cloud servers, which are generally deployed at remote locations, can extract an overview of an entire system’s main functions, networks and components; whereas fog and edge computing, which are generally deployed locally (e.g. close to the physical space), help to compute large data volumes and establish connections in the surroundings [86,87]. This vision is also considered in , where the authors show how cloud-fog architec.tures for DT ensure a better operational performance by reducing latency. With regard to data management, BD and AI techniques are needed. For the former, Qi and Tao explore in the difficulties in applying BD in DT-based industrial contexts, mainly because the process requires complex operations and rules for data conversion, cleansing, merging, and consistency. This process can even be aggravated due to the implicit heterogeneity of the industrial context itself and its data. Other problems can also arise when DT technology integrates machine learning (ML) algorithms for analytics and autonomy, as shown in . In this work, the authors propose EDiT (enhancing digital twins), which combines reinforcement learning (RL) and deep learning (DL) methods, such as Bayesian neural networks and Proximal Policy optimization, to enhance the autonomy and control policy of a DT. However, not all MLs are equally effective for industrial contexts . Both Hussain et al. in and Chandola et al. in provide a comprehensive analysis of the complexity of ML approaches, where the selection of an algorithm relies on a set of factors . These factors include, for instance, the intrinsic characteristics of the context, the simplicity of the method and the degree of training (supervised, semi-supervised or unsupervised), the accuracy level in the learning processes, and the type of contextual parameters to be adjusted. An example is found in , where authors point out that due to the special time constraints between the physical world and the digital world of the DTs in industrial systems, time-series analysis may be a suitable approach for implementing future DTs. In order to represent knowledge extracted from AI techniques, Rasheed et al. explore the current representation and modeling tools, such as CAD/ECAD (electronic computer-aided) systems and CAM (computer-aided manufacturing) systems . Through these tools and their digital models, it is possible to char.acterize states, behaviors and shapes of a particular product, process or system. This also means that a digital asset consists of a set of meaningful information related to specific (geometric, physical and kinematic) properties, capacities, be.havior, processes and control. Using this information, software processes would be able to build reasoned and trustworthy decisions, which can be remotely ac.cessed through various communication interfaces (e.g. HTTP, REST, javascript object notation (JSON)) , human machine interfaces (HMIs, with support for virtual, augmented or mixed reality -VR, AR and MR) and dashboard services . Having presented in this section the different technologies that form part of DTs, the next section focuses on analyzing the operational requirements of any DT, which is a key step in order to later explore the cybersecurity threats of the new paradigm. Operational requirements of a DT A few works have already considered the relevance of extracting the main op.erational requirements of a DT. Bächle and Gregorzik identify the main requirements of the technology looking at data models, with a specific applica.tion for IIoT scenarios. Durão et al. list a set of requirements according to the literature review (2010 to 2018) and interviews with the Brazilian industry; and in , Moyne et al. present a much more complete picture of requirements, stressing the relevance of re-usability, interoperability, interchangeability, main.tainability, extensibility and autonomy. In this paper we group together all the requirements of those three works, following the approach given in , and we extend that list with some new requirements. To clarify this grouping, we show in Figure 3 an overview of the DT requirements, employing codes of the type [Rx.y] for the requirements that are used throughout this and the following sections. This figure (also inspired by the work ) represents the hierarchical relationships between requirements, which are also described in depth in the following subsections. Infr. and resource management [R1.1] DT operational requirements Performance Communic. [R1.2.1] Overhead Computation [R1.2.2] [R1.2] Storage [R1.2.3] Coexistence [R2.1] Interoperability Synchronization [R2.2] Extensibility [R3.1] HW scalability [R3.2.1] Scalability Maintainability [R3.2] Data scalability [R3.2.2] Upgrade [R3.3] Testeability [R3.4] Availability [R4.1] Reliability Maintainability [R4.2] Fidelity [R5.1] Consistency Granularity [R5.2] Security [R6.1] Safeguard Privacy [R6.2] Figure 3: Operational requirements of a DT 3.1 Operational performance and reduction of complexi.ties One of the main objectives of the DT paradigm is to keep the digital space synchronized with the physical space . Any variation between the two spaces can lead to a significant deviation in the final representation of a physical asset. To avoid this, it is first necessary to address the various complexities of the system in terms of infrastructure, communication, computation and storage. Second, it is vital to ensure reliable connection to the physical world. Both aspects are covered in this paper, considering the following sub-requirements ([R1.1] and [R1.2]): 3.1.1 Infrastructure and resource management [R1.1] DTs must ensure efficient connections with the real world for synchronization (Layer 1), and efficient simulations for representation of the real world (Layer 3). For that reason, it is essential to take into account the current computing infrastructures in order to optimize the deployment of digital models and their processing during simulation. The combined use of edge . fog . cloud plat.forms has already been analyzed in depth by Roman et al. in and Chen et al. in [100]. Both works highlight how these platforms can positively influence the operational performance of the underlying infrastructure, identifying the chal.lenges that the computing paradigm brings to the application context. Many of these challenges are related to network management under centralized, decentralized or distributed infrastructures, mobility, degree of connectivity, us.ability and management of resources and tasks. For the latter challenge, Roman et al. emphasize the need to use offload methods to external servers, meaning that less intensive tasks can be executed locally on end devices, while computa.tionally intensive tasks must be delegated to powerful systems. An example of this approach is also found in [100]. In this work, the DT runs over the edge net.work, leaving the most complex optimization issues to powerful infrastructures such as the fog or the cloud, thereby reducing possible latency problems. Another aspect to take into account is that both computing platforms and DTs are systems running on virtualized infrastructures. As specified in , there is a particular lack of standardization in the life-cycle of virtual machines, and especially a lack of context awareness to dynamically adjust HW/SW re.sources. Through HW management, it would be possible to rationalize vir.tual resources and their performance (e.g. by using HW acceleration technolo.gies [101]), while deploying lightweight services and SW management can also help to reduce HW overheads [102]). 3.1.2 Overhead management [R1.2] As shown in Figure 3, we identify three classes of overhead related to (i) com.munication; (ii) computation; and (iii) storage. From the communication point of view, a DT manages heterogeneous data from different Layer 1 sources with support in various IIoT/CPS protocols. However, not all protocols handle data efficiently. For example, MQTT has a header size of 2 bytes per message, AMQP has 8 bytes and HTTP has variable headers depending on the underlying com.munication, all of them running over TLS. The latter feature may even produce further communication overhead as peers or intermediary nodes (e.g. bro.kers) have to previously establish TCP connections and the TLS handshake. In addition to this, overhead may grow if the DT is included in the IoT ecosys.tem to create large-scale (virtual and physical) spaces [103], with connec.tions to other DTs or external entities [102]. On the computation side, the overhead in the DT depends on: (i) the volume of data produced by the different virtual assets; (ii) the information collected from the elements deployed at Layer 1; and (iii) the complexities of applying BD and ML techniques as stated in Section 2.2. One way to reduce latency in this process and in data management would be through techniques that foster parallelism (i.e. read, write and process data streams in parallel) or to use technologies associated with MapReduce, Apache (Spark, Flink and Storm), Kafka Streams or Google Dataflow . Regarding data representation, DTs also need to reserve part of their memory and processing to extract modeling properties (e.g. kinematic models in 3D or geometric models) and characterize states through complex tools such as CAD or CAM systems. Finally, to reduce the storage overhead, data introspection could be a useful method to extract data of interest , or novel databases could be applied to expedite the querying and its management. In this case, Qi et al. [104] iden.tify some interesting databases that can be applied in DT-assisted scenarios, such as: distributed file storage systems, non-relational databases (NoSQL) , newSQL (to manage duplicated data using redundant SQL servers), and edge data centers under the premise of resource offloading at the edge. Another rele.vant technology for DT-based scenarios is distributed ledger technology (DLT), such as blockchain. This technology offers permissioned capacities (e.g. through smart contracts [105]) to protect access to the intellectual property in the DT, and capacities to manage data provenance, auditing, traceability and account.ability. Yaqoob et al. [106] emphasize all these aspects, underlining the benefits of blockchain-enabled DT. In this case, the DT can (i) manage identities and access through certificates; (ii) provide accurate activity tracking; (iii) foster transparency (e.g. in a federated consortium connected through DT); and (iv) promote decentralization and integrity of the data. Similarly, Hasan et al. [107] propose a blockchain capable of logging the processes performed throughout a DT’s life-cycle: from the design of a product, process or system to their simu.lation, validation and delivery. In either case, a blockchain-enabled DT should be subject to specific requirements for secure data storage [108]. 3.2 Interoperability between assets and layers Interoperability is defined by IEEE as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” [109]. In DT-based scenarios, this definition can be interpreted as the system’s capacity to exchange and use information between spaces . Within this concept, we further identify two relevant sub-requirements ([R2.1] and [R2.2]): 3.2.1 Coexistence [R2.1] Not only do physical assets of Layer 1 (including interfaces and communications) have to coexist in the same space [110, 111], but also digital assets of Layer 3. Digital assets have to coexist in the same virtual plane to simulate states equivalent to the physical world, and thus meet the requirements of consistency between both spaces. At Layer 1, this sub-requirement relies on the specification given by the communication protocols (e.g. MTConnect, OPC-UA) composed of predefined encoding formats (XML, JSON, binary, text). At higher layers, the data encapsulation among digital models (related to topology, geometry, kinematics and logic) is driven by specific standards such as the IEC-62714 for AutomationML (Automation Markup Language) [112,113], ISO-10303 (also known as STEP) [67,114], and the ISO-10303-238 (also known as STEP-NC) [67,115]. Furthermore, modularity-related aspects are also relevant for fostering the portability of the DT without needing to know in advance the end points where the DT is deployed. In this case, it is essential to select suitable com.munication protocols at Layer 1 (DSS, oneM2M, HTTP, CoAP or MQTT) that make it possible to create systems such as black boxes with data-oriented interfaces . For instance, the work in [103] proposes a DSS-based data-centric communication middleware to interconnect distributed large-scale DTs and share data between spaces in any format. 3.2.2 Synchronization [R2.2] In order to obtain reliable simulations with executions similar to the real world, the system must find a way to synchronize the cooperation among assets of the same space or between spaces. In [116], Qamsane et al. demonstrate the need to establish two kinds of synchronization measures in DTs: one at the communi.cation level corresponding to Layer 1, and another on the DT side belonging to Layers 2 and 3. For Layer 1, any traditional synchronization measure would be sufficient, such as the methods provided by the network time protocol (NTP) or the precision time protocol (PTP) [116]. In contrast, Zipper and Diedrich make a more general analysis. They look at the execution times between spaces [117]. In this case, they propose an online-optimization approach capable of computing the time distances between the plant’s outcome and the output of the simulation using an objective function together with Dijkstra’s algorithm. This objective function is limited to the time sum of all the executions of assets involved in the process, taking into account the delays produced by the DT itself. For in.teroperability between models and data synchronization at Layers 2 and 3, the work in [118] discloses an anchor-point-method to detect variations related to the topology, the inter-relations and the structures among models. To detect anomalies, each anchor-point needs initial information on the physical objects (e.g. class of geometry or location) and their relationships. 3.3 Maintainability of digital assets DT functions must operate over a long period of time. To address this challenge, maintainability issues must come into play [119]. This concept gives rise to two different definitions by IEEE: (i) “the ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment”; and (ii) “the ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions” [109]. The concept itself can be extrapolated to DT-based systems, since HW/SW conflicts, anomalies, breaches and bugs may arise in the four layers of the DT. To prevent these, four further sub-requirements ([R3.1]-[R3.4]) are identified below: 3.3.1 Extensibility [R3.1] and scalability [R3.2] Extensibility refers to the system’s ability to incorporate new SW components, whilst scalability refers to the system’s capacity to add new HW components. This means that extensibility can be addressed through modularity, both in the design and in the implementation, promoting good practices (well-defined interfaces and structured programming), plug&play and transparency [120]. In contrast, HW integration depends on the technologies involved, where the de.ployment of new HW resources could be combined with offloading techniques supported by powerful technologies [87,100], fast communication infrastructures (e.g. 5G/6G) and specialized communication standards (e.g. TSN). In the area of scalability, we also consider those resources associated with databases and their servers (data scalability), which are essential for fostering DT-specific services such as prevention, cyber security and predictive mainte.nance. To date, several approaches have already emerged around this issue, either to derive faults in specific CPS devices or promote early warning, predic.tion and optimization of services [121]. Depending on the extent of the DT and its reliance on distributed databases (e.g. for wide-area situational awareness), these services may, in turn, require lightweight provenance techniques at Layers 2-3 for “tracking and recording the origins of data and its movement between databases” [122] (for instance, tracking anomalies caused by an intrusion). 3.3.2 Upgrade [R3.3] This procedure should not cause greater damage to the simulation stages, but depending on the type of simulation (see Section 2) and its application mode in the PLM, some risks might arise. For example, isolated what-if focused simula.tors should not feel the upgrading effects since they run decoupled from the main system. However, centralized DTs devoted to monitoring and controlling CPS devices, services or manufacturing systems in online mode might create serious disruptions. Note that this requirement is already analyzed in and [123], but the authors focus solely on network infrastructures deployed at Layer 1. They claim that, with the exception of centralized systems such as front-ends (e.g. PLCs or RTUs), the implications of IIoT use and its distributed networks make it possible to perform gradual upgrades without impacting the underlying control. In contrast, for Layers 2 and 3, this gradual update will depend on how and where the logic of the DT is allocated, which is normally centralized in a server. In either case, virtual resources could also be updated progressively, tak.ing into account the interfaces and connections to databases. These databases could even be distributed and replicated in the entire industrial ecosystem using, for instance, edge data centers or DLT-based networks. 3.3.3 Testability [R3.4] Given the complexities of DT-based systems, testability is also an essential requirement for detecting whether security policies and the functionality criteria needed to strengthen DT functions are properly fulfilled . These tests can be planned so as to be launched periodically or automatically, and consequently determine when and how to proceed with the new maintenance plans. This information can even provide data on other essential services within the DT, such as risk management and intrusion detection. 3.4 Reliability of assets and data Reliability is defined by IEEE as “the ability of a system or component to perform its required functions under stated conditions for a specified period of time” [109], which in turn, corresponds to “a measure of the continuity of correct service” . In the DT paradigm, this concept can be associated with the system’s capacity to correctly conclude its operational functions with guarantees of quality . Depending on the nature of the underlying system, this service may even be critical or essential to ensure the continuity of the PLM. Within this requirement, Al-Kuwaiti et al. identify three essential sub-requirements : availability, maintainability and testability (note that the last two have been described before). 3.4.1 Availability [R4.1] This is related to the level of access to resources, either HW/SW components or data. With regard to access, quality of service (QoS) policies are recommended, which could be supported by diverse QoS mechanisms such as fault tolerance and exception handling. If QoS is associated with data quality , then this should be attributed to delivery (timelessness, priority, ordering and presentation) and durability (access time to valid data) . This also means that the data life-cycle in the DT should be based on methodologies and operations, such as CRUD (create, read, update and delete), whose values must be valid from their acquisition at Layer 1 to their processing and representation at Layers 2, 3 and 4. Moreover, Harper et al. highlight this aspect in [124], showing the influence of the CRUD operations in DT-assisted architectures. Misuse of these operations could, for example, invalidate access to certain data (equivalent to a threat on availability) and/or affect the fidelity or granularity of their representations (equivalent to a threat on integrity), corrupting their trustworthiness. 3.5 Consistency in reasoning and representation Consistency is linked to digital assets’ quality of reasoning and representation: what the physical asset projects must be equivalent to what its digital counter.part interprets and shows. Thus, any variation in the outputs of both spaces might create contradictory realities [109]. To avoid this, methodologies and se.mantic description languages used to encode digital assets (e.g. ontology-based models [125]) could be essential. Using these languages, it is possible to coordi.nate, compare and compute the physical system’s outputs with respect to the simulated environment’s outputs by applying advanced techniques that make it possible to interpret and derive conclusions at different granularity levels. This aspect is also considered in [126], where the importance of detecting inconsis.tencies between models is clearly highlighted. With regard to consistency, we identify two further essential sub-requirements ([R5.1] and [R5.2]): 3.5.1 Fidelity [R5.1] According to Durão et al. in , this sub-requirement is associated with ac.curacy. DTs have to show an equivalent reality to their counterparts. Any deviation beyond that reality could lead to invalid interpretations and conclu.sions, and cause inaccurate settings and inappropriate C&C instructions that may drastically change or damage the behavior of physical assets. 3.5.2 Granularity [R5.6] This sub-requirement is associated with the degree to which a DT can char.acterize the structures and the behavior of the observed system according to levels of granularity . This is in part thanks to the advances in SW engi.neering that make it possible to represent critical contexts using specific models for manufacturing domains, including reusable models [127]. In addition, the concept of granularity of the data can be adapted from the work in [128], in which (i) the level of specificity and uniqueness of the DT models to represent physical assets, and (ii) the level of the specificity and uniqueness of the data with respect to its depth, are relevant. 3.6 Safeguarding virtual resources, operations and data Security is also an important issue that must be considered within the DT paradigm. One of the main reasons is that the DT tool is being extended to multiple types of scenarios, many of which are of a critical nature (see Table 1). They can be applied for monitoring, analysis, predictive maintenance, engi.neering design and testing. All these services rely heavily on SW components (algorithms, models, applications), which are usually susceptible to multiple threats due to bugs, as well as on multiple infrastructures, interfaces and net.work connections. All of these complexities may lead to (cascading) deviations in the DT itself that may modify the performance of the underlying system due to inaccurate decisions made by the DT. Moreover, if we assume that DTs can be adapted to operate in critical environments, the need to further protect industrial ecosys.tems together with their DTs becomes a mandatory requirement. However, this need also raises the question of whether the incorporation of security measures in the DT may, in turn, increase HW/SW complexities that may affect the op.erations of the DT itself. For example, the implementation or adaptation of security mechanisms could hinder essential operations in those DTs that have significant difficulties in compiling and processing data and models without the possibility of offloading resources to powerful platforms. Operational perfor.mance in the simulations must then prevail in such systems where security must be a priority but not a predominant requirement if it seriously interferes with the simulation tasks. Obviously, a failure to establish proper security in the DT paradigm can also pose a problem. DTs are considered the mirror of the physical world, in which intellectual property copies of the (entire) IT-OT ecosystem are stored [129]. These copies may contain, for example, the mode of operation of OT units, the functional characteristics of proprietary and legacy protocols, the characteristics of the operational environment and its connections, or the security credentials for access to critical resources. This also means that DTs contain critical infor.mation, allowing attackers to extract and create a mapping of the whole system or a part of it, as well as derive private information or conduct patterns by analyzing databases, states, configurations and resources. In addition, digital assets can make their own decisions, which can severely affect their physical counterparts if those digital assets are deliberately manipulated. Security threats in the digital twin As we have shown at the end of the previous section, DTs must be treated as critical systems in which security issues need to be considered in terms of avail.ability (A), integrity (I) and confidentiality (C) of data and resources, but also privacy issues arise with respect to entities (E) and location (L) of assets. For that reason, when addressing potential security and privacy threats, it is vital to explore how they directly/indirectly affect the operational requirements of the DT (cf. Section 3). Additionally, any security analysis of a DT must take into account the four functionality layers described in Section 2 (see also Figure 2), mainly because DTs mostly rely on digital assets for data processing, involving models and algorithms as well as virtualization platforms and networks. All of them are developed throughout the aforementioned layer structure and, there.fore, its relevance to security analysis is an important part of any discussion. In this paper, we consider two types of attack surfaces: digital and physical. The first comprises all the explorations associated not only with software (e.g. poor coding and upgrades, default security settings, etc.) but also with all the components offering resources for (distributed and centralized) computation, such as the network itself and its information systems. These assets make it possible to execute and manage critical data, which can be related to processes, intellectual property and control tasks under C&C actions [48,129]. As for the physical attack surface, it embraces all those security threats associated with access to endpoints, either CPS/IIoT nodes, communication infrastructures and facilities. Hence, the overall attack surface is very wide. Attackers may compromise the DT considering the physical attack surface (i.e. from Layer 1 to Layers 2-4), but physical assets may also be at risk when the DT is attacked (i.e. from Layers 4-2 to Layer 1). In fact, in the latter situation, (internal or external) attackers can even improve their knowledge and attack techniques by extracting information from the DT itself. For example, adversaries can penetrate indus.trial control systems (ICS) and, once inside, can search the location of the DT in order to compromise it. Once the DT is compromised, attackers can learn about the system’s resources, extend their technical capabilities and access the critical system through the DT to exfiltrate information or destroy its resources, as also detailed in [130]. If, in addition, this attack sequence is carried out from a stealthy point of view, the threat would correspond to a typical Advanced Per.sistent Threat (APT) such as Stuxnet (2009), BlackEnergy (2015-2016), ExPetr (2017) or GreyEnergy (2018) [131]. Of course, the success of these attacks will also depend on the computational logic of the DT, which can be centralized or distributed throughout the entire system (cf. [R1.1] of Section 3.1). Figure 4 shows a classification of the different threats that we have identified in the DT paradigm (where [Tx.y] represents the functional layer x and the y-th threat in that layer). We have classified these threats according to a DT’s four layers of functionality, while considering other attack taxonomies like [132] and . For each of the threats, the operational requirements that may be affected are also listed. It must be noted that this part of the research is also key for identifying the general security approaches needed to protect a DT, as we will discuss in Section 5. 4.1 Threats at Layer 1 As described in Section 2.1, DTs are systems that use CPS-/IIoT-based commu.nication networks to collect information from the physical space. Their infras.tructures can be diverse, with support for wireless networks and the Internet. Generally, they are deployed in private environments, making access difficult. Even so, adversaries with the ability to interfere in these types of networks can launch specialized attacks such as: • SW attacks [T1.1]: OT devices rely heavily on proprietary or third-party SW components [133]. These components may, in turn, present bugs in their own codes, opening the door to other multiple threats such as reverse engineering , buffer overflows [134], manipulations in computing sec.tions [135,136] or alterations in the natural behavior of the node. In [134], Falco et al. offer an extensive overview of common vulnerabilities and exposures (CVEs) in SW components of OT devices, extracting such in.formation from well-known databases such as ICS-CERT, MITRE and the NIST’s national vulnerability database (NVD). In this work, they show how most of the OT devices are vulnerable primarily to buffer overflow at.tacks, derived from the implicit vulnerabilities of their operating systems SW attacks [T5.1] Rogue HMIs [T5.2] Layer 4 Visualization tampering [T5.3] SW attacks [T4.1] Extraction of private inf. [T4.2] Privacy leakage [T4.3] Data tampering [T4.4] Knowledge tampering [T4.5] Representation tampering [T4.6] SW attacks [T3.1] Privilege escalation [T3.2] Rogue virtual resources [T3.3] Extraction of private infor. [T3.4] Virtual resource tampering [T3.5] Layer 2-3 Man-in-the-Middle [T3.6] Denial of service [T3.7] Privacy leakage [T3.8] SW attacks [T2.1] Privilege escalation [T2.2] Rogue DT servers and infrast. [T2.3] Extraction of private infor. [T2.4] DT service tampering [T2.5] Man-in-the-Middle [T2.6] Denial of service [T2.7] Physical damage [T2.8] Privacy leakage [T2.9] SW attacks [T1.1] Privilege escalation [T1.2] Rogue CPS/IIoT devices [T1.3] Extraction of private infor. [T1.4] Layer 1 Digital thread tampering [T1.5] 21 Man-in-the-Middle [T1.6] Denial of Service [T1.7] Physical damage [T1.8] Figure 4: Classification of security threats in the DT paradigm (OSs), most of which are dependent on Windows. Indeed, significant diffi.culties may arise when updating the codes of OT devices (OSs, monitoring tools or other related applications). The reason for this is twofold: indus.tries still maintain the mentality of “do not touch a working system” [137], and they need to guarantee compatibility with the legacy devices. Accord.ing to a study carried out by Trend Micro Research in [137], manufactur.ing industries continue to rely on older versions of OSs such as Microsoft Windows XP, support for which ended in 2014. This situation may worsen further if source codes are made public, as in the case of Windows XP [138] whose code was leaked on the Internet in 2020. Likewise, the works [139] and [133] review specific attacks on CPS and IIoT, pointing out malware as a potential SW attack weapon (e.g. PLC-Blaster worm [140], Dragonfly, Stuxnet, BlackEnergy 3, LockerGoga, RE.vil, Industroyer, etc. [141], including rootkits for controllers [142]). This weakness is also noted in , stating how the security of DT data can be corrupted by relying directly on the security of IoT platforms. These platforms are typically prone to malware attacks due to heavy reliance on off-the-shelf and web-based [143] solutions. The latter is typically applied to connect DTs to publish-subscribe infrastructures, but also to connect DT-DT or DT-end-users. As is evident, the impact of a malware infection can aggravate the operational performance of a target and its surround.ings. Among other issues, they can: (i) cause significant overheads on the device or in its vicinity; (ii) trigger interoperability and maintainability issues (whether local or remote); (iii) disturb the synchronization perfor.mance and/or cause consistency issues; and (iv) cause security concerns. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (with impact on availability, integrity and confidentiality, labeled AIC as aforementioned). • Privilege escalation [T1.2]: Adversaries with the ability to access OT do.mains normally aim to escalate privileges and reach the administrator’s permissions. These actions generally occur when flaws in the authentica.tion and authorization mechanisms emerge, which may be maintained by administrators with insufficient security knowledge, training, or interest. These problems may also arise when OT nodes and related infrastructures are not updated on a regular basis or do not follow suitable security poli.cies. As an example of this threat, the work in [135] details the influence of Triton, which was a malware designed to interact with specific Triconex controllers by exploiting two zero-day vulnerabilities (CVE-2018-7522 and CVE-2018-8872). With Triton, attackers were able to escalate privileges on the controller to gain access to Triconex’s memory and execute arbi.trary codes. Although this is a very specific example, similar threats can also occur in DT-based scenarios. Attackers with full rights to access in.dustrial domains could disconnect Layer 1 nodes, change configurations, generate false values or manipulate network traffic , which would also lead to significant deviations at Layers 2-4. If, in addition, these DTs are designed for detection, such as [10,36,144], their systems could han.dle invalid information, producing false positive or negative rates when comparing the input and output values of the two spaces. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Rogue CPS/IIoT devices [T1.3]: Insiders with full rights to access OT do.mains may deploy, clone and replace IT/OT devices, or maliciously update SW components to take control of the physical space, and consequently interact or impact with the digital space as previously described. In , Murillo et al. show how to deliberately configure the flags of a PLC to keep the water pumps in a hydraulic system closed and cause one of the tanks to remain empty, while a DT, called DHALSIM, is applied for its detection. Similarly, in the authors modify the logic of a PLC by pre.suming the existence of an insider, in order to later stress the relevance of online defense from the digital space. Thus, through these rogue devices, adversaries may consequently lead other attack actions, such as man-in.the-middle (MitM) actions, disrupt control tasks, insert a backdoor for redirection of critical traffic, or fool the DT itself with fake output values from the physical space. Moreover, this threat can even come from within the HW/SW supply chain itself. Malicious manufacturers might, for example, insert compromised parts in CPS/IIoT devices to achieve specific purposes (e.g. create infor.mation leaks, cause malfunctions, or alter the integrity of assets) that can impact not only the normal operation of the system and any DT involved, but also an organization’s reputation [145]. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.1, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Extraction of private information [T1.4]: Insiders could also leverage their privileges to extract information from legitimate IIoT/CPS devices, such as credentials or security parameters shared with the DT. With this infor.mation in hand, they could gain access to the DT from the physical space or conduct multiple MitM attacks between both spaces. Another way to extract legitimate information would be through traffic analysis [132]. Adversaries with the ability to interfere in the traffic might eavesdrop the data consumed or produced by the physical space and the virtual plane, or analyze the network flows to map (e.g. by looking at the source and destination IP) and locate the server that hosts the DT. The latter may even jeopardize the logic of the DT because the aim of the threat may be to first attack the DT by finding out the location of the server, and later corrupt the physical space through malicious C&C instructions. The main operational requirements that may be affected are: R6.1 (C) and R6.2 (L). • Digital thread tampering [T1.5]: In [146], Shi et al. underline this weak.ness, which is related to the attacker’s ability to modify the data ex.changed (e.g. synchronization or C&C values) between the physical and digital space of a DT. This situation may occur when insiders take advan.tage of their privileges to access OT domains and freely manage devices without being supervised through security controls. In this management, they might, for example, inject malware, produce misconfigurations in the monitoring tasks, or desynchronize the digital space with respect to the physical space. An example of a digital thread manipulation attack is found in [136]. The authors produce two manipulation attacks in the CPS signal, so as to later detect the threat with their own DT. Both attacks focus on injecting false data into the output signal considering a Scaling attack and a Ramp attack (altering the . value associated with the controllers’ telemetry output values). The main operational requirements that may be affected are: R2.2, R4.1, R5.1, R5.2 and R6.1 (AI). • Man-in-the-middle [T1.6]: MitM in the communication space can also disrupt the digital thread, especially when the space relies on wireless net.works. In , for example, the authors experiment with their own DT to exploit mobile networks and cause significant delays in remote surgery con.trol applications. If we also consider the existence of industrial communi.cation protocols without integrated security measures in DT-assisted con.texts, such as ModbusTCP [147], the risks would clearly increase. More.over, given the closed nature of industrial ecosystems, insiders continue to be the main intruders with the ability to insert rogue devices or compro.mise legitimate devices, and consequently to interfere with communica.tion channels. Through these devices, they could launch routing attacks to play with the DT traffic from the physical space [133,135,148] and: (i) create deviations or routing loops that could deteriorate the QoS [149] or the maintenance processes; (ii) inject false data ; (iii) modify control packets [10, 36]; or (iv) trace the sequence of traffic flow. In [148], the authors also highlight the influence of malicious intermediaries in IIoT publish-subscribe models, which can take full control of the communica.tions, without clients being aware of their actions. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.3, R4.1, R4.2, R5.1, R5.2, R6.1 (AIC), and R6.2 (L). • Denial of service [T1.7]: Another way to attack the DT from the physical space is through a denial of service (DoS) attack. Adversaries could ex.haust the resources of constrained IIoT/CPS devices to limit automation operations in the physical space and, consequently, the simulation oper.ations in the digital space. This depletion in CPS/IIoT ecosystems can be carried out from the TCP/IP stack itself, where it is possible to cause jamming at the physical layer of the stack [146,150], inject malware at the application layer (see [T1.1]), or provoke on-the-path attacks at the net.work layer. Typical DoS attacks in CPS/IIoT routing [135,148,151] might be, for example, flooding , replay , blackhole, sinkhole (declaring a high-quality route, e.g. to the gateway or broker [151]), wormhole (similar to the sinkhole but with several nodes together) [152] or selective forward.ing (selectively forwarding packets). For those cases where Layer 1 of a DT relies on cellular communication networks, the work in [150] provides a review of threats in 5G communications, which are similar to those al.ready mentioned here. On the other hand, a DoS may also be coordinated through a distributed DoS (DDoS) attack in which several malicious nodes are compromised to prepare an army of CPS/IIoT botnets. The Mirai at.tack [153] is a clear IoT-based botnet example against a domain name system (DNS) provider. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (A). • Physical damage [T1.8]: Any attacker with access to Layer 1 elements can lead a physical attack that causes DoS (e.g. tampering, theft or destruc.tion of devices), affecting the monitoring and optimization tasks [154] of the digital space. In this kind of attack, insiders, who have access to the system and its resources, continue to predominate. The main operational requirements that may be affected are: R2.2, R4.1, R5.1, R5.2 and R6.1 (A). 4.2 Threats at Layers 2-3 In this case, we consider the threats addressed in and adapt them to a much more specific context based on DTs. Particularly, we distinguish throughout this subsection: (i) threats to computing infrastructures (cloud-fog-edge) for DT data processing and storage; (ii) threats to virtualization systems for simulation; and (iii) threats to computing techniques for data management. 4.2.1 Computing infrastructures As mentioned above, DTs can be hosted on standalone or edge servers to dis.tribute DT logic and reduce latency [155]. However, the critical nature of most industrial scenarios (cf. Section 2) means that these servers are deployed in closed environments under access constraints. With this limitation in mind, we identify the following types of attacks on those DTs hosted in computing infrastructures: • SW attacks [T2.1]: DT servers are mainly based on systems that compute specific DT services (cf. Figure 2). These services, in turn, depend on a set of SW components that include databases, ML models, applications and firmware. Unfortunately, all these SW elements may additionally present severe bugs that may alter the integrity of the digital assets or the availability of their services. This SW weakness is also addressed in [156], where the authors review the security of the most popular operating sys.tems (Windows and Linux) applied for cloud-based environments. They conclude that the current OSs still present serious security vulnerabilities, especially related to authentication, authorization, accounting and privacy (discussed in [T2.9]). On the other hand, malware infections between ele.ments of a DT and between DTs may become one of the biggest security problems of the next industrial revolution, where a highly connected indus.try dependent on IoT and cloud platforms is foreseen . In addition, the vast majority of IT infrastructures, including cloud platforms, lack anti-malware measures, as they are systems dedicated to running specific services [157]. This is relevant because any infected cloud server could, for example, complicate cross-space synchronization processes or disable essential functions of the DT. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Privilege escalation [T2.2]: Adversaries who break into the system and try to reach the DT aim to escalate privileges in order to take over the host system. As mentioned above, these problems often stem from deficiencies in authentication mechanisms, access control policies, lack of segregation, lack of knowledge or disinterest in the security of the system. In fact, the works in [158] and [146] clearly state that cloud-based resources may not be sufficiently isolated in industrial contexts, causing significant avail.ability, integrity and confidentiality problems. Therefore, the implications would be equivalent to those detailed in [T1.2], but adding threats to data scalability since DT databases can be part of these computing infrastruc.tures. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.2. R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Rogue DT servers and infrastructures [T2.3]: Insiders with full rights to deploy DT servers and related infrastructures may clone and replace components to add malicious servers. This means that data replicates of the physical world may be managed by fake servers, and insiders may take control of the digital thread shared by both worlds. This feature is also contemplated in [159], where rogue gateways are part of the edge infrastructure and adversaries may lead other subsequent attacks such as a MitM or a DoS. These threats can even come from within the HW/SW supply chain itself, as also described in Section 4.1 (threats at Layer 1), where adversaries can remotely control malicious HW/SW parts to exfil.trate sensitive information or, through these parts, take control of Layer 1 and Layer 2-4 critical resources. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.1, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2, R6.1 (AIC) and R6.2 (L). • Extraction of private information [T2.4]: Data privacy is one of the biggest security issues we can find in the DT paradigm [160], mainly be.cause the goal is to protect the intellectual property contained in their servers. In [161], Gupta and Kumar assert that adversaries with access to compromised servers or related infrastructures may extract private infor.mation, such as services, dynamics data, configurations, states or security credentials. With this information, they may exfiltrate information for cyber espionage, or identify the main vulnerabilities in the DT (including zero-days) to improve attack techniques. This method of gaining access to sensitive information can even help attackers carry out potential attacks that may result in APTs. The results may range from stealthy manipu.lations in the DT services to lateral movements between attack surfaces within the computing infrastructure itself. One example is found in [162]. The authors propose a Bayesian network based on weighted attack paths to model APT attack paths in cloud-based environments, while [163] il.lustrates a broad overview of the modus operandi for stealthy moves in IT-OT ecosystems. Likewise, network-level passive analysis can also arise in edge domains to locate the server hosting the DT. The main operational requirements that may be affected are: R6.1 (C) and R6.2 (L). • DT service tampering [T2.5]: If servers hosting DTs are compromised, either by privilege escalation or abuse, it is very possible that adversaries can manipulate the services of the DT itself. The work [159] provides a comprehensive security study associating the problem with edge servers and mobile edge devices. In both cases, the results in DT can vary greatly from the desynchronization of the digital models to the modification of the behavior of both worlds, and the alteration of the Layer 3 representation [146] to end users by hiding, disrupting, modifying or falsifying information from the cloud-fog-edge. The main operational requirements that may be affected are: R2.1, R2.2, R4.1, R5.1, R5.2 and R6.1 (AI). • Man-in-the-middle [T2.6]: MitMs are typical threats in network infras.tructures and, in that case, DTs are systems whose logic may be dispersed throughout an entire computing infrastructure. Malicious servers (in the cloud, in the fog and at the edge) can act as MitMs [159] through which DT information flows can pass. Likewise, these MitM servers that execute part of the DT logic can also (i) cause deviations in the knowledge that the DT itself processes; (ii) alter or overflow the databases that the DT manages; and (iii) change the final representation that the DT computes to the end user. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2, R6.1 (AIC) and R6.2 (L). • Denial of service [T2.7]: Like MitMs, (D)DoS attacks may also occur in applications that rely on computing infrastructures, as also stated in [164] and [159]. However, the extent of the threat may not be so dramatic in edge-assisted contexts. Roman et al. in and Zhang et al. in [165] point out that the decentralized nature of edge servers and the offloading capabilities of services within the paradigm cannot completely disrupt essential services. For instance, powerful computing services related to the intelligence and representation of the digital assets (at Layers 2-3) could be deployed within the cloud/fog, and the rest of the services distributed at the edge. This view is also shared by Al-Ali in [166], detailing the usefulness of the edge to decentralize critical services of the DT and locally recollect and process data to reduce load and latency at Layer 1. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (A). • Physical damage [T2.8]: It is not usual to witness a physical attack on servers deployed in controlled industrial contexts. Operational domains are generally closed systems that require the attacker to be close to the server or its infrastructure. Insiders would therefore be the only ones who could execute this attack as long as they were able to escalate privileges within the facility and gain access to the target. On the other hand, depending on how the DT logic is distributed in the entire system (e.g. at the edge), the scope of this threat may not be as devastating. Part of the threat may be focused on a specific location without influencing the whole, as also indicated in [159]. However, a physical attack still constitutes a threat that implicitly causes a DoS and affects the correct functioning of a DT or one of its sub-parts . The main operational requirements that may be affected are: R2.2, R4.1, R5.1, R5.2 and R6.1 (A). • Privacy leakage [T2.9]: In addition to data privacy, other privacy risks may arise, especially when computing infrastructures adapt intelligence algorithms. Edge paradigms (including cloud and fog) are systems com.posed of elements capable of computing and storing large volumes of pri.vate data, and depending on how they are managed or by whom (e.g. malicious providers or insiders), the risks can vary greatly. Malicious enti.ties may steal sensitive information (causing confidentiality issues related to [T2.4]) or derive (encrypted) production, logistics or marketing plans, which would undoubtedly put intellectual property at risk . Apart from this, location privacy is also relevant at this point. Hyper-connected servers (e.g. at the edge-cloud [167]) that contain all the DT’s logic may be clear targets for adversaries, whose initial purpose may be to trace their locations in order to lead subsequent attacks. In addition, depending on how the components of the computing infrastructure are connected and the degree of offloading in the infrastructure, shared network traffic flows in the hierarchy can be monitored to increase the attackers’ awareness in this regard . The main operational requirements that may be affected are: R6.1 (C) and R6.2 (EL). 4.2.2 Virtualization systems DTs are based on virtualization systems, capable of executing and simulating the natural behavior of the physical counterparts in terms of functionality and relationships. These virtualization systems can be local to standalone servers or they can run on top of a computing infrastructure with connection to (cen.tralized or distributed) databases, as stated in Section 2.2. • SW attacks [T3.1]: Both VMs containing the digital assets, and moni.toring and management tools of virtual resources (also known as hypervi.sors) are SW-based systems that present multiple vulnerabilities. In [168], Perez-Boreto et al. analyze the security breaches of hypervisors according to real attacks. Through these breaches, adversaries may carry out subse.quent attacks that can lead to serious security and privacy problems, not only on the VM but also on the host where the VM is running. Examples of these attacks include malware penetration into the kernel [169], infec.tion in the DT’s interconnected cyberspace [170], illicit memory writing, buffer overflow, illegal code execution, memory and information leak, se.lective manipulation of VMs, etc. [171]. Note that many of these threats have also been identified by the National Institute of Standards and Tech.nology (NIST) in [172] together with some protection measures detailed later. Besides, DTs can be based on the software-defined network (SDN) tech.nology for the management of network resources and the virtualization of infrastructures [167,173,174]. However, although the SDN benefits the defense against DDoS attacks as indicated in [175], the efficiency of packet processing in the communication space still depends on SW components. Compromised SDN controllers may result in inefficient data processing, causing significant overheads or losses of information. All these risks are also contemplated by Yang et al. in [167], in which they design a DT to test and verify the control logic of an open edge-cloud collaboration ar.chitecture for manufacturing scenarios with support in the SDN, called iCMfg. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Privilege escalation [T3.2]: As previously discussed, VMs, containers and hypervisors managing the DT’s logic may present SW vulnerabilities within their systems. These security gaps are attractive for adversaries capable of escalating privileges within the virtualization system [157]. Once inside the system, they can navigate between the virtual resources and launch multiple attacks (e.g. exfiltration, manipulations, overflows or passive analysis). Similarly, malicious VMs/containers may also escalate privi.leges to extend their capabilities and attack other legitimate virtual re.sources of the system ; for example, by exploiting the virtual channels with connection to the shared hypervisor memory or to the virtual network inside the hypervisor host [158,172]. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Rogue virtual resources [T3.3]: Insiders with the ability to escalate or abuse privileges could access the server hosting the DT to insert mali.cious virtual resources (e.g. VMs/containers), clone legitimate resources or replace the existing ones with malicious resources. The aim is to take control of a part of the DT model contained in a virtual resource or to take control of the entire DT system, including the physical space. Thus, rogue virtual assets may serve as a springboard for attackers seeking the means to carry out transitive threats between the two DT spaces (from the digi.tal space to the physical space). The work in [176] describes a way to load rogue virtual resources in a computing device and the protection measures against them by verifying the integrity of all SW components. The work in [172], on the contrary, adds several attacks derived from a rogue VM, such as isolation of legitimate virtual resources, virtual IP/MAC spoofing for loss of confidentiality, or traffic manipulation in a virtual network. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R3.2.1, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2, R6.1 (AIC) and R6.2 (L). • Extraction of private information [T3.4]: Malicious virtual resources may extract information from the system host where they are running, and information from other virtual resources running on the same host. For example, the work in [177] shows how to extract private keys by launching a cross-VM side-channel attack. Similarly, malicious hypervisors may not only be able to take control of the VMs running the DT’s services [178], but also to execute introspection techniques. As indicated in [179], a hy.pervisor may execute VM introspection (permit a VM to observe another VM’s memory at runtime) or allow the hypervisor to eavesdrop the activ.ities of all the VMs and steal sensitive information. Moreover, this way of analyzing traffic can also lead to passive analysis as in [T1.4] and [T2.4], but this time among traffic generated by digital models. The main operational requirements that may be affected are: R6.1 (C) and R6.2 (L). • Virtual resource tampering [T3.5]: As in the case of rogue virtual re.sources, adversaries with the ability to control the host system that con.tains the DT’s logic, or part of it, could manipulate sections and actions of the digital assets by compromising their VMs/containers and the hy.pervisor [179]. For example, they could switch inputs and outputs to corrupt the fidelity level between spaces, desynchronize VMs/containers to impact the interconnection of the digital models, create channels to exfiltrate intellectual property to external entities, inject logic bombs to carry out multiple attacks , and saturate shared HW resources such as CPU, cache and memory. Clearly, the consequences of this attack can have serious repercussions on the continuity of DT services (Layers 2-3), and on the data display and accessibility to the end-user (Layer 4). The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AI). • Man-in-the-middle [T3.6]: When VMs/containers need to migrate from one server to another, or replicate their operations at different locations within the system, MitM actions can emerge. This occurs when these oper.ations are carried out through a network infrastructure where adversaries can arbitrate or modify the virtual resources before they are installed on the target node [180]. This last node would include the malicious virtual instances through which adversaries could perform other subsequent at.tacks, the consequences of which would be similar to those discussed in [T2.6]. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.2.2, R3.3, R4.1, R4.2, R5.1, R5.2, R6.1 (AIC) and R6.2 (L). • Denial of service [T3.7]: Any malicious virtual resource (including the hypervisor) can demand additional resources from the server where the DT is deployed [168, 181]. This threat is designed to cause significant overload in terms of communication, computation and storage, such as memory overflow, massive request for HW resources and for connection with other related VMs, etc. Nevertheless, the impact of this threat may vary depending on the DT’s level of (de)-centralization. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.2, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (A). • Privacy leakage [T3.8]: VMs and containers can connect to the DT’s databases to handle large data volumes associated with the digital and physical assets (e.g. for online cyberdefense, predictive maintenance). If access to these virtual resources is not adequately controlled through strong authentication and authorization mechanisms and through se.curity controls that follow least privilege principles and under regulatory frameworks, multiple attacks against an entity’s privacy can occur, even if these databases are encrypted (as detailed in Section 4.2.3). In addition, VMs, containers and hypervisors are normally interconnected in a com.mon space, allowing malicious resources to analyze the information flows as detailed in [T3.4] (e.g. through a cross-VM side-channel attack [177]), in order to locate the most critical virtual resources or derive conduct patterns. That is, by observing data flows and the execution of digital models, attackers can deduce tracking times and cycles between physical assets in the real world, routine activities on machines/robots, activation times of sensors and actuators, types of protocols (for example, by the size of the packages, cf. Sections 2.1 and 3.1), etc. The main operational requirements that may be affected are: R6.1 (C) and R6.2 (EL). 4.2.3 Computing techniques In this section, we explore techniques to compute digital models and data. In this case, the techniques range from intelligence algorithms, such as ML applied for prediction and learning, to representation tools of DT models used to char.acterize states and properties of physical assets. All of these resources make use of SW components and large volumes of data, the processing of which is part of the big data life-cycle: data collection, data storage, data analysis and knowledge creation. The first two have already been addressed in Layers 1 and 2, correspondingly, while the last two are discussed in this subsection. • SW attacks [T4.1]: Digital models are an exact SW copy of their physi.cal counterparts, containing specifications (e.g. in AutomationML, STEP, STEP_NC), APIs, libraries and source codes. Without a rigorous testing and validation process in terms of design, implementation or adaptation of components (e.g. third-parties’ SW pieces), security risks can increase due to bugs caused by bad practices or the cloning of vulnerabilities when copying the SW image of the replicated physical components (note that this cloning has consequences equivalent to [T3.1]). Moreover, the lack of confidentiality, integrity and access control standards for digital models and their formats (e.g. XML-based AutomationML compatible for var.ious CAD tools) also increases risks. Brenner et al. assert in [182] that standards and access control mechanisms are still needed to protect the granularity of critical data, especially in AML-based models. For the pro.tection of these models, the authors also provide a three-level access con.trol mode based on encryption and signature schemes. The work in [183], on the contrary, presents a role-based access control (RBAC) scheme for AML-based designs executed under OPC-UA communications. As for modeling and representation tools, most of them are still suscepti.ble to malware as specified by the Trend Micro in [137]. CAD files, acting as the digital blueprint for physical assets, are somewhat vulnerable to Trojans, since the AutoCAD software includes Visual Basic for Appli.cations (VBA) macros. Infected macros may hide relevant information, modify/disrupt digital models or allow adversaries to escalate privileges within the system. Some real cases have already emerged [137], such as the ACM_MEDRE.AA. This CAD malware aims to corrupt personal data files corresponding to Microsoft Outlook and CAD files, which helps at.tackers obtain information not only about the design of a physical asset, but also about the entities working on the targeted HMI. The Trend Micro report also reveals the ease of applying CAD files that may conceal open source intelligence techniques to further foster competitive intelligence and industrial cyber-espionage. Thus, the modeling and implementation phase of a DT’s digital models are critical, where it is relevant to protect access to DT domains, and especially in their corresponding SW elements, as also pointed out by Gehrmann and Gunnarsson in [102]. This feature may be even more relevant in those DTs designed for predictive maintenance or cy.bersecurity. Rates of false positives or negatives can increase significantly if models are not properly protected and tools properly tested. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R2.1, R2.2, R3.1, R4.1, R5.1, R5.2 and R6.1 (AIC). • Extraction of private information [T4.2]: Attackers can get sensitive in.formation from the training data and the learning models. This aspect is outlined in [184], which describes how ML models can provide information with respect to a set of training data samples. Essentially, they determine whether a specific record has been applied as part of a training database. This inference of information, known as membership inference, presents certain differences with respect to an inversion attack. The latter threat aims to extract the input information of an ML model or the features of such a model. Hence, the success of inversion depends on the degree of access to the APIs corresponding to the existing ML models [185]. In that case, an attacker can derive sensitive information by: (i) directly accessing the ML model applied and any additional information required (a white-box attack); or (ii) downloading the corresponding model using open APIs together with some information gathered after feeding the in.puts (a black-box attack). This also means that once attackers gain access to the target model and its description, they may be able to apply reverse analysis to infer private data. It should be noted that if these threats are carried out on DT-based applications, the consequences can be devastat.ing, especially since DTs often handle ML models for multiple purposes, whether for autonomy, learning, prediction or detection. The main operational requirements that may be affected are: R6.1 (C) and R6.2 (E). • Privacy leakage [T4.3]: The previous point shows that ML models are susceptible to the extraction of sensitive data through inversion attacks, opening the door to the violation of privacy rights of both the organiza.tion and its customers. Here, adversaries may apply reverse engineering to estimate or project new DT states, extract logistical plans and identify vulnerabilities, among other issues. This feature becomes more relevant when the system produces large volumes of data and uses big data tech.niques with ML algorithms, whose data collectors are able to store such volumes for a long period of time (e.g. edge data centers). In contrast, DTs can also be designed to prevent privacy leakage in industrial contexts such as the one proposed in . The authors describe a privacy-enhancing mechanism based on a DT for the automotive industry. This DT is able to canalize (analyze and correlate) private data, using location-and tem.poral behavioral ML models to generate privacy parameters and detect possible leaks and anomalies. The main operational requirements that may be affected are: R6.1 (C) and R6.2 (E). • Data tampering [T4.4]: Beyond the SW exploits seen above, which un.doubtedly affect data quality and management in critical contexts, there are other issues that also affect the fidelity and granularity of such data. According to Poltavtseva et al. in [186], serious vulnerabilities can arise when data streams are transformed throughout their life-cycle without clear access controls to their structures, as also stated in [182] and [183]. In these circumstances, adversaries with previous knowledge of these prob.lems may, for example, prioritize their attack strategies to damage data consistency in terms of fidelity and granularity, and consequently affect the final knowledge. The main operational requirements that may be affected are: R5.1, R5.2 and R6.1 (I). • Knowledge tampering [T4.5]: This threat is related to the previous one, but with a strong focus on the dataset that provides a more detailed un.derstanding of reality. According to Liu et al. in [185], adversaries with the ability to interfere with a dataset can alter the quality of the classifica.tion both in the training phase and in the testing or inference phase. The most notorious threats in the training phase involve injecting malicious samples to generate invalid labels and change the distribution of training data (known as poisoning attack [187]) or directly modify the label values (e.g. through a label contamination attack [188]). In the testing or infer.ring phase, however, adversaries aim to exploit the vulnerabilities of the training model, regardless of whether the training data is protected with high confidentiality. The goal is therefore to corrupt the retraining phase by producing malicious samples or reproducing legitimate samples (known as impersonation attack [185]) to consequently redirect the classification or create invalid labels. The result of the threat would correspond with a high rate of false positives or negatives in the classifiers, and an impact on their accuracy. The main operational requirements that may be affected are: R5.1, R5.2 and R6.1 (I). • Representation tampering [T4.6]: Any deviation caused by malware (see [T4.1]) or deliberate disturbances by insiders with abuse of power or esca.lation of privileges (also see [T4.5]) consequently affect the final represen.tation of the data to the end user, such as human operators. Therefore, this threat can be seen as the result of previous threats, mainly focused on changing the fidelity and granularity of digital models and their data. The main operational requirements that may be affected are: R5.1, R5.2 and R6.1 (I). 4.3 Threats at Layer 4 Layer 3 representations are accessible through various HMIs (see Section 2.2) so that end users can draw their own conclusions and make decisions about the physical assets of the system. This also means that through these interfaces, human operators may also be able to interact directly with the physical assets in order to change their behavior. In light of the above, this section focuses on HMI threats corresponding to Layer 4 of a DT, which are as follows: • SW attacks [T5.1]: HMIs are systems mainly supported by SW compo.nents (e.g. OS, applications and dashboard services) capable of manag.ing and displaying results, and interacting with the physical space, data centers and external infrastructures/systems. The latter characteristic makes them particularly susceptible to penetrations and malware infec.tions, which, in turn, lead to multiple types of threats. These threats can vary significantly, for example: (i) producing overheads to disrupt or delay Layer 3 representations; (ii) modifying the level of fidelity and granularity of such representations; (iii) altering specific HMI configura.tions to complicate extensibility and update processes; or (iv) exfiltrating data, among other security issues. Specifically, these security concerns are detailed in [146], but with a particular focus on AR technology. One of these issues may be related to malware, for example, where adversaries can extract physical asset positions and relevant site information by turn.ing on embedded HMI cameras to consequently violate the organization’s privacy. Likewise, relevant information leaks can also occur during main.tenance processes. HMIs are systems typically maintained by third par.ties, such as suppliers and manufacturers, who may have full access rights to private information to (remotely/locally) carry out maintenance tasks. If these accesses are not properly controlled from the HMI, any informa.tion about product designs, production plans or distribution plans, among other aspects, can be revealed, including security credentials to access the virtual plane or physical space. The main operational requirements that may be affected are: R1.2.2, R1.2.2, R1.2.3, R3.1, R3.3, R4.1, R4.2, R5.1, R5.2, R6.1 (AIC) and R6.2 (L). • Rogue HMIs [T5.2]: Insiders with full rights to access the IT or OT do.mains may insert, replace, configure or clone HMIs with a connection to the DT. Through these rogue devices, they may, for example: (i) modify or disable the inputs/outputs values from/to the connected DT; (ii) alter the final data representation in the HMI to conduct invalid conclusions; (iii) block or hinder maintenance of HMIs; or (iv) exfiltrate information to other illicit sources. In [189], the authors demonstrate the influence of a rogue engineering workstation on S7 Simatic PLCs, which impersonates an HMI to later inject malicious messages and execute operations on the control logic. The main operational requirements that may be affected are: R1.2.1, R1.2.2, R1.2.3, R3.1, R3.2.1, R3.3, R4.1, R4.2, R5.1, R5.2 and R6.1 (AIC). • Visualization tampering [T5.3]: As mentioned above, adversaries with the ability to modify specific HMI settings and services may also modify the final visualization of the Layer 3 representations, as also stated in [146] but with a particular focus on AR. Adversaries may, for example, hide information, show erroneous or inconsistent data, or change the data integrity (e.g. C&C instructions). An example of a deception attack can be found in [190] and [154]. The authors demonstrate how to fool an HMI by stealthily changing the PLC register values to zeros, causing the HMI to present a different reality and forcing the worker to make an incorrect decision. The main operational requirements that may be affected are: R4.1, R5.1, R5.2 and R6.1 (AI). 4.4 Summary & discussion In the previous sections, a set of threats has been identified according to the four layers of functionality defined in Figure 2 (which comprises the three spaces of a DT), and according to the current technological trends developed in these layers. The effect that these threats can have on the operational requirements of a DT has also been explored in order to understand the degree of criticality that the paradigm can have in particular crucial scenarios, such as industry in general. Table 2 summarizes the above-mentioned effect, showing how operational requirements [Rx.y] are affected by threats [Tx.y]. For example, a threat re.lated to the SW exploitation ([Tx.1]) may involve: (i) change in the operational performance of the DT due to overheads [R1.2.1, R1.2.2, R1.2.3]; (ii) desynchro.nization of counterparts or connectivity problems [R2.1, R2.2]; (iii) difficulty for adapting new SW components (e.g. plugins or security patches) to the existing ones, or carrying out upgrade and maintenance actions [R3.1, R3.3, R4.2]; (iv) inaccessibility to required resources [R4.1]; (v) changes in the integrity of the represented data [R5.1, R5.2]; and (vi) security problems related to AIC (as also depicted in Table 4). 38 Table 3: Effect of threats on security and privacy Threats Risks A I C E L [T4.2, T4.3] . . [T2.9, T3.8] . . . [T1.4, T2.4, T3.4] . . [T4.4, T4.5, T4.6] . [T1.5, T2.5, T3.5, T5.3] . . [T1.7, T1.8, T2.7, T2.8, T3.7] . [T1.6, T2.3, T2.6, T3.3, T3.6, T5.1] . . . . [T1.1, T1,2, T1.3, T2.1, T2.2, T3.1, T3.2, T4.1, T5.2] . . . Two relevant conclusions can be drawn from Table 2. First, the threats that may have the greatest impact on operational requirements are those related to the deployment of rogue components ([T1.3, T2.3, T3.3, T5.2]) followed by MitM ([T1.6, T2.6, T3.6]), SW attacks ([T1.1, T2.1, T3.1, T4.1, T5.1]) and (D)DoS attacks (T1.7, T2.7, T3.7). For the latter, the impact will be higher or lower depending on the type of DT deployment: the more decentralized, the lower the risk of bottleneck or exhaustion. Second, almost all threats have some influence on the final consistency of the data, either in terms of fidelity [R5.1] or granularity [R5.2], which demonstrates once again the great weakness of DT technology in critical contexts, where high accuracy in data handling is essential [191]. Additionally, Table 3 includes the threats that affect the security of a DT in terms of availability, integrity and confidentiality, as well as privacy (entities and location). This table shows that threats to confidentiality have the great.est impact. The reason is that digital models represent an exact copy of the physical counterparts, thus requiring greater protection of intellectual property. This protection must even be treated as a priority in critical systems based on DT since the consequences of an attack can be devastating and sometimes irreparable, mainly due to the bidirectional communication between the phys.ical and digital spaces. In fact, Table 4, which shows the cascading effect of threats on the functionality layers. For example, a threat [T1.1] in Layer 1 may involve a synchronization variation that implies significant changes in the final management of the digital models included in Layers 2 and 3, with relevant impact on the final representation of the DT (Layer 4). The table also reveals that Layer 1 (included as part of the physical space) is the most affected layer due to the bidirectional link between spaces. This issue is considered in [130] too, where the authors highlight the potential implications of DT technology Table 4: Cascading effect of threats on funct. layers Threats Layers 1 2 3 4 [T1.4] [T5.3] [T2.4, T3.4, T4.2] [T2.9, T3.8, T4.3] [T1.1, T1.2, T1.3, T1.5, T1.6, T1.7, T1.8] [T2.1, T3.1, T5.1, T2.2, T3.2, T2.3, T3.3, T5.2, T2.5, T3.5, T4.1, T4.4, T4.5, T4.6, T2.6, T3.6, T2.7, T2.8, T3.7] : affects the physical and digital asset : only affects the physical asset : only affects the digital asset for cybersecurity. They also address the security risks involved when malicious entities succeed in accessing the digital space to learn about vulnerabilities and attack physical assets. In summary, our study has shown not only the impact that DT threats have on operational requirements, but also the risks that the technology can generate in critical scenarios. This can even create a high degree of mistrust in the deployment and use of this new paradigm if appropriate security approaches are not designed and implemented in the near future. For that reason, the following section explores how to protect DT-based systems in order to create secure and trusted environments. It must be noted that we present only an initial exploration of such approaches, as a more detailed analysis will be part of a future work. Exploration of security approaches There is already a number of research works focusing on protection-related rec.ommendations for the DT paradigm [102, 130, 192, 193]. Some of them also address security challenges that require further attention from the scientific community. Based on that previous research, and inspired by the holistic tax.onomy for cybersecurity research domains in [194], this section explores secu.rity approaches that are needed to enhance the protection of DTs and their deployments in critical sectors such as energy, healthcare, transportation, and manufacturing. Some of those approaches have a strong technical nature while others are more closely related to security management and procedures. The first ones cover those aspects that are more specific to the protection of DTs and their deployment, such as hardening of DT infrastructures, detection and mitigation of intrusions, etc., while the second ones are associated with good practices for using the paradigm within an organization, such as governance and human aspects. 5.1 Hardware and software security The interconnection between DT models, as well as between elements of Layer 1, may unfortunately add security gaps that usually originate from HW/SW vulnerabilities, as outlined in [102]. These vulnerabilities may be due to a particular lack of an appropriate design (security-by-design) or inadequate val.idation, especially in the case of third-party resources. In view of this, it is widely recommended to design approaches that: (i) ensure a root of trust from the HW (e.g. by using a trusted platform module (TPM) or a trusted execu.tion environment (TEE)); (ii) provide secure programming and good practices; (iii) establish security design patterns; and (iv) force verification processes and testing (e.g. frequent remote attestation in OT devices or servers) [194]. In [195] Amoroso also lists the most recent advances in SW security and highlights the importance of detecting errors through maturity models, auto.mated inspections, run-time controls embedded into the execution environment, and the use of new AI techniques to detect masqueraded malware. Likewise, the work [192] addresses the importance of the SW security in DT systems, recom.mending the use of data parameterization approaches to detect manipulations or deviations in the results obtained in each space. 5.2 Hardening of DT infrastructures and decoupling There is a particular need to protect the infrastructures that make up the DT it.self, involving networks, servers and virtualization systems. In this case, defense in depth constitutes the basis of approaches for protecting DT systems and, in turn, requires incorporating security mechanisms to protect access to digital assets (e.g. AutomationML specifications), as also outlined in [182] and [183]. As a first line of defense, isolation and segmentation could be good ap.proaches to bring about the decoupling of simulation functions from illicit or external access [99, 102]. To carry this out, firewalls, proxies, diode commu.nication, virtual networks (e.g. virtual private networks, or virtual local area networks to limit the broadcast), secure interconnection devices (e.g. switches and routers), good practices (e.g. closing ports), intrusion detection/prevention systems (IDSs/IPSs) and deception mechanisms, would serve as the primary defense elements. Due to the relevance of these last two mechanisms for the dynamic management of intrusions in DTs, we focus on them in Section 5.4. On the other hand, the configuration of such mechanisms and their efficiency depend on how and where they are set up and who manages them. For example, DT services spread across the entire computing infrastructure (cloud, fog, edge) may be managed by different network administrators under different security policies. They may also be deployed in different OT domains, or be maintained by third parties. For these reasons, it is also essential to pre-establish access limits and the degree of trust of each entity interacting with such DT services. Similarly, virtualization systems (virtual networks, VMs, containers and hy.pervisors) must be protected [171,172] following isolation principles (in terms of tasks, registers or memory), privilege separation and monitoring. Some of these monitoring actions could include controlling the commands to the host processor, supervising the hypervisor memory management, and protecting the computational domains of the VMs and their functions. In Section 3.2, we also discussed the fact that DT connections at Layer 1 and digital assets at Layer 3 must coexist with the environment in which they are deployed, i.e. [R2.1]. However, this coexistence requires not only understanding the communication protocols and their QoS, but also understanding the type of security that these protocols implement. Therefore, the digital thread be.tween spaces and the communication channels between digital assets in the vir.tual plane must be protected, without violating DT’s operational requirements, such as [R1.2.2, R2.1, R2.2]. In view of this, it is essential to use cryptographic lightweight approaches [99,160,193,196], and to adapt low-latency security pro. tocols such as TLS 1.3 and QUIC. A comparative study of these protocols can be found in [197]. This work discusses some of TCP security weaknesses (in terms of availability issues), and highlights the capabilities of QUIC to improve performance and security in terms of authentication and integrity in message exchanges. Last but not least, security hardening also means constantly monitoring the actual usage of DT resources, especially those deployed at Layers 1 and 2, so as not to overload the operational performance at both layers (i.e. respecting the criteria of [R1.2.1, R1.2.2, R1.2.3]) while ensuring QoS and synchronization between spaces (i.e. [R2.2]). Note that all these security approaches can equally be applied to Layer 4 communications, with access from multiple heterogeneous external sources [74,75]. 5.3 Identity, authentication and authorization As we have seen so far, DTs are complex systems that characterize real-world physical assets and networks, and comprise interfaces and processes, all inter.acting with each other to achieve a common goal (cf. Sections 2 and 3.2). This kind of coexistence, especially for dynamic environments, requires: (i) data authentication in the communication space ; and (ii) the (federated) man.agement of unique identities, not only in the physical space but also in the digital space [124]. Through these identities, it is possible to map the elements of the entire ecosystem, identify owners [95, 198] and guarantee mobility and authentication. Without such management, multiple interfaces, including the external ones, might indiscriminately act against the system. For that reason, authentication together with access control measures and perimeter security (corresponding to Sections 5.2 and 5.4) constitute the DT’s first line of defense. A DT can add an authentication approach in a local service outside the OT domain or rely on an external one established somewhere at the edge (e.g. in a cloud server as proposed in [102]). This service would force entities to verify their access from the IT domain, further protecting the underlying operational infrastructure. Depending on the size of the application context and the use of DT, federated systems may also be necessary. A specific case, for example, could be scenarios based on distributed DTs with collaborative relationships for cyber threat intelligence (CTI), in which DTs could share a database of vulnerabilities and/or attacks . Authorization approaches are also needed mainly because multiple and het.erogeneous entities may request access to restricted DT resources [75, 124]. These resources can range from IIoT/CPS devices to servers, digital assets (e.g. models, VMs, containers), databases, training samples, operation systems, etc. If access to these resources is not adequately protected or access restrictions are not established through access control policies, any entity can exploit this shortcoming to escalate privileges and compromise existing resources, as we also highlight in Section 4. Authorization schemes are therefore essential, and are also considered in the DT implementation methodology given by Greyce et al. in , the DTwins design in [199] and the recommendations in [102]. From a scientific point of view, there are already several approaches that control access rights and privileges in critical systems [200, 201], such as the combined use of RBAC with attribute-based access control (ABAC) [196] or the use of the security assertion markup language (SAML) [102]. In [102], the authors also mention that hyper-connected DTs may also require access con.trol frameworks based on standardized languages; e.g. using extensible access control markup language (XACML) to ensure the interoperability between so.lutions. These access protocols can be combined with decision and policy en.forcement points, whose decisions may depend on the application context. In fact, several approaches based on these points [200, 202] have already shown their feasibility for critical systems, and they can also be adapted for DT-based applications. 5.4 Deception, intrusion detection and situational aware.ness Security risks can arise if preventive approaches are not applied to detect intru.sion attempts and penetrations, mainly because DT technology contains impor.tant pieces of intellectual property that must be protected at all times. These risks may even be exacerbated when DT logic is not centralized, as any decen.tralization of virtualization systems and databases may involve large exposures, requiring specialized approaches for both deception and detection. On the deception side, advanced honeypots could be a suitable approach to protect access to critical OT domains, while allowing the organization to increase its knowledge of attacks and vulnerabilities in its own system. For example, a federated industrial honeypot is proposed in [203] to create and simulate real Modbus devices considering the capacities of the long short-term memory (LSTM)-autoencoder for the learning. Similarly, traditional and ad.vanced network-based and host-based IDSs with support for signature, specifi.cation, and anomaly techniques should also be integrated as part of any indus.trial network configuration approach [158]. Among them, anomaly-based IDSs are considered the current trend for OT networks (corresponding to Layer 1), mainly because specification and signature-based IDSs rely exclusively on pre.established attack databases [158]. If these databases are not properly updated, serious attacks, such as APTs, may occur within the system. This problem can be particularly noticeable and severe when DTs are added to the scenario. Advanced adversaries might first target the resources that are part of the digi.tal mirror to later attack the physical world [130]. For this reason, situational awareness is currently one of the most prominent and challenging fields of re.search in industrial ecosystems. Through situational awareness, the system is able to understand what is happening at all times and with a high degree of detail, explaining the intensity of the threat at a particular location, the areas and resources affected, and/or the impact between areas. In this sense, real-time traceability of attacks should also be part of the purpose. According to [204], the mere fact of detecting anomalies and tracing the origin of attacks in hyper-connected environments, producing and consuming large data volumes, adds a significant research chal.lenge that must be properly addressed to dynamically explain the advance of an attack. To date, the most typical situational awareness approaches are based on data collection, detection, correlation and visualization principles [204,205], but also on consensus-based principles . Consensus is a technique focused on dynamically delineating the degree of awareness per domain, either for a specific location or for several locations simultaneously. As part of the consen.sus, we stress the opinion dynamics technique. Rubio et al. recently showed the usefulness of opinion dynamics for IT-OT networks (and with respect to other similar approaches such as clustering [206]), testing the technique for real envi.ronments [131] and through game theory [207]. All these solutions can also be implemented in DTs, for two primary reasons. On the one hand, DTs are sys.tems composed of ITs in which the multiple sources, interfaces and connections may eventually lead to multiple types of anomalous events. On the other hand, these systems are usually coupled with highly demanding operational systems, further increasing the probability of exposure. Thus, IT administrators must be aware at all times of what occurs within the DT, and of what occurs between spaces and to what extent. 5.5 Response and recovery As Roman et al. state in , no paradigm is free from errors or completely secure, including DT technology. This creates a need to implement resilience measures capable of safeguarding simulation operations with guarantees of QoS and minimal deviations. However, these requirements will depend on the type of DT and on the operations it simulates. If physical world assets are part of the control of a critical infrastructure and the DT monitors the functions of these assets, then response and recovery are undoubtedly two priority security approaches needed for the deployment of DTs. Any threat risk or possible cascading effect within the IT domains (including the DT) has to be prevented to avoid any possible risk of propagation towards OT domains. Resilience is therefore a relevant protection area for the DT paradigm, and some practical recommendations can be found in [208–211]. More specifically, in [208] NIST identifies five protection areas, two of which are specific to re.sponse and recovery, whose focus is mainly based on contingency plans. In [209], Cárdenas et al. explore practical measures related to redundancy, segmenta.tion, rescheduling, reconfiguration and fault detection for critical environments; whereas [210] studies the inherent complexities of these approaches. To date, none of the existing solutions offers lightweight approaches with guarantees of protection in real time [212], where delays may result, for example, from the need to assess risks and find the most efficient response [210]. These problems can be even more serious in centralized DT systems with limited redundancy, where the primary actions of the DT can be disabled. Likewise, in [211] Nespoli et al. provide a comprehensive review of recent semi-automatic and automatic response approaches that can also be adapted to DT-based contexts and their IT platforms. 5.6 Event management and information sharing Events generated by DTs and associated IT platforms (e.g. CPS/IIoT devices, virtualization systems, protocols, etc.) can also be evaluated by security oper.ations centers (SOCs) to discover vulnerabilities, exploits and potential attacks (e.g. APTs) in the three spaces of a DT, including the digital thread. SOCs are, therefore, specialized systems overseen by cybersecurity experts in charge of monitoring security-related events, managing incident responses and coor.dinating forensics activities [213]. They can be based on security information and event management (SIEMs) systems to obtain a clearer picture and under.standing of security issues occurring within a DT. SIEMs are in charge of: (i) gathering information from different sources, such as DT logs and states, agents SW responsible for supervising DT activities [214], IDS/IPS logs, etc. (also see Section 5.4); (ii) normalizing and correlating events to discover vulnerabilities and intrusions; and (iii) notifying alerts and suggesting mitigation measures. Organizations can thus leverage the capacities of SIEMs to intensify proactive measures in DT systems and their environment, and increase their situational awareness of threatening situations. However, the effectiveness of these monitoring approaches also depends on the capabilities of their analytics (to extract, process and visualize trustworthy information in a timely manner) and response mechanisms to manage incidents and forensic information [213]. Through forensic techniques, it is possible to recover configurations, states and data, and preserve evidence in the future that associates the actions performed with identities (e.g. a DT model contained in VM/container, and the ID of the model or the logical IP of the VM/container). In this way, any suspicious action in a particular space or between spaces of a DT may be presented in court if necessary, as also stated in . However, depending on the DT’s level of decentralization and its use within the industry, various (online or offline) forensic techniques [174] can be applied under restric.tive conditions to ensure operational performance. One way to simplify this process can be to decouple the techniques from the operational environment and keep redundant data copies to facilitate the forensic processes. For data replication, DLT technology can be a suitable option to leave immutable traces of the actions taken by digital assets, and guarantee high data availability and transparency. In order to ensure proactive security approaches in DTs and increase situa.tional awareness, SIEMs and SOCs could also consider CTI procedures. Event management systems could, for example, manage shared information (e.g. at.tack vectors, vulnerabilities) belonging to computer emergency response teams (CERTs) (e.g. ICS-CERT [215] or Kaspersky ICS CERT [216]). If, in addition, there is the possibility of connecting several DTs from different domains, they could, for example, maintain a shared log of the latest threats and vulnerabil.ities along with their indicators of compromise, whether in terms of network, hosts, models or virtual resources. This information can even be shared across a DLT network [108], which can act as an internal CERT between federated DTs. 5.7 Trust management Establishing trust between collaborative components of a DT is fundamental for creating trustworthy environments. However, when applying trust measures it is also necessary to address aspects related to the attitude adopted by each DT component. By using trust controls (e.g. reputation schemes), it is possible to estimate the attitude of each component and thereby calculate the level of reli.ability and trust of the simulations. Any deviation in the simulation processes would produce a change in the trust placed in a particular DT component. For that reason, Sun et al. present a trust-based aggregation model for DT-driven IIoT scenarios [217], where the DT is able to capture the characteristics of in.dustrial devices and assist the federated learning. To control the deviations that the DT can produce in its estimations, a reputation value is computed in the model to detect deviations and increase the learning rate. However, implementing distributed or centralized trust approaches may, in turn, require a high level of computation and storage, since they usually need to compile past conducts and reflect them in the actual trust [191]. In this process, these solutions can also demand a significant exchange of information between neighbors to compute trust levels. Thus, one of the main challenges in this area is to seek lightweight approaches that give priority to avoid increas.ing costs that may impact the DT’s operational performance. Despite these inconveniences, however, the integration of trust mechanisms could improve the decision-making in the DT and facilitate the detection of anomalous conducts within its own system. To do so, the digital ecosystem must handle a reward or penalty mechanism in order to limit access to the physical world or update the use of its components. This feature can, for example, allow high-reputation dig.ital models to prioritize their computations to interact with the physical world if necessary, while low-reputation digital models would not be able to interact with the physical world or should be replaced. 5.8 Privacy Privacy leakage (in terms of data, location and usage) can take place in sev.eral ways. For example, the processing of large volumes of data using big data techniques without appropriate control over the use of these data can lead to sig.nificant leaks of relevant information, even if the data are encrypted. Through inversion attacks together with reverse engineering [185], attackers can derive operation modes (both of the digital space and the physical space), produc.tion procedures, product design, marketing or logistics (i.e. a threat [T4.2], see Section 4.2.3). For this reason, [199] and [218] underline the importance of con.sidering privacy issues in DT-based contexts, particularly the need to automate privacy profiles within the paradigm [199]. DTs need to be able to determine what information can be shared with other DTs or between services, offering different levels of granularity and access to that information. In addition, it is also essential to consider current privacy-preservation techniques, such as those described in the survey [185] of defensive techniques. The type of deployment and the level of access in DT computing infras.tructures, together with their databases, are also critical at this point, mainly because the attacker’s knowledge can vary significantly. Adversaries can in.crease their awareness by taking control of several computing subdomains and attending to their hierarchical relationships (edge . fog . cloud). They can, for instance, know or estimate where the most critical services are distributed within the DT. Part of the strategy may even involve a passive analysis of com.munication signals between IIoT/CPS devices at Layer 1 (e.g. [T1.6] in Section 4.1)) or between spaces in order to map the network topology and determine the location of the primary servers containing the DT components within the infrastructure (e.g. [T2.4, T2.6, T2.9] in Section 4.2). Therefore, it is also im.perative to adapt routing and randomization approaches (as indicated below) to protect the route information [191]. With regard to the usage of resources, the dynamic nature of the new in.dustries forces us to consider some other aspects in the approaches. Human operators, operational processes and CPS devices (e.g. robots) generally per.form the same operations following routine movements and actions (e.g. access to the same facilities, areas or resources), which allows adversaries to derive behavior patterns or the availability of resources or areas. If DT is applied following routine practices where human operators, processes and virtual assets have to carry out the same operations, the risks are similar. Thus, this situation poses the need to preserve the location and real usage of simulation services (at Layer 1-4) by means of location privacy and route protection (e.g. multi-hop routing, fake paths or random routing) together with anonymity approaches to protect the identity of the CPS/IIoT devices (belonging to Layer 1) and virtual resources (e.g. hide identities, apply pseudonyms, etc.). Nevertheless, Petroulakis et al. also recommend that CPS environments must intensify these approaches according to real privacy risk levels [219]. 5.9 Governance and security management Since DT technology is used in critical systems, organizations must consider protection measures based on defense in depth under legal, technical and or.ganizational procedures. These procedures must be considered throughout the DT technology life-cycle, in which protection principles must also be addressed for the environment where DT is deployed. It is thus essential to establish secu.rity controls under regulatory frameworks following standards and regulations applied at different levels, ranging from protection in the corporate network (safeguarding the DT from external access) to protection in the control net.work where the DT paradigm is generally deployed in industrial contexts (also safeguarding physical assets). In this regard, DT-specific standards, such as ISO 23247 [50,220–222], along with those available for the various enabling technologies (e.g. (I)IoT, CPS, cloud/edge computing . cf. Section 2) should also be broadly considered in order to cover the different layers of functionality of the DT paradigm. Besides, other recent international standards like the ISO/IEC 27000 family (for infor.mation security management systems) and ISA 62443 (for cybersecurity and resilience of industrial automation control systems) must be considered. In ad.dition, international organizations, such as NIST and ENISA (European Union Agency for Cybersecurity), also provide security recommendations, addressing, for example, cybersecurity issues for critical infrastructures [208] and for OT applications [54,223]. While all these standards and recommendations enable DT technology own.ers to carry out governance and security management approaches, there are other considerations that still need to be addressed, such as dynamic risk man.agement. The implicit complexities of industrial contexts and the new rela.tionships that the DT adds to that context create the need to automate the risk management processes to prevent potential threats (cf. Section 4). This requires automated security approaches, especially those related to: (i) mod.eling, assessment and analysis of vulnerabilities and attacks; and (ii) feedback processes to keep security controls, contingency plans and security measures up to date. This focus on automation can even be beneficial for those systems that integrate collaborative DTs , working together to accomplish a common goal or share information among them. The work in [102] also describes the impor.tance of keeping synchronized security parameters in DT environments, since different assets with specific security configurations must coexist in a common environment (see [R2.1] in Section 3.2). All these procedures must be part of the security policies that will make it possible in the future to control any access to DT systems and their correct use. 5.10 Traceability, auditing and accountability As mentioned in Section 2 and shown in Figure 2, DTs are composed of multiple layers and technologies (cf. Section 3.2) producing and consuming large data volumes. If these data are stored correctly, it is possible to track all the activi.ties, events and changes of DTs throughout their entire life-cycle. Additionally, if DTs are combined with DLT networks (see Section 3.1), then it is possible to ensure the immutability, replicability and integrity of such data [106,108]. Moreover, and as mentioned in [224], this method of tracing occurrences through decentralized databases may require approaches for: (i) data provenance tech.niques . to determine the origin of a problem between distributed databases; (ii) auditing . to clarify the actions taken by a DT system at a given time; and (iii) accountability . to identify the responsible DT in relation to a piece of data). The concept of traceability can also be applied for context-awareness, in order to explain the contextual states through which a DT (or a part of it) transits. These states can vary depending on the application context, where in.cidents, conflicts, anomalies or attacks can emerge and force the DT to change its state or behavior every time. Thus, any approach that fosters attack trace.ability can be a useful tool for the DT paradigm. As stated in Section 5.4, through consensus mechanisms [73,131,206], it is possible to learn in real time: (i) which DT or digital asset is behaving incorrectly or fraudulently; (ii) which areas are most critical; and (iii) how a threat is progressing within a DT sys.tem. This technical capacity can even promote self-awareness, where DTs can be aware of variations in their state and track them in real time. For example, the SADECEI-4.0 project [214] considers this aspect. Specifically, it evaluates the behavior of SW agents (in charge of monitoring the SADECEI-4.0 DT) by means of the opinion dynamics approach. Using these opinions, the system may be able to determine its state of health and identify malicious SW agents. Un.fortunately, this method of self-assessing behaviors is in its infancy within the field of situational awareness, and further research is needed [214]. It must be noted that traceability is a technique that allows other essential services to be implemented, such as auditing and accountability. These other two services are essential for clarifying the occurrence of an event that takes place within a system. In other words, auditing justifies an action at a given moment, and accountability identifies the entity responsible for that action. To guaran.tee these two services, it is necessary to have previously established a regulatory framework where security policies for DT systems must be included. Through this framework, organizations can: (i) identify security breaches during the au.diting process and impose accountability measures; and (ii) update actuation plans and regulatory policies such as maintenance policies, training programs or contingency plans. Moreover, DLT networks combined with DT technology can also be very useful. In [225], Mandolla et al. present a DT for additive manufacturing with connections to the DLT so as to certify the data produced in the process and monitor the whole production chain. In [226], Tozanli et al. address the blockchain for disassembled and product recovery actions consider.ing the predictive indicators provided by DT technology itself. In addition to these two works, there are others linking DT technology with DLT in terms of PLM [106,107,227–229], cybersecurity [108,196] and cyber-intelligence [230]. With regard to implementation, traceability (including data provenance), auditing and accountability present serious storage problems ([R2.1.3]) due to the large data volumes produced at Layers 1-4, and significant computational and communication overheads ([R2.1.1, R2.1.2]). Namely, the organization may need approaches to process information dispersed throughout the digital ecosys.tem that must be tracked in order to clarify the occurrence of an event. For example, different DT virtual machines located in different trust domains with the ability to generate frequent events may complicate auditing processes. In that case, an approach would be needed that processes large chains of related events, whose values may be distributed in several databases. 5.11 Training and the human aspects In the OT area, there is a particular lack of training, interest and education in the new ITs. Many stakeholders who manage OT systems have a very specific acquaintance of their environments, without delving into the suitability and security issues that ITs can provide. Similarly, IT administrators must also be aware of the need to protect OT domains and the risks that the connection between (digital and physical) spaces may entail. One way to foster learning in both directions would be through regular training programs under personalized and integrated educational methodologies based on cyber-range models [194]. In [231], Bécue et al. propose applying co-simulation modes through the combined use of cyber-range models and DT models to analyze the effect of cyber-attacks in production environments. Still, these models and programs depend on the DT used, the architecture deployed, the technologies and the models it integrates, as well as the information it handles, as also highlighted in [174]. When developing personalized training programs, automated activity con.trols (related to actions, decisions or behaviors) are recommended to determine the degree of know-how, competence and skills in the appropriate use of DT technology and the associated cybersecurity risks. These controls involve mon.itoring compliance with security policies and deploying reputation mechanisms to establish trust levels according to good practices, correct access and licit nav.igation between virtual resources, and the valid execution of C&C actions from the digital space, among other security controls. Depending on the actions and attitudes taken, an entity’s reputation can change to determine when and how the entity should undergo further training programs [232]. In the literature, this strategy is widely used to detect insiders, misuse or human errors, as also outlined in the survey [233]. Final remarks and future work A DT is based on the composition of technologies such as cyber-physical systems, the Industrial Internet of Things, edge computing, virtualization infrastructures, artificial intelligence and big data. The confluence of all these technologies when deploying a DT, together with the implicit interactions with its corresponding physical counterpart in the real world, generate multiple security issues that have not yet been sufficiently studied. This has motivated us to survey the potential threats associated with the DT paradigm, what has needed to take into account the conceptualization in layers of a digital twin. The reason is that each layer establishes a set of essential services provided by multiple interfaces, technologies and computation systems that, when integrated, entails serious security risks. For this reason, the survey that we have performed includes a classification of the threats according to those functionality layers and their corresponding technologies. Moreover, because a DT is a critical system that can be of great interest to adversaries, particularly when used in critical infrastructures, the fulfillment of its operational requirements must be considered in order to carry out more thorough and useful research into threats. In our work, we have analyzed the requirements included in previous research works of the literature while adding some new requirements that we believe are strictly necessary in the scope of new critical scenarios. At the same time, we have provided a new hierarchical organization of the whole set of requirements. Additionally, and in order to perform a more complete and satisfactory re.search of DT security threats, we have taken into consideration its four func.tionality layers, where the composing technologies reside, all of them prone to different types of attacks. As shown in the paper, Layer 1 comprises those phys.ical world control elements that feed back to Layers 2-4, which are responsible for synchronization of the DT models, as well as for simulation and representa.tion of the behavior of the physical counterparts. Threats at all of those layers have been analyzed, together with their impact on the operational requirements of the paradigm and the associated risks. Finally, and in order to initially address a scenario with the multiplicity of threats identified during our research, we have proposed a preliminary but useful set of security recommendations and approaches that can help to ensure an appropriate and trustworthy use of DTs. Some of those approaches have a strong technical nature while others are more closely related to security management and procedures. We believe that they are essential for future constructions of DTs, either for industrial or general-purpose scenarios, where it is advisable to find an adequate balance between security and operational performance of the DT. Next steps of our research will include a more detailed set of security ap.proaches as well as their specific mapping with the classification of threats that we have developed in this paper. Additionally, we intend to implement lightweight defense solutions that help to protect the DT and its deployment. Moreover, it is necessary to open a new line of research devoted to study how DTs can be used as effective tools to enhance the protection of other critical infrastructures, and hence propose particular online cyber defense approaches based on DTs.

My Take on Windows 8

Hi Everyone,

For the past few months i have heard a lot of heated arguments and reviews on Microsoft’s latest Operating system Windows 8. Here is what i think…..

I installed Windows 8 on my laptop as soon as Consumer Preview was released last year and found it less interesting. Lot of bugs and crashes, 2 days i moved back to Windows 7. 

So when MS released Windows 8 RTM  wasn’t interested much, even though i downloaded the ISO files it took me over a month to install it finally. Once installed i completely forgotten my primary boot partition(Windows 7). 

What has changed from consumer preview to RTM? MS was at its best, lot of minor tweaks bug fixes and performance improvement, really made the difference. 

Loving the performance improvement, awesome boot times, Type to search, app environment and IE 10;  inclusion of Hyper-v almost gave me goosebumps (people used older Microsoft solutions in desktop environment will understand this).

• Windows 8 is slick and seamless almost every corner, Microsoft had put really hard inputs to make the OS as much leaner as possible, and thus achieving the jaw dropping boot times and huge performance boost.
• Universal Search, although the implementation is not the best it is way more improved and categorical results allow more refined results. 
• Look at the Memory footprint, it is much lesser compared to windows 7 even with start screen with all the app loaded. My laptop running SharePoint 2010 Dev environment with SQL enterprise and VS 2012; yet i have not seen my RAM sucked up to 100%.
• WOW Finally, IE10 is the most advanced and the best IE ever released, it is quick, taunting Chrome and Firefox to do a catch up .. also huge move to finally address the open standards issues, better HTML5 rendering.
• New Windows Explorer had taken a lot of make over and improvements which allow better copy\paste, ability to pause the copy\paste in middle and ability to show multiple file transfer in a single window, ribbon’s revealing most hidden features of windows 7 to its base consumers.
• At enterprise level Reset and Refresh features helps resetting the system with out instillation or format or even refreshing the PC settings without any data lose. Happy  IT help desk team.
• Love or Hate the Dock to side ,having the ability to actually dock the chats or skype is really a nice add-on.

Despite all the above there are issues like mouse support, missing start button are present in Windows 8, does that affect you badly?

I would say no, as i spend 99% of time in desktop mode it really start screen doesn’t matter, i really liked the way APPs are arranged in the start screen.
it is easier to find, may be i feel little frustrated when i watch a move and need to open another app, new screen would kill the fun.

Removal of Start menu is also subjective, i like the implementation as my Mom can find the apps easier than going to start menu and finding it, and apps like messaging and mail helps her to be in touch with me easier rather going to browser then logging then sending a chat

Despite the little cons  i love windows 8, i find it really a great change to the future where touch screens will be a part of our life.

Big thanks to MS to think out of the box and succeeding in producing an absolute wonderful OS which allow us to think beyond present. 

As always Happy Hunting 🙂 

SharePoint 2013 Lab Server

SharePoint 2013 LAB server build..

Intel Core i7-3820 4 Core Boxed Upto 3.8 Ghz. Socket 2011

Asus P9X79 PRO

G.Skill RipjawsZ DDR3 1600 MHz 32 GB

Western Digital Caviar Green 1 TB

Corsair CMPSU-430CX CX Series 430-watt Power Supply

NZXT Source 210 Elite ATX

NOCTUA NH-L12 120MM & 92MM SSO BEARING PWM FANS CPU COOLER

2 X 500GB WD 7200 Sata III Raid 0

This weekend should be fun.. 🙂

SharePoint 2013/2010 Administration Training in Bangalore

Hi Everyone,

Are you interested in learning true SharePoint administration, not just the overview of SharePoint?
Have you ever wondered why the cost of training is so high and find out that you only learned the tip of an iceberg.. Here is a solution if you have…

From last few months I have been trying to recruit few SharePoint Admins for a company and found the “disturbing fact”, There are merely any good SharePoint admins available.

There are 100’s of SharePoint admins with no knowledge about how SharePoint really works. Everyone i interviewed had good knowledge on the application perspective, but the more non-application I went the less answers i got.

If i ask them an IIS puzzle or a Windows\DNS\AD\SQL everyone replies absolute nonsense.

Industry wants only capable SharePoint administrator in the upper ladder, others just ends up in to support functions.

Tones of opportunities are out there, do you want to make it to the top hiring list, you need to step up your knowledge… out of SharePoint, where the true admins hunts..

So i am thinking to spread the beautiful administration techniques and knowledge about SharePoint at a small package…

TOPICS

An in depth view on IIS
SQL magic
AD\DNS for SPADMIN
SharePoint 2010 administration and troubleshooting
ULSLogs, PowerShell techniques and tricks
This is my plan, so if anyone interested or think i miss something please add to the comments.

I will be covering migration strategies, capacity planning, upgrade, patch management and automation in SharePoint 2010/2013

For interested people will get a chance to work on my 2013 farm!!!

For details: Mail me (nj@outlook.com) or add a comment. [Only in Bangalore]

Happy Hunting 🙂

Name(required)

Email(required)

Rookie

Advance Topics only

Phone Number(required)

Submit

Δ

Scheduling automatic SharePoint Farm backup Using Powershell Script

Things to remember

1. Central Admin application pool account must have read/write access to the backup folder.
2. Your SQL Service account must have read/write access to the to the backup folder.
3. The Scheduling account should have elevated privileges.
4. If you’re running a farm backup from STSADM or Windows PowerShell, the account you’re running it as must have read/write access to  to the backup folder.
5. The location must be accessible from the SharePoint machine the backup is running on.
6. The location must be accessible from the SQL instance that SharePoint is trying to back up.
7. In the windows scheduler check the option “Do not store password” this is needed for authenticate to the UNC Path

Add-PSSnapin Microsoft.SharePoint.PowerShell
Backup-SPFarm -Directory \\ServerName\Share -BackupMethod full

Save as PS1 file, create  a basic task and add “Action” – Set to Start a Program.
Program/Script is “PowerShell”.  Add argument for your script (“C:\scripts\FarmBackup_full.ps1”)

Happy Hunting 

How to Clean up Crawl History in SharePoint 2010

Your crawl history can be a pain in the ass when the logs pile up..

SharePoint stores the crawl details in the following tables…

• “Msscrawlhostlist” table contain hostname with hostid.
• “MssCrawlHostsLog” table stores the hosts of all the URLs processed in the crawl.
• “MssCrawlUrlLog” table keeps track of the history of errors encountered in the crawls.

When you have not set the retention period it keeps around 90 days of crawl logs…

You could clean up the crawl logs for a shorter period using powershell…

Get the Search Service Application ID:

• Get-SPServiceApplication

Get the Search Service Application object:

• $searchSvcApp = Get-SPServiceApplication | Where {$_.Id -eq “Search Service Application ID”}

Set the CrawlLogCleanUpIntervalInDays property:

• Set CrawlLogCleanUpIntervalInDays.
• $searchApp.CrawlLogCleanUpIntervalInDays = Retention Period
• $searchApp.Update()

Hope it helps

Happy Hunting 🙂

SharePoint 2010 – ‘HTTP 500 Internal Server Error’ while trying to browse to a SharePoint site using Claims-based authentication {Event:8305}

Users will receive an error ‘HTTP 500 Internal Server Error’ while trying to browse to a SharePoint site using Claims-based authentication.

The following error message under the event viewer on the SharePoint server

Log Name : Application
Source : Microsoft-SharePoint Products-SharePoint Foundation
Date : <Date and Time>
Event ID : 8305
Task Category : Claims Authentication
Level : Error
Keywords:
User : domain name\username
Computer : servername
Description :

An exception occurred when trying to establish endpoint for context: An error occurred loading a configuration file: Either a required impersonation level was not provided, or the provided impersonation level is invalid.

CAUSE:

The Application pool account was missing the “Impersonate a client after authentication” user right.

We can resolve this issue by following this

1. Go to Start – Administrative tools – Local Security Policy – Local Policies – User Right Assignments – Impersonate a client after authentication properties
2. Add the Application Pool account for the site which is not working
3. Reboot the server, so the changes can take effect
4. Browse the site and it should work fine

Error Could not find stored procedure ‘proc_ECM_RetrieveTableNames’ while Creating Managed Metadata Service Application

Hmm…. Another error with managed metadata service application on a SharePoint 2010 server,

Error:
Could not find stored procedure ‘proc_ECM_RetrieveTableNames‘.

Troubleshoot issues with Microsoft SharePoint Foundation.

Correlation ID: <ID>
Date and Time: <DATETIME>

 

You will get this error while provisioning the MMS service…

 

Error occurs when we create MMS with a  pre-existing database (even a blank database) in SQL.

We need to recreate the managed metadata service application with a new database name.

 

Happy Hunting 🙂 …

SharePoint 2010 – ‘My Site’ link is missing!!!!

If you are not able to view “My Site” Link from any of the site collection just follow this…

Enable the ‘Social Tags and Note Board Ribbon Controls’ feature from Central Admin > Manage Farm Features.

Happy Hunting 🙂

SharePoint 2010 some users are unable to view items in the calendar

For my client many users are complaining that they are unable to view any items in calendar web part.

While browsing to the calendar you get an Error in bottom left corner in IE.
Timestamp: <Date and Time>
Message: Expected ‘}’
Line: 1307
Char: 463
Code: 0
URI:http://servername/sites/Lists/Calendar/calendar.aspx

Strange thing is that If the view is changed to Allitems view, items will be displayed.

Finally after a lot of troubleshooting and going through the ULS logs we found the answer.

The user account had an Apostrophe in his Email address!!!

eg:abc’s@contoso.com.

The resolution is to remove the Apostrophe 🙂

Happy Hunting..

 

Update: http://support.microsoft.com/kb/2405789 resolved the issue