Keep costly software bugs at bay with SDL

Every organization that develops software or write scripts should embrace security development lifecycle (SDL). However, it remains a rare practice. That’s a shame, because developing software with fewer security bugs better protects users and data for less money.

SDL is not just for full-time developers. I frequently document in enterprise assessments that the admin scripts and tiny programs created by network and infrastructure teams are among the most insecure software I find. They’re often in folders readable by the entire network of users or they contain a gambit of vulnerabilities. Even worse, I often spot hard-coded admin passwords within the code.

[ Master your security with InfoWorld’s interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]

All companies should implement formal SDL programs and processes within their internal programming and scripting groups. The following contains some guidance to help get you started.

Ready, set, learn Begin first with SDL training. You’d be surprised by how many programmers haven’t been taught the basics of threat modeling and secure programming techniques. A simple Internet search will reveal dozens of books and courses on SDL. Microsoft, my full-time employer, recently published a free white paper on the subject. The company is also one of SDL’s most vocal proponents and offers additional information on the subject through the Microsoft website, in the Security Development Lifecycle blog, in MSDN Magazine, and in a book from Microsoft Press on the subject by Michael Howard and Steve Lipner. Other good sources on SDL include SANS and the SEI (Software Engineering Institute).

As you craft a plan, make sure SDL is considered during the design of every programming project, from start to finish. Every program and script should have documentation covering its intended use, threat modeling, and implemented security mitigations. You might relax the requirements for small scripts, but personally, I’d still put in place some sort of formal SDL recognition and declaration.

Choose your tools wisely Make sure developers and scripters use coding tools that are tailored for inclusion in SDL programs and contain secure defaults. These tools should compile code and scripts in ways that get rid of the easy bugs. Today, many programming languages provide advanced protection against maliciousness. The ones that give memory protections, prevent buffer overflows, and implement safety checks should be considered seriously.

Don’t forget to have a list of acceptable cryptography. It should include what encryption ciphers, key sizes, and hash algorithms are allowed and not allowed, and it should be reviewed at least biannually. There’s no reason for today’s programs to use DES, MD5, or 1,024-bit asymmetric key sizes going forward.

Prevent the use of known vulnerable and weak coding structures. At Microsoft, these barred programming structures are labeled as “banned APIs.” Dozens of insecure programming statements cannot be present in code that gets to production. These banned APIs are prevented by training, by coding tool choice, and automated code review.

Today, OSes and browser code are becoming harder — although far from impossible — to exploit. Instead, malware writers have been focusing more often on the applications that run inside browsers and other applications. One common tactic is to malform data in a way that allows malicious code to run inside an otherwise innocent application. Think Adobe Acrobat Reader, Sun Java, or Microsoft Office — all these productivity applications have been used by the bad guys to sneak malicious code onto a user’s desktop.

Remember who you’re dealing with After nearly two decades of neglect, privacy protections are now considered one of the outcomes of SDL. Over the past few years, company after company has come under legal and legislative review for not doing enough to protect their customers’ or users’ privacy. Make sure your SDL program includes privacy considerations and review as part of the process.

Any program should have secure defaults. That was a big lesson learned by Microsoft over the past half decade. Defaults are what most users take, so implementing safe choices provides a tremendous amount of value. When a security decision is presented to the end-user, it should default to the safest choice or fail safe.

Coders should always work hard to make sure their applications consider all input as untrusted and work to prevent unsafe malformations. A common SDL tactic is to use file fuzzers, programs designed to find bugs that would allow malformed data with unexpected parameters (such as random or deliberate data variations) to maliciously manipulate an app. Almost every serious bug finder today lives and dies on the strength of their fuzzer program. There are many free fuzzer programs on the market, although commercial ones tend to be better, especially at determining what is simply a bug and what is an exploitable bug.

Test your mettle Secure coding reviews should be conducted by one team member on other team member’s code on a periodic basis. Coding teams might be given prizes and other bonus incentives for finding code bugs in another team’s code. Granting a free vacation day, free house cleaning, or a free golf outing with the boss for demonstrated secure coding or finding the most bugs is a terrific way to motivate teams. Most companies find better compliance using more honey and less stick.

Consider using internal or external code review or hacking teams before implementing software into production environments. Download and use free or commercial tools that are designed to find coding bugs. Make their use a normal part of the development process.

When — not if — a security bug is found in your production software, make sure there’s a program in place to quickly address the vulnerability. Don’t wait for the bug to be found before you create the response process. Make sure all found bugs can be traced to their source — who coded it, who reviewed it, what SDL tools were used, and how the bug got by. Make sure the bug or ones like it don’t exist in other software; if they do, proactively fix those programs and code segments as well. Find out how the weakness slipped through and implement controls, tools, and mitigations to prevent similar bugs from happening again. Better security is a process and a designation.

Lastly, make sure the code you buy from others is SDL-reviewed. Ask vendors and third parties to share with you the SDL programs they use in their software development processes. It’s likely that many of these companies won’t have official programs, but your prodding will help them see the need. Some companies, with sufficient influence and buying power, even negotiate the right to SDL review the vendor’s code before buying.

Even if every vendor and scripter created perfect software and scripts with zero bugs, it wouldn’t stop malicious hackers from doing bad things on a large scale. Today’s cornucopia of social-engineering malware, where the end-user is tricked into run a malicious program, will still be around. But making more secure software is a way to make it harder on the bad guys.

This story, “Keep costly software bugs at bay with SDL,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.