One of the components of
Cyber Space Security is the identification of security vulnerabilities in
software applications. Undetected and unplugged vulnerabilities create serious
security risks for the users of software systems. At the same time, unless a
software reaches mass use stage, some of the vulnerabilities may not surface
despite extensive beta testing by vendors.
Under the circumstances, it
is important for security organizations to keep testing products and identify
vulnerabilities for informing the user public. Once a vulnerability is
detected, the security organization would be in a dilemma as to whether it
should immediately disclose it to the public or report it to the vendor so
that a security patch can be created before the vulnerability is made public.
If the vulnerability is disclosed earlier and the software is already in wide
usage, it may be exploited by many criminals before the public can secure
their systems. News about vulnerabilities always travels faster amongst the
cracker/hacker network than amongst the public. In the absence of information
the exploitation of the vulnerability may be low. Most vendors would therefore
prefer the vulnerability to be reported to them and not made public until a
patch can be found.
While there is some logic in
the argument that the detected vulnerability should be held under wraps under
the control of the vendor, this puts the security system under a constraint.
If the vendor is unable to develop an effective patch within a reasonable
time, the society will continue to face the risk and soon crackers would get
the scent of it and start exploiting it on an unwary public.
Security strategists
therefore advocate that while a first option may be provided to the vendor to
fix the vulnerability, within a reasonable time, the vulnerability may be made
public so that the vendor would be under pressure to develop the patch quickly
and the public are secured without delay. It is however difficult to arrive at
what should be a reasonable time in this respect.
There is a debate as to
whether there should be legislation in this regard or if it should be left to
the industry to develop its own standards of disclosure. There is also a
debate on what should be the role of national Governments in such a situation
and whether there is a role for them in setting "Security Standards for
Software".
Recently, some of the
vendors in US including Microsoft and Symantec formed a body called
"Organization for Internet Safety (OIS)" with an objective to develop
acceptable processes for handling security vulnerability information. This
group has at present no public participation and therefore represents only
commercial interests. It has presently believes that the "software author
should be given a chance to create a fix before vulnerability information is
made public, but that there should be no further distribution of that
information until the fix is complete".
This suggestion means that
the community will not have any knowledge until the vendor who has a vested
commercial interest in preventing disclosure chooses to disclose the
vulnerability and the accompanying patch to fix it. In the case of IPR
protected software where the source code is protected, the public will not be
sure if the patch has been effectively fixed or the problem has only been
diverted. It will require another vulnerability detection and another patch
for this information to become public. Effectively therefore the vendor can
keep selling his product with the IPR protection and make consumers pay for
his inefficiency.
While it suits the software
vendors to delay disclosures as long as possible, it seriously undermines the
credibility of the security system vendors in the eyes of the community.
Internet Security Systems (ISS) which is one of the founding members of the
OIS has therefore come out with its own Vulnerability Disclosure guidelines
according to which the vulnerability will be made public 30 days after
notifying the vendor. And if there is a discussion of a new vulnerability on a
public mailing list, the vendor becomes unresponsive or a news article
mentions the flaw, then ISS will accelerate its public notification.
The guideline also
distinguishes between the rights of the customers of the security services and
the public. The customers of ISS would be informed about the vulnerabilities
one day after the vendor has been notified.
ISS policy which is now
public would be a new benchmark for vulnerability disclosure norms and other
security companies need to follow similar policies and make them public.
In India, naavi.org suggests
identification of an Apex Cyber Space Security organization which can develop
norms for public disclosure of security vulnerabilities and its effective
implementation.
Since such guidelines will
not be in the interest of the software vendors, it is imperative that it is
the Government that has to take the lead in this respect and should be capable
of withstanding the commercial pressures that may be brought on them to dilute
the norms.
Suggestions and views on
this are welcome.
Naavi
December 5 , 2002
Related Article:
ISS Goes Public With Vulnerability Disclosure Guidelines-e-Week
Organization for Internet Safety-FAQ
Vulnerability Disclosure Guidelines from ISS
