Protecting your ICONICS GENESIS SCADA HMI System from Security Vulnerabilities (plus White Paper)

As mentioned in a blog article we wrote earlier this week, an Italian “Security Researcher” named Luigi Auriemma published thirty-four SCADA product vulnerabilities against four SCADA products (the complete list of vulnerabilities and companies is provided in the earlier article).

Eric Byres and I have tested the vulnerabilities and today we are releasing a White Paper that analyses the ones regarding ICONICS GENESIS32 and GENESIS64 products.  The paper summarizes both the current known facts about the vulnerabilities and the actions that operators of SCADA and ICS systems can take to protect critical systems.

While there are no known viruses, worms, attack tools or automated exploit modules using the ICONICS GENESIS vulnerabilities, they do represent a significant threat. At a minimum, they can be used to crash a server, causing a denial-of-service condition and loss of view in the control system.

More serious consequences could occur if an experienced attacker exploited them to gain system access and then injected additional payloads or malicious code into key control system servers.

Though these vulnerabilities do not compromise any mechanical or process equipment directly, subsequent payloads could be used to damage the underlying plant, including equipment sabotage.

What Steps Should Operators Take?

The White Paper provides six actions (also known as compensating controls) that users of ICONICS GENESIS products should take to protect their systems. Operators of other HMI products are advised to consider similar measures.

You will have to download the paper to read all the recommendations, but there is one aspect of the vulnerabilities that is important to understand - any malware or attack exploiting these vulnerabilities would be difficult to detect or prevent since they would be using "valid" communications with the targeted server. Interestingly, this was also a feature of Stuxnet – that worm made use of the same protocols that the Siemens PCS7 systems used for normal communications, allowing the worm to “stay under the radar” and not be detected.

In a typical ICS network environment, additional risk comes from the fact that once inside the primary ICS firewall, any device on the network can send messages that exploit the vulnerabilities.

For example, a contractor laptop with no valid reason to access the GENESIS computers could still send messages to the vulnerable servers if it is attached to the control network. If the laptop was infected with a worm designed to exploit these vulnerabilities, a successful attack would be trivial.

For this reason, I am recommending that industrial firewalls are installed in-line between the GENESIS host computer and the nearest switch. Specifically, an industrial firewall is recommended, due to the high-risk exposure of these services from both less-trusted remote networks and from the local and trusted control system network.

The firewall should be configured with a rule set that allows traffic only from authorized GENESIS hosts using the specific services/ports needed for the ICONICS product to operate.  In case you don’t know what ports are in use by the GENESIS system (or even what TCP ports are), a firewall with automated learning features is highly recommended.

(Warning, Tofino  Security product pitch coming)

The Tofino Security Appliance installed with the Tofino Firewall and Tofino Secure Asset Management LSMs (Loadable Software Modules) is specifically designed to provide this level of protection from unknown threats. If OPC communication is used in the control network, then the Tofino OPC Enforcer LSM is also recommended.

Download the White Paper

Note: you need to be a member of tofinosecurity.com and logged in to have access to the paper. Register here to become a member.

PDFAnalysis of the ICONICS GENESIS Security Vulnerabilities for Industrial Control System Professionals(157kb)

GENESIS64 and GENESIS32 are trademarks of ICONICS Inc. 

This article was written in collaboration with Eric Byres.

http://www.tofinosecurity.com/sites/default/files/JLangill.pnghttp://www.tofinosecurity.com/sites/default/files/SCADAhacker_composite_white.png

Joel Langill
CSO, SCADAhacker.com
joel@scadahacker.com      

Practical SCADA Security thanks Joel for his contribution.

Related Links

ISSSource.com, March 25, 2011
Breaking Down Firm’s SCADA Vulnerabilities

Chemical Facility News, March 26, 2011
More Details on ICONICS Genesis Vulnerabilities

 

RSS Feed Subscribe to the "Practical SCADA Security" news feed

Comments

2

Understanding that Process Control System or SCADA are the software aspect of controls of these systems and we have become dependent on these software and hardware controls to run and maintain these systems, it may be timely to consider overriding the software with mechanical overrides regardless of the software controlling the system. Of course this should be used as a last resort to overrule malicious software commands or feedback into the PCS or SCADA.
Pressure presently is released with Pressure Relief Valves;
Temperature can be controlled by metallic fusible links
Flow can be controlled by diverting and pneumatically shutting down the source
I realize this takes us back to the past but it at least addresses the software vulnerabilities.

Keith J Lobo P.E

I definitely agree with you Keith - it is not that mechanical controls are necessarily better than electronic ones, but rather electronic and mechanical solutions are less likely to be simultaneously impacted by a the same failure mode. This is not the case when you have two identical systems (electronic or mechanical) backing up each other – common mode failure is a possibility.

Unfortunately, we seem to moving the wrong way these days - not only are the safety systems being all electronic (which isn’t necessarily a bad thing), but rather they are being completely integrated into the basic control system. That worries me.

Add new comment