Over the last few years, we have had the opportunity to perform a number of application security assessments, and time and time again we have observed that individual security activities, such as penetration testing or code review, very rarely provide organizations with the long-term security results they seek. Many people make the mistake of thinking software security works like a shiny red “easy button” you can hit just before you release that will send little bots through the code to magically iron out any bugs or flaws. While it would be excellent if it were true, sadly that is not the case.

At the same time we do not want you, the reader, thinking that software security is so high a mountain that you should not even bother attempting to climb it. Instead, it is important to understand that, like any other process effort, security is by no means a quick fix. Ultimately it will take a significant amount of time, effort, and continuous improvement to make sure you are keeping the bad guys out. But once you have achieved the level of security assurance desired, you will often see benefits in other areas — for instance, overall software quality.

A Failure to Communicate

Another mistake that organizations sometimes make is to think of security issues as if they simply involved software failures. While there is merit in taking this approach, it is also important to understand how security issues can differ significantly from your average software failure. Not comprehending this difference will cause stakeholders to make assumptions about the adversary that are incorrect and, as a result, give the organization a false sense of assurance.

At the very minimum, for instance, it is important to consider that when talking about security issues, one is dealing with an intelligent and potentially powerful adversary. This adversary might go to extraordinary lengths to hide his or her activities, or perhaps cause a cascading set of failures — each of which in isolation may be small but, when put together, can have a catastrophic effect on your systems. Most seriously, the bugs and flaws that make these security failures possible might just be sitting there dormant in your application, even years after development and deployment, and again this can lull you into a false sense of security.

Bear in mind also that while you as a defender must protect against each and every one of these bugs and flaws, an attacker needs to find only one that is exploitable. With the balance seemingly so heavily tilted against you, then, it is important that any defensive or mitigating strategy account for these key differences. Such a strategy must focus not just on tactical point solutions, but on the larger problem as well.

The “fix” that is put in place must stand the test of time not only as attackers grow more powerful but also as your application and security research evolve. Such a strategy is often referred to as software security. In this and the next few articles, we will cover various elements of this strategy, stressing why they are necessary as well as why each by itself is not sufficient.