Securing ICS – going beyond IT
It is often stated that industrial control system (ICS) environments are difficult to protect from cyber-attack. The use of legacy equipment, extended system life cycles, real-time requirements etc. are often quoted as reasons why ICS is so difficult to protect. These are valid arguments and should not be dismissed; however, the danger with this message is that ICS owner/operators may become daunted by prospect of implementing a cyber security programme.
Author(s): Stefan Liversidge
There is little acknowledgment of how the characteristics of ICS can be leveraged to provide a significant security benefit. Applying IT best practise is not always suitable for ICS environments, causing operational issues and security controls that fail to reach their potential. ICS environments allow the implementation of strict deny-by-default, allow-by-exception policies. Such strict configurations may be unmanageable in many IT environments due to the fluid nature within IT, where users may want to use a variety of different programmes and services. ICS environments are much more static meaning that strict configurations are manageable, resulting in a more robust control system where compliance with change management procedures and health and safety executive (HSE) work permit systems are enforced and auditable. By blindly applying IT policy, the benefits of this environment could be missed.
Industrial control systems (ICSs) are vulnerable to cyber-attack, the reasons for this are far and reaching. With the rise of Stuxnet there has been a concerted effort to increase awareness of this . Industry is starting to listen; however, change will not happen overnight and a whole culture shift within ICS is required to truly engage with the problem. One key issue within ICS is the skills gap and security within ICS is somewhat of a niche area. This has led to the involvement of IT professionals with a wealth of knowledge of cyber security, but lack the depth of knowledge about the ICS environment, resulting in conflict with the operational technology (OT) team, concerned about availability and plant productivity. The disparity between these teams can lead to a breakdown in trust and create environment, where everyone becomes nervous about deploying cyber security control measures with the OT network. What typically happens in this scenario is that a demilitarized zone (DMZ) zone is created with the associated perimeter defences to that it has been before. This approach provides little in terms of securing the ICS from attack . Collaborative working is required to bridge the knowledge between IT and OT to achieve create a comprehensive system of continuous improvement for cyber security within OT.
Further to the skills gap, another big barrier for ICS owner/operators is the fear that implementation of a cyber security programme is expensive and complex. I believe that this is due to the amount of negative coverage ICS gets, many articles published often talk about the difficulties that are present within ICS environments, but the advantages within ICS are often overlooked.
The aim of this paper is to address some of the specific areas that may get missed when developing cyber security controls for ICS. The techniques discussed in this paper are made possible by leveraging the characteristics of ICS. ICS environments are typically reasonably static, giving us great scope to configure strict policies that would not be manageable in many IT environments. Ideally, we would like to take the existing infrastructure built from commercial off the shelf (COTS) technology and lock down this equipment to a point, where it could be seen a special purpose equipment.
Invasion of COTS technology
ICS has adopted COTS technology as a matter of routine practise. This has huge advantages relating to cost, performance and ease of replacement, but these devices and software packages are usually configured for the mass consumer market, designed for ease of use and flexibility, these properties are not required or desirable in ICS. Industry has always had the desire to restrict the use of these products to the specific automation task required; however, it has been naïve in performing this functionality, for example, simply disabling keyboard shortcuts on supervisory control and data acquisition (SCADA) to prevent users from accessing the desktop.
Since this equipment is familiar to security practitioners from an IT background, it would be easy to take an IT approach to secure ICS systems. If we apply policies that are typically deployed within IT environments, we could cause issues with plant performance and we may miss opportunities to provide further security enhancements by leveraging how ICS systems are operated and how they function. The sections below represent some key areas, where bespoke ICS security policies and procedures can produce effective solutions without huge capital investment.
Endpoint firewall configuration
The default windows firewall is configured to deny all incoming connections unless a specific firewall rule exists, but all connections outbound are allowed. This has obvious benefits for a home user, for example, firewall rules do not have to be created for every application or game etc. In ICS, we have the ability to block all inbound and outbound traffic with the exception of those protocols required for the normal operation of plant.
The resulting benefit of this two-fold, we have the security benefits in that the potential for malware to spread and the attack surface are greatly reduced. Secondly, the control network becomes more robust since the data passing over the network is control relevant data only and not programmes spuriously polling to find an Internet connection.
If we take a look at a typical example of a small control system with a SCADA communicating to a programmable logic controller (PLC) over Modbus transfer control protocol/Internet protocol. In this example, we only require port 502 to be open, every single other port can be blocked.
Good control over data ingress and egress is essential for the prevention and detection of malicious activity within your network, the term I like to use here is ‘practising good network hygiene’.
Endpoint protection measures are only part of the suite of security measures that should be in place on an industry control network. Network hygiene can be further enhanced by using industrial grade firewalls that use deep packet inspection and are industrial protocol aware. This then allows, for example, Modbus commands to be further restricted to only allow certain registers within the Modbus protocol to pass though the firewall to the PLC.
User account management
Windows creates an administrative account as part of the initial system setup. This account is used as the default account on most SCADA systems that I have come across. Often the system automatically logs into the account at start-up and the same username and password is used across all machines on the plant. This is a common setup in industry since it is a simple way to enable communication between all machines to meet the functional requirements of the system. This is a huge security concern as it allows malware or malicious actors to move freely around the entire control system. By allocating user roles based on least privileges, we gain much more control over our system.
Administrative accounts for home users may be ok, having two accounts to manage, one of which cannot install software or perform certain configurations could be seen as inconvenient. In ICS, windows systems generally run a SCADA application or engineering software. Very little is changed in terms of system configuration so under day-to-day operation the operator would not even note this change; however, security will be hugely increased from this one simple step.
An administrative role has the ability to perform any action on a PC, and so malware or malicious actor running under this privileged account has carte blanche over the system. The use of privileged accounts should always correlate with the correct change management paperwork, permit systems or job report card. Usage that does not could indicate malicious insider activity or users not following the correct change management procedures. This provides an audit trail that would not always be available within an IT environment.
User account management provides us with enhanced protection from cyber-attacks, but also increases our ability to audit the use of privileged accounts increasing the likelihood of detection of suspicious activity. Ideally, the ICS system would have its own active directory to provide centralised user management and audit capabilities, but this would depend on system size, budget and the necessary resources to be able to manage this type of setup.
The power of network monitoring is often overlooked in ICS. Industry tends to have a preference for preventative measures; this is a huge opportunity that is being missed. ICS traffic is entirely predictable and the number of protocols in use on an ICS network are often limited to just a few. The flow of traffic is regular, PLC tags are polled on a regular interval, data backups are taken at a scheduled time of day and engineering activity is scheduled. Fig 1 shows a typical ICS network trace, as you can see the data is incredibly regular when compared with Fig 2 that shows the network trace of a typical IT network.
Fig 1: ICS network traffic 
Fig 2: Typical IT network traffic 
What this leads us to is that in ICS we can easily detect anomalous network traffic, simply by looking at the network throughput. This approach is incredibly powerful and not nearly as straight forward in an IT environment. If we take a purely IT approach to network monitoring within ICS, we may miss this opportunity.
Patch management is admittedly one of the most difficult aspects of cyber security to manage in ICS. Patching within IT environments is something that is generally taken for granted, but automatically patching a PC in an ICS environment is very much not recommended. The fear is that by installing certain security patches, the control system will fail to operate as tested. I have personally witnessed such issues and so the fear is not unfounded. There is one key area in ICS that we can utilise to our advantage to overcome this. Industry often demands highly available systems, requiring that no single point of failure should cause significant disruption to the plant, the advantage of this in relation to system patching is being overlooked. If the security patch is deployed on one of the redundancy partners and left to soak test for a number of days, then should an issue be detected, the control can fail over to the unpatched redundancy partner. The patched server can then be rolled back to its unpatched state until the issue can be resolved. During this period, additional mitigation measures could be imposed if the risk was deemed high enough.
More recently there has been a move toward virtualisation within ICS. This could have a significant benefit from a patch management perspective or even for upgrading the operating system of the entire plant, negating the issue with legacy operating systems. In a virtualised environment, it would be quick to build a test system which once proven could be rolled out to the production system, with the failsafe being that if problems occur, the legacy system could be recovered in a very short space of time.
Legacy operating systems within ICS are a real problem and virtualisation might just be the answer and something that should be considered when upgrading. This becomes especially apparent when you consider that windows 7 become end of extended support in January 2020.
Traditional antivirus solutions operate on a blacklist basis, where known bad applications are prevented from running. An application is allowed to run if its code signature does not trigger a match with the blacklist. Application whitelisting operates by only allowing known applications to run, every other application is blocked by default.
Application whitelisting has not been widely adopted, since it has not been favoured for use in IT environments. The management overhead associated with this method of system hardening is too large to be a workable solution in most IT environments. In ICS however, this approach is ideal since there is rarely any reason to install and run new software packages on SCADA. If there is a requirement, then this must be carried out in a controlled manner by software engineers with the correct work permits. Application whitelisting therefore enables enforcement of management of change procedures and any new software installation would have to be planned.
Application whitelisting is bundled in windows under the windows app locker. App locker is supported on Windows Server 2008 R2, Windows 7 Ultimate, Windows 7 and Windows 10 Enterprise and can be managed by a domain controller , so this is a completely free solution apart from the configuration time.
The advantage of application whitelisting over traditional antivirus is that there is no requirement for regular updates of the antivirus database.
While IT and OT share the same technology, the application of the technology is vastly different. Herein lies the true problem within ICS. IT policy cannot be blindly applied to ICS since this represents a missed opportunity to enhance ICS security. Similarly, OT can gain a lot from involving IT departments and collaboration between IT and OT is key to the development of an effective cyber security programme.
Cyber security within ICS can be enhanced by using tools already available in many solutions that are common across industry. By leveraging the characteristics of ICS, strict configurations are possible which in turn reduce the risk of infection, anomalous activity can be quickly identified and changed management procedures can be enforced.
It has also been highlighted above that existing change management procedures that are core to the management of an ICSs can be leveraged to provide auditability and traceability of actions performed within an ICS environment. These procedures have been born out of health and safety requirements and are deeply entrenched into the culture of everyone who works with automation equipment. Such a rigorous paper trail may not be available to security teams with an IT environment, who would fill out a form every time they installed a new piece of software on their laptop or whenever they inserted a universal serial bus stick into their personal computer? This should be routine procedure in ICS.
Clearly, ICS has a long way to go with cyber security and the problem is only exacerbated by the drive for connectivity and industrial Internet of Things (IIoT), but with an approach tailored to account for the intricacies in ICS, cyber security does not have to be as difficult as it would sometimes appear. We have seen above that there are some simple measures that can be used to help secure ICS environments. I strongly believe that the effectiveness of cyber security is not in direct correlation with budget. With a little thought and focusing efforts based on risk, effective security measures can be implemented without huge budgets and extended implementation programmes. What should be clear is that there is no magic bullet for cyber security. A defence-in-depth approach is required as defined in IEC62443 . This concept is not unfamiliar to ICS, anyone who has looked at functional safety will be familiar with layer of protection analysis which follows this same principle, where a failure of one of the protection mechanisms does not lead to the compromise of the entire plant.
- Kaspersky – industrial security, cyber threats to industrial control systems, 2014.
- Critical control guidelines – SANS. Available at https://www.sans.org/critical-security-controls/guidelines.
- Capture files from 4SICS geek lounge – NETRESEC, Available at http://www.netresec.com/?page=PCAP4SICS.
- Sample captures – TCP replay. Available at http://tcpreplay.appneta.com/wiki/captures.html.
- Windows AppLocker – Microsoft. Available at https://technet.microsoft.com/en-us/library/dd759117(v=ws.11).aspx.
- IEC 62443: Network and system security, 2013.