While at S4, Digital Bond Labs had a security advisory published by ICS-CERT (see ICSA-15-013-03). One thing that we tried to do differently with releasing information on the issue this time around was to reach out to vendors that were obviously using the affected software as part of their control system.
The results were pretty strange. Most companies contacted had no security@ email address, and no /security URI on their website.
Of the 32 affected vendors that we reached out to, only 3 had a ‘security@‘ email address that did not bounce (the remaining 29 we contacted using a general ‘support’ email address listed on the vendor website). Two months later, zero of the affected vendors have provided a response beyond an automated ticket.
When I worked for a vendor, I had an internal pep-talk informally called ‘dealing with researchers.’ There are a lot of cheap and easy lessons to learn, based on how the bug comes to you:
1) When a researcher contacts you directly, without ‘going public’ with a vulnerability, it’s usually a really good sign that the researcher wants to work together. This is a person that is doing work for your company for free. Use it. Be sure to reply quickly. Even if it is just a ‘Thanks, we are looking into this,’ reply, getting it out within a few days is important. Most researchers understand that companies have large internal machinery and that developers can’t just drop what they’re doing to look at a bug. Let the researcher know what you can about the process: simple, “We’re scheduling some devteam time,” style updates go a long way to keeping the researcher satisfied that the company is working the problem. Whatever status you can share without an NDA, do it. Nothing turns off a researcher like a request to sign legal documents.
2) When ICS-CERT reaches out to you on behalf of a researcher it is a little worse than case #1, but still pretty good. Yes, you’re probably going to have a CERT advisory come out. The choice is, does the advisory say the issue was fixed and validated by the discoverer (the extreme positive end, in my view), or does the advisory say that the issue will go unfixed (the extreme negative end)? In spite of the stigma often associated with advisories, I personally view a company that patches a bug and hands the patch to a researcher for testing as hugely positive. Those are the vendors that I will steer people towards when they replace control systems components.
3) When a researcher drops a vulnerability publicly, it’s not the greatest. It’s not the worst-case either, though: a researcher may just as well have sold the vulnerability on a marketplace. It’s better to deal with bad press from a researcher dropping 0day than to deal with bad press from equipment damaged or data stolen in an attack. So remember that this kind of researcher isn’t just out to make money; they probably want a little fame or whatever. Reach out to this researcher: there is some chance that you can turn him/her into the Type 1 researcher above.
The key to handling researchers really is communication. You don’t even need the best security people monitoring your security email address (some security background is helpful, but they don’t need to be a bits and bytes person).
To that end, provide the means to communicate. If you don’t have a security@ email address, you are already doing it wrong. Designate a person or small group of people to handle your security@ email. There is still a big fear among vendors that having a security email address implies that there will be security problems — get over it. Everyone has security problems; ignore them at your peril. You should also train your general support folks to kick an email to the security team if someone is bringing up a security issue.
Handling bugs well is chiefly about attitude and can demonstrate the security maturity of the vendor. There are plenty of companies that are doing these things well, but very few in the ICS space are there yet.
image by Ivan Barefield