Blog | Townsend Security

SQL Security Attacks: Same Ole, Same Ole

Written by Patrick Townsend | Feb 11, 2011 9:29:00 PM

The PCI conference is just finishing up and I’ll have more on the conference a bit later when information can be made public. One of the interesting talks was by Chris Novak of Verizon. I just want to recap some of his thoughts.

The number of highly targeted and sophisticated attacks is on the rise. We’ve heard this message over the last few months, and the Verizon study confirms this. A highly targeted attack goes after a specific companies’ assets with a lot of knowledge about the internal systems. The ability of the attacker to cloak the software is good, and the sophistication of the attack is high. These are highly knowledgeable technicians creating the malware, and they are getting good at attacking sophisticated systems like such as Hardware Security Modules (HSMs) that store or process encryption keys. The targets are usually companies with a large concentration of high value financial information. It’s expensive to launch these types of attacks, and the payoff is high. When these breaches are discovered they get a lot of press. But here’s an interesting fact: These sophisticated attacks on specific targets are still in the minority. Over 80 percent of the breaches are pretty low-tech. That’s right, amazingly most of the attacks are against web servers and most of these use SQL injection as the way to get inside. What’s stunning is that we’ve known about SQL Injection attacks for a long time. We know how the attacks are made, we know how to test for the weakness, and we know how to remediate the problem. So why haven’t we made much progress in preventing this exposure?

First, we aren’t paying enough attention to our web sites which are not directly related to credit card process. Novak used the example of an attack on a companies’ HR web site. The company posted job openings on the site and did not think it was much of a target. But attackers gained entry to this job postings web site, and then navigated through the internal network to a high value target.

The lesson? We know what to do, we just need to apply that knowledge more broadly.

We might also ask why are we still having a problem with SQL injection? Novak had an interesting take on this, too. To prevent a SQL injection attack you have to use good programming practices. You can’t just plug in an intrusion detection device and think you are safe. You prevent SQL injection by changing the way you develop web and business applications. Do you know what OWASP is? If not, there’s a good chance you are exposed somewhere in your application code to SQL injection.

The lesson? We have to get much more serious about secure programming. If you are a developer of web or business systems, you should know the OWASP Top 10 forwards and backwards. If you manage a development group, be sure everyone is trained on secure programming practices. Make it a requirement for hiring and promotion.

I will leave you with one more interesting point from Novak’s talk. In almost all breaches that Verizon studied, there was enough information in the system logs to identify the attack, but the logs were not reviewed and the attack went undetected.

The lesson? We need to monitor our system logs a lot better. This means investing in software that can automatically sort through the large number of logs and tell us when there is a problem.

There are positive changes under way at the PCI council and I will discuss these more in the days ahead. But one big take-away is that we need to do better what we already know we should be doing. This part is not rocket science.

Patrick