Snitches get riches – could bug bounty programmes take off for smart grids?

Since Netscape introduced the first bug bounty in 1996, they’ve been a go-to tool across the tech industry, winning popularity with both the issuers and the cyber security community. For issuers, it’s a way to access a pool of cyber security talent far deeper than any in-house team. For hackers and researchers, it’s a great way to get recognition and remuneration for their skills without putting on a black hat.

So why haven’t we seen them in smart grids and wider critical infrastructure? These are highly advanced technological systems and the stakes are high – why wouldn’t the industry have employed an approach with such a good track record?

If you look at some of the biggest, most successful of those programmes you see organisations such as Google, Apple (though only recently) and even the Pentagon. Looking at those names, it’s immediately apparent that the ‘tech’ companies are leading the way. Perhaps they’re just more cyber-fluent by nature – could that be it? Probably not: other types of company – such as General Motors – are edging in too. So why?

You might think that there’s a material difference in how smart grid cybersecurity and the corresponding research community works. In our experience, that’s not the case. The smart grid cybersecurity space is full of talented, curious people just the same as the broader cybersecurity space, and there’s nothing inherent about the smart grid that stops similar programmes. In fact, it’s even more important – a widespread Facebook hack is a disaster, a grid hack could be a catastrophe.

Perhaps it’s because the smart grid is still relatively young? A lot of the tech is there, but not all of it yet. And roll-outs have mainly been experimental and exploratory rather than blanket. Maybe that means the stakes aren’t perceived to be high enough yet – smart grid isn’t critical infrastructure for now.

Or, maybe it’s an issue of expense? Look at those names above. Apple has more cash reserves than many countries, Google can’t be far behind. General Motors is an industrial powerhouse and the Pentagon is one of the most advanced, well-funded defence organisations in the world.

There’s money in the smart grid for sure, but it’s a time of transition for the energy industry and research and development budgets are expensive. Against this backdrop, it’s understandable that companies would be reluctant to give away money and add to the cost base. It’s a common objection – even the original Netscape bug bounty faced opposition from the VP of Engineering, who believed it a waste of time and resources.

So what’s the reason? Perhaps it’s a mixture of maturity and funding. But neither should be an insurmountable barrier. We can’t afford to wait until the smart grid is grown-up and omnipresent to secure it – it has to be now. As for cost, bug bounties can actually be very economical ways to discover vulnerabilities. You don’t have to pay a salary or for any unused discoveries – only for results. Plus, pay-outs can range from $100s to $100ks, so there’s a bounty to suit any budget.

As ENCS knows from its research and work with the industry, collaboration is key to smart grid cybersecurity. The safety of critical infrastructure goes beyond matters of competitive advantage between companies. As a society, we can’t afford to let companies invest resources in the same things separately, re-inventing the wheel instead of making cumulative progress. Why couldn’t that spirit of collaboration extend to bug bounty programmes to spread the cost?

For now, the main issue seems to be that smart grid systems are still young, and the pay-outs needed might be a tad too high for such a programme. A better first step is to implement an industry-wide vulnerability sharing programme to iron out as many early problems as possible and help the sector mature.

Once that’s done, perhaps critical infrastructure bug bounty programmes will have their time and those snitches that help protect the grid will get their deserved riches.

Subscribe to our newsletter

"*" indicates required fields

This field is for validation purposes and should be left unchanged.