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

1/5/2018
11:00 AM
Joe Stanganelli
Joe Stanganelli
News Analysis-Security Now
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-20491
PUBLISHED: 2021-04-16
IBM Spectrum Protect Server 7.1 and 8.1 is subject to a stack-based buffer overflow caused by improper bounds checking during the parsing of commands. By issuing such a command with an improper parameter, an authorized administrator could overflow a buffer and cause the server to crash. IBM X-Force ...
CVE-2021-22539
PUBLISHED: 2021-04-16
An attacker can place a crafted JSON config file into the project folder pointing to a custom executable. VScode-bazel allows the workspace path to lint *.bzl files to be set via this config file. As such the attacker is able to execute any executable on the system through vscode-bazel. We recommend...
CVE-2021-31414
PUBLISHED: 2021-04-16
The unofficial vscode-rpm-spec extension before 0.3.2 for Visual Studio Code allows remote code execution via a crafted workspace configuration.
CVE-2021-26073
PUBLISHED: 2021-04-16
Broken Authentication in Atlassian Connect Express (ACE) from version 3.0.2 before version 6.6.0: Atlassian Connect Express is a Node.js package for building Atlassian Connect apps. Authentication between Atlassian products and the Atlassian Connect Express app occurs with a server-to-server JWT or ...
CVE-2021-26074
PUBLISHED: 2021-04-16
Broken Authentication in Atlassian Connect Spring Boot (ACSB) from version 1.1.0 before version 2.1.3: Atlassian Connect Spring Boot is a Java Spring Boot package for building Atlassian Connect apps. Authentication between Atlassian products and the Atlassian Connect Spring Boot app occurs with a se...