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 kitchenrn@ssd0.laafb.af.mil
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, wrf@ecse.rpi.edu, (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 matt@wardsgi.med.yale.edu
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 kain@ee.umn.edu
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 w0400@ggr.co.uk
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, meulen@tno.nl, 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 <padgett@tccslr.dnet.mmc.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 djy@inel.gov 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