How could CSL Dualcom have handled my report better?

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:

  1. Yes, this crypto is really bad.
  2. 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 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.

Google “Streisand Effect” and “Illegal Prime” if you want to find out more about why trying to suppress things rarely works.

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.





3 thoughts on “How could CSL Dualcom have handled my report better?

  1. Permalink  ⋅ Reply

    Art Manion

    December 1, 2015 at 9:18pm

    “Disastrous” isn’t always the case… Yes, vendors should be reachable by researchers (and coordinators like the CERT/CC). Sometimes, the CERT/CC can’t reach vendors, and we publish after our 45-day embargo has run out. In most cases, we are able to reach vendors and work out disclosure plans, and in this particular case, we did communicate with CSL. All software has vulnerabilities. The disaster isn’t that a vendor appears in a CERT/CC Vulnerability Note, the disaster is a vendor not being responsive to vulnerability reports.

    • Permalink  ⋅ Reply


      December 2, 2015 at 6:46am

      Yes – maybe I was a little unfair in that outlook.

      I think the issue is a number of these physical security companies don’t realise quite how far reaching a CERT/CC disclosure will go – most releases get a lot of exposure, and if the vendor response doesn’t meet the desires of the IT community, it tends to go big, and quickly.

      The gap between what the physical security world and IT world think is acceptable is large, so you end up with an issue being judged differently by two groups.

      Thanks for your work though – I really appreciate it. Letting others know the vendor has been given a chance to respond is vital.

  2. Permalink  ⋅ Reply

    Paul M

    February 8, 2016 at 1:16pm

    Time after time these devices which purport to provide physical security fail. Door entry systems, electronic locks, contactless card door access systems, etc, are shown to have negligible protection against an attacker who has even the most rudimentary electronics and coding skills.

    Whilst it makes many Hollywood hacker-type movies quite plausible and hilarious, it bodes pretty badly for the Internet Of Things, home monitoring devices and electronic security.

Leave a Reply

Your email will not be published. Name and Email fields are required.

This site uses Akismet to reduce spam. Learn how your comment data is processed.