Having been involved in this industry (control system security) for the last five years, a quick examination of what progress has been made in securing critical infrastructure leads me to the conclusion of “not very much”. The industry if still plagued with the same basic vulnerabilities (as noted by the recent release of 3 very simple buffer overflow vulnerabilities and exploits into the public domain) and misconfigurations that were all too common 5 years ago.
Asset owners, those who are actively pursuing more secure deployments, are oft to note that the realities in which they operate are not conductive to security. They deal with old legacy systems with no built in security, the which they can not readily patch, or upgrade. When confronted with the inherent weaknesses in their environments their response is too commonly “we simply can not do anything about it.” There needs to be a paradigm shift then in future products that does not leave asset owners and operators with no options. The reality of their situation needs to change.
As a solution to the legacy problem is not readily apparent, I offer some ideas for future products. Though, in some ways security for control systems has taken “one step forward and two steps backwards”.
What I mean by this is over the last 5 years many companies have had their products examined by researchers, and vulnerabilities have been found and fixed. Yet many “features” in new product lines expose the control system to a wide variety of other exploit pathways. New products with web server management consoles, web based HMIs, and ethernet based “safety systems” quite frankly, give me the willies.
My Wish List for future control system products (or what features I would look for in a control system):
- Product should provide some form of strong integrity and authenticity control for all on the wire communications. This could be either IPSEC or TLS based.
- All system components (hardware, software, field devices etc) should require strong passwords using a strong form of encryption and all password exchanges and key exchanges should be encrypted.
- Software, hardware, field devices, etc. must change ALL default passwords upon initial installation.
- Systems should have exceptional logging and auditing capabilities.
- Products should not come with email, web browser clients by default. HMIs, operator work stations, FEPs, historians, etc should have these removed as they are now the number one exploitation vector in the IT sector.
- Control systems should not use a web app based HMI interface requiring the use of a web browser by operators (see above).
- All unnecessary software should be removed minimizing the attack surface.
- Products should not have unsecured web based interfaces into management consoles. All web server based management products must use SSL and require an authenticated login. No blank passwords or default passwords may be allowed.
- The system must not have outward facing (from local segment into internet etc.) services necessary for its operation.
- Safety Systems should not be ethernet based as this exposes them to common IT vulnerabilities. Do we really want the safety back up systems vulnerable in this manner? (I am aware of a least two teams that have hacked ethernet based safety systems to the point where things that shouldn’t have been able to happen, happened. In test lab settings.)
- Firewalls should be a standard part of every deployment, configured specifically for the environment. The firewall should strictly limit communications to those expressly needed, and should also limit the local segment (control system) communications to those expressly required.
- ACLs should be part of the package that limit what operation users can perform. File system ACLs should also be standard.
- An IDS with the best available rule-sets for the control system should monitor all traffic into and out of the control system. This will alert to the majority of common exploits and returning communications.
- Host Based IDS (HIDS) should be present on all the systems. They should monitor for out of character traffic, modification of files, and the execution of out of character executables.
- Products should initiate patch upload from the downstream side and not allow patches to be pushed up to the field devices, servers and workstations. Patches should also be signed by some type of hash to authenticate and validate the patch.
- Systems should provide redundancy such that patches can be pushed up in real tine with out negatively impacting operations (availability). (This one may qualify as a pipe dream.)
Products designed with these features/specifications would go a long way to securing our critical infrastructure. If the legacy systems are inherently insecure the least we can do is direct the vendors into producing future products that have security as a critical design parameter.