Ghost apps: Enterprise security decisions that can haunt us

Consider what happens at a typical firm developing application software for new functionality: How often do we actually replace existing business logic? In many enterprise cases, new application functionality, predominantly business logic, is additive: We add layers and bolt-ons to it much more frequently than we remove from the code base.

If you've seen "Poltergeist," you know what can happen when you build on ancient burial grounds... 

Burying apps of the past

Let's take as an example a banking application that adds a cloud-focused extension to an existing application to enable remote deposits from a mobile device. Functionality like this might leverage an offsite virtual data center environment for support. But underneath, it might sit on a stack of technologies, like layers in an archeological dig.

Consider -  

Under the cloud application might sit a series of interconnected web services to implement business logic, possibly written within the last decade.

Those web services might interact with web server APIs on the host, which, in turn, call down to legacy data access components that could've been written in the '90s to support n tier application development and client/server.

These data access components might, in turn, wrap a 3270 emulator to ultimately tie back to green-screen legacy apps on the mainframe written in the '70s and '80s- maybe leveraging application platforms like CICS.

This stratum of wrapped technologies allowing the application to work would be: Virtualized Mobility-enabled UI -> Web Services -> Platform API's -> ODBC -> CICS

Of course, numerous permutations exist. As technology shifts occur over time, new functionality is bolted on to enable expansions and changes to the app. The original mainframe app that folks used in the '80s for account management? Still there, but buried. A ghost.

The peril of unintended consequences

Now it's not mad science to understand why this happens: After all, why replace a fully-functional application to support a new technology paradigm when you could just leverage what you already have? Application developers often abstract underlying components to allow consumption of previous code by new components.

But for application security professionals, this presents an unintended consequence. Namely, how do we ensure these old bones layered within the application chain do not introduce new logic errors or expose new threats?

Unlike the application developers building the business logic, we find ourselves evaluating again and again the security profile of supporting components and interactions between them. Spooky.

In the stories, the good guys usually banish ghosts by helping them resolve the issues that went unresolved in life. And that loosely parallels what we do to address these ghosts in the application lifecycle.

Banishing enterprise security ghosts

One successful strategy is to review and document the security profile of each component -- and the interactions between them -- as part of our application security review. Then we can carry forward the decisions, risk evaluations and assumptions for future efforts.

We might start by applying an approach like threat modeling to the existing application. Doing our risk analysis and threat evaluation in a standard format, with documentation, allows us to analyze the threats associated with interaction points between components now and use them again if we need to do a subsequent review in the future.

Using standard documentation like data flow mapping exercises to create a threat map for each component, we no longer have to reinvent the wheel. We capture the analysis we do once and make sure that ghosts stay buried - or at least can get out of our way rapidly when they surface again.

From a security standpoint, we always need to review new components, but the process gets much easier when we don't have to waste time covering old burial grounds.

Ed Moyle is senior security strategist at Savvis, a CenturyLink company.