As application security functions are further integrated into UTM platforms in 2006, focus shifts to actually building software securely. The high tech vertical will lead the way in embracing behavioral changes for developers, source code analysis tools, and techniques to protect data at rest. New Web 2.0, SOA and on-demand application architectures with better security models increase in importance.

As security professionals we spend a lot of time focusing on protecting the infrastructure and that’s pretty important. Yet, end users do not interact with the infrastructure. Their view into any organization is through the applications. Whether they are web applications or the legacy type, the user’s experience with your application(s) dictates their perception of your organization.

Before we get into tactics and trends in securing applications, let’s get on the same page relative to what is an application. Is Microsoft Word an application? Is Symantec’s Norton Anti-Virus an application? Is your homegrown manufacturing system an application? Yes, yes and yes.

Yet, for the purposes of this discussion, let’s not consider desktop or network operating systems (Windows, Mac OS, Cisco IOS, etc.) as “applications” in the strict sense of the word though many of the ideas presented here would be applicable. Hitting Microsoft with another head shot about the fact that they aren’t getting OS security done is not interesting.

First, it makes sense to revisit some history. The first “application security” products were really a set of scanners that detected vulnerabilities in web applications. Yet, given the inability of any start-ups to build sustainable businesses, it would be a stretch to even call it a niche. In fact, most of those vendors have been acquired at this point, or have supplemented their application scanner business with either developer tools or web security gateway products. But most of these functions will be subsumed into the UTM perimeter appliance [No mas box [0]], so this category is not really a user consideration anymore.

Far more interesting is the activity around secure coding. Commercial software vendors have miraculously discovered that it cost them a lot more to fix a security issue after the product was released (Duh!). So there was a big effort to introduce QA (quality assurance) tools to catch security bugs before code hits production. This applies to in-house software as well; clearly checking for obvious security holes is a good thing regardless of whether you get “paid” for your software or not.

Now the new new thing is to provide a set of tools for developers to eliminate security holes in the coding process. Obviously, eliminating issues sooner rather than later is a good thing, but keep in mind this is not a panacea. Doing some level of assessment in QA is still important because integration may have caused some unforeseen security holes. But those should be minimal.

The market for secure coding tools is still Early, with a capital E. There are just a handful of companies that offer these tools and that will grow as the tools are more widely adopted. It’s reasonably unusual for companies to talk about what they do from a security perspective (always a thorn in my side when I had the marketing role), but you’ll see a lot of companies make a big deal about their adoption of these coding tools. No one wants to buy products that need to patched frequently. I guess except Windows.

As evidence of this, Oracle made an announcement [1] with Fortify (one of the start-ups). Yet, the announcement has been pretty much vilified by the pundits, especially David Litchfield [2] of NGSSoftware and Ed Moyle [3] of Security Curve. Litchfield maintains Oracle must be lazy and if they’d code correctly in the first place there wouldn’t be a need for source code analysis. He’s right, but it’s irrelevant. Now I’m not going to say many nice things about Oracle, because their clear disdain for security researchers and general arrogance is a problem for customers. Ed sums up those issues quite well in this post [4]. I don’t think customers are out of line to expect products to be secure and when there are issues that the vendor works to address these issues expediently and transparently.

Having religion here is ridiculous. Oracle understands they have a problem and the fact they are looking for mechanisms to make their development process more secure must be viewed favorably. You can’t eat an elephant in one bite. You’ve got to start somewhere. If they can automate most of a source code review (which every software developer should be doing as standard practice anyway), why is that a problem? If Oracle is using a crutch, that’s fine with me if their software becomes more secure.

Per usual, there is a catch. Developers must be willing to embrace both a new toolset and way of doing things. That usually presents a major impediment to the success of any software. Maybe that’s the laziness that Litchfield refers to. But, I think both the very compelling cost impact of eliminating security holes during development and the increasing brand damage that results from frequent patches will force the change. The tools are also relatively immature, so there is a lot of work that needs to be done to ensure the tools are ready for primetime. But, again, it’s early in this market, so maturity will come with time.

Keep in mind the impact of increasing reliance on external outsourcers, typically in lower cost regions. An additional part of the selection criteria of these outsourcing firms is to ensure they can support your security standards. You will be best suited to keep the outsourcer in the loop during your selection process because they’ll have to live with the tools as well.

The final issue around vendor selection is viability. In an early market, it’s always dicey to pick a smaller shop, especially with something as critical as coding standards. It’s a bad day if your vendor goes away and you’ve got a ton of developers trained and using a certain tool every day to build the products that keep the lights on. Right now, the early adopters have no choice but to take that leap of faith. But over time companies more entrenched in the development world (IBM Rational and Borland) must have this capability as a core feature of their development platforms. That isn’t an option.

That’s all for Day 10. Next week I’ll address securing data at rest because that really demands a separate discussion. Tomorrow we’ll focus on education.