Hacker 2/HACKER2.mdf/cud/cud448c.txt

Text File | 1995-01-03 | 11KB | 204 lines

Date: 25 Sep 1992 11:07:31 -0700 (MST)
From: RayK <[e-mail]>
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 - [e-mail]
BITNET - KAPLAN@ARIZMIS

Snail mail:
Ray Kaplan
P.O. Box 42650
Tucson, AZ  85733-2650
FAX - [phone]

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