Emphasis on prevent. While reactive measures are obviously crucial when breaches occur, a proactive approach is also necessary when you encounter an attack as varied as injection. While you can never completely rule out an attack with so many creative applications, giving attackers as little opportunity as possible is just plain smart.
Fortunately, with an exploit as popular as SQL injection, there's no shortage of solutions, methodologies and security professionals on the other side, all actively working to negate its effects. The same preventative, systematic approach experts advise for most other aspects of AppSec apply here, too. Here are three ways to implement systematic security into your efforts to prevent SQL injection:
Put simply, treating security as a scheduled stop — let alone one implemented so late that code is ready to be tested — isn't an acceptable way of doing business anymore. Even worse, as noted in an IDG/CA Veracode white paper, entitled "IDG Study: Why Application Security is a Business Imperative," a lot of organizations and their apps don't even see that level of security oversight: The 2014 study says, "Nearly 63 percent of applications remain untested for critical security vulnerabilities." That's a skin-crawling fact considering the sorts of data these apps transmit and store.
That makes the early inclusion of security experts a necessity. If your security personnel aren't getting a chance to speak by the design phase, you're passing up a lot of valuable insight for very little cost: In the context of preventing SQL injection, for instance, a designer might help you limit the number of user input areas an app contains or come up with novel queries to sanitize before you even start coding. And those are just the things a qualified expert will come up with at a glance.
The word "systematic" implies a set of standardized procedures. Make sure security experts are in on those procedures as early as they can be useful. If you don't know an optimal time for that, ask one of your experts for help. Don't have one? Consult an expert before the "prevent" in "prevent SQL injection" becomes a necessity, rather than an option.
Preventing SQL injection and other exploits is a matter of testing constantly, usually with the help of automated tools. This more or less applies to the coding part of the SDLC, and it sticks whether you're talking about in-house code or work submitted by third-party vendors.
Let's say some new variation of SQL injection pops up. Under standard building practices, you might not notice that addition until your scheduled security stop — and only if the timing was right. A cloud-based security platform that is constantly updated with new capabilities, on the other hand, can look for the new variation without disrupting your development processes with tool updates.
Even without newfound ways of attacking via injection, however, constant vigilance is a must these days. The sheer volume of sensitive personal data — payment info, personal details, log-in credentials, etc. — being passed around and stored is, again, plenty of motivation here; between that and the reputational and financial bruising a company can take in the event of an attack, there's really no other way to go about it.
Of course, constant security means constant output — but that output doesn't necessarily have to come from human assets. While humans are certainly still integral to the overall security of a product, automated processes can now handle many tasks in the background.
From an efficiency standpoint, this is wonderful for everyone involved: Security personnel get less repetitive, more challenging tasks, bean counters get to pay less overtime for costly late fixes, etc. Then there's the simple fact that computers are better at repetitive tasks than humans, once they're given the right instructions. For example, an automated system could check your entire app perimeter for ways to prevent SQL injection in a fraction of the time a team of humans would take.
In the end, automation unlocks a lot of the benefits outlined in the other two points by design, since every line of code can be checked as soon as it's committed. If you want to prevent SQL injection, in other words, don't pass on automation.
SQL injection is nothing to trifle with. Getting a handle on it when it happens is one thing, but making every effort to protect against it before it happens is just as important of a practice.
Download the IDG/CA Veracode Study: Why Application Security is a Business Imperative for more tips on how to handle injection, especially if you're not doing anything to protect yourself now. Or check out the SQL Injection Cheat Sheet to find out how hackers exploit SQL flaws and how to fix and prevent SQL injection vulnerabilities. The risks are too big to ignore.
Photo Source: Flickr