Monday, March 28, 2011

Iconics Genesis and Software Bundling

Readers of this blog will probably remember my discussion of the problems that can arise with bundling software components when one of the components has a vulnerability. As part of a discussion with Joel Langill about the white paper he and Eric Byres did on the ICONICS Genesis vulnerabilities identified by Luigi, I asked if there might be an issue with the Genesis32 and/or Genesis64 HMI systems being bundled with control systems sold by other vendors. Joel noted that I had “really opened up a sort of Pandora's box” with that question and pointed me at the ICONICS web page discussion of teaming with other OEM vendors.

Bundling Genesis32 and Genesis64

The ICONICS web site explains that “OEM partnerships are integral to ICONICS' core business”. While some OEM vendors may choose to identify the ICONICS components they sell, other partners “prefer to market their solutions using our software under their own brand name”. So there may be other control systems that have the same vulnerabilities because they include the Genesis components.

The ICONICS web site includes a listing of some of their OEM partners, but does not say which ones use which of their multiple products. The names include some well known names in the chemical industry:

● Johnson Controls
● Mitsubishi Electric
● Moore
● Siemens
Again, there is no way of telling from the information provided which of these partners might be using the Genesis32 and Genesis64, either using the ICONICS name or partner rebrand. The only way a facility would know is if their vender notified them.

So if anyone has a control system supplied by one of the OEM partners listed on the ICONICS web page (and I have listed less than half), they should probably contact their technical representative and ask them if the system on their site contains the Genesis32 or Genesis64 systems. If it does, then the facility security management team needs to take a look at the Tofino whitepaper.

If the control system at your facility includes the Genesis components, this does not necessarily mean that when the ICONICS patch is made available that it will be applicable to the OEM implementation of those Genesis components. Again the ICONICS web site explains that their team works closely with the “OEM development teams [to] ensure tight integration of ICONICS technology with our partner’s solutions offerings”. That integration process may require adaptations of the patch to make it compatible with the OEM supplied system; again contact your tech rep for clarification.

ICS-CERT and Bundling

Now, when ICS-CERT issued their ICONICS Alert last week, there was no way that they knew about the OEM issue. Their information was based upon the information provided by Luigi on Bugtraq. But when ICS-CERT notified ICONICS one would like to think that ICONICS would have informed them that their affected systems were also bundled with other vendor systems. That would have allowed ICS-CERT to work with those suppliers to get the vulnerabilities addressed.

Alternatively ICONICS could have decided to address the issue with each of the vendors that used the Genesis systems. There would be some justification for not notifying end users until a patch was made available for those systems; the Luigi exploits do not specifically address the OEM variants so no one know that those systems are vulnerable. This is fine as long as those variants are patched in a timely manner.

Unfortunately, with no formal requirement to address the issue of bundled software, there is no way for the user community to know if they have affected systems or if their systems are being adequately protected against the exploits developed for the base programs.

1 comment:

Dale Peterson said...


The answer to this problem is actually not that hard. Owner/operators need to demand that there vendors provide a list of all software on each component for the security patch management program.

This is more than the OS and major third party apps like databases, web servers, etc. It also includes components that are not visible like JRE or a SISCO ICCP stack or TMW DNP3 stack or in this case Iconics OEM code.

Vendors will do this if prospects demand it, we have examples, or if existing customers demand it at User Group meetings. It really isn't that difficult of a request.

Of course the real challenge is for the vendors to include patch compatibility testing for more than the OS. That is a bigger issue, especially with database patches. But even the list of software would allow owner/operators to evaluate the risk and implement compensating controls.

Dale Peterson

/* Use this with templates/template-twocol.html */