We can write secure code (NOT)

Sharon and I share the same basic conclusion, WAF should be used to provide application security at run time (but of course we work for the same WAF vendor :). I think though that the reason for not relying on secure coding practices is even more fundamental.

It is true that in a hypothetical world a WAF is required for mitigating that pain in the a** one additional bug left there after the sisyphysian effort made by programmers to write secure code. However, in reality developers are not motivated by code security regardless of what security officers may want to believe.

• First, programmers (especially the ones actually writing the code) are not reporting to the IT security people. In fact they rarely interact with them on daily basis (not to say yearly basis).
• Second, programmers (and their superiors, and their superiors' superiors) are measured by the throughput they provide in terms of functional code. Numerous models for measuring programmer efficiency and performance never take into consideration the "security" of the code. Models that try to weigh in the quality of the code in terms of actual bugs found in it are hard to implement since they can only be applied post mortem and since bug metrics themselves are rather fragile.
  

So in a realistic environment programmers care only about those parameters that can be measured by their superiors. Fast, neat coding is one of them, security is not! That's it plain and simple.

Take another look at it, if an application is missing a form, or fails to complete a transaction, it will not be released. If the application can complete the transaction but is known to have some security vulnerability related to it, 9 out of 10 times it will be released. Where would a programmer put his or her attention? Yet a completely different angle is specification vs. implementation, when a programmer is writing a piece of code there's usually a clear specification document to follow with respect to functionallity (up to the color and font of particular GUI elements). However, with respect to the security of a module there are rarely any clear specifications. We all know the cryptic statements "transaction should be secure", "users should be authenticated". There is rarely a clear list of attacks to be avoided or steps that should be taken in order to mitigate those attack There is therefore no real way for a programmer to write secure code per its specification.

In view of the above discussion I can say that while it is a nice idea to have programmers write secure code to begin with they probably will never be motivated to do so. This does not mean that we should give up on trying to make them security aware, it just means that security strategies should be devised to reflect this inherent behavior and that security resources should be allocated in a manner that reflects it.

- Amichai