Digital twins are rapidly gaining popularity for the design and management of complex systems. The rise in availability of modeling tools coupled with continuous streams of real time data from live processes have turned the use of digital twins into a must for the system owner and operator.
But what is the twin in the hands of a potential hacker? Given that a Digital Twin is designed to be as perfect a replica of a system as possible, the twin now serves as a perfect blueprint of your system. Since the twin is generally a pure software emulation of the physical system, it is easily disassembled revealing your system design in its entirety. Once opened up, the hacker uses the twin to identify where the security vulnerabilities lie within the physical system and build a potential attack plan. Then, once a basic plan is developed, it is exercised against the twin and refined until easy entry is achieved prior to attacking the physical system. By simulating attack against the twin, the hacker doesn’t draw the attention of the prying eyes of the IT department until the attack plan is well baked.
Some digital twins may not attempt to model certain aspects of the system, in particular backend systems such as databases and the like. In lieu of replicating these, the twin may simply call into the actual production systems to enable this functionality within the larger system. Unfortunately, once a twin is disassembled these calls are also now exposed to the hacker providing detailed information about the API calls as well as any credentials required for access. In this scenario, instead of attacking the physical system, the backend systems become the target potentially creating an entry point into the larger corporate network.
So, what is the system designer to do? We have this excellent tool for system design and operation that is also potentially a threat to the system itself. There’s certainly no need to abandon the twin, however the twin and its security must be treated as an entity in and of itself. While designed as a virtual copy of the physical system, the twin may have additional vulnerabilities that the system itself does not have. In particular, system components may have hardware security protections built into them that are now represented within a purely software environment. These representations must be identified and hardened accordingly in order to secure the twin.
Software protection technologies are the perfect addition in order to harden these areas of code. Also, with backend API calls, the calls and credentials used can be protected using software protection to reduce the risk of exposure. Where hardware security was previously used for cryptographic operations and sensitive code in the physical system, software protection can now be used to secure within the twin. Because the digital twin simulation generally isn’t performance constrained, very high levels of software protection can be applied.
Of course, these issues are greatly reduced if the propagation of the clone itself is controlled. Strong copy protection technologies can be used to bind the twin image to a particular machine, preventing unauthorized copying (or ‘lifting’). These technologies have been used in various software implementations but are most effective when used with limited distribution software such as clones. This approach of course needs to be coupled with strong internal controls to make sure the machine doesn’t leave the facility, but it is assumed that this would be noticed if it occurred.
In summary, in the designer’s hands, the twin serves as a simulation platform for complex systems to verify their behaviour prior to deployment. In the hacker’s hands the twin not only reveals the complete solution architecture, it provides a platform to test complex attack plans. We frequently forget that any technology that makes your job easier can do the same for a hacker. Thorough ‘security in depth’ with software protection for your digital twin can help keep it from becoming your dreaded evil twin nemesis!