Have you recently worried about security in your own applications? No? Well, you should! Contrary to popular belief, application security is a problem that concerns all of us developers, not just the folks at Microsoft. People have any number of excuses why think they do not have to worry about the issue. "Why would I be a target?" many a developer asks. Or "My app is secure, because I implemented my own security mechanism," others may claim. Yet another group may announce that they "use certain security features" to make their app rock-solid.

Humbug! Statements like the above are clear indications that people have not even begun to comprehend the scale of the problem on our hands. The number of applications we all use daily that threaten our computing wellbeing is a catastrophe. But what can be done about it? And more importantly, who can do it?

Comprehending the Problem

The first step toward fixing the security problem is to educate yourself about the current situation. Many developers underestimate the threat because they do not understand the options attackers have at their disposal.

Developers know a lot about creating code that works in an intended way. Hackers know a lot about making existing code work in unintended ways, a huge difference in skill set. The only way to prevent software from performing unintended tricks is to understand how hackers work.

Attackers have all the time in the world to find the single security vulnerability that they need. Developers, on the other hand, have limited time to prevent what seems to be an unlimited number of potential security issues. The only way to approach the problem is to start out with a good set of knowledge about how the vast majority of attacks are accomplished.

We live in a world where even low-skill hackers (often referred to as "script kiddies") can execute an attack on every single computer that is connected to the Internet in a matter of days! So why would an attacker exclude you individually from that attack? It is unlikely that an attacker has the ability to single you out in such a fashion. The fact is that attacks happen every day. Many succeed. Some we hear about, but only if a very popular software package (such as Outlook, Internet Explorer, or SQL Server) was involved.

I recommend that you read "Writing Secure Code, 2nd Edition" by Michael Howard and David C. LeBlanc (MS Press, 2002), an absolute necessity for comprehending the issues. Developers who do not educate themselves about security issues should have their licenses revoked. (If ours were a licensed trade, that is.)

Taking Charge

Once the problem is understood, it is time to take charge. I often hear the opinion that security is Microsoft's problem, and Microsoft's alone. But this can't be right.

Just as every single line of code has the potential to introduce a bug, every single line of code also has the potential to introduce a security vulnerability. Every single line of code you write has a certain degree of security. Making security as tight as possible is a task that is up to you, not just Microsoft.

The majority of developers know very little about writing secure code. The .NET Framework and the CLR have introduced a great number of features that are geared toward making the software we write more secure. Some features, we get by default. Buffer overruns, for instance, are not as much a concern for the managed platform as they were in the past.

A mechanism called Code Access Security (CAS) can be used by .NET developers to significantly increase an application's security. Recently, I was involved in a panel discussion at a popular developer's conference. When the audience was asked who was aware of CAS, not a single arm was raised. Ouch!

Working Toward a Fix

We all need to work together to fix the security issue. We need to work on code one line at a time. As someone pointed out correctly, only a turned off computer buried under 1000 tons of solid concrete is entirely secure, and even then, someone would figure out a way to recover it and retrieve the data stored on it. However, creating a 100% secure system is not the goal.

The goal has to be to create a system that is "secure enough." What that means depends on the scenario. For one thing, it means removing 99.9% of the most common security pitfalls. This sounds like a difficult feat to pull off, but in reality, most attacks use a limited number of known attack patterns. If you simply learn what those patterns are and how to find and fix related problems in your code, you can achieve this goal.

"Secure enough" means that the effort it takes to break into a system is greater than the possible reward. For instance, if it takes an attacker a million dollars to steal data worth $100,000, the system is probably secure enough. When it becomes easier to ambush an armored vehicle that carries that $100,000 rather than attacking the application that handles the electronic initiation of the payment, the system is probably secure enough. If your application has a SQL injection vulnerability allowing a hacker to break into it in five minutes or less, the system is probably not secure enough.

Unfortunately, systems with vulnerabilities as trivial as SQL injection make up a very large part - possibly the majority - of today's application landscape. I encourage you to educate yourself about these issues. Then, start reviewing your code for security leaks, and fix them at once. It is time to regain user confidence and trust, one line of code at a time.

Markus Egger