Software Security Assurance Psychology - The Legacy Code

Friday, March 04, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

Nothing says "we've got problems" like finally getting a chance to run a security assessment on a small update being done to a piece of code that's been in production since the Carter administration, and finding something... big. 

The sheer panic sets in quickly as you realize that about 1/100th of the total code base has just been modified - but you didn't test that tiny piece, you tested the whole thing and you've found huge, systemic, production-stopping issues. 

This situation is fairly common as code ages and security finally gets to start testing some of these dinosaurs.  The problem - what do you do now?

Panic!

Those that have never encountered this type of situation before are going to be prone to one primal emotion - sheer panic. 

It's the same feeling a first-time homeowner gets after buying their second-hand dream home, only to pull back a piece of wallboard behind a frizzy outlet to discover the wiring is out-of-code and will need a whole-house replacement because it's a fire hazard!  Panic! 

Where the inexperienced homeowner panics, the veteran takes a step back and assesses his or her options, then panics (kidding)... 

Seriously though, in a situation where you've just found a systemic flaw in an application that's been live for years -a few quick questions come to mind...

  • Has this application been hacked before?
  • Would anyone have noticed?
  • What can I do about it now?

Big Picture

What we have here is a series of questions with no real way of getting an answer without downing the system and performing forensic analysis -except that you already know that won't be happening. 

The bigger issues lie with the fact that your organization has been depending on this application that pre-dates security, and the mandate for safer (more secure) software... so now what?  The root of the problem is money, so you have is an impossible task ahead of you. 

You have a piece of code that hasn't been completely re-vamped in a very long time... maybe there aren't even people in your organization that know what all the bits do anymore, or maybe it's written on top of an old language base or is simply poorly documented/commented.

At any rate, you've got a financial problem here.  An application has been relied upon successfully for months or years (decades?), and now that the organization finally gave you access to it because they touched/modified one small component you've found a systemic bug which requires a large-scale effort to remediate. 

Herein lies the rub... the small team that made the modifications to the new code isn't going to tackle the entire application -s o you can't hold them accountable for the whole of the code... but you can't simply let it go with such a vulnerability.

The Impossible Task

So just like a scene out of the movies, this is your task -should you choose to accept it.  You have to find a way to 'fix' this application and bring it to a reasonable state of security, retire it, or find someone willing to accept the risk. 

My guess is you'll end up with this to-do list, probably in this order:

  • Figure out business criticality of the application
  • Find someone who is at least familiar with the code (all of it) and can give you an idea of what the extent of the issue is
  • THEN create a proposal that will either tell the business how to fix the app (cost + time), or how quickly they should think about replacing it (cost)
  • OR Find someone willing to fund 'exploratory testing' to figure out where the whole of the code is broken (I recommend static analysis, very much)
  • THEN create a proposal that will either tell the business how to fix the app (cost + time), or how quickly they should think about replacing it (cost)
  • OR Find someone who's willing to put a piece of hardware/software between that application and the network -filtering attacks and hope it works
  • THEN run and hide.
  • OR Find someone who's willing to sign off on accepting that risk, make sure they understand the full extent of the issues
  • THEN hope things don't go south, like the company has been all this time

The Uncomfortable Truth

Ironically, this really all collapses into a discussion on cost vs. risk -as do most of our conversations.  It's just that this one involves something you can't readily poke at, or force someone to fix. 

Odds are you won't have the developer-power, the knowledge, time, or capital associated with making a fix to a code base of this size and age.

The uncomfortable truth (can you handle the truth?) is that most of the time issues like this are simply allowed to roll by, and the business assumed risk based on the factors cited here. 

The code base (application) eventually gets sunset and a new application - one which you hopefully have direct influence over -is brought up in a more secure, risk-averse way.

Until the new app stands up, it's going to be an uncomfortable ride... just make sure you know the bugs are there, and compartmentalize any damage that can result from a systemic hack of that faulty, old system.

Good luck!

Cross-posted from Following the White Rabbit

Possibly Related Articles:
8115
Network->General
Code Review Application Security Risk Assessments Network Security Software Security Assurance
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.