Following Equifax, Focus On Database Encryption

In the wake of the massive data breach at Equifax that has impacted millions of Americans, suspicions are arising that the company did not even encrypt its data. As hard as it is to believe that one of the big three credit agencies neglected to use encryption, a survey suggests that storing data in plaintext is a common business practice at the vast majority of IBM i shops.

Despite all the news coverage of this major data breach, critical facts and details are scarce. It’s hard to know exactly what steps Equifax’s IT department took to protect its data, for the simple reason that companies tend to keep these details secret during the best of days. During the worst of days — as it is now for Equifax with civil and criminal investigations looming and the very survival of the company at stake — such information gets locked down.

However, speculation is rising that Equifax was not encrypting the data that was ultimately stolen. The company was accused of not having encrypted the data in a lawsuit filed yesterday by the Massachusetts Attorney General, according to CNBC. The Washington Post has asked Equifax if it used encryption on this particular data, but the company has not yet responded, according to the newspaper.

There are several things that suggest that Equifax did not encrypt its sensitive data. For starters, we know what the end result was: Hackers made off with the personally identifiable information (PII) of 143 million consumers, which included names, addresses, Social Security numbers, and some driver’s license numbers. Other cyber thieves have already begun using this data to perpetrate financial crimes on the Internet.

For this to have happened on encrypted data, the cybercriminals would have to have been incredibly smart and able to hack not only the database server that held the data, but a secondary system that held the encryption keys (it’s really, really bad form to store encryption keys on the server that holds the data that’s encrypted).

However, this narrative breaks down when we consider what else we know about Equifax’s security – namely, that the credit reporting giant left a security vulnerability in the Apache Struts framework in place for two months before applying a patch. The evidence suggests that the company was the victim of its own gross negligence, rather than the unfortunate plaything of uber-hackers.

Here’s another piece of circumstantial evidence for the matter at hand: If the data was encrypted, it’s likely that Equifax would have already told us by now in an attempt to garner sympathy.

When Adobe was hacked back in 2013, hackers made off with data from about 3 million credit cards, as well as other data on 38 million consumers. However, the credit card data was encrypted, so Adobe paid a small fine and nobody really talks about that particular incident anymore, since the damage was contained with encryption.

If it’s true that Equifax did not encrypt this data, then it was not only an incredible breach of its fiduciary duty to consumers and likely a violation of some industry regulation, but it was also just a monumentally stupid thing to do.

It’s simply inconceivable that Equifax did not encrypt that database, said Patrick Townsend, a security expert and CEO of Townsend Security. “It’s truly astounding to me that they would not be encrypting that data,” he told IT Jungle. “It’s just truly unbelievable that that kind of information would not be encrypted.”

Unfortunately, leaving sensitive data unencrypted is a fairly common thing to find in the IBM i community. According to a recent Townsend Security survey, only 25 percent of IBM i shops are encrypting their data at rest, compared to 75 percent of Windows and Linux shops.

That 75/25 split was “quite disturbing” to Townsend. Why would so many organizations take such a risk with their data? Townsend figured it’s due to a false assumption that IBM i security is superior to that of other systems.

“IBM did such a good job of teaching the security of the IBM i system that people are somewhat lackadaisical in the IBM i community about protecting them, even though our systems are fully on heterogeneous networks and can be attacked,” Townsend said. “You don’t have to break into the i system. All you have to do is comprise a user PC, capture their credentials logging into the i, and you’ve got in.”

The old “security through obscurity” approach is also dead in the water, according to Townsend, who said that hackers definitely know how to get at data sitting on IBM i and mainframe systems. While the core security apparatus for these IBM servers are better than comparable Windows and Linux systems, it’s the surrounding cast of players – usually Web servers and application servers running on Windows and Linux – that are Big Iron’s Achilles’ heel.

Hopefully the Equifax breach serves as a wakeup call for the thousands of organizations that are running with essentially zero security on their servers, IBM i and otherwise. Here in the IBM i world, it’s not as if system admins have any legitimate excuses for not being aware of poor security. But just as the doctor tells you, it’s never too late to quit smoking. And it’s never too late to improve your security, either.

It’s past time for IBM i shops to get serious about security, Townsend said. “The i is as exposed as any application server in our environment, and yet clearly IBM i users are not protecting that data,” he said. “I think they’re at a high risk for loss.”

“It’s just odd because IBM did do a good job of securing the system,” he continued. “What they couldn’t do is address all the weak points that surround it. There’s a perception that the IBM i is more secure, but the reality is quite different. As all of us folks who are in the security space around IBM i know quite well, these servers are breached on a regular basis.”

In any event, it’s probably too late for government types to point to self-regulation as the answer for our data security woes. There is a serious misalignment of incentives in place with regard to data security these days. When you consider that few consumers are Equifax’s direct customers, you realize that consumers have no leverage to demand change. What’s more, many of the banks and retailers that use Equifax’s service to judge credit worthiness have had their own data breaches that gave them temporary black eyes. After paying some fines, it’s back to business as usual.

This could become the rallying cry for a United States version of the European Union’s General Data Protection Regulation (GDPR), which kicks into effect next May. “We are living in the Wild West here in the US. There are no incentives to properly protect information,” Townsend said. “I think there needs to be something like GDPR. There needs to be a federal law… to really move the needle.”

Share this:

Rise to thei can … can you? challenge at the RPG & DB2 Summit. Called intense, invigorating and rejuvenating by attendees, the Summit focuses exclusively on the IBM i development skills you need for your daily work.

Learn important new database capabilities in the step-by-step DB2 track called Design It, Build It, Secure It, Tune It. Also master the latest in practical, use-it-today tips and techniques on free form enhancements, SQL, application modernization, RSE/RDi, mobile apps, RPG, ILE, RPG & the Web, Web Services, PHP, open source & more . . . loads of detailed information that you can apply as soon as you return to the office.

One thought on “Following Equifax, Focus On Database Encryption”

I have a slightly different take on this. Certainly, data should be encrypted and maybe it wasn’t. But based on the attack model, I don’t think encryption would have helped in this scenario – http://360tek.blogspot.com/2017/09/encryption-would-not-have-saved-equifax.html
Clearly, patching was an issue. But, I’d like to see a movement toward a continuous compliance model. Security validation isn’t a one-time thing.