Why use development standards?

 These days, it seems like most companies have a standard for everything…

• Password standard – to make sure that we don’t simply leave the keys to the front door under the welcome mat.
• Acceptable use standard – to make sure that employees aren’t playing WoW all day or hosting warez on the company servers.
• (*)^11 standard – if you want to be PCI/SOX/HIPAA/* compliant.

Standards are meant to define what is acceptable or prohibited in accordance with company rules. Beyond achieving industry/legal compliance and when done right, these standards not only help employees determine right from wrong, they allow the company to operate knowing that everyone is on the same page.

Unfortunately, most organizations either overlook product/software development standards (or coding standards) or do such a poor job at defining the expectations that the development staff are left to code according to what they know best, or what they’ve done at previous employers. For seasoned and experienced developers, this might not seem like a terrible thing, so I’m going to illustrate with an example.

Joe is developing a login user interface for the next big product at the XCompany. This interface will be displayed to users visiting the application using a web browser. Being a seasoned developer, Joe implements the password portion of the login form using the HTML attribute type=”password”.

Mark is developing the iPhone application which will enable mobile users to connect to the same application that Joe is working on. Being an iPhone user himself, Mark thinks that the way the iPhone OS handles password masking is a pain and often results in failed login attempts. Mark then talks with the product manager and together they decide that instead of masking the password according to the iPhone OS standards, they’re going to display the full text of the password field until the user leaves the password field or after 3 seconds have passed without new input from the keyboard.

Jake is developing the Android application for the same product as Mark and Joe. Because Jake is paranoid and a hacker by night, he decides that the Android standard for handling passwords is too insecure and decides to totally mask the password field. Note: Android default behavior is to display the last letter typed in the password field for 2 seconds before masking.

While Mark’s approach might be acceptable and justified from a usability standpoint, and Jake’s approach might be acceptable from a security standpoint, we now have an issue where products from the same company are different in the way they implement the same functionality.

To make matters worse, without software development standards junior developers with little prior experience might end up introducing some major security vulnerabilities into the corporate applications. Lets explore another example.

Joe, Mark, and Jake are all senior developers with years of experience under their belts. In the past, their applications have been torn apart by hackers leveraging input based security flaws. As such, they’ve learned that all input must be validated prior to being consumed by the application.

Martin is the latest hire on the development team. He’s right out of college and this is his first real software development job. Eager to please, he takes on the responsibility of implementing the Search feature in the application. Bill, the project manager, agrees since the task is rather simple, all Martin will have to do is invoke the well documented search appliance API which then searches the back-end database for the results and display them back to the user. Martin quickly implements the search API and not knowing any better, doesn’t escape the user provided inputs before sending them off to the search API – now we’ve got an SQL injection vulnerability introduced into the system. (security folks, humor me, assume the API doesn’t escape input either).

While the first example seems rather benign, end users might interpret these differences as a failure to do proper quality control – which might be disastrous to the brand image if we’re talking about a major financial application. The second example leaves no room for interpretation, the lack of guidance for a new developer to lean on has introduced an avenue for attackers to steal your customers’ information or adversely impact the application by modifying or deleting critical information from the database.

If you don’t have a software development/coding standard in your organization, or if you feel that the one you have now is inadequate, here are some resources to get you moving in the right direction:

• CERT Secure Coding Standards / More here too
• Carnegie Mellon Software Engineering Institute and Team Software Process for Secure Systems Development presentation
• OWASP Secure Coding Principles