Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Security Management

11:00 AM
Joe Stanganelli
Joe Stanganelli
News Analysis-Security Now

My Cybersecurity Predictions for 2018, Part 4: Regulating Encryption

Joe Stanganelli wraps up his 2018 cybersecurity predictions with a look at what's coming in laws and regulations around encryption.

Encryption isn't an all-purpose security salve, but it's one of the easiest concepts for layperson politicians to understand -- and get constituents to rally around. That's why my next cybersecurity prediction for 2018 involves this phenomenon.

Okay, so technically, 2018 has already begun as I pen (type) this prognostication. But I say that it's early enough to count -- especially because the Internet is already awash with the predictions of many other subject-matter "experts" in the cybersecurity space.

Almost all cybersecurity predictions -- particularly those found in archetypal "end-of-year" crops -- tend to fall into one or more of the following categories:

  1. Black-hat attackers will diversify their attacks.
  2. Hackers will do damage that costs a lot of money.
  3. Current trends will continue to trend trendily.
  4. Everything will get worse.
  5. You need to buy our product or service. (Implied.)

Thus, these "predictions" are so overgeneralized and obvious that the analysts who make them are almost always right in some way. This allows them to boast a ~100% track record.

As for me? I don't care about batting average. I'm a slugger. I'm swinging for the fences with specificity.

In part three of this 2018 cybersecurity prediction series, I explained my decidedly un-eager anticipation of a roadway tragedy inflicted by a self-driving car -- and the attendant consequences. (See: My Cybersecurity Predictions for 2018, Part 3: Protecting Killer Cars.) In earlier parts (and, for our purposes here, more relevantly), I foretold counterintuitive consequences of the approaches of data-paranoid EU regulators and the "lighter touch" Trump Administration regulatory bodies in the US, respectively. (See: My Cybersecurity Predictions for 2018, Part 2: GDPR Hype Is Hype and My Cybersecurity Predictions for 2018, Part 1: Following Trends & the FTC.)

Now, in part four of my series of 2018 InfoSec predictions, I prophesy the coming of major InfoSec regulatory changes.

2018 Prediction No. 4: Headline-grabbing breaches will lead to serious pushes for regulations and/or laws that specifically require encryption of data at rest in certain sectors. This will not happen in the US.

Time and time again, as data breaches and major organizational outsider attacks have captured the attention of the press and the public alike, compromises have involved unencrypted data at rest. Critics gave Anthem, for instance, an earful over this after the health-insurance carrier suffered a substantial data breach in 2014. Apologists contend that the lack of encryption in cases like these doesn't matter because compromising administrator access makes encryption a moot point.

This argument, however misses several fundamental points about the value of encrypting data at rest. For starters, format-preserving encryption (FPE) limits the number of accounts that can legitimately access user/customer data via data masking -- so that only those with a genuine need to know (if, actually, anyone) can access actual, accurate data on users and customers -- while making such data appear as accurate without actually being accurate for the purposes of DevOps and the like.

More importantly, though, thorough data encryption and consistent data-stewardship practices solve a larger cybersecurity problem: Enterprises don't know what data they have where.

How many times have we read about a major data breach that turned out to be much wider in scope than initially reported? How many times have we read about a major data breach with damages compounded by imperfect data-encryption practices?

The case of Adobe is perhaps most instructive. On October 3, 2013, Adobe Systems CSO Brad Arkin reported in a company blog post that PII (personally identifiable information) and other customer-history and financial information from 2.9 million customer accounts had been compromised in an attack earlier that year.

Later that month, Adobe amended that claim by noting that at least 38 million customer accounts -- more than 13 times the number originally thoughts -- had been compromised in the attack. In the weeks to come, it turned out that that number may have been more like 150 million. Worse, the corresponding data dump revealed that Adobe (1) had neither salted nor hashed its encrypted user passwords, and (2) had left user password hints in plaintext -- easily allowing security researchers to decode popular passwords (if not, potentially, break Adobe's entire encryption).

Yet worse than that? The attackers apparently accessed this data via a backup authentication system that lacked appropriate security controls.

The upshot is that Adobe not only had no idea what it was doing, but simply could not have had any idea what it was doing because it had no idea what data it had where and how well (or not) its datasets were respectively encrypted. Had Adobe both kept track of its data stores and implemented consistent enterprise-cloud encryption on data at rest across the board, this disaster could have been at least dramatically mitigated.

The saga of Yahoo is more recent (extending into 2017) -- and bigger. Two years ago, Yahoo reported a breach occurring in 2013 that had impacted 1 billion(!) Yahoo accounts -- making it the largest data breach ever. It was not until just this past year, as the company was working to push through its acquisition by Verizon, that it was revealed that -- whoops! -- it turned out that all 3 billion-something Yahoo accounts had been compromised in the 2013 breach.

Yet more recently -- and more distressingly to North Americans - Equifax initially reported that its megabreach last year compromised millions fewer US residents than it actually had (and, strangely, thousands more Canadians than it did).

To wit, in these cases and others, the public was "assured" that each respective data breach impacted only X number of users -- until further investigation later revealed that that figure was more like X × Y. More to the point, the sheer architectural and infrastructural complexities of enterprise networks that so confuse CSOs and CISOs in their initial breach-impact assessments almost certainly contribute to allowing breaches of their systems in the first place.

"I remember talking to a CIO who said that he lives in fear because he doesn't know where his data is -- and it's just a matter of time [before a data breach]," Chris Richter, then senior vice president of Global Managed Security Services at CenturyLink (then Level 3 Communications), told me in an interview last year for Security Now sister site Telco Transformation. (See: Level 3's Richter: Simplicity Strengthens Security in the Enterprise Cloud. "He wakes up sweating because he's thinking one day something's gonna get out; he can't keep a handle on it."

This is a big problem. Not being able to identify what data you have or where it is means that you further can't identify your most valuable or your most vulnerable data.

But even if that wasn't true, a breached enterprise's lack of data-at-rest encryption is something that regulators and journalists love to focus on. Even if it doesn't directly contribute to a data breach, it's still recognizable as a symptom of imperfect security. Data breaches can be difficult for politicians and the public to understand, but "encryption versus non-encryption" is a simplistic, binary subtopic of InfoSec. If your organization is in the political crosshairs because of a recent data breach, the revelation that you didn't encrypt is something is as politically damning a fact as anything. Substandard encryption and poor data-identification measures can potentially be more brand damaging than the fact of a data breach itself (as in the case of Adobe) -- if not make the breach worse (as also in the case of Adobe). Uber, for instance, might have avoided one of its latest scandals -- a data breach of 57 million users that it kept under wraps until November -- had it implemented FPE on the production data that its developers were using. (See: Uber Loses Customer Data: Customers Yawn & Keep Riding and Security Executives Respond to Uber Breach News.)

More major hacks and data breaches will occur in 2018. Any fool can (and, in some cases, does) predict that and call it a day. But, inevitably, news will come out about each breached organization's security practices -- and, inevitably, one or more of those organizations will be shown to have failed to encrypt their breached data. Falling hard on the heels of 2017's mega-hack headlines (notably, those involving Yahoo, Equifax, and Uber), it seems further inevitable that some policymaker somewhere will insist upon stronger laws and/or regulations to ensure that individuals' data remains encrypted even at rest -- at a significant potential detriment to global business agility.

Outside of the US, anyway. Compared to, say, regulation-happy EU bureaucrats, the current US regulatory climate under the Trump administration represents that of a "light touch". Moreover, after the December 2015 shootings in San Bernardino, California, a case in which encrypted iPhone data was deemed crucial, many "tough on crime" and national-security hawk lawmakers across the country demonstrated their antipathy toward the private sector leveraging unbreakable encryption. Finally, complex US regulatory schemes like HIPAA have certain data-accessibility requirements that make enhanced encryption deployment more difficult from a compliance perspective. Thus, there is far too little incentive stateside for policymakers to meddle with data-encryption requirements any time soon.

Maybe that's a prediction for next year.

Related posts:

Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate-communications and data-privacy consultant, writer, and speaker. Follow him on Twitter at @JoeStanganelli.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...