Full disclosure is not the issue

When you delve down into the core of the computer security industry, it becomes possible to separate it into two distinct groups: those who advocate full and open disclosure of vulnerable information (herein referred to as Group A), and those who

When you delve down into the core of the computer security industry, it becomes possible to separate it into two distinct groups: those who advocate full and open disclosure of vulnerable information (herein referred to as Group A), and those who are against it (Group B).

Both groups present what appear to be rational arguments supporting their respective cases, and both seem to be aiming for the same end result – better computer security. However, not only do the two groups differ widely on what each sees as the best way of achieving this aim, but each group sees the other's methodology as directly contributing to the problem!

Group A maintains that full disclosure not only allows people responsible for security to receive the latest information about exploits potentially affecting their systems, but also to receive information that shows them how exploits work – and, by extension, how to protect their own systems against them. Group A maintains that this is the only way to keep 'white hats' (the people on the right side of the law) in front of the 'black hats'.*

Group B has a different ideology for achieving better security, and maintain that its methods are essential if we are to win the battle against crackers and malicious users. If you listen to Group B, you will be told that the only sure way of keeping systems (relatively) secure is to limit, or even cut, the flow of information outside of a few key groups – namely, themselves. This will stop malicious users gaining access to information that could help them attack networks, and also allow companies the time they need to release patches to fix the security holes discovered.

People who fall into group A tend to be end users – system administrators, network administrators, penetration testers and anyone who is responsible for the security of computer networks. These people are the ones for whom information (or lack thereof) means the difference between smoothly running networks and virtual war zones.

Group A is behind such resources as Bugtraq, one of several popular computer security mailing lists run by SecurityFocus. These resources disseminate security information (including how exploits work and, in some cases, the exploit code itself) to the people who need it in order to secure their own systems. This is the main advantage of Group A's point of view. It also happens to be the main disadvantage, according to Group B.

The entities who make up Group B tend to be companies that have heavy financial investments in the products being exploited. Group B says that only by limiting the flow of information to the people who truly need it can we reduce the amount and frequency of systems being cracked. Group B also maintains that in addition to making security information available to those who legitimately need it, resources such as Bugtraq (and indeed the entire methodology of group A) allow malicious users access to the same information. Thus, the same sources that provide system administrators with the information they need to protect their systems also gives the information to the people administrators are trying to secure systems against. According to Group B, if we limit the information to those who truly need it – and distribute only finished patches to the public – it's possible to reduce the overall amount of cracks.

Microsoft is a prime example of a Group B entity (for no other reason than it is the most prominent), but there are several others, including those who don't make application or OS software themselves. These entities potentially lose thousands in sales every time a new security exploit for one of their products is discovered. When information about an exploit involving their products is widely distributed, it makes for bad press among the very people whom these companies want to sell to. The solution? Limit the flow of information about new exploits to a select few, at least until a patch is made available.

Both viewpoints have their merits and their flaws. However, it may be possible that the industry as a whole is focusing on the wrong problem. The real issue may not be the availability of vulnerability information that could be used to help crack systems, but rather the level of involvement of the system and network administrators themselves.

Naturally, if you can guarantee that malicious users have no access to information detailing how an exploit works, you can reduce the number of people using said exploit. However, there is no real way of guaranteeing this. No matter how small the group of people to which you limit the information, there will inevitably be leakage. Once the information is leaked, it will go underground, creating the farcical situation whereby crackers have the information needed to compromise systems, but administrators of those same systems are left in the dark!

No matter how quickly a company releases patches, or how quickly information about an exploit (including what is needed to protect against it) is put onto a mailing list such as Bugtraq, there will always be administrators who either don't know about the patches, or don't take the time to apply them. In this case, no amount of information (or information restriction) will help.

As I see it, Group B's solution allows companies to lengthen the time they have available in which to come up with a working patch. It also allows them an easy form of damage control, as they are able to keep people in the dark about what security problems their products contain. If this happens, companies may address or ignore security problems as they see fit, without the bad reputation that comes with being lax on security issues.

Group A's solution gives people the information they need to secure their systems, but falls down by relying on system administrators to know about and act on this information. In a way, this is a flaw shared between both groups, as neither group's solution will ensure more administrators patch their systems. One solution gives sysadmins the information they need to fix a problem, but leaves it up to them to take action; the other fails to supply administrators with crucial information, relying instead on a patch release some time down the track – once again, the onus for applying it is with the administrator.

It seems the only real solution to the problem is to educate the people responsible for securing computer systems. Restricting information isn't the solution, and the current 'full disclosure' policy is only a small part of it. Before any real progress can be made, system administrators, network administrators and anyone responsible for the security of a network-connected computer must know where to get the pertinent information, how to access the information, how to apply the information and, finally, the motivation to keep their patching up to date. The amount of information available is not the problem. The real problem is what is done with it.

*Note: There is much debate about whether the term 'hacker' is appropriate for people who break into computer systems. Generally, they are either called 'black hat' hackers, or more commonly, 'crackers'. Both terms are acceptable.

--Brad Webb