Pentester’s View on “Digital Twins Technology”
Blog post 11 December 2020 by Willem Westerhof, Senior Security Specialist at Secura
A digital twin is a completely (or almost completely) digitized version of something that is normally a physical object, including the context in which that object is used.
A typical use case, for example, is predictive maintenance in industrial systems. These systems operate under great stress, and severe issues can occur if a system suddenly comes to a halt. By simulating the effects of physics and long-term strain on such a device digitally, it is possible to predict that after a certain amount of operating hours, specific parts need replacement.
Another typical use case would be a digital twin of a building, where it is possible to determine strain on specific parts of the building, figure out how much natural light is available within the building, determining what the most suitable locations are for “silence offices” or which departments should be close to one another, what the most efficient way of fire protection is etc. Furthermore, you can run various simulations on what the impact is if a specific scenario occurs, e.g.: if a fire starts in the west side of the building, what will happen?
What appears to have gone unnoticed by most, though, is that this digital twin technology can also be used to improve cybersecurity! Especially in those products and systems where a breach of cybersecurity can cause safety hazards.
From a cybersecurity improvement perspective, there are really two types of “useful” digital twins:
- Product Twin
- Ecosystem Twin
Product Twin
Creating a product twin is much like virtualizing software, but goes one step further: It also takes into account the operating context of the device. This is a huge advantage for performing security tests!
A typical example are automotive devices. While it is possible to test automotive software and hardware, you usually do so in a stationary or perhaps even engine-off vehicle. In reality however, the vehicle will be driving along the roads at medium to high-speed most of the time, and a hack of the device during this time will also be one of the most disastrous things to happen to the car (and its owner).
By creating a digital twin of such a product (such as a car) you can simulate the device driving a specific route, dealing with other traffic etc. while simultaneously attempting to hack it. Bugs that may normally go unnoticed - such as a small but potentially fatal delay in processing sensor input from sideways collision sensors - can then be found because the full context in which the device is operating can be tested as well. Another good example of this would be airplanes, or spacecraft devices, which are both systems you most definitely do not want to be hacking in the physical sense while they are flying somewhere, due to the risks involved if something goes wrong.
Furthermore, you can also test specific vulnerabilities in certain conditions. If you were to hack an industrial crane for example, and you can shift the counterbalance weight, it should not normally result in the crane falling over. But perhaps, under certain circumstances like heavy rainfall, a windy day or a heavy load attached to it, it will be just enough to make it fall over and cause serious damage to both people and property.
Besides the obvious improvement of finding serious issues and being able to test in a normal operating state, it also removes a lot of negatives from testing these products in their regular physical state. Intrusive penetration testing can sometimes break things or even crash systems permanently, and these types of devices aren’t exactly cheap to reinstall or reset to initial settings, whereas a digital twin can simply be reset to its original state.
Additionally the required overhead of getting clearance, going through all the check-ups, screening, daily walking through security checks and going on location etc. involved in testing this type of equipment can be minimized, since you can get a digital twin which you can manage yourself at your own office. Which, in the end, leads to both cheaper and more thorough penetration testing.
Ecosystem Twin
This is (and should be) a very broad term. Essentially, it is a system of systems that influence each other in a certain way. An ecosystem twin can get as small or as large as one can imagine. To name a few examples:
- The process of a product as it moves through a factory
- A smart building, with all sorts of devices inside of it.
- Power grids with autonomous responses to changes in supply and demand based upon sensor input.
- A city or nation with all its vital infrastructure systems.
- Which in fact really is an ecosystem of ecosystems.
This type of digital twin is best suited for impact analysis of a discovered vulnerability. It becomes possible to simulate what will happen if a DoS is caused on a particular system. What fails initially? What are the consequences? Does this have any cascading fall-out? For example a DoS attack on an air-conditioning system would typically be considered a medium risk issue. In the context of that air-conditioning system being the only system present in the server-room, and all servers starting to overheat and causing network failures, down-time, lack of access etc. it might however be considered a high or critical risk issue and something that should be fixed, or at least mitigated.
Another example would be, to determine attack surface. If someone is physically close to the building, which Wi-Fi/Bluetooth/Wireless technology can be attacked? Or after importing all your firewall rules, if an attacker obtains remote code execution on a specific system, which devices could he/she potentially have reached from the original point of infection? What is the impact of those systems being compromised and where are these devices physically in the building?
While these questions can sometimes be partially answered by questioning various experts within your organization, the answers are often no more than educated guesses. Especially in large or complex systems, it becomes extremely difficult to truly oversee the total attack surface and the consequences of a system failing or becoming compromised.
As an example, consider the following scenario:
A design flaw exists in a water sensor system, where the sensor data can be spoofed by an attacker and is always trusted by the central hub device. A patch has been issued to address this problem, but the device does not automatically update. One day, an attacker comes close to such a sensor, and starts to spoof the data, showing that excessive rains are coming in. The central hub trusts and forwards the alert and the ecosystem automatically responds by pumping the excess water onto floodable farmer field areas, to prevent flooding elsewhere. The farmer fields are ruined due to overwatering and in other areas problems arise due to drought issues, since the water was pumped away.
This example shows that a fairly insignificant or low CVSS score vulnerability can (when placed in context of the overall picture) have a major impact. Had impact analysis been done using digital twin technology, this problem could have easily been avoided and prevented in the future by taking mitigating actions such as:
- Patch the current sensors.
- Switch to multiple types of sensors to prevent full scale failures due to vulnerabilities in one type of sensor.
- Create additional automation to prevent faulty decision making
(e.g. a drought in one place and a flood in another close by, should
trigger some sort of alarm as it doesn’t normally occur)
The possibilities of access to such an ecosystem twin are not limited to only doing impact analysis of known vulnerabilities. It is also possible to use it as a tool for risk analysis and discover single points of failures, as well as overall design weaknesses (including weaknesses to zero day attacks) in the ecosystem. Furthermore, it might assist in determining which sections of the network should be pentested or which “flags” should be set during a red team engagement.
All in all, digital twin technology can really be used as an amplifier for an organization's security level, but of course, there are some pitfalls & dangers as well.
Common Pitfalls & Dangers of Using Digital Twins
First, and this may seem obvious to some, but you should at all times keep your digital twin secure and confidential. An attacker who has access to the digital twin of your organization, building or product can find all the information he might possibly need to try and hack you in the real world.
Second, the same principle applies that applies to all data driven systems: Garbage in = Garbage out. Either do it right, or don’t do it at all. And make sure that any advice or identified design issues are verified to be correct, by checking them in the field.
Third, if you’re creating product twins, you usually implement a lot of sensors on a live product first in order to figure out all the physics and individual things you should be implementing in your digital twin. That means you are also introducing a lot of attack surface to that specific product, so when implementing these sensors, require security in product selection.
To Summarize
All in all, digital twin technology is awesome, even for security, if you use it well. In practice it currently isn’t widely used for security, but we’re slowly starting to see some early adopters research (or even create Proof of Concepts for) the possibilities of using it for exactly this purpose.