The Issues in Cyber-Defence and Cyber-Forensics of the SCADA Systems

Posted on Updated on

Jan.- March, 2015, vol. LXII.1,
Jan.- March, 2015, vol. LXII.1, PP. 29- 41.

Sandeep Mittal, I.P.S.


As the Supervisory Control and Data Acquisition (SCADA) system are deployed in infrastructures which are critical to the survival of a nation, they have emerged as a potential terrain for cyber-war, thus attracting the considered attention of ‘nation-states’. The analysis of worms like ‘stuxnet’ ‘flame’ and ‘duqu’ reveals the hand of a ‘nation-state’ in their design and deployment. Hence, the necessity to  understand various issues in the defence of SCADA systems arises. The forensics of the SCADA system provide deep insight into the design and deployment of the worm (the malware) once the system is attacked. This is precisely the scope of this essay.


The peace, prosperity and economic development of any Nation depends upon its critical infrastructure and how well-protected it is. These critical infrastructures are distributed physically and virtually in space and time. The Supervisory Control and Data Acquisition (SCADA) systems are an important component of the process to control and monitor industrial and infrastructure process 24/7. Initially, these SCADA systems were designed to run in an isolated environment. However, with sudden improvements in information and communication technology, SCADA systems have evolved and adopted latest technologies like wireline IP communication and communicate over public IP network on one hand making the SCADA system vulnerable to attacks (Bailey & Wright, 2003) and malware infections from the much wider networks. The discovery of ‘ stuxnet’, ‘flame’ and ‘duqu’ in the recent post has opened a ‘can of worms’ which was unimaginable till recently. While ‘stuxnet’ could be termed as ‘an essentially a precision military-grade, cyber –missile’ which, once deployed, would not require any human intervention thus heralding the beginning of digital attacks on physical targets by hunting them globally (Chen and Abu-Nimes 2011 ), the other two are more improved malware to gather intelligence about critical infrastructure worldwide. The developers, critical infrastructure stakeholders are realizing this increasing threats and started taking measures to address these ( Brandle & Naedele, 2008; Ahmed, 2012). As these SCADA system are deployed in infrastructures which are critical to the survival of a nation, it has emerged as a potential terrain for cyber-war, thus attracting the considered attention of ‘nation-states’. The analysis of worms like ‘stuxnet’ ‘flame’ and ‘duqu’ reveals the hand of a ‘nation-state’ in their design and deployment. Hence, the necessity to understand various issues in the defence of SCADA systems arises. The forensics of the SCADA system provide deep insight into the design and deployment of the worm (the malware) once the system is attacked. This is precisely the scope of this essay.

The Components of SCADA System

A typical architecture of a SCADA system controlling a typical critical infrastructure would mostly comprise of a ‘control-centre’ and ‘field- sites’. The ‘field-sites’ are equipped with devices like ‘Programmable Logic Controllers’ (PLCs ) Remote Terminal Units ( RTUs) which send information by different communication media (e.g. satellite, wide area networks or radio/cellular/microwave networks) about the state of Filed-equipment to Control-centre. The major components of a control centre are Human Machine interface (HMI), data base management system (Historian) and Server or Master Terminal Unit (MTU) Components. All the communications with the field sites are initiated by MTU and it receives back the data from field-devices, pre-processing this data, if necessary, and sending to historian for archiving. The HMI provides the interface to the human operator. The typical architecture is shown in the following figure (Ahmed, 2012.)


The Defence Issues in the SCADA System

The discovery of complex, complicated and deceptive worms e.g. ‘stuxnet’, ‘flame’ ‘duqu’ and ‘careto or mask’ in recent past points to the fact that the SCADA System are rapidly becoming the targets of ‘nation-states’ who are ever-eager to deploy such cyber weapons to strike at will in the enemy territory. Therefore, the defence approach for securing SCADA systems has to be comprehensive and multi-pronged. These strategies can be broadly divided in to 3 broad categories (after Nazario, 2004)

a) Host based defence measures provide a deeper entrenchment of the defence for any single system. Therefore, multiple defences at host level make things difficult for the malware attack to exploit the system. However, these defences may fail due to misconfiguration and may be bypassed. This strategy has the following components,

(i) Host based static or the dynamic firewalls are used as a complement to the network firewalls. However, the limitations to this strategy are that the host based firewalls are ineffective in stopping the worms following the already established link paths that are allowed via policy. Moreover, the worm itself may subvert these firewalls if sufficient right are obtained by the malicious executable. A worm on launch may issue a command to unload the firewall’s rule set, completely neutralising the installed security monitor.

(ii) Server side commercial antivirus software can be implemented. However, it requires regular and timely updates to the definitions as they rely on signature based definition, failing which defence becomes ineffective.

(iii) Partitioned privileges – The service running on well-known ports (between 1 and 1024) have elevated rights and handle authentication and thus having super-user level access to system databases. However these access rights are not required through the life time of a program. Any system that does not need repealed can discard the elevated privileges, it began with, once the restricted operations are performed.

(iv) Privileges Separation – In this method, two instances of the application run, one with few privileges (only sufficient to handle user request) and second with system level privileges (required to handle services such as authentication) and the two process communicate via inter-process communication, with the child requesting the results of any operations that require any privileged access. Thus a small process run with system level access that has minimal exposure to external risks. Compromise, if any, occurs in the unprivileged process space (Provos, 2002).

(v) The other strategies include disabling the unneeded service and features, aggressively patching known holes, implementing the behaviour limits on hosts. The last of these is a promising area for computer security and can be applied to different level of networks. The behaviour of the host in normal circumstances is enforced in this method. However this method may prove useful at the network level rather them at the host level.

However, this approach may not scale well to large SCADA networks, in addition to difficulties in maintaining and enforcements. But they would continue to be used in SCADA defence as malware spreads by attacking the host only.

b) Firewalls and Network Defences

Firewalls are used to enforce a network security policy which includes authorisation to establish communication between two end points, controlled by the port, applications and protocols in place. The firewalls evaluate the connection requests against its rule base and apply a decision to requested action (Ranum & Avolio, 1994; Wack, Cutler & Pole, 2001; Nazario, 2004). Network architects and administrators managing SCADA systems should deploy firewall technology to achieve several key objectives( Wack and Cranahan, 1994);

i) Protection from malicious applications by controlling their entry and exit from a network.

ii) Control the destinations and sources of network communications.

iii) Concentrated security and enhanced privacy

iv) availability of logging statistics for internet activities.

Most of the firewalling devices are of two basic types. The first is a packet filter which performs policy enforcement at packet level and could be stateful or stateless. A stateful filter understands the context of a communication and can conditionally pass or reject packets that are part of the communication (or at least appear to be so), while, in contrast, the stateless firewall, only monitors single packet irrespective of the context of surrounding traffic. Here, filtering rules are applied on a packet level basis as opposed to a connection level basis (Chapman, 1992). Placing a firewall at the network perimeter, usually the place where two different policies exist at the end of a network. At the ‘outside’, polices are generally more liberal than on the ‘inside’ of the network, thus giving rise to the ‘trusted internal network and ‘untrusted external network’. This creates a protected network and exposed network. These exposed networks have services such as web servers and access given to the world at large. Each network is then protected with different policies to meet the differing security requirements. However, the perimeter firewalls presume that one security policy can adequately meet the requirements of entire network which is simply impossible and therefore inadequate. Therefore, a set of firewalls on each submit of the network are deployed and tailored to meet the usage patterns of the different use of groups, and are an effective natural way to defend against an active worms who spread and mutate rapidly. Another strategy is to deploy reactive Intrusion Detection System (IDS). Typically, an IDS sensor passively listens to the traffic on the network and only sends an alert when it has observed suspicious traffic, but still allowing the communication to proceed. In contrast, reactive IDS can be configured to close the connection via forged packets. A second type of network firewall is the proxy server which provides their services by being an intermediate system for a network connection. Typically a listening agent on the proxy server receives a request for a network action, and fulfils the action on behalf of the client. At no point of time the client and the final destination make a direct contact. However, as the proxy act as an active peer in the communication, it may held the data temporarily before transfer to the client system. This allows compromise of the content including the details of malicious activity being removed (Ptacek & Newsham, 1998). However, as using the proxies induces communication stream latency resulting in time lag in communication of critical instructions, its use in SCADA systems is limited.

The most important thing to be kept in mind is that SCADA systems control the critical infrastructure which requires data transmission and decision implementation in real time failing which the critical networks may collapse. Therefore, any defense strategy to be used for SCADA system should have a judicious blend of security and usability in real time.

The Forensic issues in the SCADA Systems

The reliability of a SCADA system depends not only on safety, but also on security (Brandle & Naedele, 2008). A comprehensive guide on Industrial Control Systems (ICT) Security has been published by NIST (Stouffer, 2011) and is very useful in implementing the security controls in SCADA systems deployed in critical infrastructure. A SCADA system is different than a conventional IT System i.e. criticality of timeliness and availability of its capability all the time, having terminal devices with limited computing capability and memory resources and last but not the least the direct impact of logical execution in the physical world. Additionally, the SCADA systems usually have a static topology, a presumably regular network traffic pattern and use simple protocols (Zhu & Sastry, 2010).

The Forensic examination of SCADA systems is important post-incident to understand the design, attack vector of malware and attribute responsibility if possible, to assist law enforcement in investigation.

From the perspective of digital forensics , a SCADA system can be viewed in different layers, as demonstrated in following figure (Ahmad, 2012), based on the connectivity of the various SCADA components and their network connectivity with other networks such as Internet (Bailey & Wright, 2003).


The upper layers shown in above figure correspond to the enterprise IT networks environment wherein, the routine corporate desktops, servers dealing with enterprise business operate. However it is the first 3 lower layers (layers 0, 1 & 2) where most of the forensic analysis in SCADA systems has to be performed as these layers contain the special SCADA components and are crucial for controlling the underlying industrial processes. However, the analysis may extend to further up the higher-layers if necessitated (Ahmed; 2012). As 24/7 availability is a critical requirement of a SCADA system, a forensic investigator cannot turn it off for data acquisition and analysis, necessitating use of live forensics for data acquisition and subsequent offline analysis of the acquired data (Adelstein, 2006). However, live forensics data acquisition has a few challenges in capturing data viz;

a) if the data is not acquired immediately, the volatile data would be lost.

b) maintaining the integrity of volatile data and its admissibility in courts of law.

c) inconsistent data image.

The SCADA systems typically have a primary system and a backup system. The investigator may put the SCADA system on the backup and conduct data acquisition on the primary- affected system. But it is most likely that the malware which has infected the primary system would have affected the backup system also thus making the life difficult for a forensic investigator (Stouffer & Scarfone, 2011). Forensic investigators have to deal with the problems arising from the unique features of SCADA system which limits application of contemporary forensic tools and techniques to SCADA Systems (Ahmad, 2012; Fabro and Cornelius, 2008),

a) predefined rules in network traffic of SCADA system may allow communication between various components of SCADA system, but may not allow communication between forensic tool and SCADA components during data acquisition.

b) customised operating system kernel of the SCADA components may not be compatible with the data acquisition tool.

c) resource(e.g. memory, processing etc.)- constrained nature of SCADA components (e.g., RTUs & PLCs etc.) may limit data acquisition tools.

d) log- records of SCADA systems are inadequate due to limited logging capability of SCADA systems.

e) large amount of data generated by individual field-components (e.g. large number of sensors).

f) vendor-dependency during analysis as the SCADA components ( modern as well as legacy proprietry technology ) are provided by multiple vendors some of the components being forensically compatible and some not as shown in following table. (after Fabro & Cornelius, 2008),

Table 2. Modern/Proprietary Technology and Forensics Compatibility

(after Fabro & Cornelius, 2008)

Modern/Proprietary Technology Effective Audit /Logging Forensics Complaint Reference Materials Available
Engineering Workstations, Databases, Historian Unknown Unknown No
HMI, Data Acquisition, Application Server Possibly Yes Possibly Yes Most Likely No No
Field Devices (PLC, RTU, IED), Modern/Remote Comms Probably No No No

Table 3. Legacy/Proprietary Technology and Forensics Compatibility (after Fabro & Cornelius, 2008)

Legacy/Proprietary Technology Effective Logging Forensics Complaint Reference Materials Available
Engineering Workstations, Databases, Historian No No No
HMI, Data Acquisition, Application Server Most likely No No No
Field Devices (PLC, RTU, IED), Modern/Remote Comms No No No

At present the complex SCADA environment presents a number of challenges to forensic investigator, thus preventing him from applying contemporary forensic tools and techniques. The challenges are detailed in the following lines (Wu, 2013)

  • Live Forensics and Data Integrity – The live forensics is a dynamic environment and the live data acquisition would not be forensically sound as volatile memory cannot be verified and traditional hash algorithms, e.g., MDS cannot be used. However, baseline hashing algorithms of the ladder logic of field devices can be taken and stored as read-only-access in a secure unit. In case of an incident a comparison of existing logic inside the field device would provide comparison to the baseline hash. The baseline hash of the ladder logic should be updated at regular interval to ensure device integrity.
  • Lack of compatible forensic tools for field devices- The incidents like ‘stuxnet- attack’ on Iranian Nuclear Facilities clearly demonstrate that field components of SCADA (like PLCs in this case) can be compromised. These embedded devices have low memory and processing power, thereby limiting the data retention. However, the data on RAM and flash memory would be useful for forensic investigation.
  • Lack of Forensically sound storage – OPC clients and Historians are typically the available devices for storage on SCADA systems. The data stored in these devices is for specific purposes, accessible from external environments and therefore forensically unsound.
  • Identification of Data Sources on a SCADA system is very difficult. The several layers of connectivity, as discussed earlier, having complex architecture makes the task inherently difficult.

Another important issue is a sound “SCADA Forensic Process Model” for preservation, identification, extraction and documentation of digital evidence so that it is admissible in courts of law from procedural proprietary of process, law and science. SCADA Forensics Models have been proposed by researchers recently (Radvanovsky & Brodsky, 2013; Wu; 2013).


However, it has to be borne in mind that due to complexity of SCADA components, architecture, and networking and also the sophistication of attacks now a day, one has to be careful in carrying out the various steps of the SCADA forensic model.


The complexity of SCADA systems in terms of technology, process and architecture throw a number of challenges to be experts securing the SCADA as also in collecting forensic evidence, one an incident is reported. The embedded technology, short memory, little processing power poses limitation in live forensics. Any defence strategy to be used for SCADA system should have a judicious blend of security and usability in real time. Any process of live forensic should meet the test of nonrepudiation on procedural aspect of process, technology, science and integrity of the data has to be assured, so that it is admissible in court of Law. The attacks on SCADA systems in future are not only going to increase but would be highly sophisticated, more particularly when SCADA systems would provide a potential terrain of war for the nation states. Only a judicious use of technology and common sense would help to keep the SCADA systems secure. More research is required in designing live forensic platforms that could be applicable to SCADA environment.

Note: The views expressed in this paper are of the author and do not necessarily reflect the views of the organizations where he worked in the past or is working presently. The author convey his thanks to Chevening TCS Cyber Policy Scholarship of UK Foreign and Commonwealth Office, who sponsored part of this study.


  • Adelstein, F. 2006, “Live forensics: diagnosing your system without killing it first. Accessed online on 10/05/2014 at:“, Communications of the ACM, vol. 49, no. 2, pp. 63-66.
  • Ahmed, I., Obermeier, S., Naedele, M. & Richard III, G.G. 2012, “SCADA systems: Challenges for forensic investigators. Accessed online on 11/05/2014 at:“, Computer, vol. 45, no. 12, pp. 44-51.
  • Ancillotti, E., Bruno, R. & Conti, M. 2013, “The role of communication systems in smart grids: Architectures, technical solutions and research challenges”, Computer Communications, vol. 36, no. 17–18, pp. 1665-1697.
  • Bailey, D. & Wright, E. 2003, Practical SCADA for industry. Accessed online on 05/05/2014 at:, Newnes.Brewer, R. 2012, “Protecting critical control systems”, Network Security, vol. 2012, no. 3, pp. 7-10.
  • Chandia, R., Gonzalez, J., Kilpatrick, T., Papa, M. & Shenoi, S. 2007, “Security strategies for SCADA networks” in Critical Infrastructure Protection Springer, , pp. 117-131.
  • Chapman, D.B. 1992, “Network (in) security through IP packet filtering. Acced on 05/05/2014 online“, Proceedings of the Third UNIX Security Symposium.
  • Choo, K.R. 2011, “The cyber threat landscape: Challenges and future research directions”, Computers & Security, vol. 30, no. 8, pp. 719-731.
  • Endicott-Popovsky, B., Frincke, D.A. & Taylor, C.A. 2007, “A theoretical framework for organizational network forensic readiness”, Journal of Computers, vol. 2, no. 3, pp. 1-11.
  • Fabro, M. & Cornelius, E. 2008, “Recommended practice: Creating cyber forensics plans for control systems. Accessed online on 10/05/2014 at :“,Department of Homeland Security.
  • Genge, B. & Siaterlis, C. 2014, “Physical process resilience-aware network design for SCADA systems”, Computers & Electrical Engineering, vol. 40, no. 1, pp. 142-157.
  • Hildick-Smith, A. 2005, “Security for critical infrastructure scada systems”, SANS Reading Room, GSEC Practical Assignment, Version, vol. 1.Igure, V.M., Laughter, S.A. & Williams, R.D. 2006, “Security issues in SCADA networks”, Computers & Security, vol. 25, no. 7, pp. 498-506.
  • Malin, C.H., Casey, E. & Aquilina, J.M. 2012, “Introduction to Malware Forensics” in Malware Forensic Field Guide for Windows Systems, eds. C.H. Malin, E. Casey & J.M. Aquilina, Syngress, Boston, pp. xxiii-xxxviii.
  • Nai Fovino, I., Carcano, A., Masera, M. & Trombetta, A. 2009, “An experimental investigation of malware attacks on SCADA systems”, International Journal of Critical Infrastructure Protection, vol. 2, no. 4, pp. 139-145.
  • Nai Fovino, I., Carcano, A., Masera, M. & Trombetta, A. 2009, “An experimental investigation of malware attacks on SCADA systems”, International Journal of Critical Infrastructure Protection, vol. 2, no. 4, pp. 139-145.
  • Nazario, J. 2004, Defense and detection strategies against Internet worms, Artech House.Provos, N., Friedl, M. & Honeyman, P. 2003, “Preventing privilege escalation”, Proceedings of the 12th USENIX Security SymposiumWashington DC, USA, , pp. 231.
  • Ptacek, T.H. & Newsham, T.N. 1998, “Insertion, Evasion, and Denial of Service: Eluding network intrusion detection. Accessed on 05/05/2014 online“, .
  • Radvanovsky, R. & Brodsky, J. 2013, Handbook of SCADA/control systems security. Accessed online on 10/05/2014 at:, CRC Press.
  • Ranum, M.J. & Avolio, F.M. 1994, “A Toolkit and Methods for Internet Firewalls. Available at“, USENIX Summer, pp. 37.
  • Rrushi, J.L. 2011, “An exploration of defensive deception in industrial communication networks”, International Journal of Critical Infrastructure Protection, vol. 4, no. 2, pp. 66-75.
  • Slay, J. & Sitnikova, E. 2009, The Development of a Generic Framework for the Forensic Analysis of SCADA and Process Control Systems, Springer.
  • Stouffer, K., Falco, J. & Scarfone, K. 2011, “Guide to industrial control systems (ICS) security. Accessed online on 05/05/2014“, NIST Special Publication, , pp. 800-882.
  • Taylor, C., Endicott-Popovsky, B. & Frincke, D.A. 2007, “Specifying digital forensics: A forensics policy approach”, Digital Investigation, vol. 4, Supplement, no. 0, pp. 101-104.
  • Wack, J.P., Carnahan, L.J. & Leibowitz, A. 1994, “Keeping Your Site Confortably Secure: An introduction to Internet Firewall. Accessed online on 05/05/2014.;jsessionid=948AE719480319D3CE64A25B491BF80D?doi=“, .
  • Wack, J., Cutler, K. & Pole, J. 2002″, Guidelines on firewalls and firewall policy. Accessed on 10/05/2014 at, “
  • Wright, C. 2013, “Forensics Management”, Handbook of SCADA/Control Systems Security, , pp. 173.
  • Wu, T., Disso, J.F.P., Jones, K. & Campos, A. 2013, “Towards a SCADA Forensics Architecture. Accessed online on 10/05/2014 at:“, Proceedings of the 1st International Symposium for ICS & SCADA Cyber Security Research, pp. 12.
  • Zhu, B. & Sastry, S. 2010, “SCADA-specific intrusion detection/prevention systems: a survey and taxonomy. Accessed online on 05/05/2014 at“, Proceedings of the 1st Workshop on Secure Control Systems (SCS).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s