Best Practices to Secure Your Code

How to get your team to build secure software.

• By John K. Waters
• January 15, 2008

The app layer-not the network layer-has emerged as the most vulnerable to attack. These days, the black hats aren't getting in by breaching some security mechanism, but by leveraging the functionality of an application.

Making matters worse is the mad scramble to board the Web 2.0 bandwagon. Interactions with Web 2.0 programs aren't always initiated by the user, but through an AJAX framework, so it becomes more and more difficult to tell whether the request came from the user. Attacks on Web 2.0 apps through cross-site scripting and cross-site request forgery are on the rise.

The problem is now so widely recognized that a group of technology companies, led by Microsoft, has banded together to form the non-profit Software Assurance Forum for Excellence in Code (SAFECode) to identify and promote secure software best practices.

10 Ways to Promote Secure Coding
Clearly, the industry is finally recognizing that there's a bull's eye on its application code, but it's also finding that building security into that code is easier said than done. For many dev shops, building secure software requires a cultural shift. And besides, it's just plain hard to do. Here are 10 best practices app dev managers will want to consider as they work toward that goal:

Develop security requirements. It might be obvious to say it, but to build secure software your dev team has to know the difference between what an application is supposed to do and what it's not supposed to do. Baking clarity of purpose into the early stages of the software development lifecycle is essential.

Build "abuse cases." This is one of McGraw's lightweight software security best practices he calls "touchpoints." Also called "misuse cases," abuse cases describe an application's behavior under attack. To build an abuse case, you have to know what needs to be protected, from whom and for how long. It's a way of getting into the mind of the attacker.

Give your team code-review tools. They can use these safeguards to find mistakes before the software goes out the door. Code-review tools, such as Fortify SCA or tools from the Open Web Application Security Project (OWASP), which is led by Cruz, are especially important. Why? Code is the one artifact all development products produce. But code-review tools are designed to find bugs, so they're going to uncover at most 50 percent of the security problems. Architectural analysis is needed to uncover design flaws.

Take an agile approach. Agile software development methodologies-such as extreme programming or test-driven development-that employ incremental and ongoing iterative testing can give coders the opportunity to uncover and remove vulnerabilities early in the dev process.

Require sandboxing. Cruz has suggested that developing sandboxed applications will resolve most of the vulnerabilities in today's Web apps, from technical vulnerabilities to business logic vulnerabilities. Correctly implemented sandboxed environments reduce complexity, enforce secure coding standards and give visibility on your security efforts (see the Dec. 1, 2007, cover story, "Best Defense?").

Don't overwhelm your developers with too many security tests. If you boil the ocean and test for everything, your developers will end up doing nothing. Give them something that's manageable.

Find somebody inside the team who gets it. Baking security into an app isn't going to be natural for coders who are most often driven by the need to provide features. But somewhere in your organization is a coder who understands the value of secure coding, and maybe even has some useful experience in that area. In a leadership or mentoring role, that coder could grease the skids for a smoother cultural shift.

Get somebody from outside the team to look at the code. A fresh pair of eyes can be one of the best tools for revealing flaws that weary coders have been missing.

Remember that security is an emergent property of a software system. In other words, it's not about adding security features to a program, but avoiding security vulnerabilities in, say, the interface or database module.

Invest in education. Sign up for training at the SANS Institute. Buy McGraw's book, "Software Security: Building Security In" (Addison-Wesley Professional, 2006). Get involved with Microsoft's Trustworthy Computing initiative. Do something to get your dev team thinking about security as an integral part of the development lifecycle, and to provide them with best practices they can use.

While you're at it, bug your local universities and community colleges to integrate security into their programs. As McGraw says, we've got to teach coders about security while we're teaching them to code.