June 15, 2008

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

Share:
Share on LinkedIn

Posted by Imperva Blogger at 06:11:26 AM


Tags:

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a01156f8c7ad8970c011570360c68970c

Listed below are links to weblogs that reference We can write secure code (NOT):

Comments

  • Dear anonymous, I do have some :) aquaintance with OWASP. OWASP top 10 is hardly at the level of a functional spec and couldn’t' be without being customized to every application & development framework. Moreover, I'm not arguing at all against the feasibilty of conducting a thorough security oriented code review, nor I claim that there is a theoretical technical impediment to designing and writing secure code. I do claim however that practical, organizational issues are a long term impediment.

    - Amichai

  • You said, "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 therefor no real way for a programmer to write secure code per its specification"

    Have you heard of OWASP?

    Perhaps the OWASP Top Ten Project? The Code Review project? The website is owasp.org, check it out!

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.