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…
Extracts from two newspaper articles on an ATM glitch which corrupted thousands of customer cards on Dec 31st in New Zealand. These articles are both from general circulation newspapers. The second gives a little more information. "Year too long for money machines", By Roger Fea, New Zealand Herald, Jan 2, 1993. The passing leap year caught several thousand ASB Bank customers short on Thursday - when the bank's money machines refused to process their transactions. The ASB's managing director, Mr Ralph Norris, said that a "faulty date checking routine" had corrupted the magnetic strip on the customers' money machine cards. The fault had to do with the fact that 1992 was a leap year and that Thursday was the 366th and last day of the year. The money machines were programmed to acknowledge the extra day but instead of the year 1992 being encoded, the figure 02 was used. The problem became apparent about 10 am on Thursday and covered a period from midnight to noon that day, when it was fixed. Only those customers who made two separate transactions during the period were initially affected. The first transaction went through but the problem occurred when their cards were inserted a second time. Mr Norris said all customers who used their cards during the 12 hours - possibly about 10,000 - were now carrying corrupted cards. If they used them subsequently up until Monday or Tuesday their transactions would be similarly rejected. By that time a new programme would be in place which would bypass the problem. [ Information about cards still working with other bank's machines and EFT-POS, as well as various apologies and contact information. ] "Leap year spikes cashcards", NZPA, Waikato Times, Jan 2, 1993. About 1500 TSB Bank customers in Taranaki had their Cashflow cards "corrupted" yesterday by a computer software fault that could ripple around the world with disastrous consequences. TSB customers, who used their cards between midnight Wednesday and about 12:30pm Thursday to make withdrawals, found they could not use the cards again and needed replacement cards. "It's quite a serious problem we are talking about ... which has the potential to ripple around the world," TSB information services manager John Hollins said. The 18 TSB automated teller machines (ATMs) throughout the region operated on a version of an NCR-based machine code which made no allowance for leap years. So after a first withdrawal on Thursday the machines no longer recognised the cards and came up with an "unable to process" message, Mr Hollins said. [ Information about the ASB being affected, but not the Trust Banks, which the ASB and TSB were once part of. ] Bank customers overseas who used ATMs which operated on the same NCR code could also expect problems after their first withdrawals on the last day of 1992, which had been a leap year, Mr Hollins said. However, customers who used Cashflow machines for other transactions - such as account balance queries, transfers of money, or deposits - were not affected. [ EFT-POS still worked OK, various apologies ]. ----- Background from Conrad: Both ASB and TSB are regional banks (although the ASB are starting to move into other regions). The nationwide trading banks (which also use NCR ATMs, amongst others) do not seem to have been similarly affected. This is another instance where New Zealand, as the first country in the world to see the new day, also gets to experience date-related bugs first - such as the recent 3pm Nov 1 1992 bug which broke many banking systems running on Tandem CLX hardware - as the bug hit NZ (then Australia, then Japan.....) a workaround was developed, and problems were averted in Europe and the US.....
News reports indicated that the Ross Perot campaign is being investigated by the FBI, Secret Service, and Federal Trade Commission for allegedly using stolen computer codes to obtain credit reports on some campaign workers. Investigators refused to discuss the case, but former Perot campaign employees, Equifax (the credit reporting company) and Orix Consumer Leasing of Secaucus, NJ admitted having spoken to investigators. Equifax said at least seventeen credit files of former Perot campaign workers may have been accessed illegally. Some Equifax reports were obtained using the security code of Orix, which claims to never have requested the credit reports on Perot volunteers. Officials at Orix and Equifax have said they believe Orix's security codes were stolen. [Source: LA Times 2 or 3 Jan 93] Richard N Kitchen email@example.com
The B767 aircraft suffers repeated failures of the computer that controls the individual passenger lights, sound, etc. Unlike earlier aircraft, all the switches on the armrests, including the individual light switches, sound channel and volume, and attendant call button, are controlled by a computer. On a recent flight that I was on, from Milan to Washington, the computer wedged shortly into the flight. Although one attendant figured that the situation would have to wait until the plane landed, another managed to reset the computer. According to the attendants, these computer problems happen all the time. Now of course this is not a life-critical system, but it is certainly ominous that such a simple task cannot be implemented correctly. I'm also curious about replacing 300 local light switches by a centralized computer with 300 inputs and 300 outputs. Ditto for the channel controls. Wm. Randolph Franklin, firstname.lastname@example.org, (518) 276-6077; Fax: -6261 ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180 USA
Years ago (pre-wordprocessing) I used an IBM Selectric typewriter with a correction key. For a lousy typist like me, this was *wonderful*. However, the manual warned against using a correctable (carbon film) ribbon for typing legal documents because undetectable alterations would be too easy. Well, recently on a Delta flight from Hartford to Atlanta one of the options on the inflight sound system was an interview with Frank Abagnale, a reformed forger who now advises companies on fraud prevention. Abagnale said that output from most laserprinters and photocopiers can be removed in a similar manner with correction tape because the toner powder, like carbon film ribbon, only sits on the surface of the paper but does not impregnate the fibers. I tried it and he's right. He said some of his clients have had checks altered in this manner. He suggested two solutions: 1: use an impact printer with inked fabric ribbons 2: there is a fixative, similar to the stuff artists use to protect charcoal drawings, that can be sprayed over the printout, making removal of toner more difficult. Matt Healy email@example.com PS: In the Selectric, IBM had the best keyboard I have ever used. Why didn't they use it for the PC? Closest approximation I have used recently is an old Leading Edge Model D. [If you wish to answer Matt's question, send mail to HIM, not to RISKS. By the way, the Selectric touch was fine, but the ball kept getting out of alignment. I have some wonderful concrete (abstract) poetry generated in 1969 using just such a ball. I had a real ball! PGN]
During the fall I recall that there was a RISKS contribution in which the writer speculated about the number of digit positions required to specify a real currency exchange rate, concluding that something like four or five digits would surely be adequate. This is incorrect - my daughter was previously in Zaire in the Peace Corps and is now in Congo in the Peace Corps. They (she and her husband had to leave Zaire when the Peace Corps cancelled the program in the country due to unrest which was partly due to the economy, which is in a shambles. When they went in the Peace Corps (Thanksgiving 1990 for Zaire), the exchange rate was something like 400 Zaires per dollar (officially) and about 800 Zaires per dollar in the real market. When they left the country the rate was about 80,000 Zaires per dollar (Sept. 1991), and the official rate had been dropped for some time. This weekend the rate is about 2,500,000 Zaires per dollar!! (And the largest piece of money is a [recently printed] note for 5,000,000 Zaires, but the government has said that in order to control things they were going to remove that one from circulation!) So in the face of unreasonable people (dictators, etc.), perhaps we need to use a floating point representation for the exchange rates - but I do think that one decimal digit for the exponent should be adequate. (And no one should need seven digit accuracy in the mantissa.) Richard Y. Kain, EE Department, University of Minnesota firstname.lastname@example.org
A letter in the UK magazine DEC User Jan 1993 page 6 shows a new danger" I think all readers should consider the implications of what happened to our company on 26th September 1992. At about 7:00am, our alarm was triggered, police and managers alerted, but by 7:07am we were already too late. In a precise but crude act, a single window was shattered by two lumps of concrete and our main PDP 11/84 processor was detached from all peripherals and lifted through the broken window. Naturally, we have restoration media of the recovery list, programmes and latest data. We were back in operation on Wednesday night thanks to our maintenance contract, software support and up-to-date back-up media. We are still reviewing potential motives and ramifications, but there have been other thefts in the area and complete systems are apparently reaching the former Eastern Bloc. In the meantime, if anyone offers you a cheap PDP, please let me know. A McManus Financial controller, Ritrama (UK) [BTW, I guess the letter shows 1) a criminal problem, and 2) why you make backups.) Lord John - The Programming Peer email@example.com tlx - 8951942 GLXPRI G fax - +44 81 423 4070
The statement The dutch news said that the responsible person has been found and he will be charged with neglig[ent] conduct causing death. in RISKS-14.20 on the Cindu accident aroused some excitement. In my first contribution in RISKS-14.21 I forgot to add details. Although there were some rumours that employees of Cindu would be prosecuted, the public prosecutor decided not do so. He thinks the employees were punished enough already by what had happened and that the case is too complex to be able to focus responsibility for the accident to one person. The rumours focused on the man who forgot to check the recipe before executing it. He was an apprentice operator, 3 months in service, and was alone when the accident happened. Dutch government charges the Cindu company as a whole for breaking several environmental, health, safety, and economical laws. The public prosecutor demands a fine of one million guilders (approx. US$600,000) and a suspended sentence (trial period of two years) to close the plant if another accident happens again. The latter is quite new in the Netherlands. The judge pronounced judgement on 5 January: a fine of 200,000 guilders (approx. US$100,000) mainly for breaking health and safety laws. (Of course Cindu is liable for damage etc., but this is civil law). Meine van der Meulen, firstname.lastname@example.org, The Netherlands Organization for Applied Scientific Research TNO, Department of Industrial Safety, Apeldoorn, The Netherlands, Phone: +31-55-493493. [Also noted by Anton van Reeken, A.vanReeken@be.rulimburg.nl.]
Mr. Wichmann makes the point that while often market pressures result in manufacturers concealing bugs in chips he states that: "In contrast, quite a few software vendors have an open bug reporting scheme --- and almost all provide a version number to the user." Unfortunately recent events have indicated that Microsoft does not always adhere to this maxim, choosing instead to "slipstream" certain corrections. Further from reports I have received, Microsoft employees have been distributing misinformation on incidents. The situation is as follows: when MS-DOS 5.00 was released, the CHKDSK program apparently contained a flaw that causes corruption of disks containing over approximately 65,280 clusters if the /F switch is used. Depending on cluster size, this indicates that disks or partitions containing approximately 128MB, 256MB, 512MB, 1024MB, or 2048MB are at risk. The problem had been corrected in a version of MS-DOS 5.00 dated 11-91 however other than the date, the only way to check is with a byte-for-byte check since both versions are exactly the same length (16,200 bytes). For reference, the earlier version contains the string 8B 4F 0F 8B F9 at offset DS:263E while the "fixed" one contains 8B 7F 0F 32 ED at the same offset. The sad part is that people have reported MicroSoft personnel as first recommending the undocumented VER /R switch and using only "Revision A". Unfortunately *every* version of MS-DOS 5.00 reports "Revision A". Just today I received a note from someone who contacted Microsoft and was told to "execute COMMAND.COM and check the version number" again both the old (04-91) and the new (11-91) versions report exactly the same thing. Further, this mirrors the response received when I called to report that certain corrupt values in the partition table could cause a floppy boot to hang ("You must have a bad floppy..."). To make matters worse, Microsoft appears unwilling to post an approved "patch" to the problem preferring to handle it on an individual basis (sounds kind of like WordPerfect here - call with a problem and they send you a set of "magic" disks). Thus it would seem that Mr. Wichmann has been spared contact with Microsoft in his assessment. I only wish it was true... Padgett <email@example.com> ps. Apparently the 11-91 version of MS-DOS 5.00 Revision A contains a number of changes to other programs however IO.SYS, MSDOS.SYS, and COMMAND.COM appear to be the same. pps. IBM PC-DOS 5.00 is said to return something meaningful to VER/R - the version dated 2-92 apparently has the CHKDSK "fix".
PROCEDURES FOR RELEASE OF GIS DATA TO THE PUBLIC There are many instances where non-governmental organizations request data and maps, e.g. coverages, from geographic information systems (GIS) owned by Federal and State agencies, but operated for these agencies by contractors. Release of data from these systems usually requires the contractor to submit the requested data / maps to the agency which in turn releases its to the requesting organization. GIS pose a special case because map coverages often involve multiple layers of data from third parties and have widely varying levels of quality. This posting presents a hypothetical case regarding release of GIS data, poses some questions, offers a straw man, and requests feedback. The contractor and the agency face substantial risks if the data are misused, misinterpreted, or the results of these actions create problems for the users. REQUESTS AND LIABILITY Examples of non-governmental entities include other contractors doing work for the same or other State agencies, businesses which want to use the data for their own purposes, and "good government" groups and other interest groups, who have reason to believe the data / maps will add value to their work. The issue is raised about the use of released data for purposes for which they are not intended and the ability of the original contractor and the agency to protect themselves against problems with the quality of the released data. For instance, should the original contractor prepare a "caveat emptor" statement. Further, the original GIS contractor gets much of its data from its primary customer, the Agency, and from other State agencies. The contractor does not "own" the data, does not own the hardware and software of the GIS — it was paid for with tax dollars — and, yet may be held liable by its customer for inappropriate release or failure to properly qualify the release of these same data. CASE EXAMPLE Let's take a hypothetical State Alcoholic Beverage Control Agency (ABC) which has collected information on package sales by retail outlet, by product, and other useful marketing information. The State Agency sells all alcoholic beverages in the State except beer and wine, which are sold in grocery stores. It also regulates the sale of alcoholic beverages in restaurants and bars. The State has built a GIS to make maps of sales data to support "targeting" of different products by demographics, but also to help keep tabs on public consumption habits in order to monitor "demand" for package sales v. restaurant sales. The ABC Agency argues it must have this data in map form so that it does not overstock stores near high volume bars and in resort areas. This has raised privacy issues and the legislature is asking whether the Agency has gone overboard in meeting its regulatory mandates. WHY THE DATA ARE REQUESTED Some of the questions coming from the legislature are motivated by lobbying pressures from the liquor industry. The industry has a generally adversarial relationship with the ABC Agency. It will likely use the GIS data to make a case in the current legislative session for changing the extent of the ABC Agency's powers. On the other side, a civil rights organization has requested the GIS maps in order to show there are a disproportionate number of liquor licenses in minority neighborhoods, and to show that the ABC Agency discriminates against minority applicants for these licenses. Numerous requests have been received by the Agency for copies of its maps. Suppose you are the contractor who runs the GIS for the ABC Agency. What would you do in terms of qualifying the release of the GIS data, electronic files, and hardcopy maps? What kind of release procedures would you want to use to cover your operation? STRAW MAN I'll start by offering a "straw man" caveat emptor statement. The primary objective of this data is to support specific legislative, regulatory, and administrative objectives of the ABC Agency and decision making which affects its operations. This agency takes no responsibility for interpretation or use of this data for purposes other than for which it was originally intended. ABC Agency databases and GIS coverages include many types of information with varying degrees of quality and reliability depending on the original sources. Further, it is the policy of the ABC Agency to accept and use the best data possible and to provide its users with information on the quality of that data. ABC data are subject to periodic updates, and it is the responsibility of external users to obtain these updates. Whether the data is ready for release or not the ABC Agency may be forced by Freedom of Information Act requirements in the hypothetical state to release the data and gis coverages. The absence of a legislative mandate to make the data public in other instances may not be a sufficient reason to withhold it. This case revolves around marketing and regulatory data for alcoholic beverages, but a parallel case could be developed for releasing GIS data on hazardous waste sites which impinges on public safety, privacy, and real estate values. SUMMARY The original question is — what should the contractor and the government agency do when faced with multiple requests for GIS data by non-governmental entities? What kind of "release policy and procedures" should be developed, and does anyone have any examples? Dan Yurman, Idaho National Engineering Laboratory, PO Box 1625, Idaho Falls, ID 83415 firstname.lastname@example.org 1-208-526-8591 Fax: 1-208-526-6902
Announcing the 4th AFCEA Computing Conference & Exposition Conference, Sponsored by the Armed Forces Communications and Electronics Association (AFCEA) in cooperation with the Association for Federal Information Resources Management (AFFIRM). Objective: A forum for military, civil government and industry computer hardware, software and systems professionals and users to exchange information and strengthen professional knowledge regarding capabilities, technology and application of information systems. Focus: This is not a DoD-only conference. The scope and focus of the conferences has continued to broaden to include presentations and demonstrations directed towards civil government and industry. Individuals from government, industry, and academia are invited to attend and will find the conference interesting and pertinent. Dates: Conference - February 2-4, 1993 Exposition - February 3-4, 1993 Location: Hyatt Regency Crystal City 2799 Jefferson Davis Highway Arlington, Virginia Hotel Reservations: AFCEA has blocked rooms at the Hyatt Regency Crystal City at special conference rates of $126.00/Single and $140.00/Double. Call (703) 418-1234 or (800) 233-1234 and be sure to mention that you are an ACCE '93 attendee to receive the discount rates. Security Tracks: Panel: Critical Programs Lead the Way Recent policy and mission assignments in DoD strongly support the goal to achieve adequate levels of security at an affordable price. To meet this goal, security requirements must be addressed early, from the top down, and throughout a systems life cycle to be effective. The panel will cover a cross section of activities representing the latest DoD approach to systems security. Presentations will address the vital role of security architecture, discuss current programs for meeting critical multilevel security requirements, and describe a specific security product being developed for the Navyis COPERNICUS program. Moderator: Mr. Robert Ayers, Program Manager, Defense Information Systems Security Program, Defense Information Systems Agency (DISA) Panelists: Mr. James S. Demerest, III Chief, DISSP Architecture Division National Security Agency (NSA), The Road to the DoD Goal Security Architecture lit. Col. John Sheldon, Program Manager Multi-level Security Technology Insertion Program Defense Information Systems Agency (DISA), The Multilevel Security Technology Insertion Program Mr. Michael S. Harrison, SPAWAR INFOSEC Support Office, Embeddable INFOSEC Product Panel: Standards - the Key to Interoperability To achieve security in an open systems environment requires the development of comprehensive standards touching nearly every dimension of information technology. While progress is being made in selected areas, the broadly based security standards structure needed to support the performance and user demands of emerging networks is yet to be developed. The immensity of the task requires Government and industry to work closely together on a national and international basis. The National Institute of Standards and Technology (NIST) plays a fundamental role in this effort. NIST, DoD, and industry presenters on the panel will discuss status, issues, and the direction for a number of important security standards activities. Moderator: Dr. Stuart Katzke, Chief, Computer Security Division National Institute of Standards and Technology (NIST) Panelists: Major Truce George, PhD., USAF, Sr. Techical Assistant Strategic Network Division National Security Agency (NSA), Status of Computer to Computer Security Protocols Prof. Thomas C. Bartee, Institute for Defense Analysis (IDA), Converging Labeling Standards Mr. Paul T. Cummings Sr. Software Engineering Manager, Manager ULTRIX MLS+ Digital Equipment- Corporation, Initiatives of the Trusted Systems Interoperability Group Mr. F. Lynn McNulty, Associate Director for Computer Security National Institute of Standards and Technology- (NIST), Infrastructure for the Digital Signature Standard Panel: Near-Term Implementations Current demands for network security cannot wait for mid- or long-term solutions. The need is now! This panel will address actions to provide solutions to real time network security demands. Panel members will present accomplishments and near-term plans in analyzing systems, Beta Testing, and ongoing systems security applications. The discussions will describe a System Security Profile, an ongoing Beta Test of the Preliminary Message Security Protocol, products applications at the Air Mobility Command on the Global Defense Support System (GDSS), and the plans for the Reserve Component Automation System (RCAS), the first Army system with MLS. Moderator: Mr. Charlie C. Baggett, Jr., Chief, Information Systems Security Programs Group National Security Agency (NSA) Panelists: Mr. Robert Wandell, Work Center Chief for System Security Profiles National Security Agency (NSA), System Security Profiles lit. Col. Philip Toler, USAF DMS Implementation Team Defense Information Systems Agency (DISA), Pre-Message Security Protocol (PMSP) E-Mail Beta Test Major Paul Law, USAF Implementation Team Air Mobility Command, Global Decision Support System Applications Ms. Victoria Thompson, Reserve Component Automation System (RCAS) PMO Air Mobility Command, RCAS Information Systems Security Panel: Evaluation, Certification and Accreditation The explosive growth of information technology is outstripping our capacity to perform the security evaluations needed at the product level. Similarly, there are insufficient resources to perform the certification and accreditation processes required at the system level. The panel will discuss plans and programs to enhance evaluation, certification, and accreditation capability. Moderator: Mr. Daniel J. Ryan, Director Information Systems Security Office of the Deputy Assistant Secretary of Defense (CI&SCM) Panelists: Commander Debbie Campbell, USN Standards, Criteria and Guidelines Division National Security Agency (NSA), Converging Certification and Accreditation Approaches in the Federal Government Mr. Stanley J. Chincheck, Head of Communication Security Section Naval Research Laboratory, Project Outreach - First Results Mr. Larry D. Merritt, Director for Securities Air Force Cryptologic Support Center, The Air Force INFOSEC Certification Program Tutorial: Understanding System Security Solutions The Information Systems Security field is complex and filled with jargon. This three-hour session is directed at providing a clear, plain English understanding of the fundamentals of information protection and the solutions now available. In addition, there will be a special presentation on how to conduct INFOSEC business in the DoD. Presenters: Mr. James P. Litchko, Director of Business Development Trusted Information Systems, Security Tool Kit `93 Mr. Joel E. Sachs, Vice President of Business Development Arca Systems, Inc., Multilevel Security - What It Is and What It Can Do Mr. Daniel J. Ryan, Director, Information Systems Security Office of the Deputy Assistant Secretary. of Defense (CI&SCI), How to Conduct INFOSEC Business in the DoD
Please report problems with the web pages to the maintainer