Secure Coding: Missing the Goal

Tuesday, March 29, 2011

Andy Willingham

11146d62a6c31fb9fac8ac8ac991e08d

One of the things that we are faced with is meeting goals that often change depending on lots of different things.

Current threats, business goals/needs, projects, etc… We all have the ultimate goal of securing the data and systems that we are responsible for, at least I’d hope that we all shared that common goal.

How we go about this varies greatly, again depending on lots of different factors. I’m not one to criticize someone for doing their best but I will point out areas that I take issue with. Especially when I feel that they are doing something that ultimately will cause larger problems or are making statements that I consider to be detrimental to security, others, or even just themselves.

I ran across a blog post the other day that caught my eye due to the title “Mitigating OWASP top ten without any code.” So I saved it to read later since it is relevant to my interest and potentially to doing my job in a more efficient way (not that I code - I tried my hand at that many years ago and discovered that I don’t think like a coder and would be miserable and probably very bad at it).

But I am responsible for protecting sites, apps, and systems that are potentially impacted by the OWASP Top Ten.

As I read the post it both impressed me and made me scratch my head. I know that the author says that these things have and are working for them and I think that is great. I’m not sure that I would have done it the same way and when you add all of these things together it could be quiet costly to implement.

I do love the fact that it does implement defense in depth which is still very important. The more hurdles an attacker has to jump over the less likely he is to keep after you.

What really bothers me about all of this is the final paragraph:

All the key controls are implemented in the infrastructure. Developers can be left to coding the functionality and improving performance.

I have a hard time with this because it gives developers a free pass. Don’t worry about writing better and more secure code just finish quicker or add more “features” so we can market them to increase sales.

It also allows poorly written code into production where it is vulnerable to new attacks and also the potential failure of one of your layers of defense.

Are you be better off if something fails and risks shutting down the site/app until it is fixed or allow access to insecure code with no protections in place (just like the old days)?

If we continue to allow (or encourage) poor coding practices then we will always be behind the curve and playing catch-up with the hackers.

I’m all for infrastructure protections but not if it means we give developers a pass on writing secure code. I know code will always have errors and vulnerabilities in it just as infrastructure and other areas where we implement protections will always have their shortcomings.

The very last part of this post does give a little hope though.

The security controls can also be implemented at a company level, with minimal security involvement required per project.  Is it just that when all you have is a hammer, everything looks like a nail or is this truly a better approach?

It shows that they realize that their solution may not be the best or only answer and that they are open to suggestions.

So my suggestion is train your developers on secure coding practices while implementing these other controls so that one day you may just be able to reduce the number of total controls because your software is well written.

Cross-posted from http://www.andyitguy.com/blog/?p=986

Possibly Related Articles:
3843
OWASP Software Vulnerabilities Development Secure Coding applications
Post Rating I Like this!
39ba31c76f5b8342fdcca5189a9253dc
Barry Schrager I agree completely. A former employee of mine developed a vulnerability scanner and penetration tester for IBM's z/OS -- a very secure operating system. But, the number of vulnerabilities we have found, due to poor coding practices, is unnerving. Developers of code where poor practices could expose the systems to attack all should be thoroughly instructed on proper coding techniques.

We have found a significant number of problems in a lot of vendors' code and in installation developed code.

It puts the businesses at risk and is unnecessary.

For more information, visit www.vatsecurity.com.

Barry Schrager
1301427828
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.