Web Application Security: Can Developers Learn Secure Coding?

Monday, April 25, 2011

kapil assudani


Recently, I was attending the BSidesChicago conference. My buddy Jon Rose introduced an awesome brainstorming game called Builders vs Breakers - i.e. developers vs security professionals. 

The game got lots of participation from the crowd sharing their view points on roles of builders Vs breakers. One interesting question raised in this session was “Can you teach secure coding to developers or can developers learn secure coding”?

In order to answer this question, we have to review multiple aspects.  First, let’s look at the job description or a job role of a software developer position.

I can guarantee, with the exception of top technology giants (that too not all): No job description requires a software developer to have secure coding knowledge or experience in their primary responsibilities.

Next, I can confidently say more than 80% (on an optimistic note) of corporations do not have a secure development lifecycle (SDLC) process built into the enterprise project lifecycle.

Now, with a secure coding skillset missing from their primary job responsibility and no enterprise process that introduces/enforces a secure coding process, there are really no drivers for a developer to go the extra mile of introducing security into their code, unless they are security conscious or have an interest in security. The strict deadlines and pressures on developers themselves exhaust their time on projects. 

So, no matter how much secure development training is provided to developers through an internal or external security group, with the above elements missing the bad news is security is not going to be reflected in your application code.

The point is not if developers can learn secure coding, since from my standpoint anybody can learn anything – there has to be a driver/incentive for it. And if that driver is missing, you will not get what you want no matter how much training is provided.

Since I believe in solutioneering more than problem ranting, let’s look at what the solutions are to the above problems. 

Definitely, it would be a hard sell to management requesting them to recruit software developers who have the knowledge/experience of secure coding, though 10 years down the line we can expect those kind of job prerequisites for software developers. 

Next, the best option is to introduce SDLC into a project lifecycle, although it is not something that can be achieved in a short time – starting from selling the idea at an enterprise level, demonstrating ROI etc and then defining processes, reviewing vendor technologies and so on – it must be a part of an enterprise security strategy by all means and prioritized high.

Until SDLC is realized, I would be inclined to say that “breaker” is the way to go for an organization - i.e. have your security team perform manual or automated security testing.

I am a strong proponent of the principle “In order to sell security, the security advice in most cases if not all, should make an IT personnel’s task easier rather than tougher” or simply “be a business enabler”. The only other case in which security advice would be a sell is when we are talking about critical security issues or industry regulations, all else is a FAIL. 

In line with this principle, another alternate methodology for establishing secure coding practices in an enterprise that will make a developers job easier is establishing a secure coding frameworks through secure class libraries, API’s etc. One really good example is OWASP ESAPI application security control library. 

The best way to achieve this is for the security group to partner with the development team leads/architects and build a secure framework that has reusable components to be consumed by any application. 

The secure framework is built around the primary security controls of authentication, authorization, access control, auditing, and cryptography. 

Following are the benefits that get realized with enterprise secure coding frameworks:

  • Achieves code standardization across the enterprise, which can be applied updates as required without touching each and every application
  • Makes the job of developers easier, now they don’t have to write custom code for security controls for each new application, so they have more time
  • Due to standardization of code for security controls, the job of security code review/penetration testing becomes more streamlined and efficient
  • Lower risk applications across the enterprise, compared to the band-aid approach of testing fewer applications due to resource, time or budget constraints
  • Collaboration between builder and breaker teams fosters good relationship which in turn fosters credibility of the security team and raises security consciousness across the enterprise

The bottom line is that the goal of a security team must always be to provide “value” to the business. Many organizations spend enormous amounts of money on penetration testing, and teaching developers secure coding year after year etc which is more of a band-aid approach to the problem than a comprehensive strategy oriented approach.

Compare this to a concerted one time effort of building the secure libraries or what I call secure coding frameworks at an enterprise level that will buy all the above mentioned benefits.

Clearly, the value is realized in the latter methodology, since the enterprise has introduced security oversight across the board for all applications that are at much lower risk vs reviewing a chosen few.

Possibly Related Articles:
Information Security
Software SDLC Web Application Security Development Secure Coding Policies and Procedures
Post Rating I Like this!
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.