Let’s Raise the Standard of Security Knowledge

What is the best way to raise the standard of developer knowledge in the area of security best practices?

Security Skill Improvements

Photo by CarbonNYC

I ask because this is a particular pain point of mine. Personally, I must admit I am not where I should be with programming securely. However, I am definitely experienced enough to be able to spot obvious security issues in a software application. Not a month goes by, not a month, in which I do not stumble upon some basic security vulnerability in code I am maintaining or have to instruct a colleague why a particular implementation could be catastrophic. Do others feel this way about code I have produced? I hope not.

I practice some of the basics:

  • No SQL Injection Vulnerabilities
  • No Cross-Site Scripting Vulnerabilities
  • No storage of passwords in configuration files
  • No delivery of sensitive information in plain text

How can we make sure that any developer who puts new code into production knows these standards at a minimum?

I don’t want to have to teach someone again that in-line SQL is bad or that user input can’t be trusted. I don’t want to be able to look into a database and see actual user passwords strewn about. It’s not that I don’t enjoy teaching others about these things; I do very much enjoy teaching. It’s that I shouldn’t have to. There should be a minimum security skill set that any developer should have before getting paid to program.

My frustrations with this problem have been present for years, yet they have not led me to any solutions. How do we teach young developers about security? Assuming every company hiring entry-level developers had an orientation at which best practices were taught, it would still not be long before the next generation of hacks evolved and new security knowledge would be necessary. Which begs the next question, how do we all stay abreast of the most relevant security best practices?

As noted, I am not a security expert. However, I think I am often able to think about how someone could manipulate a system as I am writing code for it. Unfortunately, I tend to only notice these vulnerabilities because I am intimate with the code. My philosophy is always that if there is a vulnerability, even one that can only be known by fully understanding the code, it is just a matter of time before a motivated hacker would be able to find the exploit.

I know that I need to improve my skills. I need to be able to design software solutions to defend against security vulnerabilities. I need to innately understand secure coding tactics. I strive to be a competent developer in these areas. Where do I go to learn best practices without devoting my entire career to this expertise?

My preference would be to get regular (annual or semi-annual) training on the topics I need to improve or that most concern my industry. It would be great to be sent by my company for an uninterrupted session with security experts. Perhaps even better would be if I was able to work closely with a senior developer who was deeply experienced with security considerations. As I have said before, it is important to work in a job at which there are more experienced colleagues to learn from.

In my past experience, it seems that companies do not prioritize security enough. Sure, the boss may say that any new applications or modules must be “secure.”

The real problem, though, is that a lot of this was beyond developers’ abilities. Any reasonably sized company is going to have many developers who are good enough at writing code, but just do not have the security mindset.

From user “Dan Ellis” on StackOverflow.com

As developers, we must be pragmatic, finding the perfect balance between practicality and principles. In other words, if the boss says that an application must be secure, he or she is inherently making a tradeoff. The developer, with security as a requirement, must spend time researching what makes an application secure, how to make it secure, and then implementing the security. All this for features which are not obvious in the final application. Security features in a product usually go unnoticed (if done right) and tend to instead get deprioritized due to the pressures in the corporate world to write software on time and on budget. Additionally, developers are more likely to focus on things that they already know. Don’t you think the typical developer would be more likely to write “working software” on time with the thought that security could be added in later?

Of course this is a misguided approach, but who is going to be the catalyst for change? In my opinion, it is the responsibility of everyone involved in writing software to make sure it is secure. It is the responsibility of the company to ensure that secure practices are a part of the culture, that developers know security is a priority, and that developers are educated about best practices. It is the responsibility of the developer to ask appropriate questions about security and to raise concerns. The developer should also spend personal time learning about security vulnerabilities and how to defend against them.

I would have thought all the horror stories (e.g. here, here, or here) about software applications being hacked and security vulnerabilities causing chaos would be enough for companies to place a higher priority on security. It hasn’t worked, so I need help. What are the points of discussion to convince software development managers that this is a higher concern? Should I just tell them, “Hey, we need to pay attention to this if we don’t want to get sued?!?!”

Links:

Food for Thought:
One thing was pointed out to me from the DiscountASP.Net Knowledge Base that often times it is not a website’s security bug but instead that a developer’s machine was compromised and sites/names/passwords were scavenged allowing a hacker access to the hosted web application.

Herding Code Podcast #75: Barry Dorrans on Developer Security

The HaaHa Show: Microsoft ASP.NET MVC Security with Haack and Hanselman

Web Security Horror Stories (slideshow)

Advertisement