Lessons of Failure
Humans + Software Development = Always Interesting

Dec/09

17

Military Software Sucks

Apparently the US Military can’t write software worth a damn.  Here’s a textbook-classic case of what happens when you decide to ignore a problem that is clearly evident at requirements time until well after post-deployment.

The Wall Street Journal did an article about the unmanned drones zipping over Afghanistan and Pakistan.  Apparently, local insurgents found a $26 piece of off-the-shelf software that could tap into the drone’s unencrypted video feeds and give the insurgents a clear view into what the US Military was watching, thus ruining the element of surprise.

Can you say “Ouch”?

A quote from the article itself says it all about military incompetence arrogance:

The potential drone vulnerability lies in an unencrypted downlink between the unmanned craft and ground control. The U.S. government has known about the flaw since the U.S. campaign in Bosnia in the 1990s, current and former officials said. But the Pentagon assumed local adversaries wouldn’t know how to exploit it, the officials said.

Holy Ostrich-Heads-In-The-Sand, Batman!  Not only did the military put software out the door with an obvious security flaw in it, they’ve ignored this problem for over 10 years because they thought the enemy was too dumb to figure it out! And the justification?

Fixing the security gap would have caused delays, according to current and former military officials. It would have added to the Predator’s price.

Yes, that’s absolutely trueBut honestly, how much would it really add? The Predators already run in the millions per drone (10-12 per the article).  Let’s analyze that, based on current prices of software contracting, estimated efforts and the technology involved.  First, we need a list of assumptions:

  1. Encryption requires additional processing power to encrypt at the drone and decrypt at the receiver.  Let’s assume they add a special card to each drone to dedicate to this task so the video feed isn’t compromised on the sending end.  Cost:  $1,000 per drone because it’s a special piece of hardware capable of running at 2Gs.  (Off the shelf solution today:  probably about $250)
  2. Cost to install in each drone:  Let’s say that it takes a tech about 2 hours worth of time per drone.  And assume the tech is paid a modest $20/hour to do his work.  $40 per drone.
  3. The card requires additional software to link it into the current drone video processing loops.  Let’s assume the video processing is well-known, and the encryption addition takes roughly 2 engineers 1 month to complete.  (2 engineer months @ $150/hour government contracting rates = $24,000 for all drones).
  4. The receiver software requires a comparable upgrade to handle the decryption.  Assume another 2 engineers are dedicated to that task for a similar length of time.  Another $24,000 for all drones.
  5. Figure in some extensive testing:  Another 2 engineers for a month:  $24,000 for all drones.
  6. Assume that managers are involved and their costs are amortized into other projects, which is likely true.
  7. Finally, assume this is for an existing fleet of 1,000 drones.

Adding all that up, I get the following:

  • 1,000 drones * $1,040 = $1.04 million for all drones.
  • Fixed costs = $72,000
  • Total costs = $1,112,000 dollars for 1,000 drones OR
  • $1,112/drone

At $10 million dollars (the low end) per drone, that’s a 0.0112% increase in price per drone.  Hardly a massive cost overrun by military standards.  And let’s assume I’m off by a factor of 10 on all my calculations…still, that’s still about 0.11%.  Again, not a massive overrun for something that mission critical.  Compared to most software projects with mid-double digit overruns on developer time, this is positively amazing.

And the delay argument?  Maybe 6 months to retrofit the fleet.  At best.  You’d think that in 10 years time, the military could find 6 lousy months to upgrade its most important asset in the 21st century.  Even a phased upgrade would have worked here over that time frame.

This is all taking into account that the military is fixing this problem well after the design and implementation phases (our old friend Habit 5:  Fix it Later) instead of identifying and fixing this problem up front.  That would reduce the costs even further.  I find it completely incredulous that not a single person during the design or requirements gathering phases said, “Hey, maybe we ought to encrypt the video feed…”  Aren’t they supposed to gather information, uh, secretly?

If you think the software we write is bad, wait until you see our solutions!

If you think the software we write is bad, wait until you see our solutions!

Clearly one of two things is going on here:

  • The military is too lazy or stupid to realize that the enemy will find and crack that exploit given enough time and resources (let’s just throw out the number 10 years…)
  • The military price to fix this flaw is much higher, meaning that the cost overruns are due to corruption, incompetence, or outright greed in government contracting.

Shame on everyone involved.  This sort of breech wouldn’t happen at Amazon.com’s ecommerce site.  It shouldn’t happen with some of our most important software technology given that this is a solvable problem with known constraints.

* UPDATE @ 12:48p, 12-17-2009:  My math was off by a factor of 1,000 on the calculations and my addition sucked.  I’ve just embarrassed every math teacher I’ve ever had.  Now it’s even cheaper and more horrific!

Be Sociable, Share!

· ·

6 comments

  • John · December 17, 2009 at 10:57 am

    I agree with the incompetence, and not taking their medicine early. As an engineer with experience on commercial projects, I am sure that some engineer did mention this, and possibly even “went to the mattress” on it, but his “lead” or manager to drop it or be fired. Happens on the time. Remember the space shuttle challenger?

    But, the costs are actually higher. Adding the extra processor increases the electrical power requirements on the aircraft, takes up volume, and weight. This is likely to have impacts on the aircrafts, size, weight, speed, range, and operating costs. So the number is likely many times higher than your calculations, but there is still no excuse for shipping an expensive weapon that can be defeated by a MAC.

  • Author comment by admin · December 17, 2009 at 11:05 am

    Yep. Agreed. And yes, I totally wrote off the hardware side of it, your points are all valid…my systems engineer friend at NASA is no doubt cringing at me right this second. But still, this is a critical flaw and poorly executed.

  • HS · December 17, 2009 at 12:40 pm

    Perhaps encryption was discarded after its costs were overestimated by a couple orders of magnitude. $1,760,000 / 1,000 = $1,760.

  • Author comment by Dave · December 17, 2009 at 12:48 pm

    LOL! Here I am railing on the military’s poor estimation and I’m off by a factor of a 1,000. Post updated. Thanks for pointing that out, and making my comments even MORE relevant.

  • igorbrejc.net » Fresh Catch For December 26th · December 26, 2009 at 4:04 pm

    […] Military Software Sucks | Lessons of Failure […]

  • Amgis · February 8, 2010 at 2:18 pm

    Could also be that all of the receivers would need to be able to handle this encrypted feed:
    Every armored vehicle
    Every forward observer radio
    Every mobile command station (computers in tents)
    Every state side command installation
    Every Jet Fighter (they can share this too)
    Every Bomber
    Every Support air craft
    Every Navy ship
    The marines
    and don’t forget the coast guard too…

    The branches of the military still don’t have radios that work well with each other. Most of them aren’t configurable by software upgrades either.

    I don’t know if encrypted video takes up more bandwidth but that seems to be a factor. Satellite time is expensive and in short supply.
    https://www.strategypage.com/htmw/htiw/articles/20091218.aspx

<<

>>