How to handle vulnerability reports in aviation

TL;DR

• Always thank researchers for reporting vulnerabilities. Acknowledging their efforts can set the right tone.
• Lead all communications with researchers. Don’t let legal or PR teams take over.
• Provide regular updates to avoid miscommunication. Keep researchers informed throughout the process.

We recently gave a talk at the Aviation ISAC Summit in New Orleans about vulnerability disclosure in aviation. The objective was to help aviation operators understand the researcher, helping to prevent misunderstandings result in wars of words, escalation and uncoordinated disclosure. There’s a lot of work going on in the industry to improve disclosure experiences.

We were amazed how many operators came over to chat after, recounting some pretty brutal experiences where they had misunderstood the researcher, or let other departments such as legal and PR manage the comms.

We’ll spare you the full detail of the talk, but here are three big themes that should help you:

Say ‘thanks’

You won’t believe the number of organisations who forget to say thank you. One simple word can start the disclosure process on a good note.

Remember, a researcher who contacts you to disclose a vulnerability is doing so because they found something and would like to give you a chance to fix it. If they were unethical, they could sell it to a broker or threat actor or drop it in public. By approaching you first, they are coming from a position of ethics.

Have some ‘swag’ ready to go. Say thanks and mean it.

Have a wall of fame if you like. Get on the socials and say thanks publicly too.

Run the comms yourself

Don’t let legal or PR take control of your comms. We can think of numerous awkward discussions with lawyers and public relation types whose sole objective was to protect the business and protect its brand. They didn’t understand security research, so tried to close down the researcher. That never ends well.

Make sure you have good support from legal and PR, but you should lead all discussions through your vulnerability disclosure program or PSIRT. These teams have a much better chance of understanding vulnerabilities and researchers

Don’t outsource your VDP completely: bug bounty platforms can help for in-scope vulnerabilities and ‘beg bounty’ but you must keep a route open to researchers who don’t want to use these platforms. If you try to force everyone through a BB platform, you will increase the chance of irritated researchers disclosing publicly.

Over communicate

So often, you’re working diligently to prioritise a bug fix, but no-one remembers to update the researcher. As far as they are concerned, you’ve gone quiet and are ignoring them.

Have a weekly check-in with them, even a short email with an update and ETA, or request for verification of a fix. Anything to keep them up to date.

A call is always wise too. It’s easy to understand each other on email, particularly when ones native language is different. Establish a relationship with them, it help prevent misunderstandings from escalating.

Security researchers often feel like they are shouting in to a void. Help make the experience they have with you different.

Finally. Road test your process

A tabletop exercise is a great way of trying out your process to see if it works well. You might one day receive a vulnerability report so serious that a ground stop is required. How do you handle that? Is your process robust enough?

Anyway, if you do get stuck in a disclosure nightmare of misunderstandings, We are here to help and have assisted other organisations with unpicking awkward situations. Hopefully you’ll never have that problem!