A Q&A with Michael Sabo of DB Networks
Every month there seems to be some major company that suffers a catastrophic breach of their network, and the investigation very often confirms that the bad guys exploited a SQL issue. Yet SQL injections have been the method of choice for hackers for more than a decade. To find out why networks are still vulnerable and what companies can be doing to better protect themselves from this risk exposure, I spoke to Michael Sabo, VP of marketing for DB Networks, which creates behavioral analysis technology solutions.

The SQL injection attacks the database, which is where the crown jewels of any company are stored.

Please explain in layperson terms why SQL exploits are the dominant means for hackers to breach corporate networks.
If I had to explain it in a very basic way, it would be this: Let’s say you get a traffic ticket and you are required to go to court. When you get there, there’s a computer terminal that asks you to type in your first and last name and you put Mark Greisiger, You Are Now Free to Go. When the judge calls your name, he will essentially be telling you that you can leave. That’s what a SQL injection does: it’s an instruction entered into a data field. The SQL injection attacks the database, which is where the crown jewels of any company are stored, whether it’s financial or personal information or intellectual property. Barclays estimates that 97 percent of all records breached involved SQL attacks somewhere along the chain. It’s like asking why rob a bank? Well, that’s where the money is.

SQL injection exploits have been happening for more than a decade. Why are we not able to stop them?
It feels like it would be simple to stop, but it’s a tough problem. Most companies don’t understand the threat or if they do they haven’t put the right measures in place. While a lot of work has been done to limit vulnerability these attacks are still happening every day and it’s actually escalating because now there are automated tools to conduct them. On average every website is supposedly subjected to 70 (not necessarily successful) attacks a day. One problem is that most people look to harden the site at the perimeter and assume they will be protected. It will certainly help but it won’t completely stop an attack. Most hackers can get through any perimeter device in a half hour. Namely this is because perimeter security is based on signature files and black lists. Hackers use utilities to hide the attack (called obfuscation) such that the perimeter security measures don’t recognize it as an attack.

What are some proactive loss control safeguards a company can deploy to mitigate this exposure?
With the proper monitoring you could see attacks immediately and stop them cold. You want a product that works inside the system. DB Networks, for example, offers the IDS-6300 to do that. It works at the core, in front of the database. By the time we see an attack it has penetrated the perimeter, but since we do behavioral analysis, which tracks the normal traffic in the application and database and uses that as a model, we can recognize when a SQL statement comes through and when it’s an attack. We also do continuous monitoring, and most companies have never done that before. For example, if companies like Target had a system like ours, it would have alarmed as soon as the first record was breached, but to this day they can’t describe exactly what happened and why they were unable to see the attack. Finally, our product keeps forensic records so you can tell what happened.

In summary…
Mr. Sabo summarizes many of the issues that create cyber risk as it pertains to breaches of PII triggered by an exploited SQL database. The SQL injection exploit is continuously listed as one of the top threats facing most web applications. Many organizations develop their own internal applications. However, due to limited budgets, they might not conduct the thorough testing needed to determine whether the new code is exploitable. The allure of SQL is that it converses with the database, so as businesses continue to build and rely on internal applications — including third party cloud-based systems — one can expect that this issue will not be going away.

See also our prior Junto interview on SQL injection issue with Brandon Williams.