Security pros push for secure code

Savvy security execs are deploying new tools to help developers with secure code.

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.

The Depository Trust and Clearing Corp. isn't taking any chances when protecting its network from application-layer 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.

Application-layer attacks on the rise
The proliferation of firewalls, VPNs and intrusion-detection systems attest to the growing security focus on the network perimeter.

As the most glaring security holes are plugged at the network layer, however, a new breed of profit-driven hackers has targeted richer hunting ground: the application layer.

Most companies use a variety of commercial and custom-developed applications for Web-driven and customer-facing activities, as well as key company functions.

In many cases, the core data repositories for these applications are ripe with highly regulated personal and financial information of great interest to potential hackers.

How likely is it that an average organization's applications could be attacked?

It's likely enough for information security organizations such as the Web Application Security Consortium to maintain a running tally of the latest application hacks perpetrated on companies. Many organizations may not yet have felt an attack firsthand, but research from Gartner also indicates it's only a matter of time. A recent Gartner research report on application security estimated that 80% of companies will suffer an application security incident by 2009.

This growing threat, along with compliance drivers like those from the credit card industry's PCI standards, have caused a growing number of organizations to look at how best to integrate application-security methods and tools into their own software development life cycles.

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.

Seven best practices for achieving application security Most software vendors that offer application security-assessment tools are the first to admit their tools should be viewed as just one component in an organization’s multifaceted approach to application security. Vendors such as SPI Dynamics, Secure Software and Ounce Labs offer training, guidance and best practices on this topic, including recommended application-security frameworks and methodologies in which their tools play a part.

Comprehensive, Lightweight Application Security Process (CLASP) is one methodology endorsed by Secure Software for building security concerns into the early stages of the software-development life cycle. It includes seven fundamental best practices:

1. Institute awareness programs.
Educate the organization on what is important and why, and who is accountable.
2. Establish an assessment strategy.
Determine what the inspection process will be and how the results will be analyzed.
3. Establish security requirements.
Ensure that security requirements have the same level of "citizenship" as all other must-haves.
4. Define and monitor metrics.
If development is not measurable, progress is impossible to determine.
5. Implement secure development practices.
Make these part of the culture: defined security activities, artifacts, guidelines and continuous reinforcement.
6. Build vulnerability remediation processes.
If it’s bad and you find it, you must be able to assess and contain the exploitation potential and collapse the problem.
7. Publish operational guidelines.
These include the safe-handling procedures for the security of an operational system. If you find something and the system can’t be fixed immediately, tell the team what the options are.
For more information on CLASP,see www.securesoftware.com/process

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-level security toolkit

Application security experts are quick to note the different types of tools available.
Shield 1Static source-code analysis tools. (Also known as white-box tools.)
How they work: These tools work like compilers and are part of a programmer’s integrated development environment. They analyze the code and identify the common security vulnerabilities they find. Most also provide a knowledge base that educates developers about the vulnerabilities and how best to correct them.
Where they are used: These tools are applied by individual developers to static source code snippets and subroutines before the code is compiled. They can be used in the early stages of development, but many organizations begin by using them for final quality-assurance or security audits before the code’s release to production.
Vendors: Coverity, Fortify, Klocwork, Ounce Labs, Secure Software and various open source software projects.
Shield 2Web application-layer firewalls.
How they work: These firewalls look at application sessions and block potentially malicious traffic. They may serve as a secure gateway for different session types, such as an XML-secure gateway for XML traffic.
Where they are used: In postproduction environments, where applications are already deployed.
Vendors: Breach Security, Citrix (recently acquired Teros), Deny All, F5 Networks, Imperva, NetContinuum.
Shield 3Automated penetration-testing tools.
How they work: These tools work like vulnerability-scanning tools, but do more in-depth testing to help eliminate false positives and better demonstrate how a potential vulnerability could be exploited in real-world settings.
Where they are used: At the end of the development cycle.
Vendors: Core Security, Immunity Security, MetaSploit open source project.
Shield 4Application vulnerability scanning tools. ( Also known as dynamic or black-box tools.)
How they work: These tools can simulate a hacker’s potential attacks. They require the application to be already compiled and running. Vulnerability reports are then produced, with the most glaring ones flagged for developers. Many focus on identifying vulnerabilities in Web applications, but may also produce reports on the degree of a code’s compliance to key regulations.
Where they are used: Part of the predeployment or assessment audit performed by a security team just before an application is released into production.
Vendors: Cenzic, NetIQ, NT Objectives, Protegrity, SPI Dynamics, Watchfire. Open source tools include Nikto and the OWASP WebScarab project.
SOURCES: FORRESTER RESEARCH, WATCHFIRE

Learn more about this topic

Consortium helps define Web application firewalls

01/23/06

Complex devices have customers uncertain about what to buy

01/13/06

Signature no longer valid

11/08/04

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies