Supporting "Unmaintainable" Applications

Sunday, May 08, 2011

Rafal Los


On an internal mailing list the other day, a colleague brought up a very interesting issue that's facing one of his customers. 

Oddly enough, although I haven't thought about it specifically in a while, it's one I've run into many, many times. 

The problem is "unmaintainable" applications... and whether you know it or not, you probably have them hiding in your environment somewhere.

Just what is an unmaintainable application?  An unmaintainable application is one that is difficult, or impossible to maintain the quality of with current technology and knowledge. 

As an example, if you have an application that was written back in 2001 using Visual Studio 6.0... you may have an issue if someone in security does a security analysis on the code only to find major security defects... do you even have a copy of VS 6.0 lying around?  Do you even have the source code anymore?  These are all critical questions to think about in an enterprise environment.

Security of applications is more than just looking at applications going through your enterprise SDLC (Software Development LifeCycle). 

A solid Software Security Assurance program also takes into consideration the legacy risks you inherit from all the applications that have existed and are being relied upon by the business before a security program came into being. 

The issues that surround these types of legacy applications are extremely complex, and can create headaches for application security teams. 

Here are 5 things to think about...

  • Does your organization have the original source code?
  • Does your organization have a way to 'update' the original source code and re-compile the application? (i.e.. a compatible compiler, or IDE?)
  • Do you have developers on-staff who are proficient in the legacy language, coding style, and version?
  • Are there security controls available in this legacy language/version?
  • Does your organization have access to the required libraries and dependencies for that legacy application?

If you've answered no to yourself for any of these questions may have a serious problem on your hands -but you already knew that.  So what do you do? 

There are generally 3 options when you run into a business-critical security risk in an unmaintainable business-critical application:

  • Rewrite the application using modern technology
  • Sunset (retire it) the application
  • Apply modern [external] protections
  • Do nothing, hope you've moved on before you get hacked

Surely there are 4 choices, but only 3 of them are realistic right?  No one would take option #4... or would they?

These are very difficult issues many of you have run head-long into already.  Many of you will continue to run into these types of security issues until your security program has caught up to your legacy applications (~5+ years from date of start, or so)... So I'm curious how you're handling this in real life?

As always, comments are welcome as is discussion.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Information Security
Enterprise Security Software Application Security Software Security Assurance Source Code Legacy Systems
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.