[ISN] Software insecurity: Plenty of blame to go around

Wed Apr 19 01:44:44 EDT 2006

http://www.gcn.com/online/vol1_no1/40437-1.html

By William Jackson
GCN Staff
04/18/06

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 today 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 he 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.