Frustration building . . . must keep civil tone . . . another silent fix in widely used control system application passes by our doorway . . .
This site has had a running series of blog entries on vulnerability disclosure including discussions on the dangers of the “silent fix”. A silent fix is when a vendor is aware of the vulnerability, has actually addressed or removed the vulnerability, but has chosen not to make any of their customers aware of the vulnerability or fix.
This is a huge problem in control systems where asset owners rarely implement upgrades, even free upgrades, unless there is no choice or an extremely compelling reason. By going with the silent fix, the vendor does not provide the asset owner with the information they need to make an informed upgrade decision. The asset owner may say I don’t need those new features and pass on the upgrade, not realizing they have a latent, easily exploited vulnerability.
I guess an argument can be made for a silent fix if it involves some new and novel attack never seen in the wild. This has not been the case in control system vulnerabilities to date. The vulnerabilities to date have involved rather simple attack methodologies taken from the IT world and applied to control systems. This is just what you would expect an attacker to do.
The silent fix may be due to the stigma of having a vulnerability. We need to get over that. Software has bugs and some of those bugs result in vulnerabilities. Hopefully we can move to a mode where vendors are evaluated on two factors:
1) There integration of security into the development lifecycle. To date this is an area where control system vendors are woefully behind.
2) The vendors response to identified vulnerabilities.