Subject: RISKS DIGEST 12.11 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 30 July 1991 Volume 12 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: DEFSTAN 00/55-56 (Victoria Stavridou and Andres Ravn) Computer problems at BCCI (David Shepherd) Census data in the Land of Oz (Michael Panosh) Soft Eng Cntrl aids during Hydraulic Failure (Science News) (Jeffrey Sorensen) Risks of human error in Soviet nuclear "industry" (Ken Mayer) Cardphone Problems in Ireland (D.P.O'Donoghue) Book review: Practical Unix Security (Clifford Stoll) *WRONG* ftp-adress in Brunnstein: Index of Known Malware (Eibo Thieme) Re: Smart cockpit with no backup (Henry Spencer) Re: The limits of simulation (Henry Spencer) Re: Licensing of Software Engineers (Henry Spencer) Data entry is NOT software engineering.. (Thomas P. Blinn) New Jersey "software engineering" registration legislation (Arthur Rubin, A. Padgett Peterson, Christopher R Riley, Chris Riley, Joseph Beckenbach) Flawed assertion in RISKS-12.08 (Mark Seecof) Re: Risks of Posting to RISKS (Jerry Hollombe) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Tue, 30 Jul 91 13:11:43 BST From: Victoria.Stavridou@prg.oxford.ac.uk Subject: DEFSTAN 00/55-56 A COMMENT ON THE REVISED UK MOD STANDARDS 00-55/56 Victoria Stavridou (RHBNC, Univ of London) and Anders Ravn (DTH, Technical Univ of Denmark) Our overall impression is that both interim standards have been substantially improved as a result of the public review exercise undertaken last year. This is particularly true of 00-55 which has been transformed from a long, confused and heavily prescriptive document to a much more sensible 2-part volume which describes the desired goals (Part 1/1 -- Requirements), suggests techniques for achieving these goals and identifies problems associated with certain practices (Part 2/1 -- Guidance). We have found that the formal methods content has been fully retained in this 2nd version and has in fact been improved since its interactions with non formal design and development aspects have, in many cases, been identified. For instance, the roles of the formal specification and the English commentary have been properly assigned (1/1 29.1) and appropriate uses are suggested (the requirement for verifying the English commentary has been removed!). Furthermore, this second version of the standard is far less prescriptive. Instead it identifies the goal and then leaves the designer/programmer free to use whatever techniques he wants so long as an overall requirement is satisfied. For instance, instead of banning dynamic memory allocation, there is now a requirement that the storage bounds during normal operation must be analysed and peak memory utilisation should not exceed 50% (2/1 30.50.2). The effect of these changes is that now ProCoS programs (which is of particular interest to us) would comply with the standard which was not the case for the previous version of 00-55. We are, however, less happy with the very weak links between 00-55 and 00-56. 1/1 8.2 on safety integrity analysis requires that this is carried out in accordance with 00-56; there is, however, no explicit way of relating the state/event spaces of the hazard analysis stage with that of the specification and/or program. This is a giant leap which assumes perfect physical components such as unfailing actuators and sensors! Current work between RHBNC and DTH is investigating this issue for the ProCoS $SL_0$ and fault tree analysis using a gas boiler as the running example. As a minor point, 00-56 states (6.8.1 Table 9) that the probability of human failure to act correctly in reasonable time after the onset of a high stress condition is between 0.3 and 1.0. It seems to us that a probability of 1.0 is pretty probable as in this case one knows exactly what the human is going to do! You just take the negation! ------------------------------ Date: Mon, 29 Jul 91 11:20:42 BST From: David Shepherd Subject: Computer problems at BCCI Recent UK newspaper reports have commented that the receivers who are trying to sort out the fraud at the now closed Bank of Credit and Commerce International (BCCI) are being greatly hindered by the fact that all the data is stored on an "archaic" computer system. They are also concerned that someone tipped BCCI off about the investiagtion before the bank was closed and that the computer records have been deliberately confused. david shepherd: des@inmos.co.uk or des@inmos.com tel: 0454-616616 x 379 inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq [A strong suspicion is that the records had been deliberately confused all along. PGN] ------------------------------ Date: Tue, 30 Jul 1991 12:49:36 +1000 From: Michael.Panosh, Unix.Education, Australia Subject: Census data in the Land of Oz Australia is coming up to another census exercise. Overheard on a breakfast radio news broadcast (paraphrase): "Confidentiality of data is assured as all the census papers are shredded." Reassured me no end!! Michael Panosh, Prime Computer, Australia -- mwp.michael@melpn1.prime.com ------------------------------ Date: Mon, 29 Jul 91 12:20:05 EDT From: sorensen@spl.ecse.rpi.edu (Jeffrey Sorensen) Subject: Science News Article: Soft Eng Cntrl aids during Hydraulic Failure [Jeffrey drew PGN's attention to a Science News article, 27 July 1991 (V 140, N 4, p 63), entitled "Software may ensure safer landings". It discusses recent problems with hydraulics (including the 1989 Iowa failure), and discusses a new software system:] The new software system has been tested on various flight simulators, including ones for the McDonnell Douglas F-15 and the Boeing 720. These simulators showed that with only manual control of the engines, crews could maneuver their planes but would have great difficulty landing. With software-controlled engines, however, pilots repeated simulated safe landings -- even in turbulence and crosswinds. [For the full article, contact Science Service, Inc., Editorial and Business Offices, 1719 N St. N.W., Washington DC 20036 (202-785-2255)] ------------------------------ Date: Mon, 29 Jul 91 17:27:44 -0400 From: ken@visix.com (Ken Mayer) Subject: Risks of human error in Soviet nuclear "industry" (Blinn, RISKS-12.08) Whenever I see the words "human error" I always think "human interface design error." I bristle at the idea of blaming people instead of poor design because the operators are the ones who are least able to defend themselves. The most highly skilled, trained human being will still make mistakes every now and then. It is up to designers to build systems that tolerate mistakes, and provide an unambiguous path to a solution. ------------------------------ Date: Mon, 29 Jul 1991 14:20 GMT From: "Parsifal aka D.P.O'Donoghue" <8614903@ul.ie> Subject: Cardphone Problems in Ireland The recent thread about disturbances in phone software brought to mind the disruption earlier on in the year to the Cardphones installed by Telecom E/ireann (Irish State phone co) around this campus. For some reason -never explained or publicised- for a period of approx 2 weeks users could utilise the Cardphones on Campus free of charge. Somehow someone discovered that by dialing the free number "17" (used to test ringback etc), hanging up and then lifting the receiver when the ringback occurred a dialtone was available. This news spread like wildfire amongst the non-Irish students here who took the opportunity to ring home. A certain amount of discreet observation meant that other people found out the method and rang for nothing. About two weeks later all the cardphones were out of order with a notice stating that a "network upgrade" was taking place and that was the end of that. Desmond P.O'Donoghue 8614903@ul.ie ------------------------------ Date: Wed, 24 Jul 91 14:11:43 pdt From: well!cliff@fernwood.UUCP (Clifford Stoll) Subject: Book review: Practical Unix Security Practical Unix Security, by Simson Garfinkel & Gene Spafford O'Reilly & Associates, Inc. ISBN 0-937175-72-2 Now, here's a book that's long overdue. If you're managing a Unix system, get this book. You'll learn much more than just how to secure your system. Garf and Spaf walk you through networks, file systems, and Unix internals, a tour customized for finding security weakness. Previous Unix security books were aimed at stand alone systems; this is the first that discusses Unix security in a networked environment. It's a practical book ("Never use Set-User-Id-Shell Scripts") with an underlying current of "here's how Unix works -- be careful of this wrinkle". Plenty of good stuff here: A chapter on how to discover a break-in, another on legal issues and privacy. A list of sensitive files in Unix. How to figure out Unix log files. Security implications of X-windows and NFS. Kerberos and Secure RPC. Most important, this is the first book to show you how to secure your computer in a networked environment. Today, most Unix computers have no system administrator. For others, a single manager handles for dozens of workstations. Old time security -- strict isolation -- just won't work. Instead, security depends on understanding acceptable network interactions. For a harried system manager, this book will pay for itself in aspirin. A few omissions: secure id cards, intrusion detection expert systems, and the Andrew File System. A few chapters are wasted on obvious things: backup your data, change your passwords, RS/232 pinouts, and the old shopworn arguments about what a hacker is. It's sad that this book needs 500 pages. Their security checklist is twelve pages long -- nobody will ever go through the entire list. Is this the fault of the authors? Or of Unix? Hard to say, but I sure wish there were an faster path to a tight system. -reviewed by Cliff Stoll 22 July 1991 ------------------------------ Date: Mon, 29 Jul 91 16:51:00 +0200 From: eibo@rosun1.informatik.uni-hamburg.de (Eibo Thieme) Subject: *WRONG* ftp-adress in Brunnstein: Index of Known Malware (RISKS-12.08) The adress of our ftp-server contained a small error, here is the correct version. But remember that our line is really slow ! VTC documents (Index of Known Malicious Software: IMSDOS.791; Index of Virus Catalog: Index.791; all entries classified up to now) are now available from FTP: Our FTP server: ftp.informatik.uni-hamburg.de ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Login anonymous ID as you wish (preferably your name) dir: directory of available information cd pub/virus: VTCs documents ------------------------------ Date: Tue, 30 Jul 91 12:54:16 EDT From: henry@zoo.toronto.edu Subject: Re: Smart cockpit with no backup >... In the event of a computer failure, the only good that mechanical backup >instruments would do would be to let the pilot watch the altitude ticking off... There is some justice in this; "if the computer fails, you're dead". But... "The" computer? *Which* computer? "Fails"? Fails *how*? It is not at all inconceivable to have a failure in which some control remains but sophisticated instrument presentations are scrambled or absent. Indeed, one would hope that the last-ditch emergency fallback mode of the software would be to provide basic control and nothing more. Henry Spencer at U of Toronto Zoology ------------------------------ Date: Sun, 28 Jul 91 19:58:59 EDT From: henry@zoo.toronto.edu Subject: Re: The limits of simulation > simulations of the [motor's] firing dynamics did not reveal subtle factors Actually, this may not quite be true, it turns out. I'm told, by folks I shouldn't identify, that some of the simulation work *did* at least hint at problems. This was not followed up, possibly as a deliberate decision by managers who didn't want to hear bad news. Henry Spencer ------------------------------ Date: Tue, 30 Jul 91 13:06:41 EDT From: henry@zoo.toronto.edu Subject: Licensing of Software Engineers >It only requires licensing of those who offer themselves for hire as software >ENGINEERS. Hire and engineer are both key words... An excellent point. Many of the readers of this list may not be aware that it is *already* illegal to offer yourself for hire as, say, a "mechanical engineer" without being a licensed professional engineer. The NJ law is closing a loophole in existing practice, not introducing something new and radical. "Engineer" is the crucial word; that term is legally protected and cannot be used frivolously... in any other field. (One exception to this: if you are working for somebody else, *they* can call you an "engineer" without requiring such qualification. [There may be some slight restrictions on this, I'm not up on details.] The more activist engineers have been known to agitate for removal of this rather large exemption.) Far too many people call themselves "software engineers", many of them having nowhere near the background and demonstrated competence expected of a licensed engineer in more traditional fields. While implementing the NJ law is going to be, um, a learning experience for all concerned, it's a step in the right direction. Henry Spencer at U of Toronto Zoology ------------------------------ Date: Tue, 30 Jul 91 09:04:08 PDT From: "Dr. Tom @MKO, CMG S/W Mktg" Subject: Data entry is NOT software engineering. In RISKS 12.10, Bill Murray and Bob Frankston comment on the NJ legislation requiring the registration of "software engineers". On the whole, I agree with Bill Murray. In spite of the fact that I program, and have even done a certain amount of "software engineering", I doubt that I could qualify as a "registered professional software engineer", in spite of my formal education (at the doctoral level) in computer and computing science and applied statistics. I find it amusing that Bob Frankston asks "What about a VCR programmer?" The stories of unusable human interfaces in commercial VCRs abound, but I'd hardly characterize the "data entry" aspect of most home VCR use as "programming". In fact, if "VCR programmers" were really software engineers, they probably would have learned (at least a modicum) of human factors considerations, and the products extant in the marketplace might be more approachable. Bob assumes the legislature is attempting "to codify what is not understood." Actually, the registration and certification of professional engineers is well understood, and it is the very lack of such that evidences the non-professional status of our business. Dr. Thomas P. Blinn, Digital Equipment Corporation, Digital Drive -- MKO2-2/F10 Merrimack, New Hampshire 03054 ...!decwrl!dr.enet.dec.com!blinn (603) 884-4865 ------------------------------ Date: Mon, 29 Jul 91 13:18:49 PDT From: a_rubin@dsg4.dse.beckman.com Subject: New Jersey "software engineering" registration legislation .... and risks of not looking at your posting software. The original file uses backspace characters to simulate underlining. Most of the underlined text was "design/designing" replacing "engineer/engineering". 2165888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal) a_rubin@dsg4.dse.beckman.com (work) ------------------------------ Date: Mon, 29 Jul 91 17:06:29 -0400 From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: Software Engineering Registration (NJ) The concept of registration for "software engineering" seems novel in that the proposal seems to both go too far and not far enough (thanks Bill). The concept that all programming be regulated, even all commercial programming, is ludicrous. At the same time certain catagories of programming cry out for regulation. As a licensed Professional Engineer, my primary responsibility is to ensure that certain engineering tasks are done in accordance with regulation and in a safe manner. The state of Florida has decided that I (as a result of experience and testing) am competant to determine this. One of the not-so-evident responsibilities is to not accept work that I am not qualified to perform. In the past, I have had the opportunity to work on many projects that did not require licensing including digital flight controls for several aircraft and a communications topology for the FAA National AirSpace Plan, two areas that probably should have been covered by such licensing. Other areas that come to mind are many medical software elements, computer assets used for road and traffic control, and emergency telecommunications networks. Certainly, IMHO in recent months we have seen several examples of what happens when software is developed without evident control. That complex software is difficult to debug does not seem to be an adequate defense for mistakes yet as more and more software replaces mechanical processes, the potential for danger increases. Certainly the computer in my wife's car is easily overridden since mechanical linkages from the wheel to the steering and from the accelerator to the throttle plate still can override any electrical command. A computerized highway control system is another matter. Consider the implications if a traffic signal were to display green in all directions simultaneously. (Yellow might be worse). Consequently, as more sophisticated systems come into use, a formal method needs to be established to determine that adequate safeguards are provided. The problem is that often, only the designer or design team has the expert knowlege of a particular system required to determine its safety. This is the reason that registration of engineers came about in the first place: since every critical design cannot be validated, we have to validate the designer. It is not the perfect answer, merely the best choice from what we have. The major problem that comes about is in designing a certification process that achieves its goals, not an easy task in any discipline but even more so in software since it is still evolving. In electrical engineering, the processes involved in providing adequate power for a building are well defined and codes have been developed that set out these rules. Nothing similar exists for software. To make matters more difficult, while electrical quanta are reasonably well defined (Alternating Current usually means either 60 or 400 hertz for most purposes & leads and lags are well defined), good computer software must consider the platform, clock speed, memory speed, bus speed, race conditions, failure conditions and a host of other variables, something many programmers are insulated from. Consequently, at some point, critial designs must be examined by someone who understands not merely the software, but the compiler, the operating system, the CPU, and the installation as well. I would not feel very safe near a nuclear power facility using a control program designed in Visual BASIC by someone who only understood Windows (trademarks acknowleged) though the approach might be well suited to balancing my checkbook. I can see a very valid need for a counterpart in software to the same certifications a licensed engineer makes when signing off on an engineering design: (in English) 1) I am competent to decide if this design is safe and meets applicable design standards. 2) I have examined this design in sufficient detail to make this determination. 3) Based on study and in my professional opinion this design is safe & meets all applicable standards. 4) By affixing my seal, I personnaly certify that this design and my study of it meet the above criteria. While the general public is often only aware of (3), all elements are actually present and failure of any element is grounds for censure/suspension /revocation of a professional license - in fact most of the board actions that I see result from defects in (1) or (2). It should also be mentioned that in many organizations, often only the Chief Engineer needs to be licensed. I would suspect that a Software Engineering license would be much the same. In short, I can see a very real need for such a licensing requirement, not globally but for those engaged in approval of critical or safety-related projects. The major problem will come from the certification process itself given the bewildering array of platforms, embedded micro-controllers, and languages. It will not be trivial to impliment but is something that needs to be done. A. Padgett Peterson, P.E. ------------------------------ Date: Tue, 30 Jul 91 11:52:52 EDT From: chris@mtuxo.att.com (Christopher R Riley) Subject: Re: Licensing of Software Engineers I think there is a misunderstanding of who is to be licensed. I have seen copies of the text that says "software 1[engineer] ________1" and another that says "software 1[engineer] designer1". The footnote at the bottom of page 1 of my copy says: EXPLANATION--Matter enclosed in bold-faced brackets [thus] in the above bill is not enacted and is inteded to be omitted in the law. Matter underlined thus is new matter. Matter enclosed in superscript numberals has been adopted as follows: 1 Assembly ACP committee amendments adopted June 13, 1991. 2 Assembly floor amendments adopted June 24, 1991. Some people's text does not have the word designers, but just the underlining (probably from backspace-underscore pairs in the text). I think the bill is intended to license software designers. My question is, does this mean that all people who write any piece of software code is a software designer, and thus must be licensed? Chris Riley chris@mtuxo.att.com ------------------------------ Date: Mon, 29 Jul 91 18:48:09 PDT From: jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr}) Subject: Re: New Jersey "software engineering" registration legislation (J.M.Ritter) The two most relevant points here: 1) How does this Act differ from any other Engineering Licensure within NJ? Answer: I don't know, but someone with a reasonable lawyer in New Jersey could probably find out some information for us. The language seems loose (regulating all practicing "software engineering"), but then we need to compare it to other language being used to regulate, eg, civil engineers. To my mind, it's a large step in the right direction. Not everyone who's wrapped a bandage needs to be a licensed medical practitioner, just those who intend to make a living of it as a main provider. At least, that's a simplification of my understanding of licensure. 2) How does this affect the "common practitioner"? Answer: Again, I don't know. However, looking at the parallels with other professions, I would venture my layman's interpretation: only those with proper qualifications may legally use the word "Engineer" to refer to themselves professionally. It does mean that all the job descriptions titled "Software Engineer" will need to turn into "Member of Software Technical Staff". I'll try to look over it a bit more before adding more humble opinion to the network. Meanwhile, it needs comparison to other Engineering Licensure statutes, such as for civil engineers and architects. Joseph Beckenbach Californian "software-engineer-wannabe" Test programs not programmers, but license software ENGINEERS! Joseph Beckenbach jerbil@ultra.com 408-922-0100 x246 ------------------------------ Date: Fri, 26 Jul 91 11:49:15 -0700 From: Mark Seecof Subject: Flawed assertion in RISKS-12.08 I'm catching some (well-deserved) heat about my assertion that it would "obviously" be impossible for a large majority of drivers to be "(much) better than average." This was poorly expressed, especially if "average" means "arithmetic mean" (of scores in some simple metric). I should have written out my opinion that an "ability score" versus population plot would reveal a typical "bell-shaped curve," that most drivers would have scores near the middle, that few drivers would score very far above the median, that by definition half of them would score at or below it, and that biases (thank you, Mr. Tanner ) in drivers' perceptions of other drivers on the road would factor into their self-assessment of superiority in such a way as to render it over-optimistic. [Messages were received from Tim Smith : "1 1 8 8 8 8 9 9 9 9. Note that the average of these 10 numbers is 7. Note that a large majority of them are above average. This is obviously possible." ... and Jeremy Grodberg : "And when it looks like statistics are *not* being abused, remember that 97.325% of all statistics are made up." ] ------------------------------ Date: Thu, 18 Jul 91 15:42:44 -0700 From: The Polymath Subject: Re: Risks of Posting to RISKS (Dunlop RISKS-12.06) There seems to have been an enormous misunderstanding here. That, or lawyers have gotten into the works, somewhere. I hope I can clear things up to everyone's satisfaction. }In RISKS 12.02, Jerry Hollombe describes our publication of his 1989 RISKS }posting about the "censorship" of rec.humor.funny at Stanford University. Mr. }Hollombe's piece was reprinted (with his permission) in Charles Dunlop and Rob }Kling (eds), _Computerization and Controversy: Value Conflicts and Social }Choices_ (Boston, Academic Press, 1991, ISBN: 0-12-224356-0). (See pp.376-379). [Further details omitted] Absolutely true. I gave my permission. I had no complaints then and I have none now. In fact, I'm quite proud of having been included in the book and have been calling my friends' attention to it. Some have expressed interest in obtaining copies for themselves. (I'm reading through it as time permits. So far I've found it interesting and thought provoking). }... However, we did not effectively anticipate this new controversy }about computerization: one's ability to fairly reprint RISKS (or any BBS) }postings after posters have given explicit permission! I certainly never intended to raise such an issue. Even if I did have a change of heart (which I didn't) I like to think I'm honorable enough to live with the consequences of my actions. My word, once given, stands. I would not retract it even if I wanted to and could. You had my permission to publish. That stands. } Unfortunately, Mr. Hollombe attributes his problem with the reprinting of }his RISKS posting solely to publishers and editors, and he conveniently ignores }his control over the publication. In RISKS 12.02 he writes: } } >The risk? The words we exchange here aren't as ephemeral as they may } >appear on a VDT screen, so be careful what you say and how you say it. } >You never know who might decide to package and ship it to a customer. } >(-: } } This complaint strikes us as unfair. ... This was not intended as a complaint and I'm amazed, and horrified, to see it interpreted as one. As I said in my posting, and have repeated here, I gave my permission for my words to be published. I've had no regrets about that, then or since. Very much the contrary, in fact. What I was attempting to convey was the idea that many people read, keep copies of and even disseminate what's posted here. It therefore behooves us to write thoughtfully, at least. On a more mundane level, I might have been more reluctant to give permission to use my posting if it had been full of spelling and grammatical errors. I was NOT complaining about the fact of its publication. }... We believe that ... }we were VERY FAIR to Mr. Hollombe. I believe you were more than fair. I'd say you were outright generous. I'm not complaining. Tell your lawyers to relax, if that's the problem. I'm not going to sue you. I like being published. Really. I don't know what more I can say at this point. Please feel free to contact me directly if you have any further questions about the matter. I'll be happy to reconfirm my permission to publish, in writing if that will help. (Alas, it seems the old risk of being misunderstood in written media is alive and well. That's no one's fault. It's just the nature of the situation). Jerry Hollombe, Citicorp, 3100 Ocean Park Blvd. Santa Monica, CA 90405 {rutgers|pyramid|philabs|psivax}!ttidca!hollombe (213) 450-9111, x2483 ------------------------------ End of RISKS-FORUM Digest 12.11 ************************