The Depository Trust and Clearing Corp. isn't taking any chances when protecting its network from attacks. The company's 450 software developers use an automated scanning tool to make sure that security holes are plugged during the software development life cycle, not after an application has been deployed.
Baking security into the software development process isn't necessarily easy. Experts say using assessment and scanning tools slows down development, thereby increasing the cost of bringing new applications into production. Also, not all developers react positively to the changes.
Analysts say the benefits of writing secure code in the first place, rather than conducting vulnerability scans after the software has been deployed and having to patch holes, far outweighs the extra effort required.
Seven best practices for achieving application security
Practitioner's guide to secure software
An interview with security guru Gary McGraw
Before James Routh, chief information security officer at DTCC, which handles more than $1 quadrillion in securities transactions annually, integrated Secure Software's CodeAssure static code scanner into the software-development process, several of the company's top developers were invited to a four-week security training boot camp.
|
After the first week, one developer went back to a fairly recent application-development project he'd worked on and turned CodeAssure loose. He was surprised when it turned up significant gaps and vulnerabilities that neither he nor anyone else had spotted.
"When developers take time out to walk through code line by line, it becomes a very labor-intensive and costly effort. Using scanning technology, the vulnerability scans are now done automatically," Routh says. He adds that tools like CodeAssure are important, because over time they help developers become better at writing secure code. "Our experience with CodeAssure has taught us that the better the contextual help is at explaining the vulnerability, the more valuable it becomes as an education tool that developers will understand and incorporate going forward," he says.
According to Gartner analyst Neil MacDonald, a variety of application software-scanning and -assessment tools now help make applications more secure. These include both static and dynamic tools (see graphic "Application-level security toolkit"). Typically, these tools analyze the state of uncompiled code or a compiled application and produce detailed reports that identify the types of security threats found in the application, while advising about ways to prevent or correct the threat.
Where these tools are applied in the average development life cycle varies. Some methods and tools are applied in the early requirements and design phase, and others are targeted at development, quality assurance or production.
Early bird catches the worm
Both MacDonald and Forrester analyst Michael Gavin are quick to point out that the earlier such methods are introduced in the development process, the better.
"It's never too early to begin thinking about security and addressing security," Gavin says. "It's much more cost-effective to fix issues early on in the process. You have more choices with how you fix the problem, including more design choices and more flexibility."
Both analysts cite a 2002 study from the National Institute of Science and Technology that proves identifying and fixing bugs early in the development cycle yields greater financial rewards than fixes after deployment. At the same time, however, both acknowledge it's tough to apply such security practices early in development.
Applying application-security tools and activities to the development effort may also be expensive. "If you adopt more-secure coding practices directly in the code cycle, it's going to add about one-third more time to the process," MacDonald says. He attributes much of this extra time to educating and retraining developers on how to recognize and prevent security vulnerabilities, such as buffer overflows, cross-site scripting or SQL injection.
Given the complexity, education and process change involved in adding security functions early in the process, MacDonald sees most dynamic, black-box scanning tools gaining initial traction with security professionals, internal auditors and compliance professionals. These people typically employ such tools to conduct security evaluations for applications about to be released or already in deployment.
Assessment tools are also used increasingly to help sign off on the security of application code written by off-shore or outsourced developers and legacy code in operation. "Writing secure applications is great for new applications going out the door, but doesn't address the thousands of applications you may already have out there," MacDonald says. "So even though it's not optimal, a lot of these tools today are being used postdeployment."
Financial Engines gears up
One company that has found it useful to apply static code-scanning tools to applications about to be released is Financial Engines, an investment portfolio management and advisory firm that develops applications for its Web-facing online adviser service and a separate managed-accounts service.
|
Faced with strict compliance regulations and a burgeoning team of primarily Java developers comprising 40% of the more than 200-person company, Financial Engines recently began using Fortify's Source Code Analysis Suite for static code analysis and audits of major software releases before rollout.
"We have a software architect who is the champion of this particular tool," says Matthew Todd, the company's chief information security officer and vice president of risk and technical operations. "He performs the audits of the code. If he finds issues, he'll generate a report based on Fortify's compilation routine or scan. He then takes those to developers, who must come up with a plan for how to fix it. He'll also get a report from the development team on those issues prior to shipping any code."
The process ends with Todd or a member of his staff certifying that code has been reviewed for security vulnerability before their signoff.
Moving security-assessment scanning in-house was a change from previous years, when the company brought in experienced auditors who would attempt to find vulnerabilities by performing penetration tests and code reviews.
Although initially skeptical about how well tools for application-security assessment could take over some of these tasks, Todd was soon won over after seeing the tools work in his own shop.
"Once we could demonstrate that this type of tool offered us some technical controls to ensure our security practices are being maintained and that what we intended to do is actually being done, it become a no-brainer to justify," he says.
Response from developers has been predominantly positive, he says. "Initially, you'll find it might be more work for individual coders, because a routine they were assigned to do came back flagged. But at the same time, they are learning how to do it better next time."
A learning experience for developers
A frequent refrain from customers is the learning benefits of such assessment tools. Allen Brokken, a systems security analyst principal at the University of Missouri, spends a lot of his time auditing applications for Payment Card Industry (PCI) compliance. His auditing expertise relates directly to industry regulations that spell out the need to obtain evidence of secure coding.
Brokken's central IT group maintains a central processing system that handles the majority of credit card payments on campus, but each department, school and college can also produce its own Web e-commerce front-end application; it's critical to review such applications before their release. Brokken uses WebInspect from SPI Dynamics to track and report on any vulnerabilities in Web applications.
That's a good thing, because only one application has ever come out of a first-time scan without a cross-site scripting vulnerability. "We used to be able to find code problems by hand. But the way we were doing it, we couldn't really help the developers solve the problem," he says. "Now, with WebInspect we have a tool that generates a report saying, 'This is broken, and here's how you fix it.'"
Any extra work involved for developers depends on how experienced they are, as well as how often they've already been audited by Brokken and his team. "If I've done two or three audits for a person, it comes back clean every time," he says. "As a security person, your job is often to tell people 'no'. With the SPI tool, it becomes basically a learning exercise. It's far more powerful to educate the developer as to what the problems are than to just point them out. Time and again, the developer comes back saying, 'I learned something from this.'"
The time savings involved with WebInspect was also an easy sell. After tracking the two days it took him to audit one piece of code by hand and write the subsequent report, Brokken was pretty impressed when WebInspect did the same thing, and more, in just 15 minutes. "The SPI report actually gave me much more information when I was done, including all the developer information on how to fix the problem," he says.
Although Brokken would like to see such tools applied earlier in the development cycle, he recognizes the quickest way for most organizations to implement these tools is still with the security team. "We do this all day long. By implementing this tool, we just saved ourselves extra time, and didn't have to change our process much. Plus it helps developers become comfortable with the idea of application security," he says.
Hope is a freelance writer who covers IT issues surrounding enterprise storage, networking and security. She can be reached at mhope@thestoragewriter.com.
| Application security experts are quick to note the different types of tools available. | |||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
