Software insecurity: Sharing the blame

The reason software so often is not secure is the fault either of developers or of users.

A free-wheeling debate on software security at the 2006 International Conference on Network Security in Reston yesterday came to no clear consensus on responsibility for the disappointing quality of software. On the other hand, it was agreed that federal security certification programs could serve as models for improving private sector IT security. Or not.

Andrew Lee, chief research officer for antivirus company Eset LLC of Coronado, Calif., blamed the problem of buggy software on a disconnect between developers and users. What seems proper and intuitive to a developer often is ignored by users, who do strange and terrible things with their applications.

"We don't account for user behavior," Lee said. "Users are just really annoying."

Even well-developed software often is too complex to ever be adequately tested, he added.

Eric Cole of Lockheed Martin Corp. acknowledged that software often has flaws, but said that careful deployment would produce greater returns than more careful coding.

"In a lot of cases, even though the bugs are still there, the impact to your organization can be mitigated," by use of a properly architected network with adequate safeguards. On the other hand, "even if you have good, solid software that is deployed wrong, you can be broken into."

One audience member criticized the security and development communities for focusing on clever tricks for solving problems and deplored the lack of due diligence by organizations in designing networks and deploying software.

"What is it about methodology that is a problem for organizations?" he asked.

Stuart Katzke of the National Institute of Standards and Technology said that standards and guidelines developed by NIST could help provide that methodology. He said the suite of documents produced for the Federal Information Security Management Act effectively establish a level of due diligence for government IT systems.

"It is likely to become due diligence for the private sector as well," he said.

The NIST publications establish requirements for agencies to comply with FISMA. Development of the standards and supporting guidelines are the first phase of FISMA implementation, he said.

"We're completing the last document now," Katzke said. That is Special Publication 800-53A, a security control assessment guide. NIST has begun the second phase of implementation, which is an accreditation program for security assessment providers. A third phase, development of a system to validate FISMA compliance tools, is "out in the future."

"The framework that we have established for federal agencies is really applicable to any environment," Katzke said. He said NIST is working with the IEEE to standardize its suite of documents that would help any organization go through the categorization, assessment and accreditation process required of government systems by FISMA.

Keith Beatty of Science Applications International Corp. went out on a limb by praising the oft-criticized Common Criteria program operated by NIST and the National Security Agency. The Common Criteria are an internationally recognized set of standards for evaluating security products. The goal is to ensure that products either meet a government performance profile, or at least perform the way the vendor claims they do.

"I came from the private sector," Beatty said. "I see models in the government," such as Common Criteria and the Federal Information Processing Standards, "that are very good. It gives you a way to compare products."

Others disagreed with the Common Criteria's worth, complaining that it was more about paperwork than software quality.

"You don't get your evaluation before the product goes out the door," one person said. The product already is in use before the evaluation is done, so "all it does is cost vendors a lot of time."

And money. Evaluation can take months or years and can cost from hundreds of thousands to millions of dollars. One person said the Common Criteria evaluation was not worth the $150,000 "entry fee" a vendor could expect to pay unless the vendor had a government contract in hand that would justify the process.

William Jackson is a staff writer for Washington Technology's sister publication, Government Computer News.