Full Disclosure of Vulnerabilities - pros/cons and fake arguments
Should the complete details of security vulnerabilities be made public or not? Not only do we need to understand the true pros and cons, but we also need to understand the "fake arguments" - the arguments people bring forth to serve some other purpose than making the "truely right" decision. This paper will try to point out all these things, to aid in building a more complete picture of the full disclosure concept.

What should be the restrictions for full disclosure?

Some restrictions should probably be:

» The vendor should be given a reasonable chance to provide a patch or new version before the vulnerabiliry details are made public.

In some cases the system administrator may be able to fix the problem without a patch - in these cases there would be no necessary need to wait for a vendor patch. A thing to remember though, is that there may be compatibility problems preventing some administrators from applying "quick fixes". The vendor usually takes these things into account when creating the patch.

The vendors need to provide sufficient information to the public so finders of vulnerabilities know how to contact the vendors. Of course they also have to really look at the vulnerability reports. I personally have experienced vendors who reply that they will not consider my findings because I am not registered as a customer...

» When releasing the vulnerability details they should be released completely. The attackers usually have a lot of spare time to figure out the missing parts, but the busy administrators usually don't.

» The vulnerability details should at least be published at places where they reach the largest possible group of security people, for example NTBugtraq for Windows NT / 2000 related bugs. Publishing the information only on not so well known places, increases the risk that attackers will use it before anybody has the chance to fix the problems.

Which are the pros?

» If the vendors know that complete vulnerability details have been, or soon will be, made public they hurry up creating patches.

There is however a risk that the vendor will be stressed to release a patch before it is really thought through and tested. The patch may then not fix the problem completely, or cause compatibility problems.

» If an administrator knows that there are complete vulnerability details made public, this increases the chances that he/she will take the problem seriously and really apply the provided patches.

There are many reasons for an administrator not to apply all available patches. They include worries that the patches will introduce new errors into the system, a high work load, plain lazyness, and that patches for example the OS are not fully supported by application program vendors. Knowledge about the fact that vulnerability details are in circulation out there also gives the administrator an argument against management/vendors for more resources in security issues.

» Those who create security scanners need as detailed descriptions of new vulnerabilities as necessary.

If an "outsider" keeps them secret, there is an increased and unnecessary work load (and delay) for these vendors. If one of them has and keeps the details secret, there is an increased work load (and delay) for the others. Of course this could be considered as a benefit due to competition (bla bla...). But do you really want the vendors competing while you wait for a working scanner to test your systems, when you know that there may be attackers out there who exploit those vulnerabilities?

» Those who do penetration testing need as detailed descriptions of new vulnerabilities as necessary.

How could we keep them secret when so many people at so many different places and organizations have them?


Harnessing artificial intelligence to build an army of virtual analysts

PatternEx, a startup that gathered a team of AI researcher from MIT CSAIL as well as security and distributed systems experts, is poised to shake up things in the user and entity behavior analytics market.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Thu, Feb 4th