20-Nov-86 22:11:34-PST,17487;000000000000 Mail-From: NEUMANN created at 20-Nov-86 22:10:00 Date: Thu 20 Nov 86 22:10:00-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.15 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Thursday, 20 November 1986 Volume 4 : Issue 15 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: IBM VM/SP SP Cracked (Jack Shaw) On placing the blame AND Safety-Critical UK Software (Bjorn Freeman-Benson) On placing the blame (Scot Wilcoxon) Safety-Critical Software in the UK (Scott E. Preece) Computer-based stock trading (from Discover) FAA's Role in Developing a Mid-Air Collision-Avoidance System (Chuck Youman) 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) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- Date: Tue, 4 Nov 1986 22:32:40 EST From: Jack Shaw Subject: IBM VM/SP Cracked To: Security List Remailed-To: RISKS@CSL.SRI.COM It appears someone (student hacker) has cracked VM. Anyone interested in this should contact their IBM SE about APAR VM26824. Looks like a pretty serious breach too...Hacker was able to change anyone's CP class from A-H or their own CP class. Jack Shaw, Univ. of Ottawa ------------------------------ Date: Thu, 20 Nov 86 12:44:36 PST From: bnfb@beaver.cs.washington.edu (Bjorn Freeman-Benson) To: RISKS@CSL.SRI.COM Subject: On placing the blame and Safety-Critical UK Software (RISKS 4.14) Organization: U of Washington, Computer Science, Seattle I do not have a copy of the ACARD report, but judging from Appendix B, this report attempts to put almost all the blame for computer failures on the software, rather than the hardware, operation or the combined system. >B.3 The fault lies not so much in the computer hardware as in the programs >which control them, programs full of the errors, oversights, inadequacies >and misunderstandings of the programmers who compose them... Any system is only as strong as it's weakest link, and so any Certified software will have to be written, installed, run on and operated by Certifed people and machines. But, worse than that, what about interactions between the software and the hardware, or even other software (like the OS)? For example, Certified package A runs on Certified OS B on Certified hardware C. Something in C fails and B takes care of it, but in doing so response time falls until A fails (such as running a ship into an oil-rig). Certifying software would be a big step forward, but I think that concentrating on just one part of the whole system will not safely Certify that system. For example, reread the past N RISKS where time after time an operator error has caused problems. Or look at the real experience that I based the previous example on: We had a PDP-11 (not Certified) in which a board failed sending an inordinate number of spurious interrupts to the CPU. The OS handled them all, but response time went down by 80%. If the system failed that way, who would be held liable? Bjorn [First, we have been around this question on numerous occasions. There is often NO ONE PLACE TO PUT THE BLAME. Second, the ACARD report sets out to make a strong case for what the UK should do WITH RESPECT TO SOFTWARE. In that context, I don't think the report as a whole denies that other factors are not also critical; it just focuses on software. (The rest of the report is certainly of interest to software engineers. By the way, don't ask me about how to get copies. Ask HMSO. Perhaps one of our British correspondents can provide ordering information.) PGN] ------------------------------ From: rutgers!meccts!mecc!sewilco@seismo.CSS.GOV Date: Thu, 20 Nov 86 11:35:24 EST To: RISKS@csl.sri.com Subject: Re: On placing the blame (Peter J. Denning, RISKS-4.14) In the [first cited] example, the collision-avoidance method failed because the air traffic controller could not communicate with the aircraft. The present method cannot compensate for jammed radio frequencies, unless the aircraft are monitoring the international emergency channel and the controller thinks of trying it. [Observation: Even though the jammed frequency is not a computer problem per se, it greatly impacts the ability of the computerized ATC system to do its job. PGN] Other recent postings have pointed out the centralized characteristic of the existing collision-avoidance methods preferred by the FAA and compared them to an aircraft-based Honeywell system. The distributed Honeywell system has the advantage of not depending upon the ground-based computer and communication with it. The present system includes distributed jammers, one on board every aircraft. Scot E. Wilcoxon Minn Ed Comp Corp {quest,dayton,meccts}!mecc!sewilco (612)481-3507 sewilco@MECC.COM ihnp4!meccts!mecc!sewilco ------------------------------ Date: Thu, 20 Nov 86 09:27:44 CST From: "Scott E. Preece" To: RISKS@CSL.SRI.COM Subject: Safety-Critical Software in the UK The proposed regulation of safety-critical software in the U.K. is very interesting. What kind of status does the committee that wrote it have? Are these proposals that are likely to turn into law or are they just suggestions? [This report comes from a very highly respected committee. After some debate, the proposals may very well get turned into law! PGN] The notion of responsibility is a central element of the proposal. That's a very good thing. Everyone building systems should be thinking at all times that they are assuming responsibility for the use of their products. That responsibility should extend to anticipating the potential misuses of the system as well as to failures to perform to spec. The proposed definitions at the end make it clear that this proposal is broader than it might first seem. They apparently propose to classify and, presumably, certify systems which endanger money as well as lives. Defining the threat to life is, of course, non-trivial (shades of the 3+ laws of robotics). Would the administrative system implicated in the power-shutoff death reported here a few days ago have been considered life-critical? Would avionics systems for which non-automated, but less capable, backups are available? Is a program doing image enhancement on satellite pictures used by weather forecasters life-critical? How about the operating system it runs on? scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece ------------------------------ From: rutgers!meccts!ems!adam@seismo.CSS.GOV Date: Thu, 20 Nov 86 15:58:04 EST To: RISKS@csl.sri.com Subject: Computer-based stock trading [Some repetition, some new things] Organization: EMS/McGraw-Hill, Eden Pairie, MN December 1986 DISCOVER, v7 #12 p13: "SCIENCE BEHIND THE NEWS" "DID COMPUTERS MAKE STOCK PRICES PLUMMET?" News item: On Thursday, Sept. 11, 1986, the Dow Jones industrial average dropped 86.61 points, to 1792.89 -- a 4.61 per cent plunge. A record 237.6 million shares changed hands. The next day 240.5 million shares were traded, and the Dow fell 34.17 more points. Though the decline on Black Thursday paled next to that of Black Friday, Oct. 28, 1929, when the Dow fell 38.33 points, or a whopping 12.82 pre cent, Wall Street was shaken, and it's still looking for the cause. The Securities Exchange Commission (SEC) is now investigating the possibility that computerized program trading may have been a contributing factor. The decline actually began on Wednesday, Sept. 10, the day before the big drop. The bond market in London looked weak, which suggested that interest rates would remain high, and there were signs of impending inflation. As always, these indications of a slumping economy drove the price of stocks down. But many analysts believe that the drop was accelerated (though not initiated) by computer-assisted arbitrage. Arbitrageurs capitalize on what's known as the spread: a short-term difference between the price of stock futures, which are contracts to buy stocks at a set time and price, and that of the underlying stocks. The arbitrageurs' computers constantly monitor the spread and let them know when it's large enough so that they can transfer their holdings from stocks to stock futures or vice-versa, and make a profit that more than covers the cost of the transaction. The computer programs used by arbitrageurs are based on simple mathematical formulas that take into account the prices of stocks and futures, dividends, and interest rates. "It doesn't require you to have 20 megabytes," says John Barbanel, director of futures trading at Gruntal and Co. in New York. In fact, the math can be done on the back of an envelope. But by the time a trader could do the calculations for his entire portfolio, the market opportunity would've passed, the price of futures and stocks changed. With computers, arbitrageurs are constantly aware of where a profit can be made. However, throngs of arbitrageurs working with the latest information can set up perturbations in the market. Because arbitrageurs are all "massaging" the same basic information, a profitable spread is likely to show up on many of their computers at once. And since arbitrageurs take advantage of small spreads, they must deal in great volume to make it worth their while. All this adds up to a lot of trading in a little time, which can markedly alter the price of a stock. If, say, the arbitrageurs see that the price of a future has dropped below the price of its underlying stock, they may buy futures and sell the stock, en masse. Although Barbanel emphasizes that arbitrage stabilizes the market over a period of weeks and months, it can cause a lot of volatility within a single day. "Some trader on the floor of the New York Stock Exchange sees all the arbitrageurs selling at once and bringing down the value of stocks," so he sells too, says Hayne Leland, the director of Leland O'Brien Rubinstein Associates, a Los Angeles investment management firm. Heavy selling leads to more heavy selling -- and even lower stock prices. And the fast calculations of computers can only magnify these effects. Barbanel says that 20 per cent of the 86-point drop on Thursday may have come from computer-assisted arbitrage. [A different item included in the same message noted that Standard&Poor now reports the S&P 500 index and S&P 100 composite stock price index every fifteen seconds instead of once each minute. (For those people who really like to think they are inside the action? In case you want to make your computer-program-based trading "more precise"?) PGN] ------------------------------ To: risks@csl.sri.com Subject: FAA's Role in Developing a Mid-Air Collision-Avoidance System Date: Thu, 20 Nov 86 16:01:28 -0500 From: Chuck Youman There have been a couple of items in RISKS lately about mid-air collision-avoidance systems. The FAA's role in developing a mid-air collision-avoidance system was the subject of testimony presented at a Congressional hearing in September by a GAO official, Herbert R. McLure. A copy of his statement can be ordered from the GAO. The accession number is 131086. See RISKS 3-67 for their address. Some of the points Mr. McLure made in his testimony: Controversy still surrounds FAA's 1976 decision to pursue its own system rather than fund one that was being developed commercially. This controversy remains largely because the technical problems associated with developing FAA's system have proved to be much more complex and time-consuming than originally anticipated. Our work has shown, however, that FAA's decision was supported by the aviation community and that, while a number of technical problems have delayed the commercial availability of FAA's system, these problems have apparently been solved. Significant issues must still be addressed, however, during the testing and certification process before FAA's system is ready for commercial use. By the 1970's private industry was developing several different systems. After testing three, FAA decided that the Honeywell AVOIDS was the most promising, but even it had shortcomings. While the technical problems found with AVOIDS were correctable, the most serious shortcoming in all three systems FAA tested was that converging aircraft would only be warned of each other's proximity if they were both equipped with the system. Since no aircraft had AVOIDS, FAA surmised that a federal mandate would have been required to ensure that the system was installed in enough aircraft to provide an adequate level of protection. Conversely, commercial aircraft equipped with FAA's system, then called the Beacon Collision Avoidance System, or BCAS, would be warned of the proximity of all other aircraft having a transponder and would receive recommended collision-avoidance maneuvers if the other aircraft had an altitude encoder. Since over 100,000 aircraft, or about 65 percent of the air fleet, already had transponders, [. . .] FAA believed that its system would offer more immediate protection at less cost to the avaition community and that an adequate level of protection could be obtained without mandating the system's purchase by all aircraft owners. Polls of aircraft owner and user groups in 1976 and 1979 showed that FAA's decision held substantial aviation community support. Honeywell stopped development of its AVOIDS system soon after FAA decided to proceed with BCAS. In the intervening 10 years, FAA has encountered a number of technical problems that have slowed the development of its system, now called TCAS. In June 1981, FAA's Administrator announced that TCAS would be the national standard for mid-air collision avoidance, and that the system would be operational nationwide by mid-1985 at the latest. While this announcement was overly optimistic, it now appears that the known technical problems with the system have been solved. Testing the system in an operational environment and certification are all that remain before at least one model of TCAS can be commercially produced. FAA's involvement in TCAS research and development has been unusual in that it has been conducted in-house by FAA's TCAS program engineering group instead of by private industry. Through its Office of Airworthiness, certification of TCAS' effectiveness is also FAA's responsibility. Some TCAS program officials felt that FAA's involvement in research and development has resulted in over-cautiousness by the Office of Airworthiness in the certification process, and that TCAS is being subjected to much more scrutiny than it otherwise would have been. Another kind of problem involves product liability. FAA officials told us they are concerned that if a mid-air collision should occur because pilots follow a faulty TCAS resolution advisory, FAA may have to accept responsibility and liability for the collision. They also think the issue of product liability would have been a major concern for private industry if it had developed the system. A more complete report is also available from GAO: "Air Safety: Federal Aviation Administration's Role in Developing Mid-Air Collision Avoidance Back-Up Systems," GAO/RCED-86-105FS, Accession number 129832, April 22, 1986. A number of the comments I have seen seem to imply that it would still be possible to implement the Honeywell system. Since its development was stopped 10 years ago, I doubt it. Also, I don't think it is valid to criticize a decision because in retrospect in may not have been the "best" decision. I think the criteria should be whether the decision was reasonable based on the information that was available at the time the decision was made. Both alternatives were viewed as being technically feasible (and this appears to be correct even in retrospect). An issue that I think we should be discussing in RISKS is whether it is appropriate for the same organization to develop and approve critical systems. I think some degree of organizational independence is an absolute requirement. Charles Youman (youman@mitre.arpa) ------------------------------ End of RISKS-FORUM Digest ************************ -------