The release of the CSL Dualcom report last week has caused quite a stir in the security industry. With just shy of 60,000 page views, thousands of tweets, many forum discussions, and one particularly lively thread on Reddit, many people in both the security and IT industries have read the work. Two clear comments have been made many times:
- Yes, this crypto is really bad.
- How did CSL Dualcom mess up handling this so badly?
If you want to fix the crypto, there are many places you can go.
If you want to handle vulnerabilities better though, I hope I can give you some advice. I’ve now dealt directly with CSL, Risco, Visonic, Dedicated Micros, Samsung, Motorola, Texecom and WebWayOne and think that I have learnt a lot about the disclosure process.
Make reporting issues easy
The first step of reporting a vulnerability is contacting someone. At worst, this requires multiple emails, tweets, phone calls, and LinkedIn prodding. Some companies have taken several months to respond, and when they do, they ask questions to check that you are eligible to receive support. Others have responded and dealt with issues in under 24 hours.
Make this easy. Have a page on your site, ideally with an email address email@example.com. Have an auto-responder on this email address, informing the reporter what the next steps are. Get back to them quickly.
Have a vulnerability disclosure policy
None of the vendors had a vulnerability disclosure policy. This means the reporter has no idea how their work will be handled – are they going to be welcomed with open arms? Threatened with legal action? Can they disclose the vulnerability?
You should have a simple and fair vulnerability disclosure policy. We realise you are dealing with potentially legacy products that are hard to update, so give yourselves a long period of time to deal with issues.
Allow researchers to disclose the issues once fixed or mitigated. This gives both parties benefits – you get free security testing done, the reporter gets reputation, and customers can see how responsive you are.
Pass it by your solicitor to make sure you are not digging your own grave.
Do not require a non-disclosure agreement
As an independent security consultant, it is essential that I do not go around signing NDAs willy-nilly.
They provide me with no benefit. There is virtually nothing that a vendor can disclose about me, but I have a lot I can disclose about them.
At the same time, they put me at risk. The vendor has little legal risk – what can I sue them for, if they have nothing to disclose? Equally, they can sue me as I hold a lot of secrets.
NDAs prevent me discussing work with existing customers. If I sign an NDA with CSL, I then can’t advise my other customers in detail about CSL’s mistakes.
Do not be threatening
Do not make any implied or actual threats, especially legal ones.
You can be in absolutely no doubt that if one person can find the issues, so can another. And that other person may not be so amenable.
Work with the researcher
In more than a few cases, the vendor made fixes for an issue, but the fixes also had problems. In some cases, they even make problems worse.
A prime example of this is reporting a backdoor password, and the vendor simply changes the backdoor password…
Check with the researcher if the fix actually solves the problem, or you will just end up with multiple vulnerabilities being disclosed.
Realise that you are Internet connected
15 years ago, signalling devices were neatly partitioned from the Internet. They had dedicated communications channels and infrastructure.
As devices added IP, they were treated as signalling devices that happen to have an IP side. They were still treated as alarm products, and not Internet connected devices. The threat model had stuck at “Billy Burglar”.
Nowadays, this attitude is still common. But devices have changed – most of them connect to or via the Internet. You need to include “Hacker” into your threat modelling. Fundamentally, a lot of attacker don’t even care if you device is an alarm – they just want another box that is able to generate traffic or send spam as part of a botnet.
You need to involve people who are versed in information security.
Avoid ending up with disclosure handled by CERT/CC
Don’t get me wrong – I love CERT/CC and what they do, but it is disasterous for a company to end up with a vulnerability on their product there. It sends a very strong signal out to the IT community that the company has had ample chance to respond to an issue and they haven’t. It also gives massive exposure to issues – over 1000 tweets showed up within 6 hours of the CSL issue being disclosed.
Work with researchers to avoid this.