In MIRANDA, the CDT concept goes one step beyond the bare usage of plain Digital Twins (DTs) for security purposes, which most papers in the literature still pursue. Specularly to the intended usage of DTs for physical systems, a CDT should support security operations (i.e., monitoring, detection, investigation, and response) by providing modeling and prediction capabilities of the evolution of cyber-attacks and the risk that potential threats materialize in the current or an hypothetical context in which the system operates. In our understanding, a CDT should map threat intelligence to the real system, to make hypothesis, perform analysis, and draw predictions of what could happen in the real system in a proactive yet not invasive way. It should leverage a bidirectional flow of information with security agents, including both monitoring and enforcement capabilities, which keeps synchronized the states of the two twins.

A CDT for DSCs must accordingly be designed to be holistic, adaptive, agile,  zero-trust, opaque and, most of all, safe. A holistic CDT must account for the presence of a broad heterogeneity of digital resources: physical devices; computing, networking, and storage infrastructures; software applications; data; processes. The latter do not have a direct cyber-physical counterpart, but correspond to human tasks – e.g., sending email, inserting data, locking doors.

One of the main challenge for a CDT is its adaptivity to the evolving context, both the operational environment and the threat landscape. This does not only require bidirectional exchange of monitoring/control data, but also entails discovery capabilities to automatically detect relevant relationships and changes in the real counterpart and to reflect them in the internal models. Agility is also required to effectively address the growing size of the chain, periodic load patterns  (e.g., daily, weekly, seasonal), and long-term trends. Furthermore, a zero-trust architecture is essential to support dynamic relationships between the different providers in accessing security-related interfaces and data. To avoid turning this prospected agility into a threat for both individual domains and the whole continuum, context and data must be made opaque to different providers, based on dynamic trust relationships built and reinforced at runtime. This will range from complete transparency of objects owned by the same provider to full opacity for untrusted providers, being the latter a negative factor in risk assessment procedures. Finally, a strong security- and privacy-by-design approach must be followed to avoid the CDT could become an attack vector itself.

The design of a CDT that models attacks and threats on DSCs should be based on two main capabilities:

  1. Context abstraction, which captures technical and functional properties of all interconnected systems, as well as the business and operational relationships that allow lateral movements between them;
  2. Attack modelling, which is used for prediction and emulation of attacks.

Context abstraction can be based on Service Context Graphs (SCGs) that describe: 1) identity and ownership of digital services; 2) the execution environment of each service, namely relevant software/hardware properties and configurations; 3) operational relationships and communication patterns between services; 4) known cyber-vulnerabilities and threats, collected from intelligence feeds; 5) Cyber-Security Functions (CSFs) available in each domain, their capabilities and controls.

Attack modeling should concern logical rules that describe how an attacker advances within the service chain (see the picture). These logical rules are enablers to adversarial lateral movement, which a defender is required to eliminate and nullify.

The modeling and prediction capabilities of the CDT underpin the implementation of advanced cybersecurity operations on the whole service chain. They include monitoring, detection, hunting, and response, which are made agile, automatic and adaptive. The main objective is to recognize on-going multi-step attacks, to predict potential attack paths based on the current service configuration and vulnerabilities, to identify the final target, and to tailor detection and mitigation/response actions to the current configurations (e.g., IP addresses, topologies).