In the last two articles we covered risk assessments and asset discovery and vulnerability management, which are the first two steps in understanding and securing ICS systems. ICS environment hardening is the next part in our series on Cyber Security in ICS Environments. If you read the second article (http://www.instrumentation.co.za/59392n), we have already started the hardening process by patching and identifying vulnerabilities across our systems. In a nutshell, ICS environment hardening is the process to improve system and asset security by removing unnecessary components/services from the environment. This can be performed for an ICS network, an ICS device, an ICS operating system, or a single ICS application.
Reducing the risks
ICS environment hardening means changing the standard configuration of a networked ICS device to reduce or eliminate a potential risk. The most effective way of doing this is to securely configure the operating systems, restrict user accounts, secure applications and implement application whitelisting, and hardening networked devices like switches, firewalls, etc.
To reduce these potential risks, only services that are deemed essential or critical for use in a control system environment, for operations or maintenance, should be enabled. All other unused services in operating systems are possible entry points for cyber criminals to exploit. As an example, if you are not using services like FTP, SSH, SNMP, etc., disable them. If we delve a little deeper, most ICS environments will have some flavour of Linux OS and some version of Microsoft running in their environment, with certain applications running on these systems. By default, these systems come out the box insecure (default user accounts, limited/no patches, etc.), and they need to be hardened. Some PLCs also come prebuilt with web servers running, and unless it is a business/processing requirement to have web access to that PLC, the web server should be disabled. There are many tools and resources that can assist in the hardening process. The Centre for Internet Security (CIS) is strongly recommended as a starting point as it is a great resource for hardening guides, tools and more importantly benchmarking tools. CIS is generally free to use and these tools are developed and maintained by leading international cybersecurity experts. The Nessus tool from Tenable (mentioned in article 2) is another great tool that can assist in identifying configuration problems and baselining. There are also some freeware tools such as Linux Bastille and SELinux that are available. It is also recommended to engage with your ICS vendor(s) as many of them have released cybersecurity guides for their specific systems.
In addition to disabling services and features, it is also vitally important to make sure that the necessary user accounts only have the applicable permissions (and that unnecessary permissions are removed) in order for operators and engineers to perform their daily tasks. Default usernames should also be disabled (if possible) and on networking devices such as routers, switches, etc., default usernames and passwords should be disabled and/or changed. A strong identity and access management (IAM) solution combined with an effective privilege access management (PAM) solution will help to achieve this. Whilst both solutions are capable of running as standalone systems, it is strongly recommended to have these integrated. Most of the commercially available tools cater for UNIX/Linux, MAC and Microsoft systems along with support for most of the major ICS vendors.
Whitelisting
Application whitelisting (AW) is another step that aids the overall cyber security posture of an ICS environment. AW defines which applications and which files are known to be ‘good’, unlike an AV solution that defines what applications and files are known ‘bad’. The crux of an AW tool works by uniquely identifying an application by either a file name, the file size, the file path, and/or the SHA1 hash value. The better tools will use a combination of the above as it is more secure. Cyber criminals can replace a whitelisted application filename with a malicious one of the same name, but if the application has a hash value, it is more difficult to achieve this. Based on fingers getting burnt, it is also recommended to roll-out an AW tool in stages.
As a cautionary note, an AW tool can add latency to the system, so comprehensive testing is strongly recommended. Besides implementing an AW solution, it is also critically important to make sure that applications like databases are also secure, and that file systems have the correct permissions. Database security is an article on its own, but it is very well documented for both ICS and IT systems.
Conclusion
In ending, it is highly recommended to start with an established cybersecurity template from CIS/ISA/etc, instead of creating your own one. The main reason for this is that the more functions you change or configure, the more likely you are to break something. Many templates that are available from the likes of CIS/ISA/etc, have already been thoroughly tested and the bugs and kinks have been worked out. In theory, a system with a reduced amount of functions will have less risk and be more secure than a system with more functions.
Tommy Thompson is a passionate cybersecurity professional with some 15 years’ experience. Starting as a firewall engineer in 2001, Thompson has assisted a variety of companies in numerous roles with their cybersecurity problems. He holds a BComm degree in Information Management from Oxford Brookes University (UK) and he is certified by PECB (Canada), as a Scada Security Professional (CSSP).
For further information contact Tommy Thompson, +27 (0)11 463 0096, [email protected]
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version