You Can't Always Be Proactive

Having your car serviced regularly, stretching before working out, and visiting the dentist twice a year are known to prevent engine failure, physical injury, and potentially life-threatening gingivitis. In addition, being proactive also extends to the world of information security.Indeed, experience teaches us that addressing small problems before they become large ones or multiply is the smart thing to do. But whether we actually do the smart thing is another matter entirely.

The use of strong passwords, antivirus, and system-hardening all can help prevent security disaster. Failure to do any one of these, or a myriad of other best practices, can lead directly to a data breach. Cleaning up after a data breach is much more costly and time- consuming than performing the aforementioned proactive measures. Case in point: Heartland Payment Systems says it has spent more than $32 million in response to its 2008 data breach incident. It is hard to imagine that proactively finding and fixing its SQL injection issues (the source attack-vector) would have cost even a fraction of that amount.

Basically every security measure can be argued as being both proactive or reactive, depending on a particular point of reference. Our industry's highly effective marketing efforts have many information security pros automatically associating certain solution classes and best practices as proactive, deserving or not, and others as reactive (a negative connotation) without really understanding why. Again, consider the Heartland Payment Systems compromise. While many details are fuzzy, basically a SQL injection vulnerability exploited by an external attacker led to further compromise of its internal network, and eventually provided access to the entire credit-card transaction system.

It is common knowledge that SQL injection attacks are extremely prevalent today because this vulnerability is quite pervasive, the exploit is easy to perform with readily available tools, and it is highly lucrative when exploited. Credit card and personal information are easily monetized, making them valuable attack targets. Therefore, it can be reasonably argued that organizations should be proactively monitoring their Web-enabled applications to spot and block these attacks with an intrusion prevention system (IPS) or Web application firewall (WAF). Right?

Not so fast. It can also be argued that IPS amd WAFs are by nature reactionary technologies. It would be more proactive to identify your vulnerabilities ahead of time, especially SQL injection, by performing a vulnerability assessment. Hack yourself first. Or is that reactionary, as well, since you obviously already have an application security problem?

Highly publicized reports, statistics, media coverage, and anecdotal information all say Web application code is prone to SQL injection flaws. So it would truly be proactive to conduct source-code reviews prior to production release during the QA phase.

Then again, the real root of the problem is the person writing the code. Developers must be proactively trained, either on the job or in college, about secure development practices from the very beginning. Is this proactive? Maybe. At the same time, we also haven't considered that there are already more than 200 million Websites and 17 million developers. Most of those sites are seriously vulnerable. The fact is we can't turn back the clock, and you can only be proactive once the problem is understood.

Maybe the core problem was the technology selection that allowed developers to make simple mistakes; a lack of proper database permissions that prohibit system calls; or poor system configuration management. Maybe the Payment Card Industry Data Security Standard (PCI DSS) needs to be tougher or the QSAs need to be more thorough. Any of these might have prevented the Heartland incident.

The point is the whole proactive versus reactive argument just does not make sense to me. Being proactive, whatever that really means, is not a luxury many possess in information security. Good idea or not, security is often introduced after enough value has been built into an application to justify the investment and after years of coding mistakes have already been made. We are charged with handling today's problems and advising others about how to limit the introduction of more flaws in the future. To get there, sometimes you have to put duct tape on a tail light, strap on a knee brace, or take some painkillers to deal with the problems at hand. There is nothing wrong with that, as long as we try not to make it a habit and make an effort to improve over time.

Jeremiah Grossman is CTO and founder of WhiteHat Security. Special to Dark Reading