SQL Attack and the Largest Data Breach in US History

CNET’s Elinor Mills wrote an article today about the indictment of three men in the largest US data breach on record. Her article details how three system crackers, two Russians and a man from Florida,  allegedly stole data relating to 130m credit and debit cards and conspired to sell these to others. The story has also been picked up by BBC News.

The hack involved using SQL injection, a technique that was pioneered back in the PowerBuilder client/server days. Many people believe that the attack reached its zenith back then, and is of little real threat today. Clearly, this is not the case.

Indeed, in the services world, SQL injection remains a powerful and often used exploit. Here at Layer 7 we developed technology to defeat this many years ago. We use the acceleration technology in SecureSpan Gateways to scan for SQL attack signatures in messages, blocking transactions that test positive for SQL attacks.

Good security should be simple to apply. If it’s easy to implement, people will use it. Here’s what a policy with SQL injection protection looks like in the SecureSpan Gateway:

It doesn’t get much simpler than this–and that’s the point. Good security must be simple to comprehend, comprehensive, and broadly applicable.

Now, if you click on the SQL attack protection assertion, you can configure for particular attacks. This is important, because databases respond differently to certain signatures:

Can a single programmer write similar protections into his or her code? Absolutely. But do they? Well, Elinor has drawn our attention to the potential cost of not doing so. This kind of security is best applied consistently across all applications.  It’s just not realistic to assume developers will always do this correctly (or at all). Governance of services needs to be done by a dedicated security officer, one who understands the problems, and is disconnected enough from the application development process to be impartial. You separate development and QA for a good reason; sometimes you need to separate development and run time security enforcement for similar reasons.

If more organizations realized there were strong technical solutions like SecureSpan that augment their overall security and governance programs, then maybe we would hear less about massive breaches in privacy and trust like the one above.

The last word from the ever-brilliant xkcd: