Full disclosure

From Wikipedia, the free encyclopedia

This article is about a policy of the security industry. For other meanings, see Full disclosure (disambiguation).

In computer security, full disclosure means to disclose all the details of a security problem which are known. It is also a philosophy of security management completely opposed to the idea of security through obscurity, and that is what this article discusses. The concept of full disclosure is controversial, but not new; it has been an issue for locksmiths since the 19th century.

1 Definition
- 1.1 Various interpretations
2 History
3 Controversy
4 See also
5 External links

[edit] Definition

Full disclosure requires that full details of a security vulnerability are disclosed to the public, including details of the vulnerability and how to detect and exploit it. The theory behind full disclosure is that releasing vulnerability information immediately results in quicker fixes and better security. Fixes are produced faster because vendors and authors are forced to respond in order to save face. Security is improved because the window of exposure, the amount of time the vulnerability is open to attack, is reduced.

In the realm of computer vulnerabilities, disclosure is often achieved via mailing lists such as Bugtraq and full disclosure by other means.

[edit] Various interpretations

Even among those who believe in disclosure there are differing policies about when, to whom, and how much to disclose.

Some believe that in the absence of any public exploits for the problem, full and public disclosure should be preceded by disclosure of the vulnerability to the vendors or authors of the system. This private advance disclosure allows the vendor time to produce a fix or workaround. This philosophy is sometimes called "Responsible disclosure".

In the case that a vendor is notified and a fix is not produced within a reasonable time, disclosure is generally made to the public. Opinions differ on what constitutes a reasonable time. Fourteen to thirty days is typical, although the period could be a matter of hours. Internet Security Systems were widely criticised for allowing less than eight hours before disclosing details of a vulnerability in the Apache HTTP Server.

Limited disclosure, with full details going to a restricted community of developers and vendors, and only the existence of the problem being released to the public, is another possible approach. Advocates of this approach also claim the term "responsible disclosure".

To address the controversy of disclosing harmful information to the general Internet community, including blackhats, Rain Forest Puppy developed the RFPolicy, which is an attempt to create a proper way to alert vendors to security problems in their products, and establish guidelines on what to do if the vendor fails to respond.

One challenge with "responsible diclosure" is that some vendors do not respond, or inordinately delay their response, to vulnerability reports that are not public. As long as a vulnerability is not widely known to the public (with enough detail to reproduce the attack), vendors may refuse to fix the vulnerability or refuse to give it enough priority to actually repair it. Unfortunately, vulnerabilities reported to a vendor may already be exploited, or may soon be detected by someone with intent to exploit them. Thus, most security researchers set maximum times (such as 14 days or 30 days) before fully revealing a vulnerability to the public, since otherwise many vendors would never fix even critical vulnerabilities in their products. Many security researchers cite vendors' past failure to respond to vulnerability reports as the reason that they fully disclose vulnerabilities.

[edit] History

The issue of full disclosure was first raised in the context of locksmithing, in a 19th century controversy regarding whether weaknesses in lock systems should be kept secret in the locksmithing community, or revealed to the public.

According to A. C. Hobbs:

A commercial, and in some respects a social doubt has been started within the last year or two, whether it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and know already much more than we can teach them respecting their several kinds of roguery.

Rogues knew a good deal about lock-picking long before locksmiths discussed it among themselves, as they have lately done. If a lock, let it have been made in whatever country, or by whatever maker, is not so inviolable as it has hitherto been deemed to be, surely it is to the interest of honest persons to know this fact, because the dishonest are tolerably certain to apply the knowledge practically; and the spread of the knowledge is necessary to give fair play to those who might suffer by ignorance.

It cannot be too earnestly urged that an acquaintance with real facts will, in the end, be better for all parties. Some time ago, when the reading public was alarmed at being told how London milk is adulterated, timid persons deprecated the exposure, on the plea that it would give instructions in the art of adulterating milk; a vain fear, milkmen knew all about it before, whether they practiced it or not; and the exposure only taught purchasers the necessity of a little scrutiny and caution, leaving them to obey this necessity or not, as they pleased.

— A. C. Hobbs (Charles Tomlinson, ed.), Locks and Safes: The Construction of Locks. Published by Virtue & Co., London, 1853 (revised 1868).

The full disclosure debate came back to life through dissatisfaction at the methods employed by the Internet security infrastructure in the early 1990s. Software security vulnerabilities were reported to CERT, which would then inform the vendor of that software. Public disclosure of the hole would not take place until the vendor had readied a patch to fix it.

However, since the disclosures were private, some vendors took years to produce a fix, or never produced a fix at all. In the meantime, the vulnerabilities were actively exploited by crackers. The tendency by software companies to ignore warnings and rely on crackers' ignorance of the problem became known as security through obscurity.

Since CERT and the vendors were aware of the holes, but attempted to keep them secret even to the administrators of machines being cracked in the field, it was felt that CERT's policies were a manifestation of an impractical, "ivory tower" attitude.

In response to this, mailing lists and other avenues for full disclosure were established, notably the Bugtraq mailing list.

[edit] Controversy

Full disclosure can be controversial, as often these disclosures include code or executable tools to exploit the vulnerability. The argument against disclosure is that providing complete details or tools to malicious attackers, such as blackhats and script kiddies, allows them to take advantage of vulnerabilities more quickly and makes attacks more widespread. However, this argument assumes that without disclosure such tools and attacks would not have occurred. The advantage of disclosure is that whitehats will obtain the information, and that the vulnerability will be detected and patched more quickly.