Why Application Security Is Often Overlooked

It sounds tremendously obvious to say it this way, but applications are everywhere. Think about it — your office suite, your e-mail reader, even the software you’re using right now to read this — these are just a fraction of the thousands (if not hundreds of thousands) of applications you use daily both personally and professionally.

For those of us in IT, we recognize that applications are critical to our business. If the right employees can’t get access to the right applications at the right time, business stops. When you really boil it down, most of what we do in IT is about making sure that the applications in our firm stay up and available.

Given the complete reliance that our firms have on the applications that we use, we would assume that the discipline of application security — i.e., validating those applications to be free from security-related flaws — would be somewhere very near the top of the priority list for IT managers and security pros.

Unfortunately, that’s too often not the case. There are some very real business dynamics that sometimes push application security down an IT manager’s priority list. However, spending some time understanding why this happens (and what we can do about it) can be a very useful way to getting a leg up.

What Is Application Security?

Strictly speaking, application security — as a discipline — is any methodology designed to ensure that the applications in scope (for example, within a particular firm) adhere to and enforce the security requirements and policy of the environment in which they live.

This can mean a number of things. It can mean, for example, implementing strategies designed to minimize security flaws such as exploitable bugs. It can also mean taking on strategies designed to meet particular goals — facilitating encryption of data when it is stored, for instance, or ensuring that data sent between components of the application is authenticated and free from tampering.

In other words, application security is concerned with both preventing unwanted events (like flaws in the code that an attacker can exploit) as well as ensuring desired events (like making sure confidential data is encrypted). This is true for both applications we build in-house as well as applications we buy off the shelf.

To satisfy application security goals, there are a number of approaches that we can use. Manual and automated approaches such as application vulnerability scanners or manual penetration testing attempt to scan the application and identify issues so that they can be fixed; source code analysis done either with automated tools or by developers trained to find common logic/programming errors attempt to parse the source code looking for mistakes.

In addition to this, educational programs targeted at making developers and implementers aware of coding errors and security policy so that the applications they write are designed and written with security in mind.

So Why Not Applications?

Most IT and security professionals recognize the importance of the applications we support. We also realize that applications — no matter whether they’re Web based, client/server, or mainframe — can have security flaws.

However, when the rubber hits the road, many firms fall down when it comes to building and executing a strategy for application security. There are a number of reasons for this, but the primary problem is the diversity of application types and the complexity of the underlying technologies used to build them.

There are all sorts of applications out there (Web apps, legacy mainframe apps, client/server) built using any number of programming languages (Java, C/C++, Visual Basic, Perl). In order to address security within those applications in a comprehensive way, we need to understand both the way that the application stores and transmits data, and also the underlying language and technology used to build the application.

In other words, evaluating a Web app written in Java (for example using servlets) is a completely different exercise than evaluating a CICS application written in COBOL. For applications built in-house, finding and employing individuals with sufficient expertise in all of the platforms in scope is a pretty tall order. For applications we buy off the shelf, we may not even know (or want to know) everything about the underlying technology in use.

However, there are other complexities as well.

In a large enterprise, the number of apps and the interaction points between them can make for tremendous complexity. Each application may interact with dozens of others, and in most cases there is a veritable spiderweb of shared data and application interfaces, and a hodge-podge of legacy components, in play. It’s difficult just trying to catalog the applications, let alone evaluate, prioritize and remedy potential security problems.

Smaller firms have different challenges. While there are likely to be fewer applications to worry about in a smaller firm, there is also correspondingly less money and fewer IT staff members. Within that context, hiring a specialized technologist with specific experience in application security may not be an option given budget and headcount.

What Can We Do?

No short article like this one can give you a full plan of action for how to approach application security in your firm. Putting together a complete strategy requires tremendous effort, thought, discussion and resources.

However, IT managers who understand why application security is sometimes overlooked (and what the challenges are) can employ some low-cost “biggest bang for the buck” strategies to get the ball rolling and give them a head start on moving security forward in the application space.

A Triage Unit

As IT managers, we know that we have limited time and resources — and we need to choose carefully where to deploy resources. In order to do this, we need to be able to prioritize from the applications that exist in the environment.

Unfortunately, there may not be a central catalog or inventory of applications. There may be “stealth” applications “lost in the shuffle,” and organizational changes (e.g., mergers) may make some applications hard to pin down.

The first step then, is finding out where the applications are, what they do, who owns them, and what their relative priority is. However, creating an inventory is expensive; therefore, look to “piggy-back” on work already being done to get the inventory.

Initiatives like Business Impact Assessment (done as part of Business Continuity Planning) or compliance-related planning (e.g. SOX/PCI audits) usually require getting a picture of the application landscape. Why not use that as a chance to get an inventory for application security as well?

Evangelize and Leverage

Use the resources and expertise within the firm and apply them to your agenda. For firms with a lot of in-house development, look to the development community to help you forward your application security goals. Train them in security policy so that they understand what goals are important to you and train them about common security flaws in application code.

By “deputizing” the development community, treating them as partners and giving them a role, you get both their attention (so they are less likely to introduce a security flaw in the first place) as well as the benefit of their expertise (so they are more likely to find, report and fix security issues in the software they maintain.)

For firms that have more commercial software and less in-house development, look to the integrators and support teams to help you identify potential issues. After all, nobody knows the applications better than the folks who work with them on a day-to-day basis. Explain to them what types of application security issues you’re looking for. Perhaps they already know about a bunch of application security issues and can help you right off the bat; worst case scenario is they can keep their eyes open as they perform their daily jobs and alert you to issues that might crop up.