Trends in Cyber Security of Industrial Control Systems
As a result of commoditisation, industrial control systems (ICS) have become increasingly like the computer systems that run enterprises and are therefore exposed to the same cyber vulnerabilities. However, the solutions that have been developed for enterprise IT systems are not always appropriate for ICS because of additional constraints such as safety. This study reviews the current threat landscape, presents the anatomy of an attack on ICS and summarises some future trends.
Chris Hankin, Professor of Computing Science and Director of the Institute for Security Science and Technology, Imperial College, London
Not so long ago, the perceived wisdom was that most industrial control systems (ICS) were ‘air-gapped’ from the external world. This perception changed in late 2010 as detailed analyses of Stuxnet began to appear. Whilst the first version of Stuxnet was accurately targeted, a subsequent version was less so. By the end of 2010, Symantec reported that there were 100,000 infected hosts worldwide .
What changed was the increasing trend to commoditisation of ICS – the use of off-the-shelf digital components replacing specialised analogue devices. These off-the-shelf components have become increasingly ‘smart’, often containing fully functional computers. Rather than being connected via bespoke links, the components of an ICS are now more likely to be connected by Ethernet, Wi-Fi or Internet Protocol (IP) connections.
The main components of an ICS are one or more control loops controlled by a controller. The controller will be connected to a control room via a human–machine interface and, more than likely, there will be a way of connecting remotely to perform remote diagnostics and maintenance. The generic ICS can be represented schematically as shown in Fig. 1 (courtesy of NIST ). The components which interact with physical processes in this figure are sometimes referred to as Operational Technology (OT), in contrast to IT.
What has changed is that, even without the links to the outside world, Stuxnet is proof that every component of Fig. 1 is now a potential target for cyber attack. More often than not, the ICS will be connected to the enterprise IT system and a data historian to record process control data. The best current advice is to employ network segmentation and defence in depth to protect the control system as illustrated in Fig. 2 .
There may not be too many examples of attacks on ICS in the open literature, but the number is likely to increase. At the end of 2014, the German Federal Office for Information Security  reported an attack on a German steel mill that led to substantial damage to a blast furnace. The profile of that attack is likely to be a common pattern: the enterprise network of the company was compromised by a spear-phishing attack; at some point the attack was able to migrate over from the enterprise network into the ICS; and then the attacker was able to control the ICS and cause the damage. Subsequently, there was a widely reported attack on the Ukrainian power system in December 2015. ICS-CERT, which monitors incidents in the US ICS sector, is logging a growing number of incidents, with the energy and critical manufacturing sectors being the most affected by the 295 incidents recorded in 2015 . The general trend of ICS incidents reported to ICS-CERT over the last few years can be seen in Fig. 3. The majority of incidents in 2015 did not penetrate very far into the system; it is difficult to determine the infection vector for many of the attacks, but, amongst the 185 which can be determined, 109 of the infection vectors were via spear phishing.
Fig. 1 Abstract representation of an ICS
It is tempting to think that, given what we know about cyber security for enterprise IT systems, it should be possible to adapt our techniques to help protect ICS against cyber threat. Whilst this is true to a certain extent, it is important to recognise some subtle but important differences. For a start, the emphasis on CIA (Confidentiality, Integrity and Availability) is not so prevalent in ICS. ICS operators will almost certainly see availability as of paramount importance: their systems are often required to be operational 24/7. Data integrity is certainly a concern, but confidentiality is probably of less concern; of course, process control data is a valuable asset and if there is the possibility that it might be exfiltrated then this picture may change. Nevertheless, AIC might be a better acronym to reflect the concerns of ICS operators and, indeed, many will think in terms of reliability, maintainability and safety as being equally, or more important attributes for a system to have. Since data exfiltration may be less of an issue, attacks on ICS are more likely to be focused on sabotage (impacting on the operation of the system) rather than espionage.
Fig. 2 Defence in depth
A more extensive list of differences between ICS and enterprise IT systems include:
- Whereas the emphasis in enterprise IT may be on data processing throughput, the computation in an ICS places more emphasis on time critical response; ICS operators are therefore less tolerant of anything that might jeopardise this and, unfortunately, cyber security controls are often seen as carrying a performance penalty.
- As already observed, ICS are likely have to be in continuous operation. An implication of this is that maintenance sessions may be difficult to schedule. As a consequence, the most effective cyber security controls for enterprise IT, such as patching, are unlikely to be implemented in a timely fashion, if at all – patches may not be applied because of a fear of invalidating, and therefore having to re-do, the safety case for the ICS.
- The recommended configurations for enterprise IT architectures tend to concentrate the most valuable assets at the centre of the enterprise; in contrast, the edge clients in an ICS are likely to be where the really important work happens – this is where the system interfaces with the aspect of the physical world that the ICS is controlling.
- Which leads to another major difference: ICS are a type of cyber–physical system. There are complex interactions between the cyber and physical world which are not usually an issue in enterprise IT systems.
- We have already mentioned the perceived performance penalty of cyber security controls. The technical controls are also likely to consume memory and power – these resources are likely to be limited, particularly in the edge clients of an ICS.
- Legacy issues present a major challenge in ICS. Systems are often designed to run for 25–30 years or longer. At the beginning of 2014, many systems still using Windows XP were being deployed – whilst the operating system is no longer supported by the vendor, the ICS will still be expected to operate in a safe and secure manner in 20 years time!
- ICS can be dispersed over vast geographic areas with some of the components in quite hostile environments (e.g. remote desert locations). In developing strategies to protect ICS against cyber threats, we must take these requirements into account. A more comprehensive list of issues may be found in the already cited NIST publication .
Fig. 3 ICS incidents in the USA since 2010
Anatomy of an Attack
Langner  provides a detailed analysis of Stuxnet which complements the more technical analysis provided in . One of the key messages of Langner’s work, that is presented early in the cited report, is that the anatomy of attacks on ICS are generally rather different from cyber attacks on enterprise IT systems. This different anatomy arises from the shift in emphasis from espionage (data exfiltration) to sabotage. Langner suggests three stages. The first involves a compromise of the IT layer and might look very similar to a classical cyber attack (but see below). The second stage involves propagation into the ICS layer. Once in control of the ICS layer, the attacker can then proceed to attack the physical plant and create the intended damage. As discussed above, analysis of the ICS-CERT reports indicates that ICS attacks often start with spear-phishing attacks, although these may have been preceded by social engineering that has gone undetected. Spear phishing is often a component of an ‘advanced persistent threat’ (APT) attack. Analysis of APT attacks has led to the development of the Lockheed Martin Cyber Kill Chain® .
The development of the kill chain was inspired by the use of this parlance in the defence field and involves seven phases: Reconnaissance; Weaponisation; Delivery; Exploitation; Installation; Command and Control; and Action on Objectives. The first phase is where the attacker may employ social engineering to extract information about key targets for the potential attack, but may also use easily accessible information from social media sites and elsewhere. Weaponisation involves introducing the malware, which may involve some remote access tools, into an appropriate delivery format, for example embedded in a document that can be sent as an attachment. Delivery is potentially by spear-phishing e-mails directed at the targets identified in the first phase, but may be by a different vector, for example via an infected field engineer’s laptop or via a USB stick. Once the payload has been delivered it needs to be triggered; this could happen by the targeted user opening the infected document or through autoexecution of some code, for example. Typically, the Installation phase involves the installation of a backdoor or remote-access tools. The next phase establishes a command and control channel to a remote server under the control of the attacker; this gives the attacker direct control of the attacked system. The attacker is now free to use the command and control channel to achieve their eventual objectives, for example to steal data. Whilst some of the phases have been illustrated by reference to ICS, the main focus for the Lockheed Martin analysis was APT attacks on enterprise IT systems, so this corresponds to the first layer of Langner’s analysis.
This last observation has led the SANS Institute to develop an ICS kill chain . This involves two distinct stages, the first of which corresponds to the kill chain described above. The Action on Objectives phase is critical to prepare for the second stage and may involve lateral movement within the infected system and exfiltration of critical data about the ICS configuration.
The second stage is also divided into a series of phases as shown in Fig. 4. The Develop phase, as its name suggests, is about developing the attack on the OT – this may exploit configuration and process control data that was ex-filtrated during stage 1. It may take considerable time to develop the attack on the OT and there may be significant elapsed time between the two stages; this should be noted in the context of the ICS-CERT statistics, where most of the incidents are at stage 1 and there have been very few reports of full-blown attacks leading to physical damage. The next phase involves testing the developed code; a sophisticated attacker might be able to conduct such tests on a copy of the target system, otherwise this might be a more limited exercise. The ICS attack then consists of the next three phases: Deliver; Install/Modify; and Execute ICS Attack.
In the cited report, the SANS analysis is validated against two case studies. The first is the Havex RAT, which is one of the remote access tools used by the Dragonfly group  (also known as Energetic Bear). This group has probably been responsible for the high incidence of reports from the energy sector reported by ICS-CERT over the last few years. The first stage of the kill chain provides a good analysis of the Havex attacks; there is no evidence of stage 2 attacks yet. The second case study is Stuxnet, which provides the first example of the complete ICS kill chain. Once developed the malware was probably delivered to Natanz through infected media (USB stick or infected laptop); the sophisticated malware was able to explore the network to identify and install itself on systems that it had been designed to attack.
Fig. 4 Second stage of an ICS attack
Further validation of the ICS kill chain has been provided by the SANS Institute analysis of the Ukrainian power outage . The attack affected three regional energy distribution companies which caused disruption to over 200,000 customers. This attack is another example of a two-stage ICS attack. The first stage of the attack used spear phishing to deliver and install the BlackEnergy 3 malware , which was able to establish a link to a command and control channel which enabled the attacker to communicate with the malware and targeted systems. In stage 2, the attackers developed attacks on the distribution management systems and also malicious firmware for the serial-to-Ethernet devices in the systems. The ICS attack involved hijacking human–machine interfaces and opening the breakers; at least 27 substations were taken offline as a consequence. It is maybe interesting to note that the cyber attack was complemented by a denial of service attack on the telephone system which prevented consumers from reporting problems – this may become a common feature of future attacks.
As noted earlier, ICS are a type of cyber–physical system. Whilst cyber–physical systems have been in the minority in the past, the emergence of the Internet of Things (IoT) will lead to an explosive growth of such systems. A number of sources suggest that there are about 3.5 billion people connected via the internet at the moment and that this is likely to grow, to give somewhere between 25 and 50 billion connected devices by 2020. Most IoT systems are cyber-physical. They share the same kind of resource issues as ICS components; indeed, most IoT devices will be much more power- and memory-constrained than typical components in an ICS. In the rush to market, IoT products are often developed with little thought being given to security aspects. There have already been stories, possibly apocryphal, of smart fridges sending out spam! More worrying are demonstrations of cyber attacks on autonomous and smart vehicles.
With both ICS and IoT systems safety is likely to be an important issue that is likely to over-ride security concerns. Safety and security are not always possible to reconcile. A good physical analogy is station barriers in the underground system: safety might require that they fail open but security would favour them failing closed. There is a growing awareness that in ICS both properties are important and new standards are trying to reconcile the two; it is unlikely that a system can be considered safe if it is not secure.
The legal position of ICS operators in Europe is also facing some radical changes. The European Union has been developing a directive on network and information security (the NIS Directive). The latest text of the NIS Directive is . The EU has identified the resilience and stability of network and information systems as being essential for the completion of the Digital Single Market. There is currently a fragmented approach across the EU, with member states at different levels of capabilities and preparedness. The NIS Directive aims to rectify this situation by establishing a level playing field. The directive has three main objectives:
- All the member states should ensure that they have a minimum level of national capabilities in place.
- The competent authorities, established as part of the first point, should cooperate within a network enabling secure and effective coordination, including coordinated information exchange as well as detection and response at the EU level.
- The directive aims to ensure that a culture of risk management develops and that information is shared between the public and private sectors.
The main implications of this directive fall on operators of essential services and digital service providers through the establishing of common minimum capacity building and planning requirements, exchange of information, cooperation and common security requirements. The NIS Directive includes an obligation of incident notification to a national competent body. The process of preparing for the implementation of the directive by identifying essential services is expected to start in February 2017. Many of the organisations operating ICS fall within the critical national infrastructure and are likely to be designated as essential services under this directive. The requirements must be implemented by May 2018.
In conclusion, ICS present a relatively new target for cyber attack. Whilst ICS look increasingly like the IT systems we use to run our enterprises, the OT has subtly different attributes which mean that we cannot blindly apply the same cyber defences. One of the key differences is the shift from attacks that are aimed at stealing data (referred to as espionage earlier) to those that exploit the cyber-physical nature of ICS and aim at sabotaging the controlled systems. Another is the complex interactions between safety and security requirements. The senior levels in businesses are less aware of the risk of cyber attack on their ICS than they are of the risks to their enterprise IT systems and we need to develop better techniques for communicating this risk. It needs to be recognised that systems cannot be considered safe if they are not also secure.
The author is grateful to his colleagues in the Research Institute for Trustworthy Industrial Control Systems (RITICS), and particularly Deeph Chana, for their many discussions over the last three years.
 Falliere, N., Murchu, L.O., Chien, E.: ‘W32.Stuxnet Dossier’, Version 1.4, February 2011, Symantec, https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf, accessed November 2016
 Stouffer, K., Pillitteri, V., Lightman, S., et al.: ‘Guide to Industrial Control Systems (ICS) Security’, Special Publication 800-82r2, May 2015, National Institute of Standards and Technology, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf, accessed November 2016
 Lee, R.M., Assante, M.J., Conway, T.: ‘German Steel Mill Cyber Attack’, ICS Defence Use Case December 30, 2014, SANS ICS, https://ics.sans.org/media/ICS-CPPE-case-Study-2-German-Steelworks_Facility.pdf, accessed November 2016
 NCICC/ICS-CERT Year in Review 2015, https://ics-cert.us-cert.gov/sites/default/files/Annual_Reports/Year_in_Review_FY2015_Final_S508C.pdf, accessed November 2016
 Langner, R.: ‘To kill a centrifuge’, The Langner Group, November 2013, http://www.langner.com/en/wp-content/uploads/2013/11/To-kill-a-centrifuge.pdf, accessed November 2016
 Hutchins, E.M., Cloppert, M.J., Amin, R.M.: ‘Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains’, Lockheed Martin Corporation, 2011, http://www.lockheedmartin.com/content/ dam/lockheed/data/corporate/documents/LM-White-Paper- Intel-Driven-Defense.pdf, accessed November 2016
 Assante, M.J., Lee, R.M.: ‘The Industrial Control System Cyber Kill Chain’, SANS Institute, October 2015, https://www.sans.org/reading-room/whitepapers/ICS/industrialcontrol-system-cyber-kill-chain-36297, accessed November 2016
 Symantec: ‘Dragonfly: Cyberespionage Attacks Against Energy Suppliers’, Symantec Security Response, July 2014, https://www.symantec.com/content/en/us/enterprise/security_response/whitepapers/Dragonfly_Threat_Against_Western_Energy_Suppliers.pdf, accessed November 2016
 Lee, R.M., Assante, M.J., Conway, T.: ‘Analysis of the Cyber Attack on the Ukrainian Power Grid’, SANS Institute, March 2016, https://ics.sans.org/media/E-ISAC_SANS_Ukraine_DUC_5.pdf, accessed November 2016
 F-Secure Labs: ‘BlackEnergy and Quedagh’, F-Secure Labs Security Response, 2014, https://www.f-secure.com/documents/996508/1030745/blackenergy_whitepaper.pdf, accessed November 2016
 European Commission: ‘Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL concerning measures to ensure a high common level of network and information security across the Union’, February 2013, http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52013PC0048&from=EN, accessed November 2016
First published on Engineering & Technology Reference 1 December 2016