Want to set up a successful bug bounty? Make sure you write it for the flaw finders and not the lawyers

If you're designing a security bug bounty for your organization's products, by all means get the lawyers to take a look, but keep their hands off the keyboard. If it's one thing flaw-finders find too tedious to deal with, which will put them off finding holes in your defenses, it's legalese – and these are people who otherwise spend all day combing reverse-engineered code for typos.

This point came up during a panel discussion this week at a summit organized by the US government's Cybersecurity and Infrastructure Security Agency (CISA).

Chloé Messdaghi, veep of strategy at infosec training firm Point3, said she's encountered bounty programs that look more like they're intended for the legal team than the security community.

"You want to be as clear, concise, and short as possible," Messdaghi said. "We come across bug bounty programs, and sometimes it is written by an attorney for an attorney to understand it."

Not everyone understands the legal jargon, particularly if they are written in a foreign language – not every bug hunter speaks English, Messdaghi noted – which means rules and limits can be misunderstood and that leads to arguments and disagreements and worse. The VP also said that once a program is in place, whoever's fielding the incoming vulnerability reports should know exactly who to send them to on the product or security teams. Seems simple but corporations get this wrong.

Microsoft forked out $13.7m in bug bounties. The reward program's architect thinks the money could be better spent

READ MORE

Other panelists noted that companies don't have to go all in when launching their bug bounty programs. Jack Cable of CISA suggested that companies can start off by only asking for reports for a small subset of their online footprint or product base, and then grow from there.

"What you can do is start small," advised Cable, an election security technical advisor at the government agency. "So it does not have to be everything under your organization."

The panel also touched on election computer security, and the progress made between the infosec community and voting machine manufacturers in terms of working more closely together in a constructive manner. Joshua Franklin, CTO of the US Election Assistance Commission, bemoaned the lack of research being done on many of the latest voting and ballot-handling systems.

"I hope that we have a clear path for well-intentioned research to be conducted on all voting systems without running afoul of Computer Fraud and Abuse Act," he said referring to America's problematic anti-hacking law. "The latest decade of systems has not received the scrutiny that past generations have."

The latest decade of voting systems has not received the scrutiny that past generations have

Others, however, saw some progress being made. Chris Wlaschin, veep of systems security at voting machine maker Election Systems and Software, said there is a "warming" of relations between machine vendors and white-hat hackers.

"The relationship between security researchers and the election tech providers was a bit frosty, but it is warming up," he said, quite possibly referring to this. "We are warming that relationship, and I think it is a great move in the right direction."

Regardless, it seems election officials would like to see both camps set aside their differences and get to work on rooting out potential security vulnerabilities in election-related systems sooner than later.

"The big reality that people need to understand," said Spencer Wood, CIO for Ohio's Secretary of State, "is the bad guys are every single day looking for those vulnerabilities." ®