On March 1st,  I was invited to speak at the CampIT conference on Enterprise Risk/Security Management at Rosemont Convention Center.

Before me there were two speakers. The first presenter spent an hour presenting the story from the trenches of technology and explaining how scary it is that bad guys from all over the world, including former Soviet Union, China and elsewhere (and from within the United States) with clearly malicious intent are out there to cause financial and reputational damage to all sorts of companies. It is a familiar but true story that we all have heard in various security conferences, read numerous articles on and agree that more needs to be done to stay one step ahead of the bad guys.

One point caught my attention in that presentation was the fact that it was 1998, some 14 years ago, the first story came out coining the now familiar and rather stubborn problem called SQL Injection attack.

Like many other common Application coding problems, SQL Injection continues to be an issue that isn't going away despite so much energy invested in educating the application development community and investment in application scanning tools such as AppScan, Hailstorm and the like.

SQL Injection continues to be one of the most prominently reported modes of attacks that have been used in causing data breach in publicly reported incidents and there is no reason to believe this is not the case in majority of unreported incidents as well.

The problem in my view is not that we do not understand the issue, neither is it that we do not know how to fix it. In fact the problem is something totally different, and it is the same problem that gets in the way of solving many other security issues, and that is the classic disconnect between Information Technology geeks, of which Information Security Technology geeks use the most complex technology language there is, compliance focused auditors and business executives.

Technology folks continue to invent terms and acronyms at a faster pace than even many insiders can begin to comprehend the meanings of, compliance and audit regulators can't stop harping on standards or regulatory terms which mean very littlle to the business executives (other than a simple translation that they must pay auditors and tell IT guys to do what the auditors want so they can "pass" the audit as a cost of doing business).

I think this is where IT Risk Management discipline is uniquely positioned to bridge the gulf between these very disjointed groups and help to enable effective communication of risk in non-technical terms to the business and guide technology gurus to begin communicating technology issues in ways that helps them get the support they need to effectively respond to issues such as this.