Put out a welcome mat for good Samaritans bearing bad news.
It sounds easy, but 94 percent of the Forbes Global 2000 offers no easy way for security researchers to report bugs in good faith. Part of the problem, Katie Moussouris tells CSO, is that business leaders confuse vulnerability disclosure with bug bounties. Good Samaritans and bounty hunters are not the same.
Moussouris built Microsoft's vulnerability disclosure program, the first of its kind for a major corporation, helped the U.S. Department of Defense (DoD) launch their Hack the Pentagon program, and has testified before the U.S. Congress on bug bounty programs. She's the co-author of ISO 29147, Vulnerability Disclosure, and ISO 30111, Vulnerability Handling Processes, and the founder and CEO of Luta Security.
In an interview with CSO, Moussouris talked about what a vulnerability disclosure program ought to look like, why companies can't outsource their security to bug bounty hunters, and her experience drafting ISO standards.
On whether bug bounty programs are right for all companies
Moussouris: What I have seen, which disturbs me as a practictioner in this area for 20 years, is that if you look at the Google search terms for bug bounties and penetration testing, they've finally converged. That to me is dangerous. It's dangerous when people think that bug bounties are the same as vulnerability disclosure.
They think they can replace penetration testing with bug bounties. It's not the same. A bug bounty is just an incentive to get people to report vulnerabilities to you. Most of the bug bounty bugs these days are XSS vulnerabilities. Tell me you couldn't have an intern find all those using free tools.
Vulnerability coordination and disclosure are absolutely not the same as bug bounty programs.
Yes, I helped create bug bounties. I was trying to create a mechanism for hackers to one, stay out of jail, and two, help people become more secure. It was supposed to catch the things you missed, not to replace penetration testing, replacing running your own tests.
Not enough critical thinking going into bug bounty programs
Moussouris: If these things become the trends, we're going to end up that you're never going to be able to find Lucy and Ethel in the back of that chocolate factory.
Bug bounties are simply a way to feed that funnel of bugs faster, and potentially have more directed results. I haven't seen a lot of smart bug bounties recently, not a lot of critical thinking going into it.
Lucy and Ethel in the chocolate factory are not well provisioned to deal with vulnerability reports, wherever they're coming from. All these mechanisms, if they are not well provisioned on the back end to do their vulnerability handling process to triage the issue and to determine whether it's something they're going to fix, are not going to have a good vulnerability response process.
How ISO standards for vulnerability coordination and disclosure are made
Moussouris: There are nine stages of hell to the publication of an ISO standard. I do consider them the nine circles of ISO hell, but you're escaping — the inner circle is where you start, and at the end you're ideally not in hell any more.
Luta Security
Katie Moussouris
As a hacker could I ever have imagined myself not just contributing to this thing but also becoming one of its authors? If you asked me ten years ago, 'are you going to become an ISO standards author,' I'd have said, 'What are you talking about? I want to live!'
It was a labor of love because of my unique position of having done all three roles — bug finder, vulnerability coordinator, and vendor — and not many people had done that, especially at the time. It was my responsibility to see this not turn out badly.
The ISO standard mentions all three roles, but only describes the activities for the vendor. The reason for that is I have never met any hackers who were interested in being ISO compliant. There's no reason for hackers to do so. There is a reason for vendors to do so. ISO standards are often put in procurement requirements for contracts, especially the ISO 27000 series to get federal contracts. It's a shorthand for assurance that your vendor is doing whatever you're interested in them doing properly.
A bug bounty program that didn't work
Moussouris: The EU parliament set aside 1.9 million euros to fund bug bounties against open source software that is widely deployed across EU governments. Open source software projects have even fewer resources to maintain the software. There are commonly very few dedicated maintainers. We saw it with OpenSSL, they had like one-and-a-half dedicated maintainers, before people started saying maybe we should actually fund this thing the whole internet is depending on right now.
Instead of doing that and asking 'how do we make these open source projects more secure?' and have a more sustainable maintenance plan for them, they put 1.9 million euros for a bug bounty. They did a pilot against VLC, and very few people participated. Five were thanked and three were paid.
Bug bounties give a false sense of security. 'Oh look! We're doing security. We did a bug bounty,' and it turned up three actionable security bugs.
There are two extremes right now: no idea where to start or do a bug bounty. I see this over and over again. Legislation has now been passed to hack the U.S. Department of Homeland Security (DHS). Unless the DHS has enough resources on the back end to process these things, they are not going to be able to fix the bugs that come in from a massive incentive push.
We have companies like Equifax that have patch deployment delays. If the Equifaxes of the world don't have a smooth and robust and fast process to apply patches for known vulnerabilities, what chance does any department of the federal government have? It's insane to do a bug bounty.
It's driving me nuts. I gave this talk at RSA, I called it "Bug Bounty Buzzword Bingo: A Deep Dive Under a Jumped Shark."
No, NIST isn't going to require bug bounties
Moussouris: The NIST Cybersecurity Framework provides a lot of guidance and it's the bar by which all organizations that want to do business with the federal government, they have to meet this bar.
In the draft 1.1 update, there is language that says organizations should have a way to receive vulnerability reports and process them to resolution and release the results of that. It's basically saying organizations should follow ISO 29147 and 30111.
What's interesting about this is that I had a couple of conversations with people who were freaking out, they thought this meant NIST was going to require them to do bug bounties. Conflation of the two terms is very dangerous.
ISO 29147 revisions: Patch, patch, patch
Moussouris: The revisions were about explaining the sections that dealt with multi-party coordination. That's the situation we find ourselves in every single day. People unwittingly are part of a vulnerability coordination supply chain. How many times do you postpone applying the patch? You're part of the security of your devices. We want to emphasize this all the way down to the deployment level.
That's where security has been falling down. It's not even about addressing the vulnerability anymore. It's about applying the remediation.