Current practice to implement cyber defence is mainly scoped on vulnerability assessment rather than threat modelling, which includes risk identification and evaluation. This assumes a potential attack vector, an actor with malicious intent, and an opportunity to exploit an existing vulnerability [23
]. There are three main approaches to perform risk assessment: qualitative, quantitative, or a hybrid scheme incorporating the first two types. While quantitative risk assessment estimates risk based on a numerical estimation of probabilities, a qualitative approach could mark risk as low, medium, or high. Therefore, qualitative risk analysis is more suitable for recognising the wider implication of hazards, and can be demonstrated and modelled using Petri Nets that can be utilised to analyse risk. Petri Nets are developed based on the calculated risk metrics together with the process function of the ICS or SCADA systems. This analysis method emphasises finding the preconditions under which various modes of failure would occur. Additionally, it helps to determine the associated consequences for such failure. Hence, outcomes are crucial for decision makers in an ICS environment when developing and implementing policies related to risk assessment and governance [24
]. For a substantial evaluation of potential risk associated with the exploitation of vulnerabilities of an ICS, each system layer should be considered. However, the performance of the systematic procedures for conducting this assessment in a production environment can be limited by the criticality of the system to the strategic business continuity plan. As a workaround, testing is almost exclusively performed in testbeds or discrete laboratory environments.
3.3. ICS Architecture Layers
The architecture of the ICS is dissected into several layers to develop a specialised understanding of the overall system. This approach allows for detailed vulnerability assessment to be performed, which is inevitable to gain a better understanding of the problem and develop better cyberdefence techniques. The different layers of an ICS are demonstrated in Figure 2
. A layered ICS model was developed in Reference [25
] to look beyond vulnerability assessment to a holistic and more detailed approach. This helps to apply a defence-in-depth strategy that is especially useful since these layers contain interconnected functionality. Therefore, the consequences of exploiting an element within a layer affect others. For example, actual electronic components, such as microprocessors and microcontrollers, are represented within the hardware layer of a given ICS. This layer facilitates access (command and control) to all layers above. An accurate input/output process is therefore fundamental for the system to work. Threat modelling for actual devices recovers two main attack vectors: firstly, when the device is compromised by attackers while working in an ICS; secondly, when an actor in the supply chain (e.g., the manufacturer) deliberately compromises the device. Attacking an operational environment to target a device requires a lot of resources to perform the required level of reconnaissance and footprinting, in addition to building intelligence around the device and the system in which it operates [25
Attacks against the system’s integrity can occur at any stage, as early as the product-design, chip-manufacturing, or supply-chain stage. Spoofing attacks can involve the modification of the actual chip by altering Boolean gates, bridging wires, or inserting additional buffers. When a backdoor is deployed to allow remote access and elevate privilege, the term used to describe this attack vector is Hardware Trojan. This allows access to further confidential data, such as encryption keys. Remote access with elevated privilege gives the ability to maintain access by installing more malicious software. Denial of service is another threat, for instance, a time bomb could be utilised to degrade performance or disable the device. Attackers tend to adopt transparent techniques to cause minimal modifications and avoid Intrusion Detection Systems (IDS) [25
Side-channel attacks imposes another form of threat where small integrated circuits are attacked through wireless or power channels [30
]. These attacks exploit electromagnetic emanations or even acoustic vibrations to eavesdrop to information leaked from the device. Cryptographic algorithms can also be vulnerable to side-channel attacks by means of differential or simple power analysis. Some attackers manipulate selected values computed by the hardware component during normal operation by deliberately injecting errors. This is known as a Fault Injection attack and it aims to affect the performance of the device. Examples include tampering with environmental operating temperature, power supply, or even the device’s clock [25
The firmware layer is located between the hardware and software layers and acts as a bridge between the two. This layer supports the execution and functionality of compiled programmes. The low and powerful level of control at this layer makes it very attractive for attacks aimed at an ICS. An example of a prominent attack at this layer can be initiated by reverse-engineering the firmware; this attempt, if successful, recovers the underpinning code and provides insight into the core functionality of the device, including potential weaknesses and the opportunity to exploit it [31
]. Further, the attackers would usually search for protocols and authentication techniques that have not been properly designed or implemented. Another attack is buffer overflow if a relevant vulnerability is identified as a result of bad programming practices. Reverse-engineering firmware exposes the system to injection attacks of malicious code at a low level. Below, we describe three known steps to perform reverse-engineering [25
Firmware image acquisition: the attacker acquires a copy of the firmware code. Acquisition can either be a copy obtained directly from the manufacturer or by utilising the Joint Test Action Group (JTAG) testing port to extract the code.
Binary analysis: Techniques such as “binwalk” and binary differentials can be used by the attacker to learn information about the used encoding, file systems, and checksum values.
Binary disassembly: Further analysis, such as extracting and studying ASCII strings from the firmware, is performed to understand firmware functionality.
PLCs within an ICS environment are known to be a popular target. Therefore, it is recommended to have a policy to keep the running firmware on these devices patched and updated. Further to the benefit of closing all known security flaws, such a policy could reduce the number of existing bugs affecting the usability side of the software [25
]. That being said, there are challenges to be accounted for before planning or enforcing such policies. For example, some environments, due to reasons related to business continuity, are required to be running 99.999% of the time, which equates to a maximum downtime of under 6 min of per annum. This is problematic because firmware patches produced by vendors are regularly released and often require a device reboot. In practice, this is one of the factors to explain why patches are applied late, if applied at all, in a year’s time. Before the Internet era, there was an argument around the efficiency of implementing a security-by-obscurity strategy, where many organisations took their chances running unpatched software since vulnerabilities were not published [32
]. However, the way we are interconnected today and the new era of common vulnerabilities and exposure databases being regularly updated means that the probability of discovered vulnerabilities being exploited is a question of time.
The software layer contains the functionality responsible for translating human input and passing it through to the machine, and vice versa. Therefore, attackers on this level focus on HMI, and any available terminals controlling the ICS processes. The software can either be off-the-shelf (offered commercially to many clients) or bespoke and specifically designed for the ICS. This affects the type of attack vectors to assess; bespoke software is not widely tested while off-the-shelf and could open a wide range of attack surfaces, from kernel exploits, command injections, to known vulnerabilities reported by the professional community. HMIs and workstations on an ICS platform could also be exploited online via attacks on web browsers through Cross-Site Scripting (XSS), drive-by-download, malware, and other techniques. Additionally, the infamous zero-day exploits pose a prominent threat and can remain undetected to software developers for long periods of time [33
]. PLCs are also targeted because they are widely used in ICS and SCADA systems. The presence of numerous security implications at this layer was attributed to the complexity of the software running on PLCs, and the lack of highly skilled programmers working in this area and having sufficient training in cybersecurity. Attackers armed with the internal knowledge of the system can modify PLC operation. The Stuxnet worm is a recent and widely cited example of a cyberwarfare weapon exploiting a vulnerability at the software layer [34
]. Compromising the software layer gives access to the legitimate control flow of the ICS to alter underpinning technologies. Similarities between software at this layer compared to toolkits in a typical ICT environment provides opportunities to utilise existing tools, either directly or after certain amendments to perform reconnaissance, footprinting, and eventually gain access to the ICS. Freely available and extremely powerful penetration-testing toolkits include Kali Linux and ParrotSec [35
ICSs can be distributed across large distances, and such a design includes a central master system managing remote locations over several communication channels. The availability element is therefore critical, and mitigation against denial-of-service attacks becomes a priority. Attack vectors in this case depend on factors including the type of used pipeline-monitoring systems, signal (analogue and digital), and communication protocols. The protocols that the MTUs and RTUs share must be the same for the system to function, and it is possible to find existing implementations utilising governing standards developed prior to introducing the relevant International Standards Organisation (ISO) standards [36
]. Two widely used protocols in SCADA systems are Modbus and DNP3, and they both have numerous known vulnerabilities. Therefore, many bespoke protocols operating at the lower two layers of the above model are not published to add a layer of security, strategically known as security by obscurity. However, since security was not considered when these protocols were first developed, they remain insecure by design. Since the risk of a cyberattack continues to increase, next-generation protocols are developed based on common information models, such as IEC 61850, which improves security.
The process layer comes next in the ICS architecture. It controls the processing logic within the ICS and governs the limits that have been programmed into the system. Cyberattacks could modify variables related to the control logic that changes process states. This could halt the system (denial of service). To avoid detection, attackers ensure that no component is operating beyond its acceptable limits [25
]. The Stuxnet worm, which targeted a uranium-enriching plant in Iran, attacked the process layer. Stuxnet modified specific Dynamic-Link Library (DLL) files, and the attack vector is believed to have been a mobile storage device. The payload was able to manipulate the PLCs that controlled spin speed to eventually destroy several of the centrifuges. The vulnerability was within Siemens Step7 software that was running on Windows computers to program the PLCs. A rootkit was utilised to keep the infection hidden from system administrators for as long as possible [37