Don’t Let Your Applications Get You Down
- By John K. Waters
- July 1, 2005
APPLICATION SECURITY IS BAKED IN
- Black-hat hackers and other malicious circumventing network-based security
- It’s 50 times more costly to fix a security than it is to fix it before
software QA, according
- The key to start getting security built into start thinking of security
as a feature.
Most enterprises have figured out that firewalls, antivirus software and intrusion
detection systems, although essential to their overall security posture, no
longer provide adequate protection. Black-hat hackers and other malicious intruders
are increasingly circumventing network-based security and exploiting loopholes
These vulnerabilities are costing enterprises a bundle. The National Institute
of Standards & Technology reports that companies are spending about $60
billion a year identifying and correcting software errors. Exploited software
flaws cost the U.S. financial services industry more than $3 billion per year,
according to NIST.
Part of the problem is the changing nature of enterprise software, says Gartner
analyst John Pescatore. Databases that were once kept in centralized data centers
and accessed primarily or exclusively by apps within the enterprise’s
security fences are now connected to customers, partners and suppliers around
the world through the Web.
Another part of the problem is the nature of software development, he says.
Application development organizations
are rewarded for delivering features and meeting deadlines, so developers tend
to focus on those things. Consequently, application security becomes an afterthought,
and developers address vulnerabilities only if they are discovered after the
applications have been developed.
Not doing the security work up front can quickly become expensive. Gartner
figures it’s 50 times more costly to fix a security vulnerability on a
production system than it is to fix it before software QA.
What’s worse, Pescatore observes, the most common forms of attack—such
as buffer overflows and SQLinjections, which exemplify most of the attacks of
the past 5 years—take advantage of known vulnerabilities. “We’re
not saying that it’s app-dev’s responsibility to make software perfect,”
Pescatore says. “But it’s their responsibility to make sure that
we’re not building in known flaws.”
It’s high time enterprises began instilling in their developers the same
level of security consciousness they’ve inspired in their operations people,
says Mike Armistead, VP of marketing and co-founder of application security
company Fortify Software. “Everyone can see that the threats have changed,”
he says. “The vehicle hackers are using today is the software. But too
much of the focus is on the hackers. There will always be hackers. It’s
the software that’s letting you down.”
Defective detective on the job
Application security vulnerabilities come in many forms: flaws in the design,
implementation and/or testing of internally developed code; flaws in vendor-supplied
application infrastructure products, such as Web and app servers; tainted code
from external sources, or with code that is being outsourced, such as shopping
cart CGIs that store price information within hidden fields; and backdoors and
debug options left open deliberately within the application.
The most important thing for developers to remember about application security
flaws, says Yankee Group analyst Andrew Jaquith, is that they’re just another
type of software defect that should be eliminated as early as possible in the
development lifecycle. (See chart at the end of the article, “Security Vulnerability
To give developers a place to start, Jaquith recommends three basic strategies:
- Standardize on some library common routines for validating user
input and sanitizing output. “The most common classes of vulnerabilities
happen because applications trust user input blindly without checking to make
sure that it’s not, say, a thousand characters with some crafty buffer
overflow code tacked on,” he says.
- Use standard libraries for authentication and access control.
“In the Web application arena, the J2EE spec and .NET frameworks reflect
a lot of hard work and learning,” he says. “Developers should
leverage these as much as possible.”
- Use type-safe languages, such Java or C#. “Modern
just-in-time compilers are good enough, and hardware is cheap enough, that
the so-called ‘speed advantage’ of C/C++ or hand-crafted assembly
is no longer a factor,” he says.
“Although some developers pride themselves on knowing how to use C/C++
memory routines safely, there are many
more that don’t. Type-safe languages tend to be ‘fast enough,’
easier to learn and maintain, and well-supported—and they almost completely
eliminate the dreaded buffer overflow.”
The key to getting security built into the applications, says Gartner’s Pescatore,
is to get developers to start thinking of security as a feature. “The standard
argument is that the dev shop is focused on deadlines and whiz-bang functionality,”
he says. “OK, then managers should get security in there on that list of features
that are going to be tested as part of the formal software Q&A code integration
test.” (See related story, “CLASP
Process Helps Developers Integrate Security.”)
“It’s also important for managers to remember that software development
isn’t really an engineering discipline,” he
adds. “And when clever, innovative people create software, they are going
to focus on features and then maybe sprinkle on a little security at the end.
In their minds, they’re not the bad guys. They’re the good guys
who are trying to do something new. And we want that innovation.
The trick is to get them to start thinking of security as a feature.”
App security is a feature
“Most companies today know enough to have a good firewall and a secure
physical infrastructure,” says Garry Hallee, EVPof technology at Financial
Engines. “But they forget about the applications. If an application goes
into production with a vulnerability, that’s not something a firewall
is going to detect.”
No one has to tell the developers at Financial Engines to think of security
as a feature. The provider of retirement and financial services advice to individual
investors, retirement plan sponsors and financial institutions has been integrating
security best practices into its development processes for some time.
Financial Engines’ 75-to-80-person IT organization maintains about 2
million lines of code, Hallee says. That code base includes the company’s
engine applications, which analyze fund data and arrive at personalized investment
recommendations, as well as a user interface designed to support a growing range
of users, from plan members accessing Web-based features to call-center advisers.
The group also has to deal with a high level of data connectivity to financial
institutions—about 25 different connections, Hallee says, through an XMLbased
exchange linking to organizations such as Vanguard and JP Morgan over the Internet.
“Our normal process is to do daily builds,” says Hallee. “We
compile all our code, and then we run what we call a smoke test, which is basic
testing to make sure that when someone wrote code that day they didn’t
break something and that all the standard features work.”
Financial Engines also conducts its own internal security audits; so do many
of its customers, and it’s not uncommon for several security audits to
be going on simultaneously, Hallee says. A chief information security officer
conducts the audits and signs off on all new releases. “I’m a big
believer in clear accountability,” Hallee says. “Designating a senior
executive to be responsible for the security of the application is one of the
best ways I know to avoid finger pointing when there’s a problem.”
But a security officer is more than a scapegoat, Hallee says. He can also be
a resource for the developers, promoting good development practices.
“This field is changing so rapidly,” says Hallee, “that it’s
hard for software developers, who are worried about getting the next feature
squeezed into a release, to be up to date on everything that’s going on
in application security—important things like bad or sloppy practices
that could expose your code to the outside world. That’s where it helps
to have the CISO; they can keep up on all this stuff, because that’s a
big part of their job, and they can educate the individual contributors.”
Hallee is also a big believer in automation, which is why his company is in
the process of integrating Fortify’s Source Code Analysis tool into its
Fortify’s flagship product searches newly written code for approximately
40,000 known vulnerabilities, alerts developers to the flaws and suggests fixes.
Other Fortify products scrutinize patterns of coding behavior to find mistakes
and enable developers to try hacking their own code.
“You really need a tool that can automate these types of checks,”
Hallee says. “If you’re doing it manually, when you look at the
code for the first time, you can do a pretty good job; when you’re looking
at it for the tenth time, it’s a lot harder to give it the same attention
to detail. But with a computer program, once you get the rules in place and
the system configured—once you get it checking for the right things—you’re
going to get the same level of attention every time.”
It’s not Fort Knox all over again
As they face the challenge of building secure applications, developers should
keep in mind that they are not being asked to take on vastly new responsibilities—to
think like a black hat, to keep up with the latest security innovations, or
to build Fort Knox every time they write a piece of software, says Gartner’s
“Take some baby steps,” he advises. “It’s like security
at your home. You’ve got deadbolts on all the doors, and that’s
good enough. Chances are you don’t have dogs and laser beams. Most software
is equipped with screen doors. Start by stating in the requirements that, at
the very least, if somebody leans on the door, it won’t fall in.”
Security Vulnerability Testing Products
|Company and URL
||Products & Features
||Hailstorm - An enterprise software suite for automated application security assessment and compliance. Hailstorm is designed to enable security experts, QA professionals, and developers to work together to assess, analyze, and remediate applications for security vulnerabilities, and verify compliance with security policies.
||Prevent and Extend - Prevent automatically analyzes millions of lines of software code and provides 100% path coverage. Extend allows for the creation and enforcement of custom coding rules unique to different companies.
|| Source Code Analysis Engine - A suite of products that automate security processes during development, including Data Flow Analyzer, Semantic Analyzer, Control Flow Analyzer and Configuration Analyzer. Multiple language support and x-tier tracking.
||ScanDo - A Web application scanner designed to allow enterprises to automatically conduct ongoing risk assessments to identify the vulnerability of Web applications at any stage of the application lifecycle, including development, QA, deployment, maintenance and auditing.
||inForce - The product performs an ongoing automated analysis of C, C++, and Java source code. Integrates into standard development environments—Klocwork provides integrations for emacs, GVIM/VIM, Eclipse, Microsoft Visual Studio and Microsoft Visual Studio .NET.
||Prexis/Engine - An automated source code analysis technology designed to deliver vulnerability analytics and measurement for enterprise-wide software risk management. Uses an innovative security compiler technology to pinpoint such vulnerabilities as buffer overflows, insecure access control, privilege escalations, denial of service, cross-site scripting and SQL injection.
||Security testing solutions suite - Allows developers and testers to verify that an application's security functions operate correctly. Available for Java, C++, .NET, HTML, XML and Web services environments.
||CodeAssure Workbench - Automated discovery and assessment
of security vulnerabilities and policy violations in source code. Uses static
analysis technologies and a knowledgebase of security problems to highlight
insecure code during the development process. For programs written in Java,
C and C++.
||DevInspect and SecureObjects - Tools for constructing secure Web applications; tightly integrated with Microsoft Visual Studio .NET 2003. SecureObjects is used to identify weaknesses, validate inputs, manage security logging, and automatically fix vulnerabilities; DevInspect is used to scan components to verify that existing vulnerabilities have been fixed and that no new ones have been introduced.
||AppScan DE - A real-time security testing and coding tool for Web app developers. Automates testing, produces defect analysis, and offers recommendations for fixing the security flaws it detects. Also identifies the location of each defect, produces detailed inline fix recommendations, and helps developers perform a granular analysis of each test and response.
process helps developers integrate security
More on ADTmag.com
IPLocks lays down laws
of risk management
By John K. Waters
RSA provides policy-based
By John K. Waters
Traveling at a zillion
events per second
By John K. Waters
PHOTO-ILLUSTRATION BY ANN ELLIOTT CUTTING