Reader Comment: Owners Should Demand Info

Dale Peterson from DigitalBond.com (FULL DISCLOSURE: I sometimes write legislative issues blog posts for DigitalBond.com) left a comment on yesterday’s blog post on software bundling issues. Dale writes that: “Owner/operators need to demand that their vendors provide a list of all software on each component for the security patch management program.” I absolutely agree and believe that if enough users start to demand this that vendors will make this listing part of the standard documentation included with the software.

User Knowledge Base

The problem is that most owner/users don’t realize how common this bundling issue is. It takes a relatively sophisticated user to understand how these components go together and interact. Dale notes that:

“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.”

Now I’m a fairly sophisticated user (not a software engineer or programmer but just a chemist that worked process issues) and I’m not sure I know exactly what Dale is describing with terms like ‘JRE’ or ‘SISCO ICCP stack’. I’m pretty sure that a very large number of owners/users are at my level of software sophistication. I’d bet that this is part of the reason that vendors don’t push more information on bundling.

Now this is one of the reasons that I’m pushing this issue in this blog. The more people that become aware of the bundling issue and the impact, the more likely they will be to request this information in system documentation, and maybe it will become common enough that vendors will include the information automatically.

Patch Management

Dale makes another important point in his comment; “Of course the real challenge is for the vendors to include patch compatibility testing for more than the OS.” One would expect that companies like ICONICS, who have an active development program with OEM customers, would be working with those customers to adapt the component patches into the OEM patch management.

From the debate we keep hearing about the vulnerability disclosure issue, however, I would be surprised if there was much of this sharing going on. If there were more active vulnerability identification and patching going on voluntarily then there would not be as vociferous a debate going on in the security research community on whether or not vendors should be notified about newly discovered vulnerabilities.

I have heard too many researchers cite horror stories about being ignored by vendors to believe that the bulk of bundled vulnerabilities will dealt with unless there is outside pressure brought to bear. Again, blog posts like this will be part of the necessary pressure, but I certainly don’t believe that a few blog posts in this particular venue will make all of the vendors see the light. I’m afraid that, lacking a major move on the part of the ICS software industry, the only way that this is going to be effectively addressed is if it is identified as a security requirement in comprehensive ICS security legislation.

Of course, Congress is even less likely to adapt this issue into legislation than are most vendors to voluntarily fix the problem without legislation. Given human nature as expressed in corporate policy or legislative action, nothing significant is going to be done until there is a major security incident involving un-patched bundled-software. Then we can count on Congress to over-react and address the issue with the finesse of a bull dozer.

Oh well, I’ll be there to say ‘I told you so’. In the meantime I’ll be watching to see how many systems are identified in subsequent ICS-CERT advisories after ICONICS announces the availability of their patch for the ‘Luigi vulnerabilities’.