Is the next big cyber threat lurking in government systems?
The evolution of IT can take place at revolutionary speed, and when systems don’t keep up with the pace of change they can become vulnerable to serious risks, says retired Lt. Gen. William T. Lord, former Air Force CIO.
“I think that the next Achilles’ heel is legacy software,” Lord said.
A combination of unsupported software, well-known vulnerabilities and new applications that expose old platforms to networks can create unnecessary complexity and open critical systems to threats, he said.
Not every piece of old software is a risk, however. “Some of the things we use in our nuclear command and control are so old, but so reliable and unconnected to anything else, that it probably does not pose a threat,” Lord said. “But our problem is that most of our legacy systems in government are 20 or 30 years old,” and need to be updated.
Fixing this installed problem will requires more flexible contracting to let government take advantage of smaller, more nimble contractors. Lord, who now is an IT systems and services consultant, is making legacy software something of a crusade in his post-military career, calling it the greatest obstacle to IT progress in government.
Defining “legacy software” can be difficult. Some would argue that any software in use can be called legacy, because if you’re using it, it’s already old. Most would agree that any software still in use that is not supported by its developer or vendor could be classed as legacy. There is a huge installed base of this. A recent analysis by the Web Security company Websense, for example, found that three quarters of government computers are running unsupported versions of Java.
Getting rid of legacy software is even harder than defining it. Wholesale programs can be expensive and often end in failure. The Air Force in 2004 began a program to replace 240 outdated systems in its Expeditionary Combat Support System with an Enterprise Resources Planning system. A contact was awarded to Computer Sciences Corp. in 2006 and terminated six years and $1 billion later. “The effort got stopped,” Lord said.
The problems included “budget doldrums,” which complicates almost any kind of project, and the difficulty of finding a good time for replacing operational systems. This can be particularly difficult with combat support systems when the combat never stops, Lord said. “In my experience in the Air Force, there was no end to the battle.”
The skills needed to update, modernize or replace legacy software can come from non-traditional service providers, he said — smaller software companies that often do not have the resources to compete in the government market. It would help to have major league contractors partner with the minor league companies for government contracts, but there often is little government incentive for this.
Agencies are supposed to make small and minority-owned business contracts, but accounting policies give contracting officers little credit for acquiring services from small companies through a larger contractor, Lord said.
Another problem is a lack of dedicated money for fixing vulnerabilities in old applications. The Air Force sets aside money for hurricane damage, but not for software bugs, so that maintaining old software is difficult. Government needs to realize that vulnerabilities are as inevitable as bad weather, Lord said. “We haven’t caught up with that kind of thinking.”
Posted by William Jackson on Apr 09, 2013 at 9:39 AM