Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

SQLAndy

I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.

More On The Target Breach

Over the past week there has been information finally coming out about how the Target breach occurred. This write up in Wired and another by Brian Krebs point back to a compromise in the Point of Sale (POS) system by malware that does ‘memory scraping’. Interesting. Typically POS devices are assumed and certified to be secure, and from a PCI perspective are far better than having an employee actually touch the card at all (note, it’s still unclear if it was the swipe terminal or the register that was compromised). Understanding the source helps explain the massive scale and it’s mildly comforting – yes, Target got beat, but at least it wasn’t from storing data in clear text or something similar. It remains to be seen if the compromise happened on premise or if they arrived/were installed that way. Most of these devices are supplied hardened and have the barest amount of configuration options by design.

Memory scraping can be headed off by never having the card number in clear text. That’s not simple to do. If you’re typing it in to some client app at your office, there is a point in time where it has to be clear text while you encrypt it. The best you can do is to encrypt it quickly and then make sure you get rid of that original value – overwrite the variable, run garbage collection, etc. In theory you’d only have one card number in memory at a time and so it doesn’t seem like as big a risk as a having a database compromised, but more and more hackers are patient, willing to slowly siphon off one card at a time to get to the big score.

PCI talks about storing, processing, and transmitting data. All the database encryption in the world doesn’t help if the POS is breached at the customer end, just like it doesn’t help if a gas pump or ATM is modified with a skimmer. From the time that card comes out of the wallet/purse to make a transaction with you bad things can happen. We tend to focus on the storage piece a lot. That’s good, because that’s the obvious place for someone to try to compromise a lot of data quickly. It’s bad too, because often other security is neglected. For example, PCI has been flexible enough that you might not encrypt card data sent over an internal network, which can all too easily be siphoned off. From a SQL perspective you want to receive the data already encrypted. If it’s not, make sure you’re forcing an SSL connection or have IPSEC or something similar in place. Don’t rely on the false physical security of it being the internal network. I’ve seen companies where CAT5 traversed over a publicly accessible hallway!

Where it looks like Target failed is not detecting the movement and storage of the data on its network. Typically this is where you hope data leakage (DLP) catches things, but it’s often deployed only on outbound segments and sometimes not on segments that go to other countries due to (believe it or not) privacy concerns! FTP was mentioned as well. FTP is evil. Shut it down. Even if you’re moving data that is always encrypted, get off of FTP.

Comments

Leave a comment on the original post [sqlandy.com, opens in a new window]

Loading comments...