Chapter 18 - Reporting Security Problems

• Published in: Hack Proofing Your Network 2E pp. 749 - 766
• Main Authors: David R. Mirza Ahmad, Ido Dubrawsky, Hal Flynn, Joe “Kingpin” Grand, Robert Graham, Norris L. Johnson, K2, Dan “Effugas” Kaminsky, F. William Lynch, Steve W. Manzuik, Ryan Permeh, Ken Pfeil, Rain Forest Puppy, Ryan Russell
• Format: Book Chapter
• Language: English
• Published: Syngress 2002
• Edition: Second Edition
• ISBN: 1928994709; 9781928994701
• DOI: 10.1016/B978-192899470-1/50021-5

The aim of this chapter is to elucidate the intricacies of reporting security problems. Most vendors are responsible to secure their products but security holes do exist in almost every product ever released by any vendor. It is not plausible for vendors to test their products under every imaginable set of conditions, and many exploits need using the product in a non-standard way that was not intended by the vendor. While vendors usually identify and rectify some security flaws on their own, by and large most security flaws are discovered by user communities and security professionals. To report a security problem, there are many factors that determine how much detail is supplied, and to whom. The amount of detail one can provide depends on the amount of time one has to spend on the issue, as well as the interest level. One may have fully developed an exploit, or the problem may be so easy to exploit that no special code is required. In that instance, decisions need to be made—such as whether one plans to publish the exploit, and when. How much detail to publish, up to and including whether to publish exploit code, is the subject of much debate at present. this chapter discusses the pros and cons, rights and wrongs, of the various options.