On Wednesday, the Ponemon Institute released the results of a new study conducted for DB Networks. In it, 65 percent of the respondents said that they've experienced one or more SQL Injection attacks in the last 12 months. In addition, each incident took an average of 140 days to discover, and 68 days to fix the issue.
"It is commonly accepted that organizations believe they struggle with SQL injection vulnerabilities, and almost half of the respondents said the SQL injection threat facing their organization is very significant, but this study examines much deeper issues," commented Dr. Larry Ponemon.
But there's a problem.
When it comes to preventing SQL Injection, those who took part in the study said that protective measures are lacking, and 52 percent of the respondents said they don't take any precautions, such as code audits and validation checks.
Yet, as mentioned, nearly half of the respondents said that SQL Injection attacks are a significant threat. Moreover, 42 percent said that they believed that SQL Injection is a contributing factor in most breaches.
The lacking prevention can be explained in part because only 31 percent of the respondents say their organization's security / IT teams possess the skills, knowledge, and expertise to detect an SQL Injection attack.
The sample size for this study was small, only 595 respondents across 16 verticals. However, the problem of SQL Injection isn't so small; in fact, this problem has existed since 1998.
Part of the reason SQL Injection exists is because on the criminal's end, it works. There are several tools on the Web that automate SQL Injection, from scanning for vulnerable hosts, to harvesting data from the database - and for most criminal's that's the only thing they need to compromise data.
For businesses, the issue is a bit more complex. Developers are paid to code, but security still isn't a primary function when a project needs to be delivered on time and under budget.
Code development has come a long way since 1998, but things still slip through the cracks. Those small mistakes that fall between the cracks are the same mistakes that turn into large breaches. This is why code assessments and continual monitoring of applications and data bases is encouraged, or outright mandated.
Still, SQL Injection happens with regularity, and the aftermath of those incidents can be costly and embarrassing (in a PR sense). Obviously, DB Networks has a horse in the race when it comes to preventing SQL Injection, but so do several other vendors. But the basics can often solve the most basic SQL Injection issues, such as those outlined by OWASP.
Still, no matter how your organization deals with SQL Injection, the important part is that it's addressed. It isn't easy, but given the value placed on data, both inside and outside of the company, it's worth the effort.