You probably all know about the MoD draft standard in Great Britain requiring formal verification of safety-critical software. Well, here is another one. I was asked to consult on the safety of a microwave landing system, and they have just sent me a copy of a draft attachment to an international standard for MLS systems by the ICAO (international organization overseeing such aircraft systems). This may no longer be a draft — there is no date on it and the company implied that they had to follow it. As you can see from the following, there is an "out," but the sophistication of the standard is a surprise to me (most American software standards are abysmal). Since the ICAO must certify these systems before they are used, the standard has teeth and could be enforced quite strictly (unlikely, but ...). The following are some interesting excerpts: "... [Software] must be developed systematically in such a way that its behavior, under all possible conditions, can be established by logical reasoning (to a level of formality appropriate to the application). "... The programming should be performed in such a way that it is easily possible to establish the correspondence between the programme and its design and to verify its correctness with respect to its specification by logical reasoning (possibly supported by software tools). "... The interface of every software module with its enclosing environment should be explicitly stated in a preamble within its code, as well as in the design documentation. Where possible, a formal specification (e.g., in terms of pre- and post- conditions) should be given. "... Consistency of the code and its comments with the specification and the design documents should be checked, as formally and precisely as possible, as each module is developed. Formal verification (i.e., proofs of consistency between formal specifications of software modules and their code) should be performed where possible. Otherwise, manual code inspections or structured walk-throughs are essential. A software safety analysis should be performed as part of the design and development using at least one technique such as FMECA, fault tree analysis, or cause and consequence analysis..."
Maybe GM and the other manufacturers *would* sell cars without seat belts and warning buzzers, if there wasn't a *law* requiring them. So if we accept this as a valid analogy (I'm not saying it is or isn't), then the conclusion is that we need a law requiring computers to have adequate security. Jay Elinsky, IBM T.J. Watson Research Center, Yorktown Heights, NY [Affiliation for identification only]
Having been in the security software business for several years, I must take some exception to Keith Hanlan's comments on manufacturer's responsibilities for security. While I truly believe that some vendors use the excuses he mentioned for not making their products secure, there is some merit to them. Security is not free. Those of us in this business do the best we can to make secure systems easy to use (at least the good ones among us do), but a wide open system is usually easier to use. Security involves a tradeoff: it what it costs you less than what you might lose without it. The customer may decide it isn't worth the cost. He may be wrong, but it's still his decision. As for bugs, bugs should be fixed. But design flaws that influence security are trickier. For some reason, customers tend to find these flaws, and set up their production systems so they depend upon them. Thus, when you fix them, suddenly your customer's shops don't run anymore, and they get very irate. If your competitors do not fix the problem in their software, your customers see this as a feature, and it puts you at a competitive disadvantage. I can see how some vendors might knuckle under to this pressure, figuring that fighting for security ideals is of no use if all the customers flee for some less secure system and cause the company to fold up. Let me reiterate that this is not a wholesale defense of those who ignore security in the name of ease of use (which may really be ease of implementation). I just want to point out the pressures that exist in the competitive arena of commercial software. Lynn R. Grant, Technical Consultant, Computer Associates International, Inc. Disclaimer: These opinions are my own, and may or may not reflect those of my employer. [One man's feature is another man's future. But one person's feature can also be someone else's destruction. I am reminded of the multiple index register instructions in the IBM 7090 that stopped working in the 7094 because they were `only features' and were not officially supported. Anyone who lives by unsupported features may die the same way. PGN]
Austin-American Statesman, Saturday, December 10, 1988, P. A29 Hacker enters U.S. lab's computers By Thomas H. Maugh II, Los Angeles Times Service A computer hacker has entered computers at the government's Lawrence Livermore Laboratory in the San Francisco Bay area eight times since last Saturday, but has not caused any damage and has not been able to enter computers that contain classified information, Livermore officials said Friday. Nuclear weapons and the Star Wars defense system are designed at livermore, but information about those projects is kept in supercomputers that are physically and electronically separate from other computers at the laboratory. The hacker, whose identitiy remains unknown, entered the non-classified computer system at Livermore through INTERNET, a nationwide computer network that was shut down at the beginning of November by a computer virus. Chuck Cole, Livermore's chief of security, said the two incidents apparently are unrelated. The hacker entered the computers through an operating system and then through a conventional telephone line, He gave himself "super-user" status, providing access to virtually all functions of the non-classified computer systems. Officials quickly limited the super-user access, although they left some computers vulnerable to entry in the hope of catching the intruder. "There has been no maliciousness so far," Cole said. "He could have destroyed data, but he didn't. he just looks through data files, operating records, and password files....It semms to be someone doing a joy-riding thing."
[EXCERPT from VIRUS-L Digest V1 #33] VIRUS-L Digest Monday, 5 Dec 1988 Volume 1 : Issue 33 Date: Mon, 5 Dec 88 11:11:06 EST From: Don Alvarez <firstname.lastname@example.org> Subject: Computer Virus Eradication Act of 1988 I just received a copy of HR-5061, a new bill being introduced in the House by Wally Herger (R-CA) and Robert Carr (D-Mich.). The text of the bill is included below (see disclaimer). It sounds to me like there are some subscribers to VIRUS-L who's background is more criminal law than computer science, perhaps some of you could help the rest of us out with a little commentary. Would this bill be helpful to you? Do you think you would be able to get a conviction with it? Do you think you would be able to recover your damages with it (and how would you go about defining those damages if you were to use the law)? If people are interested in sending their comments to the authors, I include the name and address of the legislative aide who has been working on this bill. If people would like to e-mail their comments, you can send them to me and I will mail them to him in a packet (be sure to include your name and normal postal mail adress, as congress isn't on the net). Don Alvarez, boomer@SPACE.MIT.EDU - ------Start of Bill 100th Congress 2D Session H.R. 5061 To amend title 18, United States Code, to provide penalties for persons interfering with the operations of computers through the use of programs containing hidden commands that can cause harm, and for other purposes. IN THE HOUSE OF REPRESENTATIVES July 14, 1988 Mr. Herger (for himself and Mr. Carr) introduced the following bill; which was referred to the Committee on the Judiciary A BILL To ammend title 18, United States Code, to provide penalties for persons interfering with the operations of computers through the use of programs containing hidden commands that can cause harm, and for other purposes. 1 Be it enacted by the Senate and House of Representa- 2 tives of the United States of America in Congress assembled, 3 SECTION 1. SHORT TITLE. 4 This Act may be cited as the "Computer Virus Eradica- 5 tion Act of 1988". - -------Page 2 1 SECTION 2. TITLE 18 AMENDMENT. 2 (a) IN GENERAL.- Chapter 65 (relating to malicious 3 mischief) of title 18, United States Code, is amended by 4 adding at the end the following: 5 "S 1368. Disseminating computer viruses and other harm- 6 ful computer programs 7 "(a) Whoever knowingly- 8 "(1) inserts into a program for a computer infor- 9 mation or commands, knowing or having reason to be- 10 lieve that such information or commands will cause 11 loss to users of a computer on which such program is 12 run or to those who rely on information processed on 13 such computer; and 14 "(2) provides such a program to others in circum- 15 stances in which those others do not know of the inser- 16 tion or its effects; 17 or attempts to do so, shall if any such conduct affects 18 interstate or foreign commerce, be fined under this title or 19 imprisoned not more than 10 years, or both. 20 "(b) Whoever suffers loss by reason of a violation of 21 subsection (a) may, in a civil action against the violator, 22 obtain appropriate relief. In a civil action under this section, 23 the court may award to the prevailing party a reasonable attor- 24 ney's fee and other litigation expenses.". - --------Page 3 1 (b) CLERICAL AMENDMENT.- The table of sections at 2 the begining of chapter 65 of title 18, United States Code, 3 is amended by adding at the end the following: "1368. Disseminating computer viruses and other harmful computer programs.". - --------End of Bill >>>>NOTE: The above text was typed in by hand from a printed copy of HR5061 >>>> received from Mr. Herger's office. I have no experience with >>>> legal documents of this sort, and may have made typographical >>>> errors which could affect the nature of the bill. Neither >>>> I nor my employer (MIT Center for Space Research) make any claims >>>> as to the accuracy of the text. For an official copy of the >>>> bill, please contact: >>>> >>>> Mr. Doug Riggs >>>> 1108 Longworth Bldg >>>> Washington D.C. 20515
A news report last night on the Headline News Channel reported the experimental installation of a new kind of tollbooth in Dallas, TX (I think?), and one or two other places. Instead of tossing money into a hopper, you just drive on through — while a low-frequency, low-power radio signal polls an electronic "tag" taped to your windshield, which (hopefully) squawks a valid code back at it. (I was sort of amused to learn from the newscaster that this "tag" is made from "printed circuits, capacitors and diodes.") Reportedly, toll plazas in New York City and about a dozen other places will soon be outfitted with the new technology. The problems with this system from a RISKS perspective are numerous and evident. Perhaps the most troubling is that the system works on an accounting principle. Your "tag" uniquely identifies itself to the transmitter in the tollbooth, and your passage is recorded. Presumably you then get a monthly bill from the highway people. The problem here, of course, is that when you drive through a tollbooth, Big Brother knows exactly where you are. > *Excerpts from ext.in.risks: 18-Nov-88 Smart Roads (RISKS 7.81) Robert* > *Brooks@sde.hp.com (1040)* > Much concern has been expressed about the Big Brother potential of such > systems. But this is by no means an essential hazard. The transponders, > barcode tags, or whatever could be purchased anonymously, and authorization > to cross various toll points n times purchased in advance, like postage > stamps. This would be fine, except that if the tags are completely indentity-free, then stolen tags become especially problematic — the thief is in no danger of the tag becoming disabled, and the victim pays the thief's way through n tollbooth passages, where n could be quite large (and quite expensive, especially in New York, where tolls currently go as high as $3 for passenger cars). The temptation to thieves to break into cars so equipped would therefore be very great. In the current system, the tag is a non-descript black box secured above the registration/inspection stickers by Velcro strips. Even if a car owner were to hide the tag in the glove compartment when not in use, the Velcro strips, permanently adhered to the windshield, are a dead giveaway. The RISKS of theft are great even in the case of identifiable tags. The non-descriptness of these black boxes makes it easy for a thief to replace a stolen tag with a functionless dummy, so that it could be some time before the victim even realizes the unit had been stolen, by which time the thief could have run up quite a bill for the victim. The greatest RISK posed by these units is that the subjects in the current experiment seem to unanimously love the idea. Just breeze through a toll-plaza -- great! It never occurs to the average technology-ignorant, computer-phobic user that there may be some serious security/privacy problems here. I think some sort of high-publicity demonstration of the flaws in this system are called for as soon as possible. Bob Glickstein, Information Technology Center, Carnegie Mellon University, Pittsburgh, PA
Dave Nedde quotes David Oster: <>From: email@example.com.Berkeley.EDU (David Phillip Oster) <>Is it fair to also stamp the tickets with the time of issue, so if the <>distance traveled divided by the time elapsed is greater than the average <>speed limit the toll taker can hand you a speeding ticket at the same time? <>An appropriate computer would help the toll taker in this task. Then he adds: >Alas, as a Mass police officer pointed out in an interview, you have to catch >someone *in the act* of speeding to get them for it. Probably something to do >with that annoying bill of rights... I seriously doubt that the Mass. police officer is absolutely correct. After all, a favorite FBI strategy in catching professional hoodlums was to prosecute, successfully on income tax evasion. The evidence often was nothing more than a cash flow analysis: showing that someone spent more money in one year than he reported as income! Convictions were upheld, no? Risk of computers? Sure; think how often sucn analyses are possible using computers: proving Medicaid fraud, failure to repay student loans, catching scofflaws who replace a revoked driver's licence in one state with a "good" one in another, etc. Perhaps we should call this "benefits of computers?" _Brint
From: Dave Nedde <firstname.lastname@example.org> > Alas, as a Mass police officer pointed out in an interview, you have to > catch someone *in the act* of speeding to get them for it. Probably > something to do with that annoying bill of rights... I suspect it would be trivial to modify the law if it in fact prohibits such an application now. The state has very broad discretion in controlling the use of public roads and the privileges and responsibilities of those who hold state licenses (they could make it a license requirement to report illegal traffic behavior and then fine all licensed drivers in a car known to have been speeding, if they chose to make the statutes work that way). I don't see any way the Bill of Rights is even remotely involved. scott preece, motorola urbana design center uucp: uunet!uiucuxc!mcdurb!preece
There was discussion of this in another newsgroup not too long ago. Someone pointed out that exiting the toll road with average speed greater than the speed limit does not prove you were driving over the speed limit, since you might have switcherd drivers. Maybe this defense would indeed hold up--I no lawyer--but I see no reason not to pass a new law to make exiting with too little elapsed time a new crime. The owner of a car can be held responsible for parking tickets even if someone else parked the car, so I see no reason that whoever drives through the exit booth can't be held responsible for the average speed. John Sullivan
Regarding the item about the philadelphia subway system's capability to track monthly pass-holders' movement: I'm not particularly worried about this as an invasion of privacy, as long as purchasers don't have to identify themselves when buying their passes. It sounds to me as if the data they could collect doesn't contain any identification of individuals. It doesn't seem problematic for the transit commision to be able to gather statistics on individual traveller's routes, as long as there's no ability to tie the information to who the traveller is. I confess that I don't see a usefull way to correlate information on different trips by the same individual. The most usefull information would be just what the starting and stopping points were. Without this tracking ability, they presumably can't tell what the distribution of trip lengths is, and there are probably ways to make use of that information. Oh, I guess there might be a privacy problem if there is real-time feedback from the tracking system. For instance, if some police officer decides that lots of short trips throughout the day (as an example) is characteristic of some type of criminal of interest, it would be a problem if there were a way to find out real-time that someone fitting that description were right now passing through a particular turnstile. Other than that possible hole, this seems like an example of a way to gather data that starts out as a description only of average or sample behavior. As I said, all this is wrong if users identify themselves when they buy their passes. Chris [Well, many people pay by check or credit card, and that information would of course have to be recorded, for bookkeeping reasons... PGN]
Please report problems with the web pages to the maintainer