Some Thoughts on the Target Breach

Possibly as many as forty million credit cards used at Target were compromised. A staggering breach and a cautionary tale – anyone can get beat, even a mega corp with close to unlimited resources.

My guess (no inside scoop) is that the Target IT team has had their world turned upside down –they failed (directly or indirectly). If you as a DBA can imagine not being able to restore a key database that just failed, that’s the kind of feeling that hits. Forensics investigators are digging in to everything – everything – and forensics are a big deal. Not to place blame (that will happen soon enough), but to accomplish some really important goals:

  • Establish the extent of the breach. Imagine that there is a potential of 100 million cards being exposed. The hope is that the forensic analysis can prove that only x million were truly exposed. That will make a lot of customers rest easier, but it also means that the final cost to Target is contained. Better to pay free credit monitoring for the smallest set possible. It also reduces the size of the inevitable class action suit that will follow. It also means fewer customers impacted and feels less like a complete – as in 100% – failure.
  • Understand exactly how and when and where it happened. Blame aside, you have to understand this in order to make sure you aren’t still leaking information. It’s very common for a hacker to put in place secondary malware that will activate later. It’s not enough to plug the one gap, you have to know that there are no others. To put it in human terms, imagine you found a hidden camera in your home – how long would it before you were convinced there were no others?

The team is going to hit with requests for documents, proof of processes, logs going back a year, and a lot more. The last couple PCI audits will be reviewed again and probably the equivalent of another one will be started. Compliance will be involved, as will legal, and a lot of email is going to get marked as privileged while the assessment continues. Imagine going to meeting that used to be routine, but now an attorney attends – feel the stress?

Now let’s think about the database world, what can we do?  If credit cards are stored on a system you manage, review the SQLAndy Rules for Storing Credit Numbers  and make sure you’re doing all of them, or have an equivalent process in place. Next, I’d tell you to schedule some time to review your own systems. Review the logs for the past week. Review the members of every system role. Get someone to run vulnerability scans on your systems. Double check that you’re fully patched. Confirm that your logs are being archived and retained properly. Execute password changes on all syadmin accounts and all SQL Service accounts. Will that guarantee you’re safe? You know it’s not that easy. The hard part is that all the security in the world on our systems still allows legitimate access to sensitive data. Detecting the difference between a ‘good’ user doing normal work and a ‘bad’ user emulating normal work is incredibly hard and usually has to happen further up the stack or down the stack – it’s rare that we can see someone fire the “Select * from creditcardnumbers” alert we set up.

Do the things you can do and be paranoid, because someone out there will try to beat you at some point. If you see a risk that isn’t being addressed raise it to your compliance team, from there it is a business and risk management decision.

Now we wait – it could be months – to find out how the breach happened.