1-Aug-87 20:11:47-PDT,15165;000000000000
Return-Path: <NEUMANN@f4.csl.sri.com>
Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Sat 1 Aug 87 20:09:00-PDT
Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16)
id AA00784 for RISKS-LIST@f4.csl.sri.com; Sat, 1 Aug 87 20:11:21 PDT
Message-Id: <8708020311.AA00784@csl.csl.sri.com>
Date: Sat 1 Aug 87 20:08:23-PDT
From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com>
Subject: RISKS DIGEST 5.21
Sender: NEUMANN@csl.sri.com
To: RISKS-LIST@csl.sri.com
RISKS-LIST: RISKS-FORUM Digest Saturday, 1 August 1987 Volume 5 : Issue 21
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
============================================================================
= TODAY IS THE SECOND ANNIVERSARY OF RISKS (and the beginning of our third =
= year, if you prefer to count from ONE instead of ZERO). Thanks to all. =
= (I am astonished that there were 181 issues in our second year! Maybe =
= it is time to take pity on you all [and me] and slow down a little!) PGN =
============================================================================
Contents:
Macaquepit Monkey Business on 747 (PGN)
Re: IRS Sanity Checks (Willis Ware, Joseph Beckman)
Re: Telephone access cards (Willis Ware, Robert Hartman)
Re: Origin of term "artificial intelligence" (Dave Benson)
FDA opportunity for system safety person (Frank Houston)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
FTP back issues Vol i Issue j from F4.CSL.SRI.COM:<RISKS>RISKS-i.j.
Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).
----------------------------------------------------------------------
Date: Fri 31 Jul 87 13:01:04-PDT
From: Peter G. Neumann <Neumann@csl.sri.com>
Subject: Macaquepit Monkey Business on 747
To: RISKS@csl.sri.com
A monkey slipped out of its cage aboard a China Airlines cargo plane [before
landing] at Kennedy Airport, forced the crew from the cockpit, and played
with the controls before it was nabbed. ``He wasn't making any demands --
he wasn't trying to take the plane back home,'' said John Schneider, an
animal control officer from the Port Authority who netted the 15-pound
macaque monkey after a 90-minute game of hide-and-seek through the 747 jet.
(The monkey had crawled out of the cargo area and into the flight deck.)
[UPI, in SF Chronicle, 31 July 1987]
------------------------------
To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com>
Subject: Re: IRS Sanity Checks (RISKS-5.20)
Date: Fri, 31 Jul 87 10:30:34 PDT
From: willis@rand-unix.ARPA
Re the IRS ADP procedures. Several years ago I participated with a
committee that reviewed the IRS long range planning for ADP upgrades. So
the group got to know something about general procedures, although not
intimate software details.
In these comments, I'm only offering perspective. I am neither defending
nor criticizing what the IRS or other record-keeping organizations do.
The IRS obviously runs an enormous financial operation. The accounts
receivable is huge so that there is a high motivation to get tax payments
processed and into the bank. Similarly the IRS is obligated under law to
pay interest on delayed rebates, so there is a corresponding motivation to
process tax returns rapidly. Both motivations are really in the citizen's
best interest.
The first thing that happens to any personal tax return (at the regional
processing center -- Fresno for California and the western states) is data
entry directly from the submitted form and as written. The data entry
clerks have no authority to change anything. The system then runs out the
numbers according to the rules that go along with the tax forms and tax
law. All the system does is check arithmetic, and probably verify the
presence of required parameters (e.g., SSNs).
If it finds any variance, the computer generates an appropriate letter
which is then mailed, sofar as I know without human review. A lot of
people have been the subject of a completely automated action -- including
a computer generated letter -- from detection of a problem to mailing of a
letter.
At some point (I don't recall exactly when), all tax records are mag-taped
to West Virginia to the IRS national processing center where they get
additional checking, verification, examination, extraction of statistical
data, etc. It's from this 2nd stage process that returns are selected for
audit, and that produces the statistical parameters which go into the
famous "computer evaluation" for audit selection.
The IRS motivation is to collect taxes accurately, according to law, and
in timely fashion. While I don't know this from first hand evidence, I
can imagine that there is little management motivation to include
reasonableness checks on the taxpayer-submitted numbers and forms. Among
other things, it could be a legal misstep to guess what the taxpayer
intended to write, as opposed to what was actually written; and one can
readily conceive circumstances under which the IRS -- or many other
recordkeeping organizations -- could get into hot water by second guessing
what a person intended to do on some form or in some transaction.
So, we're not likely to see many computer-based reasonableness checks in
record-keeping systems, especially finanical ones. The error-correction
feedback loop will continue to be external and through the individual
concerned, as it has been for a long time with paper-based systems. Such
a decision is partly legally based, partly because there is generally
little basis for guessing what was intended, and partly because the
operational costs will always act to minimize the amount of software that
must execute to process each transaction.
While any computer-wise person can imagine all sorts of checks to improve
the lot of individuals who have to deal with a records system, I'm afraid
that managers of record-keeping activities are just not going to be
motivated to implement subscriber-courteous safeguards.
PGN - your parenthetical comment about "There is no Sanity Clause" goes
for many record-keeping organizations, not just Federal institutions.
Willis H. Ware, Santa Monica, CA
----------------------------
Date: Fri, 31 Jul 87 08:58 EDT
From: Beckman@DOCKMASTER.ARPA
Subject: IRS Income
To: Risks@csl.sri.com
I am under the impression that the IRS is not supposed to release
information they receive to other agencies. Hence, if someone says that
there are receiving $104001 from SS, the IRS is apt to accept that,
believing, perhaps, that these people are fraudently obtaining multiple
checks to which they are not legally entitled, but report such income so as
not to be in violation of the law under income-tax evasion sections. I am
reminded of the story of the pest exterminator who put "Hired killer" under
the occupation block.
Joseph
[The point of the message was that a reasonableness check on the SS
field would certainly indicate that this return might deserve special
attention -- without having to consult the SSA. PGN]
------------------------------
To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com>
Subject: Re: Telephone access cards (RISKS-5.20)
Date: Fri, 31 Jul 87 10:30:34 PDT
From: willis@rand-unix.ARPA
Re telephone cards, SPRINT, et al. Originally the GTE/SPRINT access code
for making calls was just 7-digits for local calls, plus 2 additional
ones when out of area. After getting the SPRINT switch via the local
access number, the procedure was to dial the access code and then the
desired number. The same thing was continued when it became US/SPRINT.
Penetrators of the SPRINT system have long been a problem, and all sorts of
ways have been suggested for acquiring the access code. Among them was just
plain automated PC-based exhaustive trials searching for a good one. At one
time, my SPRINT business account got over 300 unauthorized calls in one month,
ALL from Joliet, Illinois -- the location of a well-known prison. Given
that I had always been extremely cautious about using the memorized number
at a public phone, I never did find out how it got so popular in Illinois.
Recently, as noted in RISKS, the access code has become 14-digits but
there has also been a procedural change. After getting the SPRINT switch
through the local access number, now the desired number is dialed first;
after a couple of beeps from the switch, the access code is then dialed.
It's a slight nuisance sometimes if one is using a phone that has the
buttons in the handset; he better get the receiver back to his ear fast or
the acknowledging beep-beep from the switch can be unheard.
One wonders why the inversion of parameters; here is a possible explanation
based solely on my conjecture, not on any first hand knowledge.
Given that penetrators will continue to be a problem, one would like to have
some data to help track them down or to have system characteristics that
will deter them. Clearly the 14-digit number makes guessing much more
tedious and possibly slow enough to turn away trouble makers. In addition,
if someone is trying to guess numbers, perhaps already knowing part of a
legitimate one, the system now knows what number is being sought when the bad
access code is given. As telephone companies have done for years, the called
party can then be contacted and asked who might be trying to make a call.
But the technique is at the same time so easily spoofed by calling any
number, or some public number (like an office building), or always calling
a different number each time while guessing at access codes. It's a minor
software extension to make the penetrator's PC generate a number to be
called in addition to generating a trial access code. Of course the
generated called number might not be a valid one which could mean that a
guessed access code would erroneously be discarded, but one can imagine
ways around such a small problem.
Perhaps there is no security connotation to the new SPRINT procedure;
perhaps it really stems from some software convenience, or some billing
requirement. Perhaps, also, the system designers bet on a security
safeguard that has little to offer. Perhaps the state-of-art for (what is
really) computer security in the telephone business is not as well advanced
as it is in mainframe world.
Willis H. Ware, Santa Monica, CA
------------------------------
To: seismo!comp-risks@seismo.CSS.GOV
From: sun!rdh@seismo.CSS.GOV (Robert Hartman)
Subject: Another comment on passwords (Re: RISKS DIGEST 5.19)
Date: 31 Jul 87 07:14:30 GMT
Organization: Sun Microsystems, Mountain View
In response to Jonathan Thornburg's peeve/idea/complaint, it should be obvious
that any string of digits that can be attributed to an individual by a few
simple database lookups isn't a good candidate for a secure password. Your
random hacker might miss, but your diligent government could get right in.
Perhaps not the most reassuring thought. -bob.
[Like the "Yes, Virginia, there is a Santa Claus" letter that reappears
once a year in the European edition of the Herald Tribune, this
discussion keeps recurring in RISKS. I try to staunch it, but it seems
to take on a life of its own. PASSWORDS ARE INTRINSICALLY WEAK. THERE ARE
TOO MANY WAYS TO FIND COMPROMISES. Passwords might be considered better
than nothing, but only if people don't believe in them blindly -- in which
case NOTHING might be even better, relying primarily on establishing
communities of equal trustworthiness. At any rate, I have closed the
spigot on several other messages on this subject that get into second-
and third-order ramifications without confronting the deeper issues.
[While on the subject of spigots, we also received a flood of messages on
nuclear power. They have been getting farther and farther from RISKS
relevance, and thus are not included here. Jef Poskanzer
[unisoft!jef@ucbvax.Berkeley.Edu ...ucbvax!unisoft!jef] suggests that the
sci.misc USENET newsgroup is a more appropriate place for the not
immediately RISKS related contributions. PGN]
------------------------------
Date: Thu, 30 Jul 87 14:36:22 PDT
From: Dave Benson <benson%cs1.wsu.edu@RELAY.CS.NET>
To: risks%csl.sri.com@RELAY.CS.NET
Subject: Re: Origin of term "artificial intelligence"
Jon Jacky (>>):
>>... the term
>>"artificial intelligence" was originated in the 1950's by John McCarthy,
>>generally regarded as one of the most important computer scientists (he
>>invented LISP, among other things). The story goes that he created the term
>>in a grant application in order to kindle funders' interest in topics like
>>symbolic logic with otherwise seemed rather esoteric and impractical.
That's not the way John McCarthy tells the story. He indeed wanted to
create <intelligent machines>.
The term "machine intelligence" was in use for a while at the University
of Edinburgh, which at one time had both a department of Machine Intelligence
and a department of Artificial Inlligence.
The earliest popularization I can recall was entitled "Giant Brains, or
Machines That Think", written by One Of Us. (Edmund C. Berkeley, if I recall
correctly).
Unthoughtful scientists and engineers have often in the last 70 years been
carried away in explaining the delights of their subject to others. This
is a risk in any enterprise and we needn't be surprised at its occurrence
in fields of computing. Like any other risk, we indeed ought to avoid
overly extravagant claims.
David B. Benson
[Always look a gift expert system in the mouth. PGN]
------------------------------
Date: Fri, 31 Jul 87 11:18:05 edt
From: houston@nrl-csr.arpa (Frank Houston)
To: RISKS@csl.sri.com
Subject: FDA opportunity for system safety person
FDA is seeking a person versed in system safety, especially computer system
safety, to help advance the state of the art in medical systems. The job
will involve both research and routine and requires a fair amount of
experience in software. FDA would be willing to help train in the medical
part.
Anyone interested should contact me at (301)443-5020 or mail a resume soon to
my attention at Food and Drug Administration, Center for Devices and
Radiological Health HFZ-142, 12720 Twinbrook Parkway, Rockville, MD 20857.
Frank Houston, Biomedical Engineer, Food and Drug Administration
------------------------------
End of RISKS-FORUM Digest
************************
-------