The RISKS Digest
Volume 18 Issue 40

Tuesday, 3rd September 1996

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Accidental missile launch: color-code mixup
Ken Wood
About 3 weeks with network problems...!!!
Isaias Callejas
A funny thing happened on the way to the bank...
Andy Piper
Changing credit-card address
Gene M. Stover
Back-country technology
Andrew Duane
FedEx monitoring of cellular phonecall locations
Bernard Glassman
Re: "More power to us"
Ralph Barone
Algol passwd changer?
Marianne Mueller
Risks of multiple HTTP standards
Pete Bentley
Re: Tunnel vision of Computer Society CD-ROM
Geoff Kuenning
Theodore Y. Ts'o
Timothy R Prodin
Re: Exploding GPS (RISKS-18.39)
Matt Fichtenbaum
Re: Karpov v. the Internet" game
Dick Mills
Pete Mellor
19th Information Systems Security Conference
Jack Holleran
Information Security Conference - Cleveland
Robert Terry
Info on RISKS (comp.risks)

Accidental missile launch : color-code mixup

Ken Wood <kenwood@ti.com>
Fri, 30 Aug 1996 12:00:09 -0500
The never ending saga of technology + human error = disaster:

 Inquiry Ordered in Missile Incident
 STEWART BELL, *Vancouver Sun*

 The Canadian navy mistakenly launched an unarmed missile at a town near
 Victoria, B.C. on Thursday, hitting a residential garage and narrowly
 missing a food store and day care centre.  Sailors were testing weapons
 systems aboard the HMCS Regina at 11 a.m. when the missile was fired at the
 town of View Royal on Vancouver Island.  The military has since suspended
 all such testing on both coasts and ordered an inquiry.  Although nobody was
 injured, residents of the bedroom community of 6,000 people say things
 could have been much worse. Thirty-two children were a half-block away at
 the Tiny Tots Day Care Centre when the incident occurred.

 HMCS Regina, one of Canada's new $1-billion high-tech frigates, was docked
 at CFB Esquimalt on Vancouver Island during the mishap.  A military
 official blamed human error, saying a sailor inserted a live missile instead
 of a dud into the launcher.  The error apparently resulted from a mix-up
 over the color-coding of the missiles. While the test called for a green
 "inert test set," which contains no propellant and therefore could not
 launch, a blue "inert practice round" was mistakenly used.

 Neither the missile that was fired, nor the one that was supposed to have
 been fired, contained explosive materials. But the errant missile
 - 1.5-metres long and weighing 18 kilograms - struck with considerable
 force, punching a hole in the garage roof and passing through a
 workbench before exiting the building and burying itself deep in the lawn.

The story says it all, no commentary needed!
Source: http://www.southam.com/vancouversun/


About 3 weeks with network problems...!!!

Isaias Callejas-SYC <isma@sycmail.syc.com.mx>
Fri, 30 Aug 1996 11:23:25 -0600 (CST)
About 3 weeks with network problems [resulted] when on an "enchanted" day
somebody connected an Ethernet transceiver AUI-UTP over the net with the
Heartbeat Switch enabled.

There are two switches located on the top of the unit: the Heartbeat Enabled
(HBE) switch and the Link Test (LNK) switch. The switches are initially set
to both Heartbeat and Link test "Enabled".

In the Heartbeat enabled position, the transceiver send a signal (called a
"heartbeat") across the AUI collision pair (COL) immediately after it
transmits. In the disabled position, a heartbeat is not sent back to the
attached device.

The manual says that if the transceiver is attached to a repeater you have
to place the switch in the disabled position. Otherwise, the heartbeat
signal will falsely indicate collisions to the repeater.

The risks I see are :

 * The transceiver was connected to a PC over the net WITHOUT read the
network board's manual of the PC and transceiver, and as the HBE is enabled
by default...

 * The risk begin when somebody do something that can affect to everybody
without tell it to anybody...!!!

My questions are :

 * Is it necessary to have the HBE enabled by default from factory..???
 * Is more common to need the HBE enabled than disabled...???

The problem was already solved and we spent a lot of time trying to do it.

E. Isaias Callejas Mancilla  Sistemas y Computadores de Gestion
Luis Kuhne #10, Col. Las Aguilas  C.P. 01710, Mexico D.F.   (525)664 00 96


A funny thing happened on the way to the bank...

Andy Piper <andyp@parallax.co.uk>
Mon, 2 Sep 1996 17:02:16 +0100
Not a new subject to RISKS readers, but a personal experience that amazed me
could happen.

I went to our local ATM to get some cash to pay the plasterer last week.  I
requested 110 pounds, the machine said "please take your money", nothing
appeared, then it said "please take your receipt", nothing appeared.  I
rushed into the bank, they checked it on the computer and yes it appeared to
be a valid transaction and yes it had been debited from my account. As it
wasn't a branch of my bank I have had to fill in a disputed transaction form
to try and claw the money back.

This of course is the age old risk of the computer says its true so it must
be :). However, we usually associate problems with ATM's with malicious
intent rather than software bugs. For I realised what the problem was - when
I used the ATM I initially pressed proceed without entering an amount. The
machine then reported the error and asked me for the amount.  I am convinced
that the "unusual" input conditions triggered a software bug, and sure
enough when I tried again entering the right amount straight off I was
presented with the cash, although by this time I was 220 pounds the poorer.

I am just shocked that it was this easy to confuse a simple piece of
software/firmware, where the result is rather painful.

I assume that they count the ATM delivery every night so that I *will*
eventually get my money.

andy piper  andyp@parallax.co.uk


Changing credit-card address

"gene m. stover" <gangrene!gene@netcom.com>
Fri, 30 Aug 96 22:36:31 -0500
I know we've already seen incidents like this, but I thought I'd mention it
for the record:

I recently moved and called my credit card company to inform them of my new
address. To verify that I was who I claimed, they asked me for the last four
digits of my social security number, which I supplied.

Of course, their records didn't agree.

The clerk and I discussed for a while how I could prove my identity. In the
end, she said she would change my address now if I agreed to call during the
next business day to work out the discrepancy with my social security
number.

But it gets better.

I called during business hours the next day to give them my true social
security number. Of course, they needed to verify that I was who I was, so
the clerk asked me for my address.

The risks? Let me count the ways ...

gene m. stover (gene@CyberTiggyr.com)


Back-country technology

Andrew Duane USG/PE <duane@zk3.dec.com>
Tue, 3 Sep 1996 10:10:08 -0400 (EDT)
>From the GORP section of the September 1996 issue of the AMC (Appalachian
Mountain Club) *Outdoors* magazine:

Clueless:

When two Pennsylvania hikers discovered they were lost in the White Mountain
National forest this summer, they tried to use their spiffy high-tech Global
Positioning System (GPS) [receiver] to get un-lost — only the darn thing
turned out to be pretty useless without a map.  No matter, the hikers simply
dialed for assistance on their cell phone.  Luckily, officials who fielded
the call had not only a GPS, but a map, too, and located the hikers.

Andrew L. Duane (JOT-7) Digital Equipment Corporation
duane@zk3.dec.com  (603)-881-1294


FedEx monitoring of cellular phonecall locations

<glassman@sunsite.unc.edu>
Mon, 2 Sep 1996 22:24:13 -0400 (EDT)
A week or so ago I used my Cellular One phone to call FedEx to inquire about
Saturday pickup locations near Boone or Blowing Rock NC. At the time, I was
nowhere near either of those places, so I did not bother to mention my
current location to the operator. The next day, Saturday, I called FedEx
with the same cell phone from Blowing Rock to arrange the pickup. The
operator immediately asked if I wanted them to come to the intersection that
I had placed my call from the day before.

Two days later, a FedEx operator confirmed that they are getting "new
systems" at some locations that are able to record the locations from which
cellular calls are placed.

I have now asked Cellular One three times to explain to me why they do not
tell subscribers that they pass this location information through the
system, but to no avail. Each person I talk with says that he or she has
never heard that this information is available,

1. Is it just me, or does it seem to other readers that there are legitimate
concerns about RISKS to cell phone subscribers who are not warned that they
may be having their locations monitored?

2. Is it possible for FedEx to capture information that Cellular One doesn't
know it's passing?

Bernard Glassman


Re: "More power to us" (RISKS-18.32)

"Ralph Barone" <Ralph.Barone@BCHydro.bc.ca>
Wed, 14 Aug 1996 11:07:09 -0700
  [This message was intended to have been included earlier.  It is offered
  now as presenting some useful background on the 10 August power outages.
  PGN]

In my personal opinion (not that of my employer), there are some factors
that contribute to outages like this.

1) The transmission system (the lines between substations) is constructed
with more redundancy than the distribution system (the lines from the
substation to your house).  As a result, the transmission system tends to be
more reliable than the distribution system and most failures on the
transmission system do not result in loss of service to customers.  Usually,
when you have an outage at your home, it is because of a fault on the
distribution system.

However, the transmission system is built on a much larger scale than the
distribution system.  Also, when redundant systems finally fail, they tend
to fail in a much more spectacular fashion than non-redundant systems.
Therefore, when an outage is due to transmission problems, it tends to be a
BIG outage.

2) Utilities, like any other business, are in business to make money.  To
make more money, you should own as few assets (lines, generators) as
possible, utilize it as heavily as possible (to maximize sales) and keep
other costs low (small staffs and extended maintenance intervals).  This is
counterbalanced by pressures from regulatory agencies and customers to
provide reliable service.  The opening up of the wholesale electricity
market in North America is putting greater pressure on electric utilities to
be profitable.  This tends to push the balance point towards the side of
unreliability.

A similar thing has happened in the long distance telephone market.  AT&T
originally lost customers over price, but is recovering customers on the
basis of convenience and reliability.  The electric power market appears to
be going through a phase similar to the early days of competitive long
distance telephone service.

3) Western Systems Coordinating Council (the coordination council for
Western US/Canada) regulations mandate that each utility must have 10% extra
generation or "Spinning Reserve" available in the event of a system
disturbance.  For example, if the utility is presently generating 1000 MW,
it must be able to bring an additional 100 MW on-line within a certain
period of time (1 - 3 minutes, I believe).  Power brokers have recently
started buying selling reserve, aggregating it into a pool and selling it
from the pool back to utilities.  For example, if utility A requires 100 MW
of spinning reserve, but the only generator they have that isn't already
generating is 200 MW, they can now either:

    - buy 100 MW of reserve from the pool and take their generator off
      standby (perhaps for maintenance).
    - leave their generator on standby and sell 100 MW of spinning reserve
      to the pool, allowing some other utility to take a 100 MW generator
      off standby.
    - buy 120 MW of reserve from the pool, put their generator on-line and
      sell 200 MW on the open market.

The net effect of this is a reduction of total spinning reserve due to the
better fit of each utilities individual resources into the larger spinning
reserve pool.  This gives the system a smaller buffer in the event of an
emergency and increases the chances of outages cascading.

Ralph Barone, Protection & Control Manager/HVDC Control Engineer
BC Hydro  Ralph.Barone@bchydro.bc.ca


Algol passwd changer? (Re: Bass, RISKS-18.39)

Marianne Mueller <mrm@Eng.Sun.COM>
Tue, 3 Sep 1996 10:20:04 -0700
The article in RISKS titled "Java passwd changer?" caught my attention, but
the surprising discovery was that this article has nothing to do with Java.
The author speculates about the risks of an automatic password changer, but
there isn't one being used today that is causing him to worry.  Of course,
such a system could be written and deployed in any language.  But it
couldn't be written and deployed as a Java applet, since the default Java
applet security policy prevents applets from reading or writing to the
client disk.

I'm not sure what the moral of the story is, but I do know that since the
RISKS list is archived all over the place, Java will now show up on search
engines with the title "Java passwd changer?" and no doubt people will start
writing "USA Today"-style articles about the danger of Java changing
passwords!

It may be that the biggest Internet security risk right now is that it's
getting harder and harder to find accurate information about
computer-related risks.

Marianne  JavaSoft engineering, security  http://java.sun.com/people/mrm


Risks of multiple HTTP standards

Pete Bentley <pete@mimir.com>
Tue, 03 Sep 1996 15:37:16 +0100
The Microsoft Network offers a free service allowing people to create their
own custom 'start' page at http://www.msn.com/ which may contain personal
information including the individual's address.  All of this information is
encoded into a 'cookie' which is stored by the user's own web browser and so
in theory cannot be seen by other people.  Or can it?

MSN uses Microsoft's own product, Microsoft Internet Information Server 1.0,
as its web server and it tries to send a response which will ensure that
http://www.msn.com/ is not cached by any proxy servers (to prevent people
seeing each others information by mistake), but is cached by the users web
browser for a short time (for speed). It does this by sending an HTTP/1.0
reply with Date and Expires headers which indicate that the information is
valid for half an hour and adds a "cache-control: private" header to prevent
any proxy servers from caching the information.  However, cache-control is a
header from the draft HTTP/1.1 specification which is not interpreted by
many HTTP/1.0 proxy servers in use today (verified by myself with the CERN
and Squid proxies) and so is ignored.  The remaining headers indicate to the
proxy that it may cache the page itself for half an hour.  If the proxy then
caches a page containing a user's personal information then any other user
accessing http://www.msn.com/ via that proxy in the next half hour will
receive that page (and personal information).  This scenario has indeed been
observed in practice with a busy web proxy run by a large ISP and a detailed
analysis has been sent to Microsoft for their attention.

The risk here seems to mostly be mixing HTTP standards and assuming that
HTTP/1.0 servers will understand some HTTP/1.1 headers. It raises issues for
both server coders and cache coders as the Net starts gradually migrating to
HTTP/1.1 at the same time as 'smart' web servers (generating pages on the
fly) want finer control over caching proxies.

Pete
  [Aside: whilst making HTTP requests by telnetting to www.msn.com:80
  (to compare headers), I noticed that www.msn.com either restarts
  (connection refused) or goes missing (routing loops between msn.net
  routers) quite frequently. ]


Re: Tunnel vision of Computer Society CD-ROM (Kuenning, RISKS-18.39)

Geoff Kuenning <geoff@ficus.cs.ucla.edu>
Fri, 30 Aug 1996 12:42:22 -0700
Only moments after the appearance of my complaint about the short-term
usability of the IEEE Computer Society CD-ROM, people started e-mailing me
to defend the decision to use SGML.  Rereading my posting, I realized that I
did not make myself clear.  I do not object to the choice of SGML as a
format; to the contrary (without having had the time to read an SGML spec) I
suspect that it was a very wise choice.

My problem is two-fold.  First, the software to view the articles on the
disc was provided in a very short-term format, and one that disenfranchises
a large fraction of the potential customers.  (To publicly answer a couple
of private suggestions, I do not think that I should have to go out and
browse the net to get this software, nor do I think that it would have been
any better to have included an emacs viewer as well as those already
present.)

The second problem, which I somehow omitted from my previous message, is
that the software to search the database is proprietary.  So even if I
download an SGML viewer from the net, I can only display articles, and can't
take advantage of the nifty search features that ought to be available to
everyone.

*No* solution is acceptable if it depends on external capabilities other
than the ability to read simple ASCII from the CD-ROM.  Bootstrapping by
compiling is OK, and it's OK to provide pre-bootstrapped software for common
platforms.  But I doubt that any of those platforms will be common 30 years
from now, so the Computer Society should have provided for this possibility.

(Incidentally, Software Practice and Experience made the same mistake a year
or two ago, except that they limited themselves to Windows 3.1.  I contacted
them at the time, and received a polite response that resulted in no
action.)

    Geoff Kuenning  g.kuenning@ieee.org geoff@ITcorp.com
    http://fmg-www.cs.ucla.edu/geoff/

  [RISKS received messages on this topic from
     jdzik@aol.com (JDzik),
     ajm@mcs.com (Alan Miller),
     Matthew Wojcik <woj@ccs.neu.edu>,
     tprodin@ford.com (Timothy R Prodin),
     "Theodore Y. Ts'o" <tytso@MIT.EDU>,
     Al Stangenberger <forags@nature.berkeley.edu>.  Al noted that
       "This is a widespread problem, though.  I try to convince users that
       using Excel spreadsheet format for long-term archival storage of data
       is not a very good idea."
  Geoff's message more or less summarizes much of the discussion, but the
  following messages from Ted Ts'o and Timothy Prodin seem worthy of
  inclusion, even if somewhat redundant, as representative of these
  responses.  PGN]


Re: Tunnel vision of Computer Society CD-ROM (Kuenning, RISKS-18.39)

"Theodore Y. Ts'o" <tytso@MIT.EDU>
Fri, 30 Aug 1996 16:01:44 -0400
Actually, storing its articles in SGML was the right choice for the IEEE to
have made.  The reason for this is that SGML is a platform independent
format --- SGML, or "Standard Generalized Markup Language" is an ISO
standard ISO 8879:1986.  While the CD-ROM may have only had viewers for
Macintosh, Windows 3.1, and a few Unix platforms, it's much more likely that
an article formatted in SGML will have viewers available on other platforms
than, (for example) if the articles were stored in Microsoft Word format.

A few more words about SGML.  What's really good about SGML is that it is
designed to deal with *structured* text.  You don't specify things like
"Times-Roman-Italics, 10 point"; instead you specify "book title", and leave
it to the SGML viewer to put the text of the book title in the appropriate
font.  This is important, because different platforms have different fonts
available to them; and 100 years from now, who knows what fonts will be
available by default.

An SGML document has a prologue where it declares its Document Type
Definition (DTD).  The Hypertext Markup Language (HTML), which is used by
the Web, is a DTD.  Other examples of SGML include the QWERTZ DTD, which
provides most of the facilities of LaTeX, and the LinuxDoc SGML, which is
derived from the QWERTZ DTD, and which is the standardized format for the
Linux Documentation Project (LDP).  The LDP has provided Linuxdoc-SGML
translators which will take the Linuxdoc-SGML and translate it into LaTeX,
groff, HTML, and texinfo.  (And of course, from all of these formats, you
can then get postscript or Adobe PDF).

So the mere fact that the IEEE CD-ROM is using SGML does not mean that they
have "stumbled badly".  What's really important is what DTD did they use to
format their articles, and is that DTD documented so that other people can
write their own SGML translators.  Of course, it would have been best if the
IEEE could have provided the source to the SGML translators, but there may
have been licensing issues barring them from doing so.

Could you use raw ASCII text instead of SGML?  Of course.  However, you
would lose all the nice formatting that you would get if you were reading
the article in printed form.  Things like diagrams and graphics would be
lost.  The advantage of using SGML is that all of this information is
preserved, and assuming that the definition of the DTD is public, it
shouldn't be difficult to write a SGML -> raw text translator.  It would no
doubt lose information during this transformation, but that's what you get
if you insist on viewing things using raw text.

Ted


Re: Tunnel vision of Computer Society CD-ROM (Kuenning, RISKS-18.39)

Timothy R Prodin <tprodin@ford.com>
Tue, 3 Sep 1996 10:31:22 -0400 (EDT)
In RISKS-18.39, Geoff Kuenning pointed out some problems with the IEEE
Computer Society publications on CD-ROM.  I would like to correct a mistake
and some perception problems that appeared in his article.

First, SGML is not a superset of HTML.  SGML is a meta-language that is used
to describe content models for documents.  Various flavors of HTML are
implementations of SGML; with the notable exception of Netscape 3.0.

The tool that IEEE provides for viewing the collection is EBT's DynaText;
but because a conforming SGML document instance is tool independent, you can
get many different viewers for many different platforms and not have to
worry about tool compatibility.  You can even construct your own
viewers/publishers/search engines, use DSSSL to provide online or paper
formats for the instance, and standard tools to perform transformations into
other DTDs, such as HTML 3.2.

 [...]

IEEE did not disenfranchise their members or customers.  An SGML instance is
not based on proprietary software; it is in fact based on the complete
opposite, a recognized international standard, ISO8879.  There exists many
tools in the public domain and commercial markets for viewing, manipulating
and transforming instances.

Second, the choice reflects lots of planning for technology of the 21st
century.  There exists a commitment from ISO to keep any modifications to
the standard backwards compatible with the current version.  Because the
standard is in the hands of an international body and not a corporation
(such as Netscape's HTML; or Microsoft's RTF) there is a guarantee that
changes to the standard will be made only with public comment, public
notification, and reference implementations.

It is precisely because IEEE cannot predict the future that they selected a
document format that will insulate them from various operating system
quirks, future changes, and emerging technologies.


Re: Exploding GPS (RISKS-18.39)

Matt Fichtenbaum <mattf@harpa.ultranet.com>
Fri, 30 Aug 1996 19:47:17 GMT
At my last employer we once had a lithium battery explode.  Maybe it's the
same phenomenon.

The battery in question preserved calibration data in a memory chip.  When
the instrument in question was powered, the memory was powered from the main
supply and a diode blocked current from flowing into the battery (lithium
batteries are not meant to be charged).  In this particular instrument, the
diode had been installed backwards, so when the instrument was on the
battery had energy fed _into_ it.  The resulting internal heating raised the
internal pressure until the battery case let go.

Or maybe, in the GPS instance, the GPS receiver thought it could get a better
assessment of its location if it was in lots of places at once.


Re: Karpov v. the Internet" game

Dick Mills <rj.mills@pti-us.com>
Sun, 1 Sep 1996 12:44:53 -0400
PGN wrote:
   >Better yet, one grand master with others kibitzing by e-mail.
   >If a grand master can play simultaneous matches, it should be
   >no difficulty winnowing the e-mail suggestions in real-time.

I didn't see the smiley after your note Peter, think again.  [RISKS
  TENDS TO SUPPRESS GRATUITOUS SMILEYS.  HOWEVER, ONE WAS EVIDENTLY
  IMPLIED FOR THIS ENTIRE DISCUSSION, which intended to convey that
  the whole thing was rather silly.  PGN]

Rather than an aid, this would be the ultimate sabotage for a grand master
trying to concentrate on his game, while playing against a time limit.  It
would be akin to having many people trying to shout in his ear.

The same reasoning leads us to forbid citizens from using hand-held radios
to kibitz the flying techniques of pilots while on final landing approach at
the airport.

Dick Mills +1(518)395-5154     http://www.pti-us.com
AKA dmills@albany.net          http://www.albany.net/~dmills


Re: Karpov v. the Internet" game

Pete Mellor <pm@csr.city.ac.uk>
Sat, 31 Aug 96 20:07:17 BST
PGN adds:-
> The result was clearly not a surprise.  Only about 300 hundred opponents?

Maybe that was the 300 people who did not realise that the exercise was
farce!

> Suppose the group was
> composed of only a few grand masters?  What would that do to the odds?

Improve them for Karpov! (Each grand master would propose a brilliant move
in each situation. These would generally be dissimilar, since each grand
master would have a different vision of how the game would look 10 moves on.
Their brilliance would therefore be cancelled out.)

> Better yet, one grand master with others kibitzing by e-mail.

*That* is the point. Karpov was not (as far as I know - correct me if
I'm wrong) playing the combined power of 300 brains.

Given 300 randomly selected players, most of whom would make weak or
indifferent moves, the "most frequent" response chosen "by computer" would
almost certainly be one of the weakest responses, and (as an earlier
correspondent pointed out) not consistent with any single well-thought out
plan of attack or defence. The group that Karpov was playing were *not*
consulting one another to agree on the best strategy.

What is the point of having computer voting that looks one move ahead
in opposition to a chess genius who thinks at least 7 moves ahead?

It would be interesting to see an analysis of the resulting game.
I bet it was more crapov than Karpov!

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, p.mellor@csr.city.ac.uk


19th Information Systems Security Conference

Jack Holleran <Holleran@DOCKMASTER.NCSC.MIL>
Sun, 1 Sep 96 08:28 EDT
ANNOUNCEMENT
  19th National Information Systems Security Conference
  Baltimore Convention Center
  October 21-25, 1996

The full announcement [see below] is now available on-line and has
 1. The final program  (complete, long, & detailed)
 2. Workshop and Demonstration information
 3. Registration Form
 4. Housing Form (Conference Hotel with pricing information)

Registration Information:
  Tammie Grice, Conference Registrar
  Voice:  (301) 975 - 3883
  FAX:  (301) 948 - 2067
  EMAIL:  nissconference@dockmaster.ncsc.mil
  WWW:  http://csrc.nist.gov/nissc/

Cost:  $295, with early registration through September 19, 1996;
       $335 after September 19, 1996


Information Security Conference - Cleveland

Robert Terry <utility@primenet.com>
2 Sep 1996 05:03:12 -0700
Second Annual NASA Lewis Research Center conference - "Perils of the
Internet and Practical Solutions - Confronting Threats from Hackers,
Crackers, and Sniffers." 24-26 Sep 1996, Cleveland, OHIO.

For more Information: http://www.dis.org/se7en/ndi

Please report problems with the web pages to the maintainer

x
Top