Here’s the theory with responsible disclosure: you find a security vulnerability in someone’s software or service so you contact them privately to let them know. They then fix it and save themselves a potentially nasty incident. This, in its purest form, is a fundamentally simple concept and indeed it’s one that we want to encourage responsible people to do. After all, it’s in everyone’s best interests and it’s dead easy to do, right? Yeah, about that…
I’ve had many challenges with responsible disclosure before which have made doing the right thing difficult. I struggled with 000webhost, we couldn’t raise VTech and the same saga played out time and time again over many subsequent incidents. But I’ve just been involved in an all new saga which is unprecedented in my experience and there’s some really valuable lessons we can learn from this.
This relates to CloudPets and the piece I wrote about this on my blog earlier this week has attracted a huge amount of media exposure. That’s worth reading first for background, but I don’t want to focus on their specific security woes here, rather the lengths people sometimes have to go to when they’re trying to get an organisation’s attention. Let me lay it out chronologically then we’ll come back to how it was all handled:
- October: Paul Stone of Context Security tries to warn them of security flaws in their Bluetooth implementation, sending several emails as well as contacting them via Twitter and Facebook
- December 31: Victor Gevers of the GDI.foundation tries to warn them about their exposed database
- December 31: The individual who later contacted me tried to warn them about their exposed database (the email address on their contact page bounced)
- December 31: The same individual tried to contact the WHOIS registrant
- January 5: Still without a response, the same individual tried to contact their hosting provider
- February 22-27: Lorenzo from Motherboard tried to get hold of them via various phone numbers
- February 22-27: Lorenzo also tried to reach the Romanian-based developer of their software
So what actually happened? I mean did the company actually receive any of the messages? Well it’s a bit hard to say because their responses are contradictory. The first any of us actually heard from them was in a story on Network World where the CEO stated that “the company never received the warnings”, even despite the ticket sitting in their ZenDesk account Victor linked to above. Fast forward half a day though and the tone changes: “We did have a reporter, try to contact us multiple times last week, you don't respond to some random person about a data breach”.
You can see where the problem is here: even when those attempting to exercise responsible disclosure reach the right person, the message can fall on deaf ears. That’s not the end of it either, in a submission they subsequently made to the California Attorney General office, they went on the say that “Spiral Toys was not contacted by any cyber security professionals”. So you can see the problem here – disclosure can be hard!
But let’s turn this around and talk positively for a moment; Tesla have an excellent vulnerability reporting policy which covers how to get in touch with them, how to encrypt your communications, what’s responsible “testing” and how quickly they’ll try to get back to you. This is a few paragraphs and it’s such a simple thing to add to a website. It’s not a “program” that has to be implemented or a product that has to be bought, it’s simply a recognition that security failures happen and when they do, the organisation would like to know about them.
Paradoxically, the hardest thing about responsible disclosure is also the easiest thing to fix.