home *** CD-ROM | disk | FTP | other *** search
/ Black Box 4 / BlackBox.cdr / textinfo / risks8b.arj / RISKS826.TXT < prev    next >
Encoding:
Text File  |  1989-02-18  |  17.7 KB  |  363 lines

  1. RISKS-LIST: RISKS-FORUM Digest  Wednesday 15 February 1989   Volume 8 : Issue 26
  2.  
  3.         FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
  4.    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
  5.  
  6. Contents:
  7.   "$15 Million Computer Dud Baffles Udall" (Joseph M. Beckman)
  8.   Re: Computer blamed for 911 system crash (Rodney Hoffman, Paul Blumstein)
  9.   Selling who-called-the-800-number data (Bob Ayers)
  10.   PIN?  Who needs a PIN? (Alan Wexelblat)
  11.   Door Sensors and Kids (Eddie Caplan)
  12.   Risks of misunderstanding probability and statistics (Tom Blinn)
  13.   Why you can't "flip" bits on a WORM disc (Daniel Ford)
  14.   Credit Checker & Nationwide SS# Locate (David Andrew Segal)
  15.   Re: Authenticity in digital media (Pete Schilling)
  16.   Re: multi-gigabuck information "theft" (Jeff Makey)
  17.  
  18. ----------------------------------------------------------------------
  19.  
  20. Date:  Wed, 15 Feb 89 16:45 EST
  21. From: "Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA>
  22. Subject: "$15 Million Computer Dud Baffles Udall"
  23.  
  24. Summarized from the Washington Times (2-15-89):  The US Office of Surface
  25. Mining has spent some $15 million on a computer system to prevent strip mine
  26. law violators from obtaining new permits.  The GAO is calling it a failure.
  27. The system apparently has a high error rate because it uses lists of names and
  28. addresses that are not complete.  Arizonia democrat "Mo" Udall was quoted as
  29. saying "I'm really baffled.  We have computer systems in this country to keep
  30. track of everything from missiles to kindergarten kids who are sick or absent.
  31. But the Interior Department can't develop a system, even with the help of %15
  32. million, to keep violators out of the coalfields."
  33.  
  34. By using the phrase "missiles to kindergarten kids" he seems to imply that
  35. systems are handling things as complex as missiles to as simple as...  Of
  36. course, the fact that the subjects of the systems may be very complicated says
  37. nothing about what the system is actually doing.
  38.                                                         Joseph
  39. ------------------------------
  40.  
  41. Date: 15 Feb 89 09:38:31 PST (Wednesday)
  42. From: Rodney Hoffman <Hoffman.ElSegundo@Xerox.com>
  43. Subject: Re: Computer blamed for 911 system crash -- more (RISKS-8.24)
  44.  
  45. On Saturday, 11 Feb 89, the Los Angeles city emergency 911 telephone system
  46. crashed twice.  The initial story, summarized in RISKS 8.24, blamed "a
  47. power failure in the computer's signalling mechanism."  The `Los Angeles
  48. Times' (14 Feb 89) carried a follow-up story by Frederick M. Muir and Paul
  49. Feldman, with the following new information.
  50.  
  51. The crash was caused by one power converter board, an SL/1 positron switch,
  52. that helps control power fed to a complex switching system.  It failed for
  53. still unknown reasons.  It's an off-the-shelf part that involves a low
  54. degree of technology and sells for $1000, according to Pacific Bell service
  55. manager Mike Fink.  The switch recieves incoming 911 calls and routes them
  56. virtually instantaneously to the first open phone line.
  57.  
  58. "Fink said the board that failed is usually so reliable and simple that no
  59. backup was designed into the system.  It is virtually the only part of the
  60. system -- which cost $1.6 million to install -- without a backup."
  61.  
  62. Asked for past failure statistics, Pacific Bell and General Telephone,
  63. which between them operate hundreds of 911 systems across California,
  64. reported only two other failures in the past two years, neither of which
  65. was linked to the part which failed Saturday.
  66.  
  67.  
  68. ------------------------------
  69.  
  70. Date: Wed, 15 Feb 89 09:29:23 PST
  71. From: Paul Blumstein (paulb@ttidca.tti.com)
  72. Subject: Computer blamed for 911 system crash -- more (Re: RISKS-8.24)
  73.  
  74. ... The Los Angeles 911 system has had continual overload problems since its
  75. inception because it was expected that only 30-40% of emergency callers
  76. would use the system.  The actual number turned out to be 75%.  In
  77. addition, the system has received a large amount of non-emergency calls.
  78.  
  79. The overload has caused a several-minute delay during peak periods before a
  80. 911 operator could be reached.
  81.  
  82. Paul Blumstein, Citicorp/TTI, Santa Monica, CA
  83. {philabs,csun,psivax}!ttidca!paulb  or  paulb@ttidca.TTI.COM
  84.  
  85. ------------------------------
  86.  
  87. Date: Mon, 13 Feb 89 12:59:53 PST
  88. From: ayers@src.dec.com (Bob Ayers)
  89. Subject: Selling who-called-the-800-number data
  90.  
  91. Those that liked the idea of states selling driver info will really love
  92. this one.  As reported in the 20 February Forbes magazine, a new company,
  93. Strategic Information Inc ...
  94.  
  95.     will collect, analyze and resell information on everything from retail
  96.     prices in grocery stores to the premiums charged by insurance
  97.     companies ... [it] intends to offer custom tailoring of such data to
  98.     meet the needs of individual clients ...
  99.  
  100.     One feature, available this spring through a 160-million-name database
  101.     that Strategic recently purchased, will be marketed to companies with
  102.     toll-free phone lines: For a fee, the companies can check the origins
  103.     of any calls they receive through 800 numbers -- even those that don't
  104.     go through -- enabling them to target the dialers for follow-up
  105.     mailings or sales pitches.
  106.  
  107. ------------------------------
  108.  
  109. Date: Wed, 15 Feb 89 10:39:44 CST
  110. From: wex@radiant.csc.ti.com (Alan Wexelblat)
  111. Subject: PIN?  Who needs a PIN?
  112.  
  113. Last night I had a rather frightening experience with my bankcard.  Using
  114. one of the network of machines which is supposed to accept my card, I tried
  115. to make a withdrawal.  The machine accepted my card, printed a message on
  116. its screen saying "Hello Alan Wexelblat, welcome to <competing bank
  117. machine>" and gave me the standard menu of options (withdraw, deposit,
  118. transfer, balance).  At no time did it ask for my PIN.
  119.  
  120. I didn't notice this until I had already tried to make a withdrawal.  The
  121. transaction was denied because my bank's computer was down, but the
  122. implication is really fairly scary: anyone with my card can walk up to this
  123. machine and get $400 of my money without either him or me doing anything to
  124. compromise the "highly private" PIN.
  125.  
  126. I'm not sure if this is the normal mode of operation for this bank's
  127. machines, or was a peculiar isolated failure or was due to a system-wide
  128. fault in the operating software.  Anyone else had a similar experience?
  129.  
  130. (The machine maker is Diebold; does anyone know if all machines by a given
  131. manufacturer run the same software?  I've used other Diebold machines before
  132. and never had anything like this happen.)
  133.  
  134. --Alan Wexelblat     TI Application Tools, Austin, TX
  135.  
  136.              [If you bank in a Diebold Cave, you say "NO PIN, OH SESAME!"  PGN]
  137.  
  138. ------------------------------
  139.  
  140. Date: Wed, 15 Feb 89 16:42:36 EST
  141. From: eddie.caplan@H.GP.CS.CMU.EDU
  142. Subject: Door Sensors and Kids
  143.  
  144. While reading back issues of RISKS, I ran across the discussion here about
  145. automatic sensors for controlling doors.  This made me recall that when we
  146. would bring our 2 year old son into work, he was not tall enough to trip the
  147. electronic eyes on the elevator doors.  Subsequently, we always had to be sure
  148. to hold the door until he passed through or he would get bonked.  The doors
  149. never closed hard enough to cause him any serious damage, but that's the RISK
  150. of the doors' hardware working properly.
  151.  
  152. ------------------------------
  153.  
  154. Date: 15 Feb 89 08:37
  155. From: blinn%dr.DEC@decwrl.dec.com (Dr. Tom @MKO, CMG S/W Mktg, DTN 264-4865)
  156. Subject: Risks of misunderstanding probability and statistics
  157.  
  158. As a person who has earned a doctorate in statistics, with emphasis on its
  159. practical applications (although I no longer work in that field), I have been
  160. both amused and appalled by some of the recent contributions focusing on
  161. probabilistic and statistical analysis of the risks of aircraft engine failures.
  162.  
  163. Some of the contributions assume, for example, that there really is such a
  164. thing as "the probability that one engine will fail", and that therefore you
  165. can compute the probability that two engines will fail (assuming that the
  166. failures are independent) by simply squaring this "p".  This is such an
  167. incredibly simplistic way of looking at the problem that I'm amazed that anyone
  168. would offer it for consideration.  Clearly, on any given aircraft, the engines
  169. share some subsystems in common; for example, they draw fuel from a common
  170. supply, possibly with a common fuel pump, possibly using two or more
  171. independent pumps.  Certain failures in the common subsystems could cause both
  172. (or all) engines to fail.  On the other hand, the engines have other subsystems
  173. that are not shared.  While these unique subsystems may have been equivalent
  174. (and thus, have a common propensity to fail) at the time of manufacture, they
  175. almost certainly are not equivalent after any period of maintenance in the
  176. field.  Consequently, even if we disregard the failures of common subsystems,
  177. the remaining engines almost certainly don't share a common probability of
  178. failure.  Assuming they do can be an interesting and useful strategem for
  179. thinking about joint probability of failure, but it's a dangerous
  180. oversimplification.
  181.  
  182. In RISKS-FORUM Digest Volume 8 : Issue 24, it is asserted by Barry Redmond that
  183.  
  184. >If someone makes a mistake on one engine at any of these times, there is a
  185. >high probability that they will make the same mistake on the other engine(s).
  186.  
  187. That may be true, but it may not be true, because the same person may not
  188. be working on all the engines.  I would agree that an incompetent mechanic
  189. working on all the engines is likely to make the same mistakes on all of
  190. them, but the reality of aircraft engine repair is different.
  191.  
  192. >The probabilities of failure are not independent because if one engine fails it
  193. >immediately increases the probability of another failing.
  194.  
  195. This is a very interesting assertion.  It seems to be saying that there is a
  196. causal relationship between a first engine failure and the likelihood of a
  197. second.  Now, I would agree that if I were on an aircraft where one engine had
  198. just failed, I'd worry lots more that a second would fail as well then I
  199. usually would worry about engine failure when no engines had failed, but this
  200. doesn't mean that the probability of failure of the other engines has changed
  201. in any way.  (It also doesn't mean that it hasn't, and if it has changed, it
  202. could be less or greater.)
  203.  
  204. It's unfortunate that a thorough grounding in probability theory and in
  205. statistical inference (and in risk analysis) isn't a part of the technical
  206. curriculum.  Failures happen.  They usually are not independent.  Knowing how
  207. to analyse the risks of failures can help in making the tough decisions about
  208. where to put resources to "prevent" or "protect against" failures.
  209.                                                                        Tom
  210.  
  211. Dr. Thomas P. Blinn, Marketing Consultant, Application Platforms,
  212. U. S. Channels Sales, Digital Equipment Corporation,
  213. Continental Blvd. -- MKO2-2/F10 Merrimack, New Hampshire 03054
  214.  
  215.   Opinions expressed herein are my own, and do not necessarily represent
  216.   those of my employer or anyone else, living or dead, real or imagined.
  217.  
  218. ------------------------------
  219.  
  220. Date: Wed, 15 Feb 89 11:23:41 EST
  221. From: Daniel Ford <daford@watdragon.waterloo.edu>
  222. Subject: Why you can't "flip" bits on a WORM disc
  223.  
  224. Some contributors have noted that there are risks in trusting the integrity of
  225. data stored on indelible storage devices such as WORM type optical discs.
  226. These types of devices are often employed to store archival data that is never
  227. legitimately altered (bank records, school transcripts, transaction logs,
  228. etc.).  There seem to be two risks to trusting this technology.  The first is
  229. "How can you be sure that the disc you are reading is the original and not some
  230. altered copy?" and the second was "How can you be sure that some bits have not
  231. been 'flipped' by overwriting a disc sector with a new value that happens to
  232. burn a pit in the right spot?" The first concern is valid, but the second is
  233. not.
  234.  
  235. There are two reasons for this.  Firstly, each disc sector on a WORM (and
  236. other types of optical discs) disc is protected with a sophisticated error
  237. correction code.  These codes are very robust and are used because the very
  238. high storage densities of optical discs tend to give them correspondingly
  239. high error rates.  So, if a bit (or several) was somehow "flipped", the ECC
  240. would either "correct" the change or report a read error.
  241.  
  242. The second reason has to do with how data is actually encoded on the disc
  243. surface.  Contrary to what might first be thought, "pits" (the holes) and
  244. "lands" (space in a track between pits) do not correspond directly to 1's and
  245. 0's.  Rather, their lengths and transitions form a sequence that encodes the
  246. data.  Many codes have been developed, but a common one is NRZM (Non-return to
  247. zero mark).  Basically, in this code the transitions between the lengths of
  248. both pits and lands record sequences of 0's and the transitions between the two
  249. record individual 1's.  Certain minimum and maximum lengths of pits and lands
  250. must be respected for clocking and detection purposes.
  251.  
  252. In such a scheme, you cannot just flip one bit (by making a pit longer) you
  253. must flip two or more.  So, even if you could get past the ECC, it would be
  254. quite difficult to get something specific and meaningful (i.e. not some weird
  255. control character in the middle of someone's name) by overwriting a WORM disc
  256. sector.
  257.  
  258. Further, each sector overwrite will also overwrite the ECC and change its
  259. encoded value, which is burned into the disc along with the data, to some
  260. other value.  As such, it is unlikely that the ECC and the sector contents
  261. will remain consistent after an overwrite (giving subsequent read errors).
  262.  
  263. It would be much easier to forge a disc and substitute it for the real thing
  264. then try to alter the original.  But, safeguards against that can be developed
  265. as well.
  266.                                         Dan Ford
  267.  
  268.      [Thanks for the elaboration.  But remember that even if you have an
  269.      N-error detecting code, many (N+1)-bit falsifications will go
  270.      undetected.  Similar problems exist with ECC.  PGN]
  271.  
  272. ------------------------------
  273.  
  274. Date: Wed, 15 Feb 89 16:52:28 EST
  275. From: dasegal@brokaw.LCS.MIT.EDU (David Andrew Segal)
  276. Subject: Credit Checker & Nationwide SS# Locate
  277.  
  278. A member of my research group received the following "comforting"
  279. advertisement in the mail (comments in [] are my editorial remarks...):
  280.  
  281.         CREDIT CHECKER & NATIONWIDE SS#-LOCATE
  282.                    just got
  283.                    BETTER!
  284.  
  285. PROFESSIONAL CREDIT CHECKER has always offered:
  286. * Consumer Credit Reports from thousands of credit sources coast-to-coast.
  287. * Social Security Number tracing anywhere in the country.
  288. * Driver's License reports from every state but Massachusetts [See Risks 8.20]
  289. * Financial reports on over 9,000,000 businesses all across the USA.
  290.  
  291.                    and now,
  292.              PROFESSIONAL CREDIT CHECKER
  293.            offers an exciting NEW service: [oh, boy]
  294.  
  295.          NATIONAL ADDRESS/IDENTIFIER UPDATE!
  296.          -----------------------------------
  297.  
  298. With NATIONAL ADDRESS/IDENTIFIER UPDATE you can enter either a name
  299. and address or a Social Security Number.  The Network will search all
  300. over the nation and get a complete report back to you in just seconds!
  301.  
  302. You can get such information as all current names, aliases, social
  303. security numbers and/or variances, date of birth, present and past
  304. employers and past and/or present addresses.
  305.  
  306. You can find people anywhere in the country without having to access a full
  307. Credit Report.  No permissible purpose under the Federal Law is required to run
  308. NATIONAL ADDRESS?IDENTIFIER UPDATE...and NO RECORD of an inquiry will be logged
  309. on the consumer's credit report! ... [Boy, it isn't illegal and no one will
  310. ever no you invaded their privacy!]
  311.  
  312. -----END OF ADVERTISEMENT------
  313.  
  314. I think the ad says it all.
  315. David Andrew Segal, MIT Laboratory for Computer Science
  316.  
  317.                              [And don't forget the on-line National Credit
  318.                              Information Network mentioned in RISKS-8.11.  PGN]
  319.  
  320. ------------------------------
  321.  
  322. Date: 15 Feb 89 14:51:00 EST
  323. From: "ALBTSB::SCHILLING1" <schilling1%albtsb.decnet@aldncf.alcoa.com>
  324. Subject: Re: Authenticity in digital media (RISKS-8.25)
  325.  
  326. Seeing hasn't been believing for a long time.  Remember Fred Astaire dancing on
  327. the ceiling in the movie "Singing in the Rain"?  And the newsreel footage
  328. showing Hitler dancing a little jig in front of the Eiffel Tower after the
  329. French surrender in WWII was a good piece of 1940 film editing, not an accurate
  330. motion picture.  Counterfeit paintings in the style of well-known artists have
  331. been around for at least four hundred years.  The Shroud of Turin was recently
  332. found to date from the 13th instead of the 1st century A.D.  Counterfeit coins
  333. were a problem in Roman Empire.
  334.  
  335. Computers haven't cut us off from history.  They just provide new tools with
  336. which human beings can fool one another.
  337.                                              Pete Schilling, Alcoa Laboratories
  338.  
  339. ------------------------------
  340.  
  341. Date: 14 Feb 1989 2127-PST (Tuesday)
  342. From: Jeff Makey <Makey@LOGICON.ARPA>
  343. Subject: Re: multi-gigabuck information "theft"
  344.  
  345. In RISKS DIGEST 8.23 Mark Brader <msb@sq.sq.com> paraphrases a recent
  346. article from the Toronto Star:
  347.  
  348. >A password belonging to [a large Canadian] company was used to steal
  349. >information which the company values at $4 billion (Canadian) ...
  350.  
  351. This report isn't news.  The "computer files" are nothing more than the source
  352. code for AT&T's UNIX operating system, copies of which may be easily obtained
  353. for a license fee on the order of a few thousand dollars -- a far cry from $4
  354. billion.  I suspect that AT&T's lawyers are at the root of this sensationalism.
  355.  
  356. Jeff Makey
  357.  
  358. ------------------------------
  359.  
  360. End of RISKS-FORUM Digest 8.26
  361. ************************
  362. -------
  363.