This blog post was inspired by a recent report of a Database Analyst at American Express stealing Credit Card data.
It’s amazing how many companies still follow a mainly “perimeter security” approach when it comes to controlling access to sensitive information—their focus is on network security using firewalls, advanced authentication options, and so on. Even with such measures, it’s very common to setup strong barriers to the outside world but very little by way of internal limits; most internal people have some level of access to servers that store and process sensitive data.
Well, there’s nothing wrong with pre-screening your stuff, or having access to the sensitive information, or setting up advanced authentication. Nevertheless, we at Pythian always hear this argument: “Our environment is much more secure if only exposed to a very limited number of people.” If, however, security stops here, this is a very shortsighted position.
Yes, having seven DBAs accessing an environment is inherently less secure than than having only two DBAs, if nothing else is done. What if, however, those two DBAs don’t have any experience in locking down a database server, and can’t reliably guarantee that it’s not exposed to all internal personnel?
How many times did they implement advanced authentication options and auditing for their databases? And what about implementing data encryption, securing all transportation channels for the data, and making sure off-site backups won’t be the source of information leaks?
What about adopting the latest intrusion detection technologies (such as Sentrigo’s products)? What about running periodic security reviews, and implementing regular database vulnerability assessments?
Fortunately, with the arrival of special laws and regulations, security has to be addressed much more broadly than simply limiting personal access, and this is especially true for North American enterprises, and I think for European companies as well.
Even though some international standards are applicable for Australian companies (such as PCI DSS, which we are implementing with a client), local regulations currently are quite weak, and when it comes to personal information loss, Australian companies and agencies do not have to disclose any leaks identified.
Another problem with implementing security for standard compliance, is that companies target passing the audit rather than trying to genuinely secure their data. Our experience having gone through security audits with our customers, is that various auditors pay more attention to different areas while verifying for compliance to the same formal standard. So having passed the audit doesn’t automatically mean the data is secure (and if you read auditor’s contract, it becomes pretty clear that they don’t guarantee that).
To conclude, I want to get back to the stolen credit card numbers and identities I mentioned in the beginning. I’m sure that American Express have good security standards and screening checks for their analysts, as well as strong perimeter security, but all that didn’t prevent an insider from stealing thousands of credit card numbers along with cardholders’ personal details.
How to make your security stronger? I guess there are many ways and a number of things to be done in the enterprise, but in any case, adding the right security expertise in your DBA team is a no-brainer decision, and any Security Officer would support it.
Share this article
2 Responses to “Database Analyst Steals Credit Card Data”
Leave a Reply