[BreachExchange] What might bug bounty programs look like under the GDPR?

Audrey McNeil audrey at riskbasedsecurity.com
Fri Mar 30 10:06:01 EDT 2018


https://iapp.org/news/a/what-might-bug-bounty-programs-
look-like-under-the-gdpr/

With GDPR D-day looming, how are large companies going to ensure that they
are not breached? There is a lot of speculation about which company will be
the first to be hit with a fine under the new rules, and while many data
protection authorities will give a certain amount of grace period, data
protection officers will need to get their houses in order. If a breach
does happen, DPAs will also look more favorably on those organizations that
can show they took serious steps to improve cybersecurity and keep data
safe.

To date, bug bounty programs — in which ethical hackers identify security
lapses for companies before a nefarious hacker can — have been increasingly
used by organizations, both public and private, to keep an eye on
vulnerabilities in their systems that could lead to data breaches. But at a
recent hearing on the massive Uber data breach, there was talk that such
programs, which often yield the bounty hunters significant monetary prizes,
could create perverse incentives if they're not done right. That is, it
could become more beneficial to become a bounty hunter than to create a
solid system in the first place, and we might start seeing engineers
shifting to the other side.

So what might this look like under the GDPR's fining scheme?

“Bug bounties are a good and proactive mechanism for encouraging disclosure
of issues and disrupting the threat model,” explains Daragh O’Brien,
Castlebridge managing director. “In my view it will depend on how firms
implement the bounty program, but it it might be viewed as analogous to
consumer product firms using complaint hotlines to spot defects and trigger
recalls.”

Lukasz Olejnik, independent cybersecurity and privacy researcher and
consultant, agrees. “GDPR might incentivize the creation of bug bounty
programs at larger organizations. Specifically, those that already have
mature and functioning security and privacy teams. Organizations can view
bug bounties as an additional strategic component in their risk management
process. But if an organization does not have a functioning security and
privacy process, running a bug bounty should not be a thing to consider.”

But even as organizations gear up for May 25, hacker groups could also be
rubbing their hands with glee says Meeuwisse. Hacker groups may see GDPR as
a sort of bug bounty payday he says.

“Because if they can get in, GDPR is going to make personal data a lot more
valuable to hackers, for resale or basic ransom - a substantially more
attractive target. You could end up with a trend for people scouring the
internet for loose portholes, and we will very likely see an uptick after
May,” he warns.

“It’s interesting that GDPR doesn’t explicitly prohibit the payment of
ransomware,” he adds.

Given this, could some companies be tempted to pay ransomware extortion and
"call it a bug bounty" rather than report a breach? Several DPAs are still
trying to work out exactly what happened in the Uber case, but the
temptation to pay to make the problem go away must be significant.

“It is certainly “inadvisable practice” to try to avoid the new
regulations. And of course it is ethically and morally correct to report,
but that isn’t necessarily what every organisation does initially. I feel
that you should never pay ransomware. There are a significant number who
don’t, but there is a significant minority who do,” said Meeuwisse.

PaulBernal, senior lecturer University of East Anglia Law School, says this
possibility is also interesting: “As I understand it, it’s only actual data
breaches that have to be reported, rather than potential data breaches, so
this looks possible. The GDPR is intended to encourage more security, so
that should in theory mean that it encourages companies to find and address
bugs quickly, and that could well include offering bigger bug bounties. The
proof will be in the pudding, though: How strongly it is all enforced has
yet to be seen.”

Regardless of how strictly the new rules will be enforced, “simply
requalifying ‘extortion-like’ requests as bug bounties does not waive the
responsibility of communicating a breach to the DPA,” says Olejnik. “GDPR
does not allow for laundering of the kind and it is highly unlikely that
DPAs would accept this practice. That said, it is pretty much unclear how
some of the processes in the bug bounty programs relate to the requirements
of Article 33 and 34 of GDPR.

“Bug bounty participants are not agents affiliated with a data controller
running the bug bounty program. If a vulnerability is found and reported,
is it a potential data breach? Strictly speaking, bug bounties relate to
systems, implementations and configurations, and not data that can be
accessed. However, if a bug bounty participant exceeds what was allowed
and, perhaps, inadvertently gains access to private data, the event may
need to be isolated and analyzed by the organization running a bug bounty
program. In some cases, I would expect there will be a need to even report
such an event to the DPA within 72 hours. Therefore, bug bounties should
incorporate the appropriate GDPR rules, to be on the safe side,” Olejnik
explains.

Leaving aside GDPR enforcement, O’Brien says “ransomware payouts don't
disrupt the economic model for bad actors, so I would suggest that
regulators would view this as a less than positive action, particularly as
the ransomware attack would only be that effective if there was no backup,
no recovery plan, no tested controls, or weak organizational or technical
controls. There is a difference between rewarding someone for flagging
something you did not catch in design or testing that creates a risk and
paying someone off because you failed to plan for and take reasonable steps
to proactively mitigate.

So while we still don’t know exactly how GDPR will be enforced from May 26,
and the threat landscape may worsen, the message remains, err on the side
of caution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180330/0e94452e/attachment.html>


More information about the BreachExchange mailing list