Original URL: https://www.theregister.com/2006/11/06/armistead_on_bad_software/
Software bad across the board
Fortify talks application security
Posted in Software, 6th November 2006 09:47 GMT
The security problems that hit the headlines are those in web browsers and operating systems, but application security is in many cases a bigger risk.
I spoke to Mike Armistead (vice president, products) at Fortify Software, specialists in software security solutions, takes a far broader view of where the risks lie.
"Most of the prevailing security strategy is to build big walls, walls around the perimeter of an organisation so you keep the bad things out. People writing applications extend the enterprise outside of these walls. We've seen that everywhere through web-facing applications connecting suppliers and partners, supply chains, financial service chains, even the opening up of employee self-service type portals. All these applications house private information. The new reality is that there isn't a perimeter to these enterprises. Protecting them is no longer something that can just be done by building a big wall. Gartner estimate that 75 per cent of all attacks occur at the application level."
I asked Armistead if some programming platforms were more secure than others. "Generally, we've found software is equally bad across the board," he says. Is open source more secure than commercial? From every kind of evidence we've seen it's not. There's the argument open source has more eyes on it, but the counter is that the people contributing the code are still working towards, hey, let me add my new cool thing. We've found things in open source software that have been there for a number of years.
"The problem is twofold. Coding and testing applications for security is difficult, and developers are generally rewarded for features and time-to-market, not for the security of their code. Armistead says the problem cannot be fixed solely by educating developers. "Many of these vulnerabilities lie between assumptions made by team members, like thinking another group is doing the checking. Something doesn't get checked and a SQL injection vulnerability pops up."
How then can applications be secured? "You're not going to be able to do it from one magic silver bullet," says Armistead. "We believe that at development time you'll try to identify and analyse those flaws, but at the same time you want to be able to harden the infrastructure."
Naturally, Fortify would like to sell you its tools and services. These start with static analysis. Fortify Source Code Analysis (SCA) applies thousands of rules to your code, covering data flow, control follow, semantic analysis and code structures. It works with compiled languages including C/C++, C# and Java, but not currently with dynamic languages such as PHP, Perl or Ruby. "We expect that in the future we'll be going in that direction. Those are a little harder because they're interpreted and on the fly."
Static analysis is not sufficient on its own. It is also important to test and analyse the running application. Fortify Tester is a plug-in for Microsoft Team System which does "Black Box" testing, so-called because it simulates attacks. You can either point it at a URL, or else specify an existing Team System web test for Fortify Tester to use as the basis of its own test. It looks for vulnerabilities including command injection, SQL injection, cross-site scripting and leftover debug code.
Fortify Tracer is a coverage tool for security tests. It works with J2EE applications while other tests are running, and reports on what percentage of security-critical functions were exercised.
Finally, Fortify Defender is a run-time solution to use with deployed applications. Fortify calls it a "function-level firewall". It can be applied to any .NET or J2EE application, working with the compiled binary code and looking for attack patterns. The company claims a low performance overhead and a low rate of false-positives.
"We are looking for input that is tainted, but you can specify usage rules. For example, end the session if anyone tries five credit cards within two minutes. We took a lot of the rules from source code analysis and turned them into runtime rules. The development team that should have written those checks into the application, but because of time constraints, or if they're inheriting the source, they just aren't there."
Fortify Defender does not come cheap, at around $6,500 per application instance, but this kind of smart runtime checking does make sense as part of a secure application strategy. It is no substitute for coding securely in the first place, however.
There's plenty more information on Fortify's approach here and Fortify is not alone in this space. Cigital has some useful resources and Microsoft .NET developers should also check out DevPartner SecurityChecker from Compuware. ®