recommended reading

Programmer, procurement staff failings contribute to software attacks

When hackers take advantage of a software flaw in a federal financial system to steal credit card numbers, procurement officers and program developers are both to blame for the intrusion, some information security specialists say.

"We were at fault because we allowed that common weakness that let them into the system," Joe Jarzombek, director of software assurance at the Homeland Security Department, told Nextgov after speaking at an Orlando, Fla., cybersecurity workshop.

Vulnerabilities stem from the inadequate training of software engineers, as well as inadequate requirements from acquisition officers. In the old days, when software operated in an isolated system, developers thought threats would be limited to that computer's physical area. In today's networked world, however, software is operating in environments that the developer may not have had in mind when building a program.

This week, Homeland Security held a software assurance workshop during a conference hosted by (ISC)2, a trade association for cybersecurity professionals, to press upon information security specialists the importance of eliminating vulnerabilities during the design phase.

The most high-profile system intrusions -- from data theft to industrial sabotage -- all are the result of interlopers exploiting a previously undetected weakness. The Stuxnet worm apparently derailed machinery running Iran's nuclear program by taking advantage of an error that the system's software developers had not noticed. In that instance, the system wasn't even hooked up to the Internet. A thumb drive delivered the malicious program.

"Nowhere in my own training or in the guidance I've ever been given did people talk about how hostile of an environment your software may be in," Bob Martin, principle engineer for Mitre Corp., said during an interview after speaking at the workshop.

But software makers and consumers -- including federal agencies -- are not helpless in this challenge.

"We have to get away from this victim mentality of 'I can't do anything about it . . . It's too expensive,'" Jarzombek said. "Those who are saying that are those who have not baked in security to the system."

Michele Moss, lead associate at Booz Allen Hamilton who also gave a presentation at the conference, said greater communication between software makers and agency buyers would help both parties spot potential defects earlier.

"Everyone involved in the development or the acquisition of software should have awareness of the threats that are out there today so they can make decisions based on the environment that is out there," she said in an interview. "Historically, the communities have been segregated."

Vendors and federal managers typically only collaborate to meet cost, schedule and system performance goals, not to sleuth out software vulnerabilities. So, defects often are caught after installation and fixed by releasing a patch, usually included in updates that users are prompted to download every few days.

The current patch management approach opens up networks to attack if not regularly applied but, conversely, is expensive to regularly apply.

Procuring trustworthy software may involve additional up front expenses, but experts estimate that the initial purchase costs about a third less than the price of continuously patching vulnerabilities.

To change agency buying habits, DHS, in cooperation with the software industry, has developed downloadable handbooks on various software assurance subjects.

A contracting handbook published in 2009 provides sample software provisions tailored to government task orders that address personnel, security training, background checks of developers, threats, penetration testing and application development. A due diligence guide, also released in 2009, offers questionnaires to help purchasing divisions gather software supply chain information from potential contractors.

The due diligence document contains a separate, smaller set of questions geared toward cloud service providers, or data center operators that provide organizations with on-demand access to software that is stored on the companies' servers. The items include: "What are the procedures and policies used to approve, grant, monitor and revoke access to the servers? Are audit logs maintained? What type of firewalls (or application gateways) are used? How are they monitored/managed?"

In time, procurement officers may have another tool -- nutrition labels for software, so to speak. "Labeling would be something that would let you understand what kind of testing and examinations the software went through," Martin said.

But Jarzombek said he does not believe labels, surveys or specific contract language should be mandatory. "Everybody has to make choices for their own enterprise," he said. "Hacking is going to change behavior more than anything. I think that has a bigger impact than saying let's legislate this."

Some in the programming industry have criticized software labeling as useless to the average consumer because the nature of software testing does not lend itself to plain English.

Labeling backers say the food and beverage industry encountered the same problem, but grocery shoppers, restaurant patrons and now health regulators have learned to translate the descriptions.

"Food labels have been out for a decade but it's only been recent that government has been regulating things based on what's on the label," Jarzombek said.

"This is about making better informed decisions," he added. "Right now consumers do not have enough information to specify what they want."

Threatwatch Alert

Network intrusion

FBI Warns Doctors, Dentists Their FTP Servers Are Targets

See threatwatch report


Close [ x ] More from Nextgov

Thank you for subscribing to newsletters from
We think these reports might interest you:

  • It’s Time for the Federal Government to Embrace Wireless and Mobility

    The United States has turned a corner on the adoption of mobile phones, tablets and other smart devices, outpacing traditional desktop and laptop sales by a wide margin. This issue brief discusses the state of wireless and mobility in federal government and outlines why now is the time to embrace these technologies in government.

  • Featured Content from RSA Conference: Dissed by NIST

    Learn more about the latest draft of the U.S. National Institute of Standards and Technology guidance document on authentication and lifecycle management.

  • A New Security Architecture for Federal Networks

    Federal government networks are under constant attack, and the number of those attacks is increasing. This issue brief discusses today's threats and a new model for the future.

  • Going Agile:Revolutionizing Federal Digital Services Delivery

    Here’s one indication that times have changed: Harriet Tubman is going to be the next face of the twenty dollar bill. Another sign of change? The way in which the federal government arrived at that decision.

  • Software-Defined Networking

    So many demands are being placed on federal information technology networks, which must handle vast amounts of data, accommodate voice and video, and cope with a multitude of highly connected devices while keeping government information secure from cyber threats. This issue brief discusses the state of SDN in the federal government and the path forward.

  • The New IP: Moving Government Agencies Toward the Network of The Future

    Federal IT managers are looking to modernize legacy network infrastructures that are taxed by growing demands from mobile devices, video, vast amounts of data, and more. This issue brief discusses the federal government network landscape, as well as market, financial force drivers for network modernization.


When you download a report, your information may be shared with the underwriters of that document.