It’s one of the certainties in life: when summer approaches and the large hacking conferences such as Black Hat and DEF CON are upon us, the security media starts spinning its wheels. These are the moments when the ‘celebrities’ of our field have their red carpet premiere – what kind of fascinating new research will they show? This research is of course often about some form of hacking – and that’s exactly the point I want to address. What is the point of proving something is broken? Are we over-valuing these “stunt hacks”? And would the industry as a whole not be better off if we focused a bit less on breaking things, freeing up some of our time for building and improving?
Breaking for a cause
To start with the first: of course there is a point in proven something is broken - you could say most of our industry is working on the premise that if you don’t find a bug yourself, someone else will at some point (and this other person might not have good intentions and tell you nicely!). But within our industry, we definitely over-appreciate the art and skill of breaking things – which I think undermines our effectiveness but more importantly, also our position within our organisations.
We tend to keep applying the same old techniques, with the only difference that we re-aim them towards yet another item with a power plug (or a gasoline tank). Sure, it makes for some entertaining movies to watch another video of a car being controlled remotely – but the methods to make it work are nowhere new and often rely heavily on getting physical access to the target device.
We would be a bit surprised if a doctor would try to infect multiple people with some virus – “just to raise awareness” – when there are already well known cures available. Furthermore these hacks can be far from practical applicability – either because they don’t scale or because there is just not a logical business case from an attacker’s perspective.
Winning by building instead of breaking
This focus on breaking also weakens our own positions in our organisations. It reinforces this notion that you only need to involve security before you release a new piece of software – to do the required “penetration test”. We can keep complaining that “the business” doesn’t get it and keeps making the same mistakes – but if we then also stick to the same approaches in proving this point, we are together maintaining a nice standstill.
And don’t get me wrong – I get that breaking something, and proving someone else did not do a good job is a lot of fun. But if we don’t follow up with a very clear focus on how to build something better, I’m afraid that we will make ourselves irrelevant. “The business” does know that security is important – especially as customers expect this from the companies they are buying from – but if the only thing the security team can deliver is a “sorry – we broke this great thing you built” we should not be surprised that we only get involved at the latest stage of a project – or not at all…
Make impact by creating value
So what do we do? I would urge everybody to consider a “year of building”. Refrain from any “breaking for the sake of breaking” – if you want to do some hacking, make sure it’s relevant, repeatable and realistic, and if you’re not sure, consider using the time and resources to work on building something based on earlier experience of things that went wrong.
Try this for a year – very strictly restricting the number of hacking activities you undertake – and closely stay in touch with your colleagues on how your security team is perceived. Not sure it will also be a certainty in life – but I would be surprised if your team is not held in more regard come next summer. Let’s aim to build an industry of people building great things instead of pathological destroyers – that would be creating value.