RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (02/17/89)
RISKS-LIST: RISKS-FORUM Digest Thursday 16 February 1989 Volume 8 : Issue 27
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
FBI NCIC Data Bank (Bob Morris)
Internet mail forgery (Walter Roberson)
Re: Dead code maintenance (Clifford Johnson)
Probabilities and Engines (Steve Philipson, Robert Dorsett, Daniel A. Graifer)
[OK, guys, enough on this topic for a while!!!]
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
* RISKS MOVES SOON TO csl.sri.com. FTPable ARCHIVES WILL REMAIN ON KL.sri.com.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
FOR VOL i ISSUE j / ftp KL.sri.com / login anonymous (ANY NONNULL PASSWORD) /
get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
Volume summaries in (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99).
----------------------------------------------------------------------
Date: Thu, 16 Feb 89 09:41 EST
From: RMorris@DOCKMASTER.ARPA
Subject: FBI NCIC Data Bank
Proposed FBI Crime Computer System Raises Questions on Accuracy, Privacy --
Report Warns of Potential Risk Data Bank Poses to Civil Liberties
Washington Post, February 13, 1989
by Evelyn Richards
On a Saturday afternoon just before Christmas last year, U.S. Customs
officials at Los Angeles International Airport scored a "hit."
Running the typical computer checks of passengers debarking a Trans World
Airlines flight from London, they discovered Richard Lawrence Sklar, a fugitive
wanted for his part in an Arizona real estate scam.
As their guidelines require, Customs confirmed all the particulars about
Sklar with officials in Arizona - his birth date, height, weight, eye and hair
color matched those of the wanted man.
Sklar's capture exemplified perfectly the power of computerized crime
fighting. Authorities thousands of miles away from a crime scene can almost
instantly identify and nab a wanted person.
There was only one problem with the Sklar case: He was the wrong man. The
58-year old passenger - who spent the next two days being strip-searched,
herded from one holding pen to another and handcuffed to gang members and other
violent offenders - was a political science professor at the University of
California at Los Angeles.
After being fingered three times in the past dozen years for the financial
trickeries of an impostor, Sklar is demanding that the FBI, whose computer
scored the latest hit, set its electronic records straight. "Until this person
is caught, I am likely to be victimized by another warrant," Sklar said.
Nowhere are the benefits and drawbacks of computerization more apparent than
at the FBI, which is concluding a six-year study on how to improve its National
Crime Information Center, a vast computer network that already links 64,000 law
enforcement agencies with data banks of 19 million crime-related records.
Although top FBI officials have not signed off on the proposal, the current
version would let authorities transmit more detailed information and draw on a
vastly expanded array of criminal records. It would enable, for example,
storage and electronic transmission of fingerprints, photos, tattoos and other
physical attributes that might prevent a mistaken arrest. Though
controversial, FBI officials have recommended that it include a data bank
containing names of suspects who have not been charged with a crime.
The proposed system, however, already has enraged computer scientists and
privacy experts who warn in a report to be released today that the system would
pose a "potentially serious risk to privacy and civil liberties." The report,
prepared for the House subcommittee on civil and constitutional rights, also
contends that the proposed $40 million overhaul would not correct accuracy
problems or assure that records are secure.
Mostly because of such criticism, the FBI's revamped proposal for a new
system, known as the NCIC 2000 plan, is a skeleton of the capabilities first
suggested by law enforcement officials. Many of their ideas have been pared
back, either for reasons of practicality or privacy.
"Technical possibility should not be the same thing as permissible policy,"
said Marc Rotenberg, an editor of the report and Washington liaison for
Computer Professionals for Social Responsibility, a California organization.
The need to make that tradeoff - to weigh the benefits of technological
advances against the less obvious drawbacks - is becoming more apparent as
nationwide computer links become the blood vessels of a high-tech society.
Keeping technology under control requires users to double-check the accuracy
of the stored data and sometimes resort told-fashioned paper records or
face-to-face contact for confirmation. Errors have plagued the NCIC for many
years, but an extensive effort to improve record-keeping has significantly
reduced the problem, the FBI said.
Tapped by federal, state and local agencies, the existing FBI system juggles
about 10 inquiries a second from people seeking records on wanted persons,
stolen vehicles and property, and criminal histories, among other things.
Using the current system, for example, a police officer making a traffic stop
can fine out within seconds whether the individual is wanted anywhere else in
the United States, or an investigator culling through a list of suspects can
peruse past records.
At one point, the FBI computer of the future was envisioned as having links
to a raft of other data bases, including credit records and those kept by the
Immigration and Naturalization Service, the Internal Revenue Service, the
Social Security Administration and the Securities and Exchange Commission.
One by one, review panels have scaled back that plan."
"There's a lot of sensitive information in those data bases," said Lt.
Stanley Michaleski, head of records for the Montgomery County [Maryland]
police. "I'm not going to tell you that cops aren't going to misuse the
information."
The most controversial portion of the planned system would be a major
expansion to include information on criminal suspects - whose guilt has not yet
been established.
The proposed system would include names of persons under investigation in
murder, kidnapping or narcotics cases. It would include a so-called "silent
hit" feature: An officer in Texas, for instance, would not know that the
individual he stopped for speeding was a suspect for murder in Virginia. But
when the Virginia investigators flipped on their computer the next morning, it
would notify them of the Texas stop. To Michaleski, the proposal sounded like
"a great idea. Information is the name of the game."
But the "tracking" ability has angered critics.
"That [data base] could be enlarged into all sorts of threats - suspected
communists, suspected associates of homosexuals. There is no end once you
start," said Rep. Don Edwards (D-Calif.), whose subcommittee called for the
report on the FBI's system.
The FBI's chief of technical services, William Bayse, defends the proposed
files, saying they would help catch criminals while containing only carefully
screened names. "The rationale is these guys are subjects of investigations,
and they met a certain guideline," he said.
So controversial is the suspect file that FBI Director William Sessions
reportedly may not include it when he publicly presents his plan for a new
system.
[A case similar to Sklar's was reported previously in RISKS -- that of
Terry Dean Rogan, who was arrested five times because of outstanding
warrants caused by someone else masquerading as him. He finally settled
for $50,000 in damages. PGN]
------------------------------
Date: Wed, 15 Feb 89 22:14:45 EST
From: Walter_Roberson@CARLETON.CA
Subject: Internet mail forgery
A few days ago, someone forged a message to rec.music.misc. The "From:" address
corresponded to that of a gateway for the Apollo mailing list. A couple of
people, not recognizing that the fake name corresponded to a mailing list, sent
their replies in `privately' instead of to rec.music.misc, with the result that
their replies were broadcast whereever the Apollo list and comp.sys.apollo
reaches. They were, it seems, subsequently `flamed' for their unintential
mis-mailing.
A subsequent note from someone, exposing the message as a forgery, states
> With SMTP and/or NNTP, the forgery could come from anywhere, not
> necessarily berkeley or ucsf.
Perhaps someone else can comment on this: can we trust -any- of our
(non-encrypted) network mail to be from the claimed author? How about the
other way around: how much danger is there that someone can spoof mail in
order to receive messages destined for someone else?
Walter Roberson <Walter_Roberson@Carleton.CA> (if you can believe that...)
References: <11366@cgl.ucsf.EDU> (the forged message)
<8039@netnews.upenn.edu> (the exposure, written by
george%hyper.lap.upenn.edu%netnews.upenn.edu%eecae%mailrus.uucp@
ames.arc.nasa.gov (George "Sir Lleb" Zipperlen) )
[The simple answer is "no". Furthermore, encrypting the networks does not
help very much if the operating systems are vulnerable to attack.
Previous spoofs include "Chernenko at Moskvax" (see ACM SIGSOFT Software
Engineering Notes 9 4, July 1984, and last year's "Spafford" hoax. PGN]
------------------------------
Date: Wed, 15 Feb 89 18:04:41 PST
From: "Clifford Johnson" <GA.CJJ@Forsythe.Stanford.EDU>
Subject: Re: Dead code maintenance
My useless code maintenance story concerns a job I applied for once, as a
contracted programmer, specifically to maintain one Cobol program. It was
billed as a 20-hour per week job, and it's maintenance had kept a Stanford
Ph.D. programmer/statistician busy for that amount of time, for some months.
(None of this relates to work done at or for Stanford.)
The job was to run the program against fresh data a couple of times a week, and
keep the record formats (which rarely changed) up to date. As soon as I
reviewed the program, having taken the well-paid job, I discovered that all it
did was read-in a file a record at a time, and rewrite some fields from each
each record it read-in, without any data change or sorting whatsoever. The
second set of records was then read by a statistical program -- which could
have read-in the original records directly, simply ignoring the un-needed
fields! I contemplated how easy the job was, but recommended scrapping the
Cobol program, which not even said Ph.D. had realized was utterly purposeless.
This was done - and so I put myself out of work.
I wonder how many programmers do similarly unproductive work because their
managers don't realize what is and isn't really being accomplished? Sometimes
immediate management knows the score, but instructs one to take more time than
needed to make a change. In one employment I was told to take at least two
weeks to change the title line in a report, to impress upon senior management
how tricky it was and how overloaded we all were.
------------------------------
Date: Wed, 15 Feb 89 17:50:26 PST
From: Steve Philipson <steve@aurora.arc.nasa.gov>
Subject: Probabilities and Engines
In RISKS 8.26 blinn%dr.DEC@decwrl.dec.com, Dr. Thomas P. Blinn writes:
>In RISKS-FORUM Digest Volume 8 : Issue 24, it is asserted by Barry Redmond that
>>If someone makes a mistake on one engine at any of these times, there is a
>>high probability that they will make the same mistake on the other engine(s).
>That may be true, but it may not be true, because the same person may not
>be working on all the engines. I would agree that an incompetent mechanic
>working on all the engines is likely to make the same mistakes on all of
>them, but the reality of aircraft engine repair is different.
There are several well known cases where all engines on a multi-engine
aircraft failed (or were in the process of failing) due to the same
maintenance error. Sometimes it's the result of a single person's work,
and in other cases it's the result of systematic error by a group. The
reality is that such errors and failures do occur.
>The probabilities of failure are not independent because if one engine fails it
>immediately increases the probability of another failing.
>>This is a very interesting assertion. It seems to be saying that there is a
>>causal relationship between a first engine failure and the likelihood of a
>>second. ... , but this doesn't mean that the probability of failure of the
>>other engines has changed in any way. ...
There is such a causal reationship. When one engine fails, the remaining
engine(s) may have to be operated at increased power levels and shoulder
additional tasks. This raises the stress on them, and gives us an a priori
knowledge of increased probabilty of failure.
It may be necessary to have a thorough grounding in probability theory
and statistics, but it is also necessary to have knowledge of the specifics
of real world operations. Either without the other sets us up to allow
problems to escape detection and analysis.
------------------------------
Date: Thu, 16 Feb 89 14:56:20 CST
From: mentat@louie.cc.utexas.edu (Robert Dorsett)
Subject: Probabilities and Engines
NOTE: a longer version of this tirade will soon appear on USENET's
rec.aviation... I'll mail a copy to anyone without usenet access.
Jordan Brown wrote:
>727 engines (3/airplane) are wimpy compared to DC-9 engines (2/airplane).
>BAe-146 engines (4/airplane) are *really* wimpy. (This assumes that
>727s are approximately the same size as DC-9s. Bae-146's are smaller.)
The 727 and DC-9 engines are the same, derivatives based on the Pratt &
Whitney JT8D. What is significant, in the context of this discussion, is
how the engine thrust relates to the airplane weight. Here are a few
thrust-to-weight ratios, assuming various weights and engine-remaining
situations:
727-200,000 lbs (max) 727-200, 140,000 lbs DC-9-30,140,000 lbs (max)
3 4:1 3:1
2 6:1 5:1 4:1
1 13:1 9:1 9:1
One can change the performance of an airplane by losing weight; to lose
weight, fuel is dumped. The 727 can lose some 60,000 lbs of fuel.
The one-engine case with no fuel is a performance increase of some 30%
over the same thrust at max.weight.
To give an example of the significance of all this, recently a fully-loaded
Continental 747, enroute to New York, attempted to take off from Gatwick,
heading north. It had an engine fire and shutdown at takeoff. The pilot was
just barely able to hold altitude after takeoff (with three engines), at 200-
300 feet, with the stick shaker and stall warnings active. The airplane went
behind some trees; the controller called a crash after losing radar and visual
contact. The plane dumped a massive amount of fuel, managed to gain altitude
(after several minutes), and returned to the field.
The moral here, again, is that from the mundane perspective of keeping
the airplane in the air, it's not how many engines you have, but how
much you weigh. What is far more important for trans-oceanic operations
is how likely it is to lose some or all of your engines, and how likely it
would be to get to an airfield once you do. Considering the frequency
with which total (or near-total) freakish engine failures have occurred the
last few years (even though the engines themselves are more reliable
than in the past), this isn't really as trivial or as "safe" as the numbers
might have us believe.
>Airplanes are required to be
>able to maintain such-and-such a level of performance with one engine out.
The most important situation normally considered being takeoff. I doubt
a 727 could take off with two engines out; it wouldn't have the time necessary
to dump, or the thrust necessary to maintain airspeed. As the above 747
example shows, even the worst-case performance figures can be misleading.
At the end of the flight, that same 747 would be able to perform with only
one engine operating (as a recent United Airlines emergency landing
on a flight to Tokyo showed).
>I don't believe a 727 can fly on one engine. It must have two.
It can fly on one engine. And even if it couldn't fly on one engine, as
another poster pointed out, having *any* thrust means the difference between
a steep glide and a long glide. According to the 727 patterns manual, a one-
engine ILS approach is made by assuming a decision height of some 600 feet,
with an airspeed in the 160-170 kt range. Best climb speed, for the go-
around, is 200 kts (190 knots with two degrees of flaps). There's an
implicit assumption in the training manual that between 600 feet and ground
level, they will be able to accelerate--and hold--200 kts.
>A three-engine airplane has a higher probability of having a failure in
>the first place, and when it does have a failure it then has two points
>of failure, EITHER of which will cause an accident.
The 727 has three engines because, more than any other factor, Boeing
perceived a need to trade off airline requirements at the time the plane was
constructed. United Airlines wanted a four-engine airplane, Eastern wanted
two. So they compromised, and agreed on three. I suspect a similar history
with the Tristar and DC-10: four is too many, two is too few. Three is nice
and "safe."
>Going from one engine to two adds redundancy. Going from two to three,
>with two required, REDUCES redundancy.
Perhaps we should look up the meaning of "redundancy." Three engines provide
three thrust sources, three generators, three pneumatics sources, and (on the
727) two hydraulic sources. I can't imagine how that is "bad," since (apart
from fuel starvation, mismanagement, and particle ingestion) they really don't
have a common failure mode. There are more parts to fail, but the issue here
is whether more engines will make it more likely for everything to go wrong in
a catastrophic manner, which years of experience has shown to be fallacious.
Robert Dorsett
------------------------------
Date: Thu, 16 Feb 89 16:52:04 -0500
From: dag@fciva.UUCP
Subject: Re: Aircraft failures (RISKS DIGEST 8.26)
First, there seems to be some disagreement on the subject. Does anyone have
any information on the capability of currently popular 3-engine commercial
aircraft (DC10, L1011, B727) to maintain level flight with only one functioning
engine?
Second, to expand upon the comments of Dr. Blinn, my recollection of statistics
is as follows:
Each engine has its own (unknown) probability of failure during any time
interval. This probability is a function of many known and unknown factors
(history, current aircraft state, fuel, maintainence, etc.). Initially, we
have an ESTIMATE of this probability which is the same for all engines: some
sort of historical average or other statistic. The failure of one engine on an
aircraft gives additional information regarding those factors which are common,
and thus allows us to revise our estimate of the probabilities of another
failure on the same aircraft in the near future.
Normally, a statistician would say that the probability of failure hasn't
changed, just our estimate. There is an exception to this statement. It is
possible that the failure of the first engine is itself a factor in the failure
of the second, for example, by increaseing the load that engine is run under,
or stress on the aircraft from unequal thrust.
I think the most misunderstood aspect of statistics is that probability
distributions for real world phenomena are rarely known, only estimated. The
march of time gives us new information to refine our estimates.
Dan Graifer
The usual disclaimers....
Daniel A. Graifer, Franklin Capital Investments,
7900 Westpark Drive, Suite A130, McLean, VA 22102 (703)821-3244
------------------------------
End of RISKS-FORUM Digest 8.27
************************
-------