In this episode of What That Means, we’re talking crowdsourced security and bug bounty, and we’ve got a treat for you: double the brilliance with Katie Noble and Alexander Romero (RoRo). Both are Directors of PSIRT at Intel and both have extensive experience in cyber security as DC veterans (think Department of Homeland Security and the Pentagon).

Our convo covers:

• The flavors of bug bounties

• Crowdsourced security

• Vulnerability Disclosure Programs (VDPs)

• Security Technical Implementation Guides (STIGs)

• CSIRT & PSIRT

• Hackcidents

• Red teams, blue teams, purple teams

• IoT

...and more! Join me for an interesting and insightful conversation.

Here are some key take-aways:

• Crowdsourced security relies on the wisdom of the crowd to find vulnerabilities in systems that might otherwise be missed.

• Bug bounties differ from VDPs in that they’re more of an invitation to find vulnerabilities and report back to the vendor. With bug bounties, there’s also an incentive (sometimes financial, sometimes not).

• Bug bounty incentives can include money, airline miles, lunch with important people, pieces of hardware, and other things.

• Static bug bounty programs are often open to all products and all people. Proactive bug bounty programs may be time-sensitive and only open to specific products and specific researchers.

• Bug bounty programs aren’t for everyone. There are some steps you need to take beforehand, like deciding what you’re asking people to look at. You also need to have a strong VDP in place first, so you can deal with the submissions and effectively mitigate problems.

• Problems and vulnerabilities with products are reported to PSIRT. Problems and vulnerabilities with infrastructure are reported to CSIRT.

• There are legal coverage considerations that you must think of with a bounty. The scope should be well understood, but you also need to allow for the reality that you might not know everything that the system touches.

• If you start with an internal bug bounty program, you need to teach your internal team to have a different mindset, a hacker mindset. The mindset of a builder is typically much different from the mindset of a breaker.

• Until we get to a place where we understand that there is only one world now, there's so much attack structure that is being left unsecured.

Some interesting quotes from today’s episode:

“We had our own tools and our own way of looking at problems, but when you bring somebody from the outside in, they have a different view of the world, different frame, different lens, and that's very helpful at times to kind of see things from the perspective of an adversary or an actual criminal hacker.”

“There is this compliance checklist, for example. We call these Security Technical Implementation Guides — STIGs. And if you follow these, you should be secure. But that's not really always the truth. Sometimes there are other things, some other interactions between software or the services that you're using, that then lead to vulnerability.”

"But researchers had never really been given the opportunity to talk directly to the DoD in that form before. And it turns out they had other vulnerabilities that they were aware of, that they wanted to tell us about, but we didn't have a good way to accept those.”

“A bug bounty, for better or for worse, is going to pull attention towards your product or your company.”

“Bug Bounties are not appropriate for everybody. There is kind of a push, like a ‘fear of missing out’ kind of deal. Like ‘Everyone has a bug bounty and I want one, too.’ But that may not be appropriate for your business. There are other steps that you probably need to think about before you start with a bug bounty.”

“You need to be able to decide, what is it you want people to look at? Are you asking them to look at your products or are you asking them to look at you? That's going to be different.”

“I would say you need to have a strong vulnerability disclosure process in place…You need to be able to deal with those submissions. You need to be able to respond effectively, mitigate the problems. All of that takes policy, process, procedure, infrastructure. It's not something that is an overnight sort of deal.”

“You need to have a method of receiving that information, triaging that information, mitigating it, and then communicating back out to the researcher that you've done those things.”

“I would recommend that every organization start out with a sort of ‘internal bounty’ first. So have your engineers, have your folks who understand the system, try to find vulnerabilities. And if they don’t, still pretend as though they did, and then run it through your process that way — so you can find areas where your process might have holes, or you don't know who the system owner is, or who can take action on it. At the end of the day, that’s what you're trying to do.”

“A lot of times when folks have designed the system, they're looking at it from that perspective. And it’s hard to switch over to kind of an adversarial mindset, which is what these researchers bring.”

“Also, things change, implementations change all the time. So it wasn't necessarily a flaw when the product was designed, or a weakness — it was something that was meant to be that way. But then a product changed or was implemented in a way that the original engineer didn't anticipate.”

“The role of the PSIRT is to facilitate. It's to be the coordinator. It's to be the balanced voice in the room that's kind of trying to move things along. We're not tied to one perspective or another perspective. We're willing to be open-minded and see all the perspectives. And you definitely need all the perspectives.”

“The goal is always to protect the user, and it doesn't matter if you're in government or if you're in private sector. The goal is to keep the eyes on the prize, protect the end user, make this as strong as we can.”