Software makers must improve the robustness of software
as a priority over creating new features, but they lack legal
incentives to do so, a report by theHouse of Lords Science and Technology
Committeehas concluded.
The report on internet security, published in August, said that
software suppliers could design more robust software through
self-regulation and use of standards such as
ISO 9126.
This standard distinguishes software failures in two categories.
The first category is not fulfilling a usage requirement, for
example, critical banking software having weak authentication. The
second category is not fulfilling a specified requirement, for
example, software not being interoperable on different systems.
The report found that software is being released with major
defects. End-users who suffer loss as a result have no legal
recourse against suppliers as licence agreements generally exclude
legal liability.
Legal liability
"The absence of liability means that there is little incentive,
particularly given the high degree of uniformity across the
marketplace, for suppliers to raise security standards in software
development," said Lord Broers, chairman of the report.
Because of this, the committee recommended that the government
explore the introduction of supplier liability within the
industry.
Philip Virgo, strategic adviser at the Institute for the
Management of Information Systems, said, "The cautious
recommendation from the Lords committee that the government explore
supplier liability legislation is well overdue for what claims to
be a mature industry selling reliable products and services."
However, Virgo questioned how one would demonstrate negligence
on the part of a software supplier, given the complex nature of the
product. "Software can be installed or even configured incorrectly
by a user - how do you account for that?" he said.
A spokesman for the Department for Business and Enterprise said
that before legislation was introduced the industry would have to
"look at what would be the likely impact in terms of price and
availability of software, and whether legislation would really
deliver more robust software".
Guy Bunker, senior director of technical strategy at security
software supplier
Symantec, said, "I think liability would be very difficult to
prove. Software suppliers would have to start to protect themselves
legally in the licensing and use of their software, thereby
limiting their liability and limiting the functionality and
interoperability. Using open source software - where no single
person can claim full authorship and responsibility - would also be
limited."
Sun already does this with the latest
Java Runtime Environment. In a rather extreme example of
possible limitations, the licence agreement for the Java
environment excludes its use in designing and operating nuclear
power stations.
Alan Cox, a programmer closely involved with the development of
the Linux kernel, who gave feedback to the Lords committee, said
that software can sometimes interact with different applications in
unpredictable ways. "The rational thing for a software supplier to
do faced with liability would be to forbid the installation of any
third-party software on the system," he said.
Trade off
The Lords report said that some software companies might seek to
maximise flexibility and functionality at the expense of security,
and others might make security decisions that make it more
difficult to download and run third-party applications.
"Good software security begins with good design, but that early
on in development, conscious decisions have to be made to balance
software security with usability," said Guy Tribble, vice-president
of software technology at Apple.
Carrie Hartnell, programme manager at IT suppliers body
Intellect, said that bug-free software could not be guaranteed, and
changing liability could prevent smaller software development
companies from doing business because of the potential compensation
costs.
Ross Anderson, professor of security engineering at Cambridge
University, said that if liability was introduced, courts would be
faced with difficult cases where ascribing liability to a supplier
or to a user who misconfigured the machine would be complicated.
"But analysing such questions of fact and reaching a judgment is
what the courts do every day," he said.
Mark Handley, professor of computer science at University
College London, who contributed to the Lords report, said, "A key
question is assessing whether the person who wrote the software did
the best job that the industry knows how to do in writing that
software. If they did, I do not think they should be liable, but if
they did not, then I think some liability ought to be there."
Market pressures may encourage the use of a "less than optimal
amount of time and resources for testing software", according to a
2002 US report from the National Institute of Standards and
Technology entitled "The economic impacts of Inadequate
infrastructure for software testing".
Daniel Dresner, head of standards at the National Computing
Centre, pointed out the risks in this. "Developers should spend
time getting the design right up-front and prioritising the
features. Then delivery can be channelled around the benefits
required from a release. More features - wow. Bet you do not use
half the old ones. More software interaction is bound to lead to
more problems, but only if you want to accept the risk," he
said.
Dresner said that it would be unfair to lay blame at the feet of
software developers, but there needs to be some way forward to sort
out problems.
Broers said, "Just because something is complex, it does not
mean that we should not begin to take steps to understand it and
fix it. It is better to light a small candle than to continue
complaining about the darkness."