Text File

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 ************************ -------