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.”

— by Aliya Sternstein – NextGov – 09/22/11 – at http://www.nextgov.com/nextgov/ng_20110922_9166.php?oref=rss?zone=NGtoday