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…
This isn't a computer incident, but it contains several system safety lessons that may be of interest to readers of this digest. The accident has been discussed in the Seattle papers almost every day since December 22. The following excerpts are from one of the stories that describe the cause, in THE SEATTLE TIMES, Monday January 8, 1990, p. 1: TWO SHORTED WIRES JOINED TO CAUSE FATAL ACCIDENT, INSPECTORS SAY by Dick Lilly ... Engineers found that a screw driven into one wire and a short in another wire caused last month's fatal opening of the (Evergreen Point Floating Bridge's) drawspan. (The inspectors will report) to the State Department of Transportation (DOT) on Friday, said Richard Hearth, one of two engineers from the consulting firm of Parsons, Brinkerhof, Quade and Douglas Inc. who inspected the faulty Highway 520 bridge Saturday and yesterday. The two shorted wires, one on the east drawspan and one on the west span, combined to send current around safety systems and lift the west section of the drawspan during a routine test December 22. Several cars crashed into the unexpectedly rising bridge deck. ... One (driver) was killed. Five people were injured in the morning rush hour accident. ... "Each fault individually did not cause the problem," said Patrick Buller, an electrical engineer from the (Washington State) Patrol who took part in the investigation. "It took both problems simultaneously for the bridge to rise," he said. Power from the burned cable on the east drawspan probably reached the west side either through the metal of the bridge deck or along the metal walls of the submerged cables which connect the two movable spans with the control tower, said Daryl Rush, bridge maintenance supervisor for the DOT. Picking up that current, the short on the west side, where 3/8-inch sheet metal screw holding an electrical box cover had pierced a wire, sent power to motors that lifted the west span, Hearth said. The routine tests during which the accident occurred had until Dec. 22 been run almost weekly without incident for 18 years. Ironically, it was a tiny heater designed to keep moisture from damaging circuits in an electrical relay that burned plastic insulation from one of the wires, causing the short circuit on the east span. Such heaters protect many of the bridge's electrical devices. During a bridge opening, the device housing the burned wire senses the rotation of a gear in order to tell operators how far the east draw span has retracted. At Step 10 in the 18-step dry-run test that ws going on the day of the fatal accident, the device received power. Though the bridge does not open during any part of the test procedure, the shorted wire allowed power to reach motors on the west span. For the Evergreen Point Bridge to open, grated sections of the bridge deck rise, allowing sections of the roadway to slide back for the passage of ships. ... [ Here are further excerpts from THE SEATTLE POST-INTELLIGENCER, January 8, 1990, p. 1, ELECTRICAL SHORTS LIFTED SPAN by Mike Merrit ] One move tranportation officials made to ensure such an accident doesn't happen again is to stop the "dry run" tests of the bridge's control systems. Future tests will be done only with the span closed to traffic. ... Hearth declined to comment on whether the bridge should have been designed with automatic mechanisms to prevent activation of its lift-deck motors unless the span was closed to traffic. "In hindsight, the question is a good one," (John) Stevenson (assistant district administrator for DOT) said. "But when the design was being completed, it's hard to know what factors were taken into account. ... The span was built across Lake Washington in 1962. ... The west span short circuit, caused when a tiny screw touched wires inside a metal box, had probably existed for some months or years. The second short circuit ... had probably occurred gradually over several months or a year ... (a) heater apparently melted insulation from one of a bundle of wires. Sometime between tests run Dec. 15 and Dec. 22, when the malfunction occured, enough insulation melted away to let the bare wire touch the metal cover plate. ... "The wire (with the melted insulation) is in such a place that it's not real visible," said Ernest Frye, who oversees inspections as the bridge's lead maintenance technician. ... (the assembly containing the wire) is inspected annually ... the latest inspection was April 9, 1989. But the damaged wire is one of a bundle of wires under a metal cover plate that is not usually removed in routine inspections. Charles Mayhan, state moveable bridge engineer, said he did not do a detailed examination of the ... mechanism while inspecting the bridge earlier this year. "If I took the time to do all that, I wouldn't be able to do more than one bridge a year," he said. [ The consulting engineers will recommend installation of devices to warn operators of short circuits ] Devices to detect small short circuits weren't widely used when the bridge was designed in the 1950's ... - Jonathan Jacky, University of Washington
On Friday Jan 5, 1989, as I was returning from a day's skiing, the electrical system of the bus I was riding in suddenly went dead. The driver was forced to pull over on the side of the expressway. Subsequent investigation showed that the cause of the problem was a loose connection of the power cable leading to the starter. This cable can carry several hundred amperes of starting current; power is actually delivered to the starter motor via a nearby relay controlled by the ignition key. According to the driver, the cable came off a loose connection at the starter and shorted the high side of the battery to the bottom of the oil pan, burning a hole and spattering oil on the engine. Luckily, no fire resulted. The driver got out and walked back to an emergency phone placed at the side of the highway. He returned, saying that instead of being connected to the police, he had heard a recorded message saying the phone was "not in a designated area", and giving another number to dial. But the phone had no dial on it! A passing motorist was able to help the driver by relaying a message to the police. As a result, the bus company was notified, and sent another bus to get us home. Some further observations: 1) The headlights and AM/FM radio still worked after we pulled over, but not the rear flashers or rear lights. The driver put a flare behind the bus. 2) Installation of a two-way radio was planned for the following Monday. But I wonder if it could operate independently of the electrical system of the bus, in an emergency. 3) The extreme cold weather had ended, so that no-one felt cold. The part that is computer system related is the part about the roadside phones giving an "error message" that the user could not respond to. I am reminded of the customer-operated touch-screen POS terminal reported in RISKS that gave a software error message and asked the user (customer) to hit return on a keyboard that presumably had only been present during testing. I see this situation as a case of losing track of the system's behaviour as seen by the user. If you can get connected to a recording, then why not the police station? In a potentially life-threatening situation, no other system response is acceptable, in my view. Remeber the Woody Allen film where an attempt to call the 911 police number results in an "all lines busy" voice recording, followed by a disconnect? This case was no joke. Nor did it seem to have been a failure of an individual phone, which wouldn't be worth mentioning in RISKS. There's also the issue of the primary failure (electrical failure) resulting in a failure of systems to prevent further damage (the flashers). So, while this tale appears marginally related to computers, I feel the system ergonomics and reliability design issues are very pertinent, and easy to visualize in this case. Peter Jones MAINT@UQAM (514)-987-3542 "Life's too short to try and fill up every minute of it" :-)
A couple of nights ago I was working away merrily on my Macintosh with two cats plopped all over the table as usual. For some reason, while I was working in a usually reliable program, the computer froze. Couldn't figure it out; all I was doing was typing. While I was still thinking, the Mac suddenly unfroze, and the icon for the CDROM drive popped up on the desktop. It takes more than minute for this particular CDROM to come online, during which time the Macintosh is busied out, thus the inexplicable delay. Who had pushed in the CDROM? A cat. One of them woke briefly, stretched, changed position, and in doing so shoved the disk into the drive. Since I am quite used to cats stretching I didn't bother to watch him and had no idea he needed the disk online. I was already cursing the software for crashing the machine until the icon showed up. Part of the blame for this confusion can be laid squarely on Apple. Their own Human Interface Guidelines specify that the pointer should be replaced with a watch for a "lengthy operation" (Inside Macintosh p.I-37). They often follow their own guidelines, but not in this case. [Another hidden side-effect of the Unix "cat" command? If blank text had been inserted, you might have thought the system had gone tabby. Part of the problem is the emphasis on just "human" interfaces. But perhaps your cat now has a Macintush. Therein lies a tail. PGN]
> One student's answer: "Passwords have the advantage that it's easier to let > my friend use my account. If the system uses biometric devices for user > authentication, I have to be there when he logs in, to get him on to the > system. But, if the system uses passwords, I can just tell him my password, > and don't have to be there - he can login at his leisure." GOOD LORD IN HEAVEN!! And these are going to be our System Managers and administrators of the FUTURE?? Heaven help us!! Phil Ritzenthaler The Advanced Computing Center for the Arts & Design (ACCAD) Systems Manager The Ohio State University
>One student's answer: "Passwords have the advantage that it's easier to let
>my friend use my account..."
>So much for that one-week unit on 'Individual Accountability'.
I hope you also spent some time talking about how formal mechanisms often
imperfectly capture the real nature of human organizations, and about the
negative effects on security when overly-rigid formal mechanisms lead to the
evolution of informal "bypass" mechanisms? This is a perfect example. Anyone
who has ever loaned someone else a key knows that there *are* real requirements
for such things, accountability problems notwithstanding, when the overhead of
"doing it right" is high.
Henry Spencer at U of Toronto Zoology
In an editorial remark added to my recent RISKS contribution, our Moderator
writes:
If you want individual accountability, you do not share passwords.
The telephone system is intrinsically vulnerable to illicit use of
credit cards. If you wish to trust a friend, that may have low risk
— unless MANY people are involved; then you might like to have
records that show who is actually using your resources....
This continues to miss the point I was making.
Consider the following two situations:
1. The system manager on my machine assigns a shared account to
me and five other people (who, let us say for the sake of
argument, are my friends).
2. I let the same five friends know what my password is.
Are these equivalent? The answer is absolutely not: While the "observable
facts" may look the same - the same people have the same information - the
RESPONSIBILITIES are radically different. In case 1, if one of the six people
with access to the account abuse it, I will be able to deny responsibility -
as will the five others. This is "lack of individual responsibility".
However, in case 2, if one of the six of us abuses the account, it is clear
who bears the responsibility: Me. My five friends are acting as my agents,
and I can complain all I like that it was they who acted - in giving them my
password, I implicitly accepted the consequences of their actions.
Now, the problem is that those of us with an interest in security can easily
see ourselves in case 1 - and we've learned that case 1 represents bad, if
all too common, system management policy. (How many times have heard of
systems in which each account costs money, so any number of users are assigned
to the same account to keep the accountants happy?) However, we have much
more difficulty imagining ourselves in case 2, since WE certainly would never
let others know our password.
However it is exactly case 2 which we are discussing here! As long as it is
understood that the "owner of record" of an account remains responsible for
it no matter who he allows to use it - just as the owner of a telephone must
pay the charges his friends run up on it - I can see no issue of "individual
accountability" here.
The law, and our common sense of ethics, has been dealing with lending in this
way for a long, long time. Why should computer accounts be treated in any
different way? Admittedly, it may be worthwhile to point out to people that
lending their accounts has a greater potential for abuse than lending their
shirts, or whatever - exactly because passwords as a means of identification
are freely reproducible. People understand this; they are more willing to lend
a key than to "lend" the combination to a lock.
— Jerry
It has always seemed to me that there is no point in trying to prevent people from `lending' their passwords to others — they'll do it anyway. A better administrative strategy might be to make it plain to people that they will be held responsible for any act committed under their login, whether they actually did it or not.
> [Yes, some people are concerned about computer security and others are not
> — at least not until they've been burned. But Reality and Sensibility
> are in this case two radically different things. If you want individual
> accountability, you do not share passwords. ...
This is all true, but the amount of security you need depends on many things.
For example, an account you pay money for might be a different matter than
an account on a local BBS, which again is different from an account on a
friend's UNIX box. Work and school accounts are another matter.
I wouldn't casually hand out passwords here at work, but I might give someone
my compuserve password... and I'd change it later. I'd be even more likely
to give someone a password for a local BBS, and probably wouldn't bother to
change it.
Another variant is who you give the password to. You might be willing to swap
passwords to class accounts at school, or project accounts at work, but you
probably wouldn't hand out your CI$ password to your co-workers.
So, having the ability to lend access to a resource is valuable, and is not
always somehing to be feared. Security and convenience being opposed goals,
it's important to gauge the level of security to the value of the resource in
question.
Peter da Silva +1 713 274 5180
1990 IEEE Symposium on Research in Security and Privacy
ADVANCE PROGRAM
4 January 1990
MONDAY, MAY 7, 1990
0845-0900 Welcome, Introduction, Deborah Downs, Deborah Cooper
0900-1030 Commercial A1, Steve Lipner, Chair
Status Update
A VMM Security Kernel for the VAX Architecture, Paul Karger, Mary Ellen Zurko,
Douglas W. Bonin, Andrew H. Mason
An Architecture for Practical Delegation in a Distributed System, Morrie
Gasser, Ellen McDermott
Practical Authentication for Distributed Computing, John Linn
1100-1200 A1 SOS, Elizabeth Sullivan, Chair
The Army Secure Operating System, Neil Waldhart
Specification and Verification of the ASOS Kernel, Ben L. Di Vito, Paul H.
Palmquist, Eric R. Anderson, Michael L. Johnston
1330-1500 Database I, Teresa Lunt, Chair
Integrating an Object-Oriented Data Model with Multilevel Security, Sushil
Jajodia, Boris Kogan
A Little Knowledge Goes a Long Way: Fast Detection of Compromised Data in 2 D
Tables, Dan Gusfield
Extending the Brewer-Nash Model to a Multilevel Context, Catherine Meadows
Rejoinder
Database II, Earl Boebert, Chair
Polyinstantiation and Integrity in Multilevel Relations, Sushil Jajodia, Ravi
Sandhu
Naming and Grouping Privileges to Simplify Security Management in Large
Databases, Robert W. Baldwin
Referential Secrecy, Rae K. Burns
Discussion
1730-1930 Reception
2000-2400 Poster Sessions, Hospitality Suite
TUESDAY, MAY 8, 1990
0900-1030 Information Flow, John Rushby
Information Flow in Nondeterministic Systems, J. Todd Wittbold, Dale M. Johnson
Constructively Unsing Noninterference to Analyze Systems, Todd Fine
Probabilistic Interference, James W. Gray, III
Security Models and Information Flow, John McLean
Rejoinder
1100-1200 Access Control and Integrity
Beyond the Pale of MAC and DAC — Defining New Forms of Access Control,
Catherine Jensen McCollum, Judith R. Messing, LouAnna Notargiacomo
Some Conundrums Concerning Separation of Duty, Michael J. Nash, Keith R.
Poland
1330-1500 Authentication, Tom Berson, Chair
SP3 Peer Entity Identification, Bill Birnbaum
The Role of Trust in Protected Mail, Martha Branstad, W. Curtis Barker,
Pamela Cochrane
A Security Architecture and Mechanism for Data Confidentiality in TCP/IP
Protocols, Raju Ramaswamy
Reasoning about Belief in Crytographic Protocols, Li Gong, Roger Needham,
Raphael Yahalom
1530-1650 Verification, Deborah Cooper, Chair
The Deductive Theory Manager: A Knowledge Based System for Formal Verification,
Ben Di Vito, Cristi Garvey, Davis Kwong, Alex Murray, Jane Solomon, Amy Wu
Formal Construction of Provably Secure Systems with Cartesiana, Heinz Brix,
Albert Dietl
Verifying A Hardware Security Architecture, Joshua D. Guttman, Hai-Ping Ko
A Hierarchical Methodology for Verifying Microprogrammed Microprocessors
1700-1800 Technical Committee Business Meeting
2000-2400 Poster Sessions, Hospitality Suite
WEDNESDAY, MAY 9, 1990
0910-1020 Auditing and Intrusion Detection, Jim Anderson, Chair
The Auditing Facility for a VMM Security Kernel, Kenneth F. Seiden, Jeffrey P.
Melanson
Adaptive Real-time Anomaly Detection Using Inductively Generated Sequential
Patterns, Henry Sl Teng, Kaihu Chen, Stephen C-Y Lu
Auditing the Use of Covert Storage Channels in Secure Systems, Shiuh-Pyng
Shieh, Virgil D. Gligor
1020-1030 Presentation of Awards
1030-1100 Break
1100-1200 Database III, Cristi Garvey, Chair
Transaction Processing in Multilevel-Secure Databases Using Replicated
Architecture, Sushil Jajodia, Boris Kogan
Multiversion Concurrency Control for Multilevel Secure Database Systems, T.F.
Keefe, W.T. Tsai
Modeling Security-Relevant Data Semantics, Gary W. Smith
1330-1700 Panel Discussions — To Be Announced
Please report problems with the web pages to the maintainer