GCN Home > 04/18/06 web stories
Software insecurity: Plenty of blame to go around
By William Jackson, GCN Staff
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 dont 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.

More news on related topics: Software Applications, IT Security