Date: 25 Sep 1992 11:07:31 -0700 (MST) From: RayK Subject: File 3--Implementing System Security Toward the Implementation of a System and Network Security-Related Incident Tracking and Vulnerability Reporting Database by Ray Kaplan Consider the need for a system and network security-related incident tracking and vulnerability reporting database (herein referred to as ITVRD for convenience). Such a database might be a relational combination of reported vulnerabilities and incidents that could answer queries such as "show me recorded instances of compromise for version xxx of operating system yyy on zzz hardware" or "show me a list of known vulnerabilities of the login sequence for version xxx of operating system yyy on zzz hardware" or even, "show me a list of reported compromises of version AAA of third party product BBB running under version xxx of operating system yyy on zzz hardware". We might even be able to ask "show me known instances of password guessing attacks on version xxx of operating system yyy on zzz hardware at banks." It is widely known that the flow of security-related information is carefully controlled and that such information is not readily or widely available to those who need it to protect their systems and networks. There is plenty of information available - but, its availability seems limited to the underground. While this apparently serves those who know and control this information, but it does little to help those who are trying to protect their systems and networks. Security by obscurity is widely known to be a flawed concept. My argument would be that this game of security incident/vulnerability tracking is a lot like dealing with the AIDs crisis. If we don't start talking openly about it, we are all in trouble(1). While some of the various computer incident handling capabilities do an excellent job of distributing SOME significant vulnerability and incident information publicly(2), VERY LITTLE detailed information gets disseminated in comparison to the number of known vulnerabilities and known incidents. In addition, those who are not connected to the Internet have a difficult time staying abreast of those incidents that are reported. Worse yet, I speculate that the majority of systems and private networks that exist in the world today are simply not even tapped into the meager flow of security-related information that does exist. I believe that this sad situation is due to the politics of security vulnerability information between vendors in the market(3), and an inherent desire to control the distribution of this information by the portion of the security community that has placed themselves in charge of it. As proof of this, consider that prototypes of system and network security-related ITVRDs are known to have been funded by the government, but were stopped when the funding agency wanted to classify the effort making it publicly inaccessible(4). What we - as a community - are left with is an odd situation where the best collections of vulnerability information are to be found only on the clandestine sources of the world's underground computer community. At this writing, the Defense Advanced Research Projects Agency's (DARPA) Computer Emergency Response Team (CERT) is reporting on the order of 3 incidents per day, but we - as a community - hear very little about the exact nature of these problems, how they can be used against our systems or their fixes. While the relatively new Forum of Incident Response and Security Teams (FIRST) is working on the problems associated with the design and implementation of a ITVRD, their discussions are carefully restricted to their members and this topic has been under discussion for quite a long time with no apparent movement. In addition, most of us are not members of FIRST, so we can't contribute to the discussions even if we wanted to do so. Since I know that the formation of a widely available ITVRD is a very, very emotional issue in the security community and since I am not willing to suggest that I have the best design and implementation plan for it in mind - I'm simply throwing the question out into the community for an open, vigorous debate: how can a system and network security-related ITVRD be implemented - or should it even be implemented? Based on my recent, unsuccessful experiences in trying to get members of the legitimate security community at large to talk to members of the world's computer underground, I have decided that it is not prudent for me to proceed with the design and implementation of a ITVRD until some consensus in the community is reached about how - or even if - such a thing should be done. As a seed for the debate, here are some of the questions surrounding the implementation of a ITVRD that I think need vigorous discussion by the community. Please consider them carefully and offer us your thoughts. Post your reply to this channel or send it to me at any of the addresses below and I will collect it, combine it with others that I receive and report it in some regular manner which is yet to be determined. A Myriad of hard questions: What of the morals and ethics questions that surround the establishment of a widely available ITVRD? While this is not a new idea(5), we are talking about the morals and ethics of making an ITVRD available to anyone who wants access to it. This necessarily includes those that are not members of the legitimate security community. Even though information such as that which an ITVRD would hold is readily available now, it takes a lot of time and energy to find it. An ITVRD would make incident and vulnerability information trivially available to anyone who wanted it. How should an ITVRD be accessible? Should it be a database on the network that can be accessed by simply sending a well-formed query via electronic mail to a database server? Should an ITVRD allow interactive access? Should it be available via a toll-free, 1-800 number? A pay per-call, 1-900 number? Since it has its own very well-developed channels of communication, why would the underground even care to contribute to such an ITVRD? Would a widely accessible ITVRD threaten or replace popular underground publications like Hack-Tic or 2600? Would the underground be happy with attribution for the holes that they find? Would the contributors to an ITVRD even want to be identified? Should a subscriber-based ITVRD pay its contributors for their submissions? If so, on what basis and how much? Should it be available to those that want to passively access it without contributing to it? Should this access be on a subscription basis? If so, does such a subscription service need some sort of authentication to restrict access to only legitimate, paid subscribers? Should the contents of an ITVRD be exactly what is submitted to it, or should submissions to it be edited and/or verified for authenticity. If editing, verification and authentication of submissions are to take place, who should do this and under what rules should it be done? In recognition that many organizations do not currently report their security problems, should anonymous submissions be allowed? Should such an ITVRD be in the public domain or should it be private property. Where should an on-line ITVRD be maintained? Should it be located outside the traditional boundaries of countries that would restrict its availability? I am sure that I have missed many, many important questions. Please contribute to this discussion. Electronic mail:Internet - kaplan@mis.arizona.edu BITNET - KAPLAN@ARIZMIS Snail mail: Ray Kaplan P.O. Box 42650 Tucson, AZ 85733-2650 FAX - (602) 791-3325 This has been posted to: Some common Network Newsgroups, and the DECUS DECUServe bbs.Several of the world's underground publications: 2600 and HacK-Tic.Selected members of the security community. Please feel free to re-post this anywhere you see fit - it is hereby released into the public domain. If you post it somewhere - please let me know where you put it so I can try and track the discussions - I'd like to do a summary of it all one of these days. In advance, thanks for your time and consideration. Since I know that the ire of powerful forces in the security community may be stirred up by the idea of publically discussing the design and operation of an ITVRD, I only hope that a reasoned exchange of ideas will follow. ++++++++++ (1) I get into some interesting discussions with people who argue that secrecy is the best course of action. For instance, while splitting hairs on the tough subject of when you begin (of if there even should BE) sex education, there is an argument that says educating very young people about their sexuality will induce them to experiment where they otherwise might not do so. In my view, this is similar to discussions that I have with those that oppose the implementation of an ITRVD. There are those that say the mere availability of an ITRVD will cause more incidents. In the face of this criticism, I say that while this may be true, at least system and network managers WILL have a reference for this information where currently there is none. Just think, the formation of an ITRVD may lead to vendors actually shipping a document that describes the known vulnerabilities of their systems to their customers. Sort of like the warning from the surgeon General's warning on alcohol and tobacco products? (2) Of note here is the Defense Advanced Research Projects Agency's (DARPA) Computer Emergency Response Team (CERT). While these consummate professionals do an excellent job of distributing incident and vulnerability-related information to the Internet community, not nearly enough is being done. (3) While it is clear that there are vulnerabilities which affect many vendors, there is evidence to suggest that some vendors in the incident response community don't acknowledge those reports by other vendors which clearly affect their own systems - let alone reporting all of the vulnerabilities of their own systems. (4) References available if you'd like them. (5) There most certainly are ITVRDs currently being maintained in various places. Downloaded From P-80 International Information Systems 304-744-2253