[iwar] [fc:'Responsible.Disclosure'.Draft.Could.Have.Legal.Muscle]

From: Fred Cohen (fc@all.net)
Date: 2002-03-11 17:43:25


Return-Path: <sentto-279987-4591-1015897333-fc=all.net@returns.groups.yahoo.com>
Delivered-To: fc@all.net
Received: from 204.181.12.215 [204.181.12.215] by localhost with POP3 (fetchmail-5.7.4) for fc@localhost (single-drop); Mon, 11 Mar 2002 17:52:08 -0800 (PST)
Received: (qmail 29550 invoked by uid 510); 12 Mar 2002 01:48:57 -0000
Received: from n30.groups.yahoo.com (216.115.96.80) by all.net with SMTP; 12 Mar 2002 01:48:57 -0000
X-eGroups-Return: sentto-279987-4591-1015897333-fc=all.net@returns.groups.yahoo.com
Received: from [216.115.97.187] by n30.groups.yahoo.com with NNFMP; 12 Mar 2002 01:42:14 -0000
X-Sender: fc@red.all.net
X-Apparently-To: iwar@onelist.com
Received: (EGP: unknown); 12 Mar 2002 01:42:13 -0000
Received: (qmail 8732 invoked from network); 12 Mar 2002 01:42:13 -0000
Received: from unknown (216.115.97.171) by m6.grp.snv.yahoo.com with QMQP; 12 Mar 2002 01:42:13 -0000
Received: from unknown (HELO red.all.net) (12.232.72.152) by mta3.grp.snv.yahoo.com with SMTP; 12 Mar 2002 01:42:12 -0000
Received: (from fc@localhost) by red.all.net (8.11.2/8.11.2) id g2C1hPK31889 for iwar@onelist.com; Mon, 11 Mar 2002 17:43:25 -0800
Message-Id: <200203120143.g2C1hPK31889@red.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
X-Mailer: don't even ask
X-Mailer: ELM [version 2.5 PL3]
From: Fred Cohen <fc@all.net>
X-Yahoo-Profile: fcallnet
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Delivered-To: mailing list iwar@yahoogroups.com
Precedence: bulk
List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com>
Date: Mon, 11 Mar 2002 17:43:25 -0800 (PST)
Subject: [iwar] [fc:'Responsible.Disclosure'.Draft.Could.Have.Legal.Muscle]
Reply-To: iwar@yahoogroups.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

'Responsible Disclosure' Draft Could Have Legal Muscle
A proposed Internet standard would dictate how researchers report and
vendors close security vulnerabilities. Ignoring it could be risky for
either side.
By Mark Rasch
Mar 11 2002 12:43AM PT

<a href="http://online.securityfocus.com/columnists/66">http://online.securityfocus.com/columnists/66>

A proposal recently submitted for comment to the Internet Engineering Task
Force by Steve Christey of MITRE and Chris Wysopal of @Stake would create an
official standard for reporting security vulnerabilities to vendors, and for
vendors to respond to any such reports. It's worth reading, because if it
becomes an official Internet standard, called an "RFC", it could expose
those who fail to adhere to it to legal liability for negligence or
defamation.

By and large the report articulates what many in the security industry have
considered to be a reasonable method of reporting security vulnerabilities.
Essentially the draft recommends a process whereby a person discovering a
security vulnerability would notify the vendor of the vulnerability, but not
publicly disclose it.

The vendor would, after having seven days to acknowledge receipt of the
disclosure, be obligated to validate the existence of the vulnerability, and
resolve the vulnerability either by issuing a patch or resolution, or
indicating that the vulnerability is not susceptible to any fix, and
recommending remedial efforts, if any. The proposal creates a role for a
"coordinator" (e.g., an ISAC or CERT) to mediate between the reporter and
the vendor, and to help publicize the existence of the patch or remediation.

While such policies and procedures have been frequently followed among
responsible computer security professionals, those discovering
vulnerabilities have complained that vendors may have no individuals
specifically designated for notification of security vulnerabilities, and
may be unresponsive to reporters complaints. Meanwhile, vendors complain
that hackers frequently report or even exploit vulnerabilities before the
vendor can take reasonable steps to repair them.
'To the extent that the standard results from a consensus, failure to adhere
to it could be deemed by a court to be negligence. '

Liabilities Associated With Reporting
The proposal is intended to address the release-and-patch security cycle of
modern software. Software vendors frequently put out code that is at best
insecure, and which exposes users to serious vulnerabilities. Not only might
the code itself be insecure, but particular configurations of the software,
or the interface between different applications, may render the overall
enterprise vulnerable to attack.

Hackers -- used in the non-pejorative sense -- complain that vendors fail to
take responsibility for such vulnerabilities, particularly where they result
from the interaction between one vendor's product and another, blaming the
other vendor for the problem, or blaming the user for improper
configuration. Code may be release to be public as a "final" version, with
an implicit recognition that the consumer will act as the ultimate "beta"
tester. Rather than implementing a full quality assurance program, the
vendor may rely on consumers to report vulnerabilities.

Imagine buying a new car where neither the brakes, seat belts or air bags
have been fully tested, and having the manufacturer tell you to report any
problems with the safety systems, and they will be fixed in the subsequent
model year. To make matters worse, the vendor will rely upon disclaimers of
warranty in the click wrap or shrink wrap license to absolve themselves of
any liability for such security vulnerabilities. Additionally, vendors do
not have a centralized reporting structure -- a specific individual or set
of individuals whose sole responsibility is to fix security related
vulnerabilities, not only of the vendor's product itself, but of
vulnerabilities associated with the use of the vendor's product.

Finally, vendors are frequently seen as unresponsive to external reports of
vulnerabilities. The reporter may not know that the vendor has received the
report, and is frequently kept in the dark about the status of the
investigation and repair of the vulnerability. Faced with apparent inaction
on the part of the vendor, the reporter may resort to "self help" and simply
make public disclosure of the vulnerability.

To Report or Not To Report
From the vendor's standpoint things are equally bleak. Vulnerability reports
may be nothing more than hoaxes or rumors, the investigation of which leads
to a waste of time or resources.

Fixing security vulnerabilities may not be the vendor's highest priority,
particularly where the product involved is freeware or shareware, previously
released and unsupported software, or otherwise unprofitable to support. The
vendor may not feel it is a worthy use of limited engineering resources to
fix a vulnerability that is theoretical, or represents only a minor threat.

Where the vulnerability results from a configuration issue, or
interoperability between programs, the vendor may simply recommend a
reconfiguration of the software, even if that results in a significant loss
of performance. Likewise, the interoperation problem is likely to be blamed
on the other guy's software. Finally, no vendor wants to publicly admit that
a product was released with a vulnerability.

All of this brings us to the reporting dilemma.

The law generally requires people to act "reasonably." That is, a vendor
owes a duty of due care to the community of people who use or rely upon the
product, and makes certain warranties and representations about the product
itself. For products, this generally includes a warranty that the product is
"fit" for its intended use, although unless prevented by state or federal
law, some of these warranties can be modified by contract -- typically the
software license itself. Even if warranties (express or implied) are waived,
the vendor must still act reasonably when notified of a defect in its
product.

Similarly, a person discovering a vulnerability is required to act
"reasonably." Publicly reporting a fictitious vulnerability would likely
subject the reporter to liability for tortuous interference with business
relationships, business defamation, or other potential liability. For
example, willfully disseminating false information about a vulnerability
could even result in liability for securities fraud or stock manipulation if
the disclosure was intended to affect the price of the company that
manufactured the product. If a company publicly discloses the existence of a
vulnerability in a competitor's product, this could be either the act of a
good Samaritan or an unfair trade practice.

Negligence Per Se
The standard of reasonable care is a difficult one to deduce -- particularly
where there is little consensus on the proper thing to do. This is
especially the case for reporting of security vulnerabilities. The law
distinguishes between "ordinary" negligence -- simply not adhering to a
standard of care -- and "negligence per se" -- acts which are so violative
of a known standard of care that they are presumed to be negligent.
Typically (but not invariably) failure to comply with a law or regulation is
deemed to be negligence per se -- it is negligent to drive 75 MPH in a 55
MPH zone. The law or regulation establishes the standard of care.

In this case, the "Responsible Disclosure" draft sets out recommended
practices and procedures for reporting of security vulnerabilities and for
vendor's responses thereto. While there are flaws in the proposal, to the
extent it results from a consensus, it can be seen as establishing a
standard of care. Failure therefore to adhere to this standard (just like
failure to adhere to a standard such as BSD 7799) could be deemed by a court
to be negligence per se.

The development of a consensus on reporting of vulnerabilities is only one
step in solving the problem. Vendors need to accept social and legal
responsibility for the quality and security of their products, and for their
interoperability. Vendors must make those responsible for security more
visible, and more public. Indeed, searching most vendor websites, one is
hard pressed to find the name of a specific individual responsible for
reporting security vulnerabilities.

Because of the diversity of the reporting community, it must inevitably be
recognized that groups of hackers will exploit rather than report
vulnerabilities, or will publicly disclose them in order to take "credit."
There is no provision in the draft that would permit or require the vendor
to responsibly notify the user community (even in a confidential fashion)
that a vulnerability exists before a fix or patch is available. The draft
essentially absolves the vendor of liability for damages that result from
exploitation of a vulnerability known to the vendor, but not yet patched. In
many cases, the reasonable thing for the vendor to do would be to advise the
user community to disable or discontinue use of a product or functionality
pending the investigation of the exploit, but the draft has no such
requirement. The implication is that failing to do this on the part of the
vendor is not unreasonable.

Common sense has a tendency to trump all rules and regulations. While the
decision whether or not to disclose or report a vulnerability is a difficult
one, common sense should prevail. All the law requires is that we act
reasonably. If only we could agree on what that was.

Mark D. Rasch, J.D., is the Vice President for Cyberlaw at Predictive
Systems Inc. in Reston, Virginia, a computer security and network design
consulting firm. Prior to joining Predictive Systems, Mr. Rasch was the head
of the U.S. Department of Justice Computer Crime Unit and prosecuted a
series of high profile computer crime cases from 1984 to 1991.

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



This archive was generated by hypermail 2.1.2 : 2002-12-31 02:15:04 PST