The RISKS Digest
Volume 5 Issue 21

Saturday, 1st August 1987

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

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
Info on RISKS (comp.risks)

Macaquepit Monkey Business on 747

Peter G. Neumann <Neumann@csl.sri.com>
Fri 31 Jul 87 13:01:04-PDT
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]


Re: IRS Sanity Checks (RISKS-5.20)

<willis@rand-unix.ARPA>
Fri, 31 Jul 87 10:30:34 PDT
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


IRS Income

<Beckman@DOCKMASTER.ARPA>
Fri, 31 Jul 87 08:58 EDT
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]


Re: Telephone access cards (RISKS-5.20)

<willis@rand-unix.ARPA>
Fri, 31 Jul 87 10:30:34 PDT
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


Another comment on passwords (Re: RISKS DIGEST 5.19)

Robert Hartman <sun!rdh@seismo.CSS.GOV>
31 Jul 87 07:14:30 GMT
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]


Re: Origin of term "artificial intelligence"

Dave Benson <benson%cs1.wsu.edu@RELAY.CS.NET>
Thu, 30 Jul 87 14:36:22 PDT
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 

FDA opportunity for system safety person

Frank Houston <houston@nrl-csr.arpa>
Fri, 31 Jul 87 11:18:05 edt
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

Please report problems with the web pages to the maintainer

x
Top