Don’t Let Your Applications Get You Down

Don’t Let Your Applications Get You Down

on Jul 1, 05 • by Lynn Gayowski • with No Comments

Klocwork Products Protect and Prevent Software from Malicious Activity By John K. Waters BURLINGTON, Mass. – August 1, 2005 – Black-hat hackers and other malicious circumventing network-based security and exploiting it’s 50 times more costly to fix a security than it is to fix it before software QA,...

Home » Industry Articles » Don’t Let Your Applications Get You Down

Klocwork Products Protect and Prevent Software from Malicious Activity

By John K. Waters

BURLINGTON, Mass. – August 1, 2005 – Black-hat hackers and other malicious circumventing network-based security and exploiting 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 in applications.

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 Testing Products.”)

To give developers a place to start, Jaquith recommends three basic strategies:

  1. 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.
  2. 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.”
  3. 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 development processes.

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 Pescatore.

“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


Cenzic


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.

Coverity


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.

Fortify Software


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.

Kavado


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.

Klocwork


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.

Ounce Labs


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.

Parasoft


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.

SPI Dynamics


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.

Watchfire


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.

About Klocwork

Klocwork® offers a portfolio of development productivity tools designed to ensure the security, reliability and maintainability of complex code bases. Using proven static analysis technology, Klocwork’s tools identify critical security vulnerabilities and reliability defects, optimize peer code review, and help developers create more maintainable code. Klocwork’s tools are an integral part of the development process for over 1000 customers in the consumer electronics, mobile devices, medical technologies, telecom, military and aerospace sectors.

Media Contact:
Meranda Powers
1.866.556.2967
press@klocwork.com

###

Klocwork and the Klocwork logo are registered trademarks of Klocwork, Incorporated in the United States and other countries. All other names are trademarks or registered trademarks of their respective companies.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top