Verifying Fixes

I got some interesting feedback on a phrase in yesterday’s post about advisories from NCCIC-ICS; in particular the common sentence in too many of my responses: “There is no indication that Knowles [substitute the name of the current security researcher reporting the vulnerability] has been provided an opportunity to verify the efficacy of the fix.”

First, I got a TWITTER® DM from a long-time reader associated with OSIsoft, the subject of one of the advisories discussed yesterday. That DM informed me that while NCCIC-ICS did not routinely comment on researcher verification efforts, the OSIsoft advisory did include such language in this instance. Unfortunately, I cannot see that advisory since it is behind a customer only firewall. In any case, it seems (see below) that OSIsoft was actively involved in allowing researcher verification of the fix reported in this instance and are to be commended for that.

This in turn led to a series of emails from folks at Applied Risk, the company reporting the OSIsoft vulnerabilities. They confirmed that OSIsoft had actively worked with them to allow verification of the fixes announced in Tuesday’s advisory. In fact, according to William Knowles, the researcher involved in the situation, OSIsoft went so far as to provide a temporary license for the software to help Applied Risk in their evaluation.

Knowles went on to say:

“Verification of fixes of course always a good thing, but it really depends on whether software access is still available.  As you’ll know, getting access to this software isn’t always easy (expensive price tags, no trials, etc), and initial exposure often comes through consultancy work in third party environments. That access is often very transient.  At that point it all depends on the institutional openness and willingness of the vendor, and furthermore, who you’re even dealing with at the vendor on an individual level, and if they have the capability of dishing out temporary licenses and links to software downloads.  That isn’t always easy; however, in the case of OSIsoft it was, as the process was encouraged from their side.”

We have seen a number of instances where ‘fixed’ vulnerabilities had to be re-fixed at a later date when it was determined that the vulnerability still existed. I noted yesterday that the 3S update published by NCCIC-ICS was apparently one of those situations. If more researchers were involved in fix verification, this problem would be greatly reduced. For the vendors involved it would also demonstrate their commitment to work with the independent researcher community in identifying and fixing security vulnerabilities.

I will continue to call out vendors when they do not support researchers in this manner. And, of course, I will give credit when it is due.