Although I would always advocate having every feasible layer of security in place to protect an organisation’s industrial control systems (ICS), what I’d like to share now are my thoughts on how good system design techniques can augment those other layers. Doing so is a capability that is often overlooked, which is surprising considering that this is often the last line of defence after all other layers of security have been compromised.
‘Out of the box’ settings
To fully appreciate what can, and should, be achieved through rigorous design, configuration and management, one first needs to understand the condition in which ICS components are often delivered. Vendors are motivated to make their equipment easy to configure, easy to integrate, and least likely to generate technical support workload or service returns. All of this helps to create a positive first impression with their customers. To this end, devices tend to have the simplest, most accessible configuration:
- common addresses are used (192.168.y.x)
- default names, usernames and passwords are set
- methods of automatic configuration are enabled (BOOTP, DHCP for example)
- a wide range of protocols are installed/enabled
- a wide range of services are activated, whether they are needed or not (web server, for example)
Although this is far from an exhaustive list, all of these are serious potential vulnerabilities. Default names will result in your system being easily discovered using open source methods. Default credentials will result in its compromise.
If they exist it is always worth using the vendor hardening guides to manage these risks.
Introduction of new features over time can catch out even the wary. My recommendation is to fully research all the features of your control hardware and software, as well as how to disable/secure/enable them effectively. Enable only what is needed. The temptation is always to leave well enough alone once working.
Several design choices can greatly assist with resistance to attack, post-event forensics and recovery from upset (both accidental and intentional). These include:
- Correct initialisation of states and variables – set values explicitly at start-up
- Strong typing of variables (in common with many programming languages)
- Tight scoping of routines and variables (in common with many programming languages)
- Boundary/limit checking (again, in common with regular programming)
- Well defined and repeatable response to power cycles – hot, cold and warm restart behaviours
- Known and repeatable procedures for bringing the process up from dark and cold
- Independent logging of operator actions and equipment responses
- Good User Interface / human factors design that minimises the chance of human error
- Electronic signatures/ electronic records – record what happened and when.
Take the opportunity to configure security, also known as hardening, very early in a project, when risk to delivery is low. It won’t happen later, after all!
Some kit is well-behaved and allows you to load/save configuration data. Other equipment will require that you painstakingly note it down and change it manually. Having found the best settings, manage them and ensure they stay that way. Some hardware can automatically load settings and programmes from non-volatile (NV) memory on replacement, and optionally on power cycle. Ensure the correct settings and programmes are stored in NV memory. Record (and check) versions and checksums where possible.
Keeping your industrial control assets up-to-date will have benefits outside of improved security. A good starting point to ongoing management includes:
- Survey/audit – know what assets you have and where they are
- Information – subscribe to OEM updates to hear about patches, new features/releases and updated firmware
- Adopt OEM security features – enable and actively manage them (code protection, security managers, access control passwords etc.)
The kind of information you need to secure a system can be a big help in maintenance. Understanding data flows and required services is really useful when it comes to troubleshooting. Making security an integral part of good system design will help to stop people seeing it as a tax.
All of these features require effort and carry some risk (locked out by your own security, for one). And while their implementation may not be completely ‘free’, you must balance the costs against the potential benefits – in cyber resilience, maintainability and Total Cost of Ownership.