How To Keep Your Company Out of the Data Breach Headlines

When I last checked, very little in the way of technical detail was known about the breach at Equifax that resulted in the exposure of the personally identifiable information (PII) of over 143 million people. The data exposed included key information like social security number, birth date, and drivers license numbers; the same information that large companies often use in combination to authenticate customers who are calling them for help or other reasons. I’m still shocked by the number of call centers that ask me for my mother’s maiden name as though it’s a secret being kept in a hermetically sealed mayonnaise jar on Funk and Wagnalls’ porch. 

There are several ways that the Equifax hackers might use your social security number to pretend they’re you. As a side note, if you haven’t already looked into “freezing” your records at the big three credit reporting agencies — Equifax, Transunion, and Experian — do not waste any time doing it (they all offer it for a nominal fee at most). 

Whenever you try to establish a financial account of some sort, the organization will invariably do a credit check based on your social security number. If you freeze your records at the big three, such credit checks will simply fail to execute, thus blocking the ability to establish any new accounts under your social security number. It even blocks you, but you have the authority to temporarily or permanently lift the freeze when you need to. Such freezing may not prevent all the potential damage in a case like this. But it will surely stop some.

Back to the breach. 

Even without the technical details, this breach and the questions it raises should serve as a massive reminder to Web service, site, and API providers about some of the key fundamentals of digital security. If the difference between the right and wrong thing to do isn’t enough to rattle your conscience, then maybe the fact that Equifax’s publicly traded stock lost 17.4 percent of its value is. A whopping $2.8 billion in market cap vanished in the blink of an eye. 

Keep in mind that that’s only the beginning. A class action lawsuit has already been filed and it’s only a matter of time before the US Government (and maybe some states) levy a world record fine against the company for the breach.  Calling it #NapkinMath, Facebook user Brian Guadenti did a back of the envelope calculation based on the FTC guidelines for fines associated with PII breaches: "Assuming only one piece of PII was leaked per user, 143,000,000 affected users at $40,000 per PII (FTC guideline) = $5,720,000,000,000. Assuming three pieces of PII were leaked per user, [that’s] $17,160,000,000,000."

And perhaps proving that the people in charge at Equifax aren’t terribly bright with your information or their own, some people will probably go to jail now that it has been revealed that company executives executed unplanned sales of their stock in advance of the breach announcement.  

And the same clowns that were in charge of your personal information, some of whom appear to have engaged in insider trading that could never be kept confidential (doh!), were also responsible for the distribution via the media of a Web URL — https://trustedidpremier.com/eligibility/eligibility.html -- for checking to see if you were impacted by the breach. Only, as you can see, the URL was not at Equifax.com. It’s a bona fide phishing pattern of the sort that we’ve been taught to avoid for the last 20 years. Even worse, as the Huffington Post has reported, Equifax is essentially turning its own mistake into a source of revenue.

Yes. These are the digital security “pros” that our identities have been entrusted to (and in most cases, we had no say in this decision). If any good can come from this debacle, perhaps the silver lining lies in a couple reminders and questions we should be asking ourselves as API providers and operators of other Web sites and services:

Is your data encrypted in both transit and it rest? Although we can’t be sure, I’ve yet to see any suggestion that the data that was stolen was acquired in encrypted form. Usually, the spin doctors will disclose a detail like that in an effort to head-off any negative PR regarding best practices. If the data was acquired in unencrypted form, that opens up a whole bunch of questions starting with where exactly was the data was taken from? Did the hackers penetrate the database where Equifax stores all its data? Or, did they somehow manage to intercept the data while it was in transit? Perhaps the cybercrooks were able to install a man-in-the-middle (MITM) attack between one or more of Equifax’s partners and Equifax’s systems in such a way that the partners' systems were fooled into establishing an encrypted line of communication with a rogue system.

In either case, the question for you is what safeguards are in place to ensure that all sensitive data is being encrypted wherever it exists (in-transit or at rest)? One of the better known API breaches in recent history involved the theft of Oauth tokens that were stored in clear text in a Mongo database. And, beyond double checking when and where you’re encrypting customer data, what other intrusion detection systems are in place for preventing various forms of attacks designed to circumvent your encryption efforts (like MITM attacks)? Lastly (on the encryption point), what are you doing to regularly challenge the functionality of your safeguards?

Scale Matters: Even in cases where the hackers are after very specific targets (as was the case in The Fappening and more recently, in the Instagram hack whose initial damage was limited to celebrities but now appears to impact a larger group), API providers and Web site operators should always remember that hackers want to run attacks that can scale. In other words, by way of code that repeatedly loops against its target in milliseconds of time, an extraordinary amount of data can be compromised. 

For example, in the case of the recent Instagram attack, Kapersky Labs initially reported to Ars Technica "that exploiting the bug was 'quite labor intensive' because each attack had to be done manually rather than using an automated script.” In other words, it didn’t scale very well. But in response to the report, the hackers wrote to Ars Technica saying "it was possible to exploit the Instagram bug in an automated way. That made it possible to steal data at roughly 1 million accounts per hour.”

So far, Instagram hasn’t confirmed or denied any of these more technical details. However, more important in this conversation is the hacker’s never ending quest for scale. What’s the relevance?

In order to achieve scale, hackers need to be able to write some sort of script or loop that repeatedly interrogates a predictable and consistent interface.  One of the chief selling propositions of APIs is how well they scale. In some ways, the situation is akin to terrorists that use cell phones. For the most part, cell phones are used to facilitate legal if not noble conversations. But there is always an element who will use a good technology for nefarious purposes against innocent people. But, do we get rid of cell phones?

The same is true of APIs. When used for their intended purposes, their scale can really help to deliver on their promise. On the other hand, that same scale is like a juicy cheeseburger to a hungry cybercriminal. We won’t get rid of them, but we have to deploy them responsibly knowing full well that not every developer has the best intent in mind.  And for service operators without APIs, you have to keep in mind that any predictable interface (like a Web page) is essentially an API. Where developers can’t find an API to breach, they’ll try to fabricate one based on what they can find. 

If you always keep this in mind, then you’re one step closer to deploying the sorts of solutions and tests that are designed to limit damage. A good but simplistic example is how many APIs are put into production without rate limits (see Equifax Secret PIN Controversy Exemplifies the Need for Rate Limits). If you’re not thinking about how hackers love scale, then you’re probably not even close to thinking about how rate limits and other solutions can slow hackers down, if not stop them altogether.

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.
 

Comments