The Equifax data breach continues to reverberate in the media, raising various issues that pertain to data security and privacy.
Asymmetry between errors and consequences
These issues present an asymmetry, what risk theorist Nassim Taleb refers to as ‘convexity’ (link), between the degree of negligence on the part of the data owner and the extent of the damage. In options theory, a convex payoff means that, in exchange for a small, defined loss, you obtain the possibility of an unbounded gain. The usual example is an exchange-traded option to buy or sell a financial asset. (Many people also think of lotteries in this context, but the analogy doesn’t apply, since lotteries are artificial, arranged as games of chance with known probabilities and a maximum payout.)
In IT security, asymmetry is not your friend
Unfortunately for IT shops, the convexity of data security is in the opposite direction (called ‘concavity’): small omissions, errors, or delays can lead to damage with no upper limit. A breach has the potential to destroy the organization and harm to data subjects that may persist throughout their lives (link).
This asymmetry is well known to administrators and security people, who are acutely aware that they can never be heroes, unlike star developers. If the system gives no problems, others assume that the admin was ‘just doing her job’. If, on the other hand, there is any problem at all, the admins are the targets.
A big breach threatens the entire business, especially under GDPR
Imagine a major breach, such as this one from Equifax, under the GDPR. The data controller might receive thousands or even millions of purge requests, and need to satisfy them quickly. Not only would this be a technical challenge but also a business risk, given that Equifax’s business is selling data about the financial condition of individuals and companies.
For a profit-making business, this risk is the worst-case scenario under GDPR, not the prospect of an official fine (the risk of which I suspect is overblown (link)), at least for those cases where data subjects can take their data and move to the competition.
Once the breach is discovered, further damage can ensue from the efforts of individuals to protect their own positions. For example, in the Equifax case, senior executives sold large blocks of shares after the breach was discovered, but before it was made public. If the officials in question sold with prior knowledge of the breach (‘insider information’), it could be a criminal violation of U.S. securities law. Equifax asserts that the executives in question had no knowledge of the breach, but many doubt this claim (link). Even if there was no wrongdoing, the reputation of Equifax is even further damaged by public suspicions.
Damage-control narrative: the breach could’ve happened to anyone.
It appears that the breach was due to failure to apply a patch to Apache Struts (link), a development framework for web applications. This detail was probably released to give the impression that the oversight was a minor, unlucky failure of the type that humans are prone to, and not the result of systemic lapses.
Left unexplained, in this case, is why the patch remained un-applied for 2 months (link). This gave attackers plenty of time to capture data, perhaps without downloading a large enough volume at one time to attract attention.
One can easily imagine scenarios for the patch omission: the notification was buried in the large volume of emails that everyone receives, the person who usually handles this was out of the office, or applying the patch required application downtime at an inconvenient moment.
The failure to notify promptly after discovery, however, must have been deliberate. Whatever the reason for the delay, it left the affected data subjects unaware of the threat, and thus more vulnerable to any scams that might have been carried out in the interim.
The patch window has narrowed to days or hours
After the Apache foundation released the patch to Struts, reports of the first attacks attempting to exploit the patched vulnerability started appearing 3 days after the security patch was made available (link). In other words, as soon as a vulnerability is revealed by the issuance of a patch, attackers begin crafting attacks to exploit that opening, hoping to catch organizations before they applied the patch. In other words, the lead time between patch issuance is small, and likely to become smaller.
The immediate cause of the breach was a failure to patch quickly, made all the worse by the emerging ability of hackers to take a patch notice and devise an attack aimed at the defect (the one that is fixed by the patch) in a matter of days (link).
In the near future this delay could be reduced to mere hours, or even less. In other words, the window of opportunity to patch before being attacked is now so small that round-the-clock monitoring and action are necessary. In the future it may be prudent, once a critical patch notice is received, to take affected systems offline automatically until the patch is confirmed as having been applied.
There are likely other inadequacies that are not mentioned
A typical damage-control response is to focus on one technical problem that is easily fixed, such as applying the patch, and leave out the upstream or parallel failures that allowed the published cause to happen in the first place.
- Why was the patch not applied for more than 2 months
- Why was there such a long delay between the breach discovery and its being made public
- Why did monitoring not detect that large number of records were being queried, nor that outgoing network traffic was suspiciously high
Equifax had breaches in 2013, 2014, and 2016 (link) and was even under court order to correct password problems. Judging from the little evidence divulged, the problems at Equifax are not isolated, but systemic. Failure to patch is not a technical problem, but one of process, akin to automatically creating and, if needed, escalating trouble tickets.
I expect that, when GDPR takes hold and actions like 72-hour breach notification and data purging become mandatory, that many process-level inadequacies will be revealed, in addition to the usual technical shortcomings.
Society’s financial habits force people to surrender their data
Many countries rely on credit-reporting agencies (CRAs), including some EU members (link). These agencies collect data on citizens’ financial transactions and provide it to interested parties, for a fee. In some countries, such as the U.S., a poor credit score (or no score, as may happen if one is newly-resident in the U.S.) may mean that not can you be denied credit; you might not even be able to rent an apartment or a car. In other words, you must give up your data in order to live normally in society.
Consumers have no choice except to deal with the CRAs, which collect their data without their consent (or possibly even knowledge) and sell it for profit to whomever pays them. The data subject cannot require a CRA to delete his or her data, but only get the CRA to promise, for a fee, not to divulge it. This is completely contrary to the spirit of the GDPR.
An even broader problem concerns the use of unique, lifetime identifiers for persons. A prime example of this is the U.S. social-security number (usually abbreviated as ‘SSN’), which is issued to every citizen and permanent resident and used as an identifier for taxes and many other purposes. A criminal in possession of such a number has a perfect key to stitch together data sets from many sources and build a comprehensive dossier on a person.
How can such a business model persist under GDPR?
The short answer is that it probably can’t, not in its present form. This model, which probably worked well enough in the pre-internet era, is a privacy nightmare. The data subjects need not have consented to their data being collected, nor do they know to whom it is sold, or for what purpose.
What might replace it? This model is not universal (I have never encountered it in Belgium, where I have lived for years), which demonstrates that alternatives exist. For countries where residents must rely on CRAs, the transition will be far-reaching, entailing an overhaul of customs and business models.
Attacks are likely to increase, with most people affected
The market for stolen data is growing (link), indicating that there is a specialized criminal underground for obtaining data, and another group, possibly with no technical knowledge but adept at using this data for profit. Stolen data is on its way to becoming a global industry, with specialists in finding target, writing attacks, brokering the data to thieves, and exploiting the stolen data for things like credit-card fraud and identity theft.
Given the large number of data breaches around the world in recent years, it seems likely that most people will have their privacy threatened at some time in their lives. Measures like the GDPR will help, but much of the stolen data is already at large and can never be recalled.
In the past I’ve seen many administrators and managers regard the installation of patches and upgrades with dread, which is understandable given that the process does not always go smoothly. As I said above, administrators get the heat when things go wrong, but are otherwise taken for granted. As a result, the patch is usually planned for a weekend, users are notified of the downtime, trial runs are made on development and test platforms, and so forth. Having to patch quickly, within days or hours, can only increase the risk of unforeseen headaches and delays.
Fear of blame is not the only reason for failures to patch or upgrade software. I’ve seen cases where deprecated versions of Oracle RDBMS were still in use because the application they supported would not work on later versions, and the application vendor had gone out of business.
I’ve even seen companies running software that had been completely deprecated, no longer receiving even security patches. This problem recently made headlines with the ‘WannaCry’ attack, which exploited a weakness in Windows XP (link), for which security updates had ceased sometime earlier. In the WannaCry case it turned out that many copies of Windows XP were still in use, perhaps because older machines that run XP well are too slow to run later versions of Windows.
It will not be pleasant to inform management that it must abandon a working application or replace hundreds or thousands of PCs in a short period, but that’s where we’re heading.
There is no upper limit on the amount of damage to data subjects
One of the themes is the number of people affected, and the collective damage to them. Initial reports are that around 144 million Americans had personal details divulged (link). If we suppose, conservatively, that only 1% of these data subjects become victims of identity theft, and that each victim incurs expenses of $10,000 over his or her lifetime due to the theft, we have total damage of 15 billion dollars born by the victims. This is more than the market capitalization of Equifax (11.19 billion as of 15 September 2017).
In other words, the entire value of Equifax would not be enough to compensate the out-of-pocket expenses of the U.S. victims of this breach. Non-monetary damages, such as time spent to rectify matters, time taken off work, loss of reputation, and so on are not realistically quantifiable, but are heavy costs for the victims.
The damage may persist for the lifetime of the data subject
Not only the monetary cost, but also the duration of harm, of such a breach is impossible to foresee. While some information can be changed with varying degrees of expense and hassle (email address, credit-card number), other items (name, address, social-security number, personal photo) may prove difficult or impossible to change.
Considering that, with enough of your information, adept thieves can build profiles sufficient to completely impersonate you and borrow money, claim state benefits, and even commit crimes in your name. You may never be able to say that the threat of a fresh impersonation has been eliminated. You are stuck with your identity; for the thief, your identity is merely one costume in the closet.
In the U.S., credit-reporting agencies collect data on people without asking (or needing) their consent. In fact, you must pay them to refrain from selling your data, which does not mean that they delete it. Thus, even data subjects who have asked for their data not to be exposed can still lose it in a breach.
Asymmetry and structural impediments to improvement
Optimization of one variable leads to fragility in some other variable; for example, a small economy in staff numbers, out-of-hours cover, software tools, or backup measures can have unpredictable costs further along.
- Post-mortem causes will focus on proximate cause, leaving out root causes (link), which are more likely to reflect risk-enhancing management choices
- Asymmetry of responsibility – Personal and organizational motivations are not the same
- Proximate causes are cited in public, but Ultimate causes are generally not revealed, almost a guarantee that underlying organizational vulnerabilities will remain unaddressed
- Lack of processes, or failure to follow them, is likely to be a factor. Processes are explicitly de-emphasized in Agile development practices (link).
- Lack of accountability – decision-makers may be officially or effectively shielded from personal loss
- Global trends (outsourcing, offshoring, cloud, cost-cutting) either spread data around, increasing the number of targets, or add vulnerabilities.
- Outside of the EU, the GDPR may be unenforceable, providing a way to evade privacy restrictions
- The GDPR is an EU regulation (which has the most effect within its borders) attempting to impose rules on a borderless, global internet. I consider it a first step toward elevating privacy to a right and personal information to a kind of property (link), a measure in direct competition with the profitability of personal data, a set-up for ongoing conflict
- Even a country with binding treaties on data privacy may prove to have a legal system that is not effectively usable. This difficulty has, for example, affected attempts by Italy to manage its problem banks (link).
Before the internet, the slowness and cumbersomeness of communication meant that data theft was a person-by-person affair, for example, stealing useful postal mail, such as a credit card, from someone’s mailbox. Now, with the internet, one may steal a million credit cards almost as easily as one.
The push for privacy will be a long struggle
Privacy invasion is now one of our biggest knowledge industries. The more the databanks record about us, the less we exist. Marshall McLuhan, Probes, pp. 334 and 357
There is a fundamental problem of privacy in the internet age. This problem is being brought to a head with measures like the GDPR, which pre-suppose that simply saying “make it so” (like Captain Picard on Star Trek) will be sufficient to solve the problem.
The GDPR is a counter-push against the looming loss not only of personal privacy but legal identity. As such it threatens to turn established practices that depend on personal legal identity (citizenship, credit, pensions) upside down.
It is even possible that the GDPR is too little, too late, and that a long-term solution will be one that is adapted to the new technologies, for example, a system based on blockchain or quantum keys (link). The impact of such a transition is beyond assessment at this stage.