Let’s start with the basics. Data Breaches are common — and will continue to be the norm.
How the App Economy and Big Data ruined it
As we shifted towards the ‘App-Economy’ and ‘Big-Data’ (circa 3 years ago), consumers begun sharing more data with more apps. Everyone and their granny, wanted to create a new app, and everyone was told to collect as much data as possible. Then, because storage costs were low, they were encouraged to store as much data as they could first — and figure out how to use it later.
Apps like UBER, Deliveroo, Spotify, FourSquare, GoGet, are ideas we never thought possible 5 years ago. yet today, they’re an ingrained part of how Urbanites (like me!) live our lives. And each of these is a service that has your data, not just what you gave them when you registered, but probably all transactional information as well (every order, deal or purchase you made from their service).
Today, we’re beginning to view Data not just as an asset, but also a liability. Legal regulations have placed penalties for organizations that lose customer data, but you can’t lose what you don’t have. If your company deletes customer data it no longer needs, then it doesn’t run the risk of losing it to a hack — better yet, if the company doesn’t even collect that data in the first place, the risk is completely eliminated.
But this is paradigm shift is new, and we’re still living with the consequences of the ‘App-Economy’ and ‘Big-Data’. It doesn’t mean that these ideas were bad, it’s just the implications are only now being understood, and while there was a lot of good as a result of the app economy and big data, there were some bad consequences as well.
As more apps, have more data, it’s more likely one of them loses it, and lost it bad!
“But hang on a minute! Don’t these companies have security in place”. Yes they do, but security is hard.
Every Death Star has an exhaust port
On the internet, attacking a website is a lot easier than defending it, every death star has an exhaust port, and sometimes you don’t even need Jedi to exploit them.
Let’s assume you own a site, makemoney.com, and you run this site on fairly standard Windows Servers. Attackers continually scan and look for vulnerabilities throughout the site in an automated fashion, because the cost of scanning is essentially zero. An attacker can try different angles, and techniques, and each failed attempt is simply shrugged off.
But a defender like yourself, has to defend against all these attacks, all the time, everytime! Screw up once, and your data is gone.
And even assuming you have the most secure-minded developers working for you, so your application itself is secure (a very big IF), your supply chain might is never pristine. Every now and then, Microsoft releases a new patch that you need to update on your servers. Forget to patch, and it’ll leave your server vulnerable to exploit.
But Patching has a risk — what if you patched and then the server crashes, or some feature doesn’t work anymore? What if you patched windows and suddenly makemoney.com stopped making you any money? That’s a risk you can’t afford, you’ve got kids to feed.
Hence, you build out a test environment, test out the new patches, make sure everything works, and then (and only then) do you deploy this change. Risk averted, but doing this takes time, only the most mature development teams can build, test and deploy an application in hours. Most take days, weeks, or even months — if I’m being honest, years isn’t unheard of either.
In the mean-time you run the risk that maybe you get hacked, but that’s better than definitely not making money. Which is a rational decision, but it will leave you and customers at risk.
If we put those 3 things together, the App Economy, the Big Data craze and the difficulty of defending against attacks, you have all the ingredients necessary to guarantee that data breaches will continue to happen, and we shouldn’t limit our focus to just avoiding data breaches, but rather expand it to both avoidance and response.
Responding to a breach
So if breaches are to continually occur, what can we do?
To me, first and foremost, we need to notify victims. This is just not up for debate, a victim of a crime should know if they’re a victim, and more importantly what they’re a victim off.
I’ve blogged before about the disclosure principle of the PDPA:
The PDPA states that if someone discloses your data to a 3rd-party, they have to inform you, and seek your consent prior to disclosure. Seems logical, that if they lost (instead of disclosed) that same data, to a malicious 3rd-party, those same principles apply. Obviously consent is moot when it comes to breaches, but the notice and choice principle is meant to inform the data subject, and that principle should still stand.
The responsibility of notice and choice cannot simply vanish because data was hacked, if anything the responsibility to disclose has to be intensified. Breach notification is primarily concern in helping the victim mitigate the effects of a breach on the. Breach notification is about taking the data in a breach and using it for good.
And if we agree that breaches occur, and breach notification should be important, let me now make the case for centralized notification.
Centralized Notification
Traditionally breach notification involves a bit of finger-wagging at the organization to informed its customers about the data breach, and what specific elements of data were in it.
But that only goes so far, the impact of a breach is both far-reaching in time, and cumulative.
If you haven’t changed your phone number since 2014, chances are your number is in the Nuemera breach, and since your father/mother remain the same person for your entire life, that piece of data is always considered breached thanks to the dermaorgan breach.
Breaches are also cumulative, in that a sum of data across all breaches add up. Maybe we get your name from one breach, phone number from another, and spouse information from somewhere else. Individually each breach may only whisper a bit about your identity, but cumulatively these breaches might give enough information for a full blown history of your life, enough for someone to steal your identity or scam you directly.
So if the premise is to inform victims of their risk, and that risk is the cumulative risk of individual breaches, than breach notification must also be cumulative — centralized in one place for victims to get the right information.
And centralized notification, under the government auspices (of course!) has the added benefit of ensuring consistency and quality of breach notifications. The organization that was breached still needs to inform its customers, but the victims can now view their full risk profile across multiple breaches in one place.
Finally, since the risk is also far-reaching in time, i.e. a breach from 2014 can still be used in 2018 to scam you, we need a place that will persist the data in one place. If you had 10Malaysian haveibeenpwned? mobile phone accounts across 10 different telco’s, you’d have to call each one of them to get your breach details — 5 years from now, which breaches you were a part of, calling them again can be tedious.
And since breach notification isn’t revenue generating, organizations are unlikely to process them efficiently, usually resulting in a turn-around time measured in x working days. This is not effective.
Centralized breach notification will benefit victims immensely and allow them to get a centralized view of all the breaches they’ve been in, from a single place.
What does centralized breach notification look like?
The one working example is haveibeenpwned.com
Services like haveibeenpwned are enormously successful, sometimes averaging millions of user per day.It’s now being recommended by law-enforcement and used by government agencies in the UK and Australia.
This is a private service, operated by an individual, dealing with stolen(?) data, and it’s used by Police as well as official government agencies, and the best (and only) example of centralized breach notification around.
Regardless of which data breach you were in (Yahoo!, Dropbox, LinkedIn, etc), you can understand which breaches you were apart of by simply typing your email into a search box and get a full understanding of your risk across those known data breaches. Simply put, haveibeenpwned is amazing.
But how would this work for Malaysia?
Malaysian haveibeenpwned?
Well, since you asked.
I propose a single website where people can type in their IC Numbers, and quickly figure out if they were part of the many(!) data breaches affecting Malaysian Personal data. This way, as new data breaches are announced, they can be added to the list, and people can slowly (but surely) understand how their risk increases with each breach.
Sounds eerily familiar to something I worked on before, but just can’t remember.