Path: utzoo!attcan!uunet!peregrine!elroy!ames!haven!mimsy!aplcen!aplcomm!trn@aplcomm.jhuapl.edu
From: trn@aplcomm.jhuapl.edu (Tony Nardo)
Newsgroups: news.sysadmin
Subject: Re: Proposal for comp.security/alt.security
Message-ID: <2518@aplcomm.jhuapl.edu>
Date: 22 Nov 88 14:25:05 GMT
References: <2347@isis.UUCP> <22460@tis.llnl.gov> <1147@unisec.usi.com> <38151@zardoz.UUCP> <22274@sgi.SGI.COM>
Sender: news@aplcomm.jhuapl.edu
Reply-To: trn@aplcomm.jhuapl.edu (Tony Nardo)
Distribution: na
Organization: Johns Hopkins University/APL (Baltimore, Md.)
Lines: 89

In article <22274@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes:
>In article <38151@zardoz.UUCP>, neil@zardoz.UUCP (Neil Gorsuch) writes:
>> Any commercial or educational site listed in the uucp maps can be added
>> by a mail request from root or one the email contacts or the map entry writer.
>> Any commercial or educational site listed in the MX tables can be added
>> by a mail request from root.
>
>All of the talk about dirty, nasty, greedy, lazy vendors is kind of silly
>if you are going to keep this stuff secret.

Odd.  I don't see talk about "dirty, nasty, greedy, lazy vendors" in the
quoted paragraph.

>You "SA's" do occassionally install new releases, don't you?  Do you
>sometimes install new systems, occassionally from a different vendor?  Do
>you want the holes fixed, or are you simply accumulating your own bags of
>security holes, for your own use, whether to impress your clients and
>bosses or for worse?

No, we sometimes need to fix a problem as soon as it is discovered.

We don't want to wait *years* waiting for a vendor to patch a problem, and only
have the problem addressed when an Internet worm/virus/demon-from-hell hits.

And no, we don't always install new releases.  Have you ever had to reengineer
a product because some vendor believed the term "upward compatability" was a
quaint idea in theory, but useless in practice?  I have -- not on UNIX, but
another operating system.  When you design a process control system that can't
afford down time (because the end user was too cheap or too limited in budget
to afford redundancy), you tend to freeze the end product -- including the
computer vendor's software -- as soon as the system goes into continuous use.

>You need to tell every vendor from whom you might ever purchase a system,
>ideally including those not on the Internet or Usenet.  (Yes, there are
>companies my current employer thinks are competators which are on
>neither.  Of course, you are more than welcome to disagree about this.)

I don't recall seeing any rules against vendors subscribing to either list.
In fact, a sufficiently conscientious vendor would make the effort to join
on its *own initiative*.  Call it attentiveness to customer concerns.

I will agree with you on one thing.  If someone owns a system and doesn't
report a known bug to the vendor, they have no right to scream about the
vendor not fixing it.

>The people who administrate the gateways usually have nothing to do with
>the people who build and fix the products.  (It is a sign of a small or
>until recently small company when the MIS types have not been able to wrest
>control of the gateway from engineering.)

Corporate America *does* have its problems there...

>If you tell Foo Inc about a
>bug, and it is a real bug, 100 to 1000 people will be privy to it.

In my experience working for "FUBAR" (I prefer the proper initial slang), if
you told that company about a bug *ONLY THROUGH PROPER CHANNELS*, maybe six or
seven people would hear about it.  The problem would then be effectively buried
until a sufficent number of customers (and potential customers) started talking
about the bug amongst themselves.

Worse, even when knowledge of a bug did reach the general engineering
community in "FUBAR", management clones discouraged work on fixing the problem
unless (a) some customer was footing the bill, (b) a chemical plant blew up
(or something equally embarassing) and legal action was threatened, or (c)
ex-customers started warning potential customers away.

>At most one will be an "SA", and three or four might know the root password
>of foo.com.  (In bigger companies than I've worked for, that might be
>>>1000.)

All it takes is one person at "FUBAR" to distribute the knowledge gained from
the networks/mailing lists.  (Ever hear of an "outstanding problem" list?)  Of
course, some companies are too myopic to see the need to give someone adequate
time to fill this role.

>In sum, if you're not basically a 'bad-guy' yourself, you're going to
>end up letting many unwashed people in on the secret.  The longer you
>delay, the longer it will take to get it fixed.

A lot of "washed" people will be in on the secret, too.  Reporting a problem
to some vendors is like putting a note in a bottle and throwing it into the
ocean.  Exchanging problems with other SAs gives all of us a chance to
work around them until proper solutions are provided.

===============================================================================
ARPA:	trn@aplcomm.jhuapl.edu			(currently off line)
UUCP:	{backbone!}mimsy!aplcomm!warper!trn
===============================================================================