With the importance of keeping corporate data secure, it is important for developers to know some basics of keeping it safe. Troy Hunt, a Microsoft Regional Director and MVP, wrote a series of articles fixing data breaches. I have not finished reading this yet but so far it is great information.
Fixing Data Breaches Part 1: Education
We have a data breach problem. They’re constant news headlines, they’re impacting all of us and frankly, things aren’t getting any better. Quite the opposite, in fact – things are going downhill in a hurry.
Last month, I went to Washington DC, sat in front of Congress and told them about the problem. My full written testimony is in that link and it talks about many of the issue we face today and the impact data breaches have on identity verification. That was really our mandate – understanding the impact on how we verify ourselves – but I want to go back a step and focus on how we tackle data breaches themselves.
Fixing Data Breaches Part 2: Data Ownership & Minimisation
Yesterday, I wrote the first part of this 5-part series on fixing data breaches and I focused on education. It’s the absolute best bang for your buck by a massive margin and it pays off over and over again across many years and many projects. Best of all, it’s about prevention rather than cure.
The next few parts of this series all focus on cures – how do we fix data breaches once bad code has already been written or bad server configurations deployed? In part 2 of the series, I want to talk about data ownership and minimisation and this is all about reducing the impact on individuals and organisations alike when things do go wrong.
Fixing Data Breaches Part 3: The Ease of Disclosure
This week, I’ve been writing up my 5-part guide on “Fixing Data Breaches”. On Monday I talked about the value of education; let’s try and stop the breach from happening in the first place. Then yesterday it was all about reducing the impact of a breach, namely by collecting a lot less data in the first place then recognising that it belongs to the person who provided it and treating with the appropriate respect.
Today, I want to focus on the ease of disclosure. What I’m talking about here is ensuring that when someone wants to report something of a security nature – and that could be anything from a minor vulnerability through to a major data breach – that channels exist to easily communicate the issue with the organisation involved. That may sound both obvious and simple, but it’s frequently a tedious, time consuming process which results in many serious incidents going unreported.
Fixing Data Breaches Part 4: Bug Bounties
Over the course of this week, I’ve been writing about “Fixing Data Breaches” which focuses on actionable steps that can be taken to reduce the prevalence and the impact of these incidents. I started out by talking about the value of education; let’s do a better job of stopping these incidents from occurring in the first place by avoiding well-known coding and configuration flaws. I went on to data ownership and minimisation where I talked about giving people back control of their data and collecting less of it in the first place. And then yesterday, I encouraged people to make disclosure easier because there are way too many cases where serious issues go unreported.
Today’s post extends on yesterday’s but I wanted to break it out into a discrete piece and come at it from a different angle. Bug bounties have a really interesting way of changing the economics of security flaws and reversing the outcome from one where companies and customers lose, to promoting one where everyone wins. Let’s explore that further.
Fixing Data Breaches Part 5: Penalties
In the first 4 parts of “Fixing Data Breaches”, I highlighted education, data ownership and minimisation, the ease of disclosure and bug bounties as ways of addressing the problem. It was inevitable that we’d eventually end up talking about penalties though because the fact remains that although all the aforementioned recommendations make perfect sense, we’re still faced with data breaches day in and day out from companies just not getting the message.
This part of the series is also the hardest to implement. It requires regulatory changes, can be highly subjective and poses all sorts of cross-border challenges. But it’s important, so let me do my best articulating it.
Dauvis' Dev Musings 