Software Insecurity is Our Biggest Weakness

ST. PAUL, MINN.–If the United States wants to remain competitive in the global economy and prevent widespread penetrations of its strategic, corporate and commercial networks, enterprises and government agencies should stop relying on commercial software and go back to writing more of their own custom code, a security expert said Tuesday.

ST. PAUL, MINN.–If the United States wants to remain competitive in the global economy and prevent widespread penetrations of its strategic, corporate and commercial networks, enterprises and government agencies should stop relying on commercial software and go back to writing more of their own custom code, a security expert said Tuesday.

Speaking at the Secure360 Conference here, Marcus Ranum, CSO of Tenable Network Security, said that the country’s reliance on commercial off-the-shelf software has made us more susceptible to attack, not to mention less innovative and creative. While dismissing the current fascination with cyberwar as hype, Ranum said the reality is that foreign governments and intelligence agencies are doing their best to penetrate our government and commercial networks every day, just as the U.S. government is working to compromise foreign networks.

That reality means that poorly written and deployed software is a major problem, he said.

“If we’re going to maintain our place in the world, software is not a strategic problem, it is the strategic problem going forward,” Ranum said. “Covert penetration becomes something that you think about on a five, 10 or 20-year scale. If you look at the problem of doing a significant penetration, it’s not something you can do immediately.”

Using the federal government as an example, Ranum pointed out that many, if not most, of the internal software development groups that used to exist in federal agencies are now largely gone. In their place now is an army of contractors doing much the same job, but with a couple of important differences. Because the internal development teams no longer exist, the contractors are reporting to program managers instead of managers who were developers themselves.

As a result, there are fewer and fewer people inside the agencies who understand what it takes to write and deploy good software. And the software they’re getting is costing several times what it used to because it’s coming from contractors rather than internal employees.

“We’ve jammed the money valve wide open to the point that we’re spending five or six times the money on contractors,” Ranum said.

In place of this current model, Ranumm suggested that it may be time for a centralized federal development organization that focuses on writing custom software.

“Why don’t we have a government coding office? We have a government printing office,” he said. “Why don’t we have a strategic software reserve? Is this putting us at a greater or lesser risk? I’m not sure. But our own software is probably a greater threat to us than anything other people can do to us.”

Discussion

  • decula on

    You know, in a free market system, I can see where outsourcing by the Government is a good thing. However, we don't trust free markets for our Army, for our financial core (IRS) and in the past, our communications (snail mail). I have to agree with Marcus. Software developed by contracting is open to whoever the contractor hires, perhaps even foreign entities. At one time, there was even a push in Government to standardize on a programming language that had inherent protection from the bane of buffer overflows (ADA). It probably was the other end of the extreme, isolationism. We just need to find the middle of the road.
  • Eric on

    Ranum's idea is interesting, but 30 years ago the government was on the cutting edge of computers (afterall, it did create the Internet), not so today.  The creativity and agility of commercial software makers is 100 times better than government software.  If government created software it would be designed by beaurocrats (sp?) and wouldn't get out the door until 3 years after it was needed. 

    The government should stick to writing laws, not to writing code.

     

  • andrew sinclair on

    Eric is wong on one point:  government did not create the Internet.  The Internet was the outgrowth of ARPAnet, a development done by Bolt Beranek and Newman (BBN) as primary contractor, with contributions from around the world.  Ranum's idea has merit because it requires a "government coding office" to work with different priorities than a commercial company.  A commercial software vendor is out to make money, and success is measured by the bottom line.  A government coding office doesn't have the almighty dollar as its driver, so it can concentrate instead on other priorities:  security and accuracy, for example.  Also, the government coding office could concentrate its efforts on external-facing items, while contractors can work within a walled garden.  That way, you end up with the best of both worlds.

     

  • Sartorius on

    The idea is interesting, but then governments should have Offices for everything, from electric appliance manufacturing to construction to restauration. I do agree that more and more projects are managed, everywhere, by people who have no idea whatsoever what the projects are about; MBA graduates who are trained to believe that, if they know how to balance a budget then they can successfully manage any company in any field. That's the main issue, IMO.

  • Rico Marsden on

    "A government doesn't have the almighty dollar as its driver".  Hmm, then what is the driver?  I'll tell you, it becomes politics, job security, and mindless bureaucracy.  Government control of this isn't the answer either.  Government can do precious little very well.  You will end up with career bureaucrats who don't really care about whether the product works, but they followed procedure and had all the required meetings, and will declare victory regardless.

  • Mike on

    There's no need to reinvent the wheel, we just need to ensure that the products used are safe and maintained. The US government has the Energy Independence and Security Act of 2007 to help with our energy security, why not have a less prescriptive (i.e. voluntary) version for software/networking products? There is the Energy Star program to help people find more energy efficient products, why not have a "Security Star" program to promote products which meet a (hopefully strict) security standard, and have guaranteed maintenance/updates for a set period? This would help the private and public sector, which both share many of the problems mentioned in the article. We don't need a centralized software development center, we need a standardized method to make sure the software available is safe.

  • jay m on

    The mention of "commercial off-the-shelf software" at the beginning of this article is not on target. Ranum's beef, as I understand it, is primarily with outsourced *custom* development being done by contractors without sufficient oversight by tech-savvy government program management. I doubt anyone would argue that COTS stuff is by nature less secure than custom stuff (although it often presents a much bigger and better understood target to the black hats)

  • Michael on

    The three year development cycle mentioned by Eric does not disappear when the government hires private software companies as prime contractors.  One reason for prolonged development cycles is the need for far more secure and reliable software than that which the private sector routinely gets away with.  The reason commonly blamed is federal government's outdated and finance-oriented project methodology which is indeed paperwork-heavy.  That said, it also includes much "common-sense" need for risk avoidance, which sadly does little to reduce the risk caused by using contractors whose goals do not align with those of taxpayers.  Dennis is correct- these urgent calls for maintained privatization are dangerous as private corporations have no true sense of morals, patriotism and certainly not responsibility as we're witnessing yet again in the current oil spill.  It's no wonder these software mercenaries avoid open source and open standards, which are often useful reducing both risk and cost, as well as negotiate contracts to maintain code developed for the government in order to maintain their competition-free position as a single-source bidder.  Remember that the free market only works with healthy competition, which all too often is not the case.  If you want to assign blame for our government systems, don't stop at government officials.

    Public sector development is standard in other nations, and is not the crazy idea private industry moguls would have us think.  Employing serious software engineers whose motivation is the public interest is the way to go with national security and mission-critical systems. For example see our very high-tech ally, Israel, which generally develops all its software in-house, and reaches out to its military industry for hardware development.   Private industry can certainly be employed, but cannot be trusted with the reins as has been discussed at length this past year with regards to using private-run cloud computing systems.

    Rico's comment is pointless and insulting. Take out your frustrations on corrupt politicians if you like.  But leave well alone the many public servants who work harder and at lower pay than our private-sector counterparts to serve our nation.  Try to realize it's against your interest to make us feel unappreciated and you come off like the type of jackass who expresses his sorrow by heckling the team he roots for.  Think you can do better?  Man up, sign up and prove it.

  • Rico Marsden on

    Even a "voluntary" governement designed program would be produced by Capitol Hill staffers and driven by political expediency.  The Energy Star program is not a very well run program.  Practically, meeting the requirements to get something "Energy Star" designated is not rigorous. Another problem is that any government based program would be inflexible and probably obsolete by the time it hit the President's desk.   About the only (and best) thing the government could do would be to significantly lower corporate taxes to encourage business to react to the needs of the market and produce a product that is secure.   If the need is there in the market, and the government gets out of the way, the market will produce a solution.  Because money talks and BS walks.

  • Anonymous on

    Government programs without a contracting vehicle breed stagnation and complacency. Without the encouragement of a management driven by the desire to win the next contract bid, development stagnates. The need to compete and recompete for the contract forces companies to push their employees to produce better products. If you want to increase the security of the code being developed, the solution is not to switch to a system where there are no incentives; the solution is to create measurable security benchmarks that hold the companies accountable for the security of their code. When there is a serious risk that the discovery of a SQL injection flaw in your code could cost your company a multi-million dollar contract, and could cost you your job, you can be assured that you will read everything there is to read about SQL injections and do everything right to avoid them.

  • Rico Marsden on

    Michael, since you fired the first personal salvo, then I will respond.  First, I have been a "public servant".  I have seen how it all works.  Government employees don't work any harder than anyone else-and,as of late, it seems they are being paid more than the private sector.  Plus it takes nearly divine intervention to fire a government employee.  You demonstrate arrogance and sense of entitlement when you say private industry cannot be trusted.  As if government employees are not subject to the same temptations and failings that anyone else faces.  Also, the government is not the focus of my loyalty, it is my country as a whole, and the founding ideas. 

    Further,  there are many government agencies that I DON"T appreciate!  There are some I do.   My loyalty to my country is not somehow compromised by the fact I am not a government employee.  So if I don't monolithically cheer for every last thing my government does and make you feel "appreciate" it is against my best interest?  How?  Is that a threat?  Are you going to use the machine of government to try to destroy me because I have a different opinion?  I don't know which country you are in employ, but I hope it isn't mine.  Finally, name calling? Really?  then I simply say Good day to you sir...I said Good day!!

  • RAB on

    Reading a lot of Schneier, lately.  His take would probably be that -- in a free market -- when there's financial liability for insecure software and vendors have no choice but to purchase liability insurance to protect their stockholders, then and only then will we see software getting more secure.  The thought of government sticking its corruptable fingers into software development for all but the most sensistive projects, is ludicrous and not one of its core functions.  That would be my take, as well.

  • Cliff on

    I agree that writing code is not one of the government's core functions, and I would hate to see a "Ministry of Coding" created.

    I also agree with RAB that the core problem is that authors of code are not accountable for its security.

    - Cliff

    Author, High-Assurance Design

     

  • Brett on

    The back and forth, and the rest of the comment stream illustrate, more than anything else, it seems, both the reality of the core issue, and the complexity/subtlety of the challenge.  There is no question concerning the rapidly increasing complexity and vulnerability of the software on which we depend.  Part of the threat indeed is embedded in our propensity to be almost completely dependent on, for example, a single brand of globally distributed software which by definition cannot possibly be secured.  (Not a cut at the vendor, simply a reality of the global market.) 

    On the other hand, that problem is not solved if the government developed an universal proprietary alternative (the Chinese way?).  And the complexity of the system could grow quite exponentially, if for example, every program and sub-agency had a unique system approach.  Furthermore, while I do believe that the government must do a better job of retaining sufficient internal expertise at least to understand and to maintain competitive position (There is some effort to turn this around).  This of course presents a genuine "greying" crises, as there simply are not enough new computationally skilled graduates to meet the need (another issue!).  So, the fact is that strength in both public and private sectors needs to be shored up -- NOW!

    The other fact of life, which plays into the underpinnings of the talk, is the simple reality that the world is after us -- and they are relying on the hugh numbers of users experienced in the same software we use.  It is sobering, by the way, to realize that 108 countries now have established formal 'cyber warfare' OFFENSIVE programs, specifically able to attack the US as a major target.

    Having said all of that, even a master code library would not help.  Indeed, there has been such a federal repository for over 35 years.  What IS a problem, however, is that the way we program has essentially not changed in 30 years (sure, languages have changed, but not the fundamantal way we program).  We definitely need to change that, if only because the amount of code is so large, that the way we do things, almost by definition, system performance and vulnerability cannot be known. 

     It is quite true that we all are on a fragile sheet of ice.  Being frightened could be helpful, but is not the objective.  Thoughtfully changing the paradigm, and carefully considering the pathway to the present and the future, at least might bring us to the starting blocks of the cyber-physical future we must develop.

  • Anonymous on

    This guy is smoking dope. I've worked in the DoD sector for 20 years and there are government employees who code and also contractors who code. The contractors do not cost 5 - 6 times more (usually the same when all benefits are considered). I agree that program managers are too often clueless and do not have a technicial background. But in my experience, these lame PMs are government employees, not the contractors where their mangagement has usually risen from the technical ranks.

    There is plenty of COTs being in in government (why reinvent the word processor) but the mission critical system are all GOTS (government off the shelf) and not generally available to the public.

    They tried to create a code repository for Ada code years ago. It was a joke. Perhaps if the author had spent any time in the environment he would know these things and stop talking nonsense based on his theories of how thing might work.

    I do agree with the bacis tenent that our government systems are stragetic assests and need to be protected. Otherwise, I know which end is doing the talking for this clown.

  • Anonymous on

    I agree fully with the previous poster.  I've been a government contractor for 25+ years and the government gets its money's worth out of us, in fact more than they deserve.  What I've seen over and over again are technically-clueless government employees "managing" large software projects.  We as contractors are supposed to provide technical advice and support to the government - what I've seen is that we are consistently ignored.  The contractor managers mostly have technical backgrounds but the civil servants are generally (but not always - there are some standout exceptions) not up to snuff.  They do take lots of classes in touchy-feely things like recognizing sexual harrassment and race relations, but when it comes to technical issues they are sadly lacking.  Where I work we get to do software projects with indeterminate requirements, and we are required to come up with time estimates before fully being able to analyze what is needed.  We are then held to our time estimates.  Of course subsequent requirements are then added to the task with no time revisions allowed, and our management never says no to the customer - it's forbidden.  Contractor management has been known to suck up to government, screwing their own employees - we can always add more work to a task for free. From my perspective we do quality work for an uncaring customer.   Nobody gets rich from government contracting except the people who own the companies.  The idea that contractors cost 5 or 6 times the cost of a government person is absurd.  I have access to government personnel data and a listing of all of the GS employees would immediately show that it's a bogus statement.  The government has some excellent civil servant talent, but not where I work.  Meanwhile, let's have another reorganization to make things more "efficient", like we do every 2 or so years...also, while we are at it, why don't we get a new CIO or CTO and change everything around, again?

  • Anonymous on

    Just improve the rule:

    - fine vendors 10% of their annual revenues for any extra vulnerability after 5 have been found during the same year.

    Then, the world would save a lot of time and money because 'security' tools, as well as patching would mostly be pointless.

    Of course, this policy would only be efficient if the rule of law was applied to those who can afford to buy governments (and routinely do it).

    Another day in wonderland...

  • Bob_Robertson on

    Seriously, Andrew Sinclair points out something often glossed over: Government did not invent the Internet. The colleges, universities and research institutions around the world which created the Internet through the RFC process did it. Maybe ARPAnet was the seed, but it was not the whole plant or even a major part of it. It wasn't until late 1992 that the NSF changed the rules excluding "commercial content" and "commercial providers" from connecting to the "Internet". THEN the explosion of innovation and use occurred, utilizing the fundamental protocols outlined in the "open" RFCs to eventually connect everyone on Earth to everyone else. The US Fed.Gov has, for the most part, always been clueless about computers. The NSA, one of the few actually computer competent agencies in addition to NASA, created SELinux a decade ago. If it weren't for politics, if security actually mattered to people in the Fed.Gov, they would be using SELinux instead of Windows. But Windows is an easy purchase on government procurement forms, and reinforces one of the big donors to re-election campaigns. Taking the time to spec out a machine for SELinux would be too inconvenient. Security is inconvenient.
  • SWADA on

    >>so it can concentrate instead on other priorities:  security and accuracy, for example.

    You have to be kidding, right?  SCIPP International developed an ANSI accredited security awareness course for those involved in the SDLC and specifically the coders.  Over the past 18 months we've had people from every vertical and every sector come and take the course EXCEPT one...Guess who?  The US Government.  Out of 1,000's of participants, we have not had a single federal agency register an employee.  After spending 20 years in the military and being the Superintendent for computer security at US STRATCOM - I can tell you the average government employee who is a developer has no idea what cross-site scripting is. 

  • SadieMae on

    There is absolutely nothing wrong with the software any agency uses. The problem lies in clueless employees and clueless IT. Too many offices and agencies are simply not training their emplyees properly and allowing them administrator access to their machines. It's just easier than creating secure policies on employee usage and enforcing them to the max. People are simply allowed too much access to the Internet and Email. Employees should be allowed access to those sites they need and only company email. Also, all access to social networking, instant messaging, etc. should be blocked and enforced. No employee for any reason needs this to do their job.

  • Anonymous on

    Oh what short memories we have....  Do you remember just how high the percentage of failed software development projects were reported in large corporate & govt institutions throughout the 1980s and 1990s?  The key reason for outsourcing was to lay the blame outside of the govt staff to avoid risk & embarrassment.  Contractors still screw up, but they are blamed and this can't be the fault of the govt staff member, right? 

    The reality is that this is a pipe dream that isn't backed up by historical fact.  Govt organizations don't have the incentive or brain trust to write the sort of software you are suggesting they do.  Sure, they can maintain systems and sometimes they get lucky but for the most part software is successfully written by about 5% of the development team, who contribute about 95% of the code.  That 'magic' isn't incentivized in govt departments and consequently even if a dept had a kick-ass programmer onboard, they'd be lured into the private sector with some promise of money pretty quickly.

    Its not going to happen, although I'd agree that I wish it could.  With that said, what infuriates me is that this outsourcing that has been going on all too long is often to US companies that are fronting sweat shop development labor in 3rd world countries, where little of the govt money spent remains in the US economy.  Now that's a recipie for failure, not to mention the increased security risk.

    If govt contracting stipulated that only US legal workers could do the work, then I'd say you might be able to at least get some decent results and help keep the jobs here as well.  But its rare to see such policy implemented let alone policed in govt purchasing policy.

  • Perry on

    We already have an agency, the NSA, that could be doing this work. There is no need to create a separate office for these kinds of projects, the NSA is well funded and of course they have the expertise to deliver on these kinds of projects. If there is to be competition, then let the NSA compete with another government agency.  As to private industry, they can't make good software without the help of a small army of people who donate their time to cracking software.  The software companies rely on these folks. Why not pay some of them to do the same thing for government software.  Give them security clearances and a sum of money to find holes in software  if they qualify and have them collaborate to crack codes if necessary, although most of these folks are one man shops with a unique ability to cut through the BS.  I'm all for cheaper outsourcing, but outsourcing has not proven to be cheaper in many instances.So let's just recruit the folks doing this work for free for software companies, have them sign security agreements and agree to monitoring and then assign them software to crack. They're doing if for free now so why not hire them and swear them to secrecy and let them make some money doing what they love.

  • Greg on

    I think one area which is lost here is the development of web applications. When I run across the internet, I find very few sites which adhere to web standards, let alone standards put out for php, database queries, cold fusion, etc. Many of these sites within government are very small and don't necessitate establishing a whole contract within the government just to develop the small quantity of pages which make up the web app. In the instances where I have seen this performed, the adherence to standards is so terrible it is no wonder the internetworking cloud is such a calamity for malicious activity.

    I agree an organization should be held accountable in producing these applications, but it should be guided by a mandatory adherence to the standards which are already established. Prior to this happening, a standards needs to be developed for session handling, database queries, etc. Obviously I am more focused on the web applications, however the database queries apply to nearly any application within the government anymore with all the data sharing which is performed between remote locations.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.