Almost without fail, vendors mishandle their first contact with a security researcher who has found a vulnerability in their product. This problem is not unique to control system vendors, and there are many tales of mishandling including the well documented Core Security / CitectSCADA vulnerability disclosure event.
We often recommend and perform a vulnerability handling dry run for vendor clients who have not yet experienced a vulnerability event yet. Of course this has to be done with appropriate vendor approvals and someone inside who is positioned to step in at the right moment – – and they are typically bcc:ed on all communication.
There is a long list of common problems identified in the dry run, but here are a four that stick out for frequency and importance.
2. No PGP key or secure way to communicate with the researcher. This probably is less important for the risk of someone compromising the email than it is for first impressions of the researcher. Recently we received a “We don’t have a PGP key. Please send any details on . . . ” Not a good start.
3. “The SCADA / DCS is on a private network protected by a firewall” response. The go to answer for a control system vendor first contact with security researchers. Unfortunately some vendors still rely on this after vulnerability experience and way too many owner/operators still accept this.
4. The vendor feels they control disclosure. I did a Pecha Kucha presentation on this, but like it or not the person who found the vulnerability calls the shots. He can disclose immediately, agree to the vendor’s disclosure plan, or anything in between. Understanding this may help with the negotiations with researcher on a more vendor friendly disclosure result.
There are certainly more lessons learned, but if you are vendor who has not faced this situation, try a dry run and make your mistakes before it counts.