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…
From the Boston Globe of Friday, 3 Dec 1993: What "The Who's Tommy" needed yesterday was a computer wizard, not a pinball wizard. Last night's opening Boston performance of the high-tech musical was canceled because several computers required to stage the show suffered technical difficulties as a result of being shipped to the Colonial Theatre from Louisville, where the production completed a one-week run on Sunday. ... "Touring is apparently being more funky on the computers than anyone anticipated," David Balsom, the show's local press representative, lamented last night. ...
The attached article is from The Independent, 9 Dec 1993. This is the first I
have heard of such a scheme here in the UK, but would not be at all surprised
if similar schemes already exist elsewhere (you would not expect to find such
information from a press conference!).
I was particularly "interested" in the paragraph:
The key to the card's security lies in the Japanese-developed technology
and microchip. NatWest and Midland said that a technical breakthrough had
made it impossible to counterfeit cards.
and look forward to the reactions of RISKS' readers.
Brian Randell, Dept. of Computing Science, University of Newcastle, Newcastle
upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk PHONE = +44 91 222 7923
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TIME FOR A TOP-UP: MONDEX FACES A YEAR-LONG TRIAL, BEGINNING IN SWINDON IN
1995.
NATWEST IS RUNNING THE PROJECT IN CONJUNCTION WITH MIDLAND AND
BRITISH TELECOM.
BANKS STEP UP WAR ON CASH WITH PLASTIC CARD THAT CAN BE TOPPED UP BY PHONE
EVEN STREET VENDORS WILL BE ABLE TO TAKE THE NEW ELECTRONIC MONEY, SAY ITS
MAKERS.
Nicholas Bannister reports on Mondex
NATIONAL Westminster Bank has developed an alternative to cash - a plastic
card with a microchip which stores "electronic money" and can be topped up
over the phone. Yesterday it revealed plans for a year-long trial of Mondex,
its electronic money system, starting in Swindon in 1995. The pilot project,
in conjunction with Midland Bank and British Telecom is likely to involve
about 10,000 people, mainly bank customers and retailers.
The system lets customers add money to their card by using adapted cash
dispensers or phones to access their accounts. Once charged with money, the
card becomes the equivalent of cash. Payments are made by slipping the card
into a retailer's terminal. The sum is transferred from the card to the
retailer without need for time-consuming authorisations or signatures.
Provided there is enough money on the card, the transaction will take place.
Payments between individuals are carried out by inserting the card into a
pocket-sized electronic wallet and making six keystrokes. Both customers and
retailers can deposit electronic money into their bank accounts over the
phone.
Bert Morris, NatWest's deputy group chief executive, said that cash was still
used for 90 per cent of all transactions in the United Kingdom, and that
handling cash cost the banks more than #4.5 billion a year. He claimed that
widespread use of Mondex would not lead to staff cuts and branch closures. Mr
Morris, who is also on the Department of Social Security board, said that
social security fraud could be reduced if the Mondex system was used for
payments.
Tim Jones, one of the two NatWest executives who came up with the Mondex
concept, said the card was not intended to replace traditional debit and
credit cards. The system was designed for small and large payments. Small
traders, for example a newspaper vendor, could have a battery-powered
terminal. He claimed that it was safer, quicker and more convenient to handle
electronic rather than physical money. But if a Mondex card was lost or
stolen, the money on it would be lost in the same way as money in a missing
wallet.
However, cards could be locked to prevent unauthorised use by tapping in a
four-digit personal code. Once locked, the money could not be spent without
re-entering the code. He said initially cash dispensers would be adapted to
give customers the choice between drawing physical or electronic money. But
the telephone would be the most important access point.
BT was planning to adapt its pay phones, and special phones for home use were
being designed. Customers would insert the card into the phone triggering an
automatic call to the bank's computer system. After a prompt, the customer
would tap in his personal identification number and transfer money from his
account to the card or vice-versa. "Our strategy is that in 10 to 15 years
time, we will see the phone as the dominant way in which electronic money is
drawn and deposited," Mr Jones said.
Derek Wanless, NatWest's chief executive, said: "Although Mondex will be
launched in the UK, it is a major commercial, opportunity for banks
everywhere. Mondex is a multi-currency product, capable of holding five
separate currencies on a card simultaneously." He said that other British and
foreign banks would be invited to join Mondex in due course to create a "truly
global payment scheme". The British Retail Consortium said that the
convenience, security, flexibility and potential for development should ensure
customer acceptance of Mondex. Its director general, James May, said: "If
successful, the Mondex trial should give UK shoppers a better way of paying,
and provide retailers with benefits in this first step towards a cashless
society."
The key to the card's security lies in the Japanese-developed technology and
microchip. NatWest and Midland said that a technical breakthrough had made it
impossible to counterfeit cards. But Mr Jones said that Mondex would have a
research budget "for ever" to keep ahead of the counterfeiters.
Notes From the Financial Sector of Cyberspace: How To Profit by Faking Out the Market. A good deal has been written lately on the ease, dangers, and risks of spoofing (or counterfeiting) mail on the net. Stories of practical jokes and character assassination abound. A similar but much more serious risk exists in financial information networks. My consulting work brings me in touch with some very large mutual fund companies. Many of them have extensive network infrastructure to support systems to quickly distribute news items from a variety of sources: Comtex, Dow-Jones, Standard&Poors, and others. The delivery end of these systems work like a cross between rn and a mail-reader: Story headlines are displayed (like mail "Subject:" lines), most recent to least, with the body of the news story available on demand. The headlines are constantly updated with fresh stories. The news service is used by a variety of people: traders, portfolio managers, commercial brokers, to name a few. Trading (sometimes very high-volume trading) is quickly initiated based on the incoming news. Often the body of the stories is never read; hot stories contain only a headline - if you take the time to read the story, you've lost some or all of your opportunity. The time-dependence of the incoming news is striking. The traders act immediately on the incoming information; their 'edge' is the timeliness of the news. It enables them to exploit short-lived opportunities. In that business, information goes stale and becomes useless very quickly, sometimes in a matter of minutes. The news source is trusted. Verifying stories is not a top priority. With the proper access to the hub machines and a little understanding, news stories can be faked. Just as email can be spoofed with the popular port 25 Unix hack, a story which didn't originate at a legitimate news source can be injected into the flow. Given that the news wire is the trader's primary window into the marketplace, one could create a phantom in that window, one with predictable effects: "Bill Gates Dies of Heart Attack"... (perhaps just prior to selling short on Microsoft). Now the risky part: my experience to date is that many of the hub machines, servers, and subnets involved are no more secure than any on the Internet, and in some cases much less so. Any Unix site administrator connected to the Internet should be shivering in his/her boots at this point... Tom Scoville - tscovill@xs.com
>From United Press International newswire via Executive News Service (GO ENS)
on Compuserve:
Study says database breaches costly and increasing, by Robb Stewart
TORONTO (UPI, 2 Dec 1993) - A Canadian study released Thursday says one
quarter of North American companies have suffered data base breaches, at a
cost of up to $1,000,000 per incident. The study by the Ernst and Young
financial consulting firm and Information Week magazine said the problem is
growing and that companies need to put greater emphasis on protecting their
computer systems."
Key points:
o 30% of losses caused by employees.
o Half of these criminals are greedy, the rest disgruntled.
o Organizations "must integrate system and date security into their basic
information technology strategies" to reduce fraud.
o 80% of all employees surveyed have access to computers.
o Additional problems are caused by hackers and by natural disasters.
o "...senior managers need to send a message to employees that this is a
serious issue," according to the author, John Kearns.
o The author emphasized the importance of employee awareness training,
security policies, and especially the example set by senior managers.
According to Kearns, "employees react to the attitude of senior
managers, leaving PCs on, or leaving documents on their desk or
sharing their password."
<
Risks of being a programmer
Jon Jacky <jon@violin1.radonc.washington.edu>
Mon, 13 Dec 1993 10:36:51 -0800
In this Sunday's NEW YORK TIMES (Dec. 12, 1993) the cover story on the
business section is about Apple's Newton handheld computer project:
MARKETER'S DREAM, ENGINEER'S NIGHTMARE
Apple's chief promised too much on the Newton, and the design team
paid a heavy price. by John Markoff
... The pressure to finish, exhilarating at first, eventually overwhelmed some
of the young designers. After 18-hour days, some engineers went home and
cried. Some quit. One had a breakdown and ended up in jail. One took a
pistol and killed himself.
(The story provides more detail on each of these.)
- Jon Jacky, University of Washington, jon@radonc.washington.edu
The risk of distributed servers with only partial uninterruptible power
"Bob Cunningham" <bob@kahala.soest.hawaii.edu>
Fri, 10 Dec 93 07:08:48 HST
Earlier this year in the School of Ocean & Earth Science & Technology at the
University of Hawaii we replaced our large centralized NFS servers (all in one
building with a large-capacity uninterruptible power system) with small,
distributed mini-servers on each subnet in each building.
This noticeably improved NFS performance, did away with a substantial amount
inter-subnet network traffic, and reduced traffic significantly on the subnet
the centralized servers were previously on. Economical, too, since the small
servers were cheap. We didn't even bother to install UPS systems for the new
mini-servers, though we did put the small server that replaced the large one
in the original building on the old UPS. Which seemed like a good idea at the
time...
Of course most of the services were duplicated on all servers and we crafted
the NFS maps such that systems within a particular building mounted from their
in-building NFS server if possible, but could use a server in another building
if their local server was down.
Everything worked well until we had a series of power outages last week.
After each outage, more and more individual computers would lock onto the
small server in the original building (alway ups, thanks to its UPS) in
preference to their local mini-server (with no UPS, those went down--and
typically were slower to reboot than their former clients).
NFS mounts are remarkably tenacious. We finally had to shut down the
UPS-protected mini-server for several hours and reboot a variety of systems in
several buildings to relieve the single overloaded server.
Risks of inband communication triggering call forwarding
Simson L. Garfinkel <simsong@next.cambridge.ma.us>
Sat, 11 Dec 93 11:32:42 -0500
Fascinating article in the November 1993 issue of MIT Information Systems
journal. "When Call Forwarding Goes Awry."
"Have you ever heard from people who tried to dial you directly at your MIT
number, but got the MIT operator instead? Or the operator at the Whitehead
Institute? Or someone with no connection with your department?"
Turns out that, at MIT, you can initiate a call-forwarding command by dialing
78-
Mail forwarding as easy as Call forwarding
<kiser@tecnet1.jcte.jcs.mil>
Tue, 7 Dec 93 23:56:53 EST
After a recent move, I decided to fill out a change-of-address form at the US
Post Office to have my mail forwarded for me as my personal name, me as my
sole proprietorship, both of the names of the little informal "businesses" I
and each of two friends have formed (to be on better terms with larger
companies), and, since each of my friends occasionally sends mail from our
hobby/ventures to my place, for them as well (for a grand total of five
forwarding orders).
I expected the large number of forwarding orders to be questioned; it wasn't.
And I was not pleased to learn that just anyone can walk in and fill out one
of these things for me. How did I come do that conclusion? I was not asked
for any ID at all. Finally, when I asked if it "was ok" for me to fill out a
change of address for someone else (i.e., the ones with my friends' names on
them and my signature ;-<), the mail clerk responded "as long as they don't
mind."
Has anyone ever tried to have 1600 PENNSYLVANIA AVENUE forwarded?
Re: Massive credit card fraud (RISKS-15.32)
Pete Mellor <pm@csr.city.ac.uk>
Mon, 13 Dec 93 19:22:37 GMT
"Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> writes:
> o Thieves monitor external mailboxes on homes for weeks in wealthy
> neighbourhoods to steal credit cards and new cheques arriving in the
> mail.
A minor point here is that the theft requires the existence of *external*
mailboxes, which are virtually unknown in the UK. (The only reason that UK
e-mailers understand the "Mailbox" icon on the Sun windows interface is
because they've read Li'l Abner! :-)
All "letterboxes" in the UK are slots in the front door with metal hinged
flaps over them. The mail drops down inside and lands on the doormat.
(One exception to this is that blocks of flats *sometimes* have downstairs
mailboxes for all occupants, but these are usually opened only by the owner's
key, and are usually in an internal foyer, with at least some protection from
casual theft. I live in a high-rise block of flats, and the postman delivers
mail to each individual flat.)
Risks here? Well, some terrorist or vandal could drop something nasty through
it. (I will leave it to readers' imaginations what sort of "nasty" this could
be!) Alternatively, the family dog could rip the mail to shreds. (This is a
surprisingly common habit of dogs in the UK. I remember that the letterbox
in my childhood home was backed by an internal mailbox to stop our otherwise
sweet-tempered black labrador from doing just that.) Otherwise, the only
problem is that delivery boys and postmen do not push the stuff right through
the slot, so that a wedge of protruding paper advertises to the passing
burglar that there is no-one at home, as well as leaving the mail itself
once more vulnerable.
Given that the two problems above can be solved by simple devices or by
training (of dogs and delivery boys!) there is a possible low-tech solution
to high-tech crime (or aren't US postmen allowed to walk up garden paths? :-)
Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq., London EC1V 0HB Tel: +44 (71) 477-8422, p.mellor@csr.city.ac.uk
Apple has poked around on your hard disk before
Grady Ward <grady@netcom.com>
Wed, 8 Dec 1993 09:32:47 -0800
Saul Tannenbaum in RISKS-15.32 explains how an uninvited software applet can
unintentionally cause RISK to a user of certain Apple distribution software.
This is not the first time that Apple software has violated the usual
distinction between user hard disk data and its corporate interest.
In 1991 as part of their developer's CDROM, an Apple application automatically
gathered information about your Macintosh system configuration, names of
Inits, Cdevs, and Extensions (applets associated with the operating system and
generally available to all applications).
Without assuring proper authorization, it then automagically e-mailed the
information in real-time to Apple developer support. The RISK here is obvious:
particular system configurations, code names of applications and system
applets, and other gathered information could be used for significant
competitive intelligence: knowing that the name of an application under
development is, for example, NewApp version 1.0b32 gives a significant clue
that the NewApp software is almost ready to go to market; knowing that a
developer has installed a driver for a unique piece of hardware might very
well tip off Apple that a new software product using that hardware is
imminent.
Subsequent issues of the Developer's CDROM with he offending Hypercard stack
were changed to make more explicit the default behavior of the
intelligence-gathering trojan.
The RISK moral? A company has to give thought on how to obtain proper,
informed authorization before a customer's privacy is invaded. :w
Re: Corrupted Polling, Inside Risks, Comm. ACM
<Brian.Randell@newcastle.ac.uk>
Fri, 10 Dec 1993 09:58:31 GMT
Quoting Rebecca Mercuri, Corrupted Polling, Inside Risks, Comm. ACM,
vol 36, no 11, November 1993, p. 122.
>Technology alone does not eliminate the possibility of corruption and
>incompetence in elections; it merely changes the platform on which they may
>occur. The voters and the Election Boards who serve them must be made aware
>of the risks of adopting electronic vote-tallying systems, insisting that
>the checks and balances inherent to our democracy be maintained.
This comment reminds me of a fascinating book I read some years ago:
R.S. Brumbaugh. Ancient Greek gadgets and machines, New York, Crowell,
1966. (Reprinted 1975 by Greenwood Press, Westport, Conn.)
From memory, the author is a Professor of Classics, and puts forward the
thesis that the Ancient Greeks tended to trust gadgets, i.e., physical
devices, more than each other. He explains that this is why they devised and
used, for example, means of trying to ensure that voting was carried out
fairly, and that speeches were of equal length.
(Unfortunately the book is not readily available to me, otherwise I'd quote
chapter and verse.)
[I think we are ready for Linux Polling. PGN]
Re: Digital Woes
Harry Erwin <erwin@trwacs.fp.trw.com>
Wed, 8 Dec 93 15:11:58 EST
I just started this book, and it caused me to open my desk drawer where I had
an old memo. This is a certificate of commendation for my participation and
support on the BMDSTP Software Project during 1972-1979. If I may quote Jack
Distaso:
Because of the expertise and dedication provided by the individuals who
contributed to this project, STP established a record of outstanding
performances which culminated with the complete success of the key
demonstration mission for the Army. All milestones were completed on time,
the software met 100 percent of its performance objectives, and the project
generated a substantial cost underrun on our incentive contract.'
My question is: why does this record remain nearly unique? My experience on
the project seemed to show that software management was proactive and
thorough. Since that time, I've never seen its like. The people on the
project, while typically good-quality, were no better (for the most part) than
many I've met since. What made the difference?
Harry Erwin herwin@cs.gmu.edu or erwin@trwacs.fp.trw.com
COMPASS '94 Call for Papers and Call for Tutorials
JOHN MARCINIAK <marcinik@smtplink.cta.com>
Fri, 03 Dec 93 16:20:24 EDT
CALL FOR PAPERS, COMPASS '94
9th Annual IEEE Conference June 27-30, 1994
on COMPuter ASSurance Gaithersburg, MD
The purpose of this conference is to bring together researchers, developers,
and evaluators who work on problems related to specifying, building, and
certifying high-assurance computer systems. What distinguishes COMPASS from
similar conferences is its emphasis on bridging the gap between research and
practice. Researchers are provided an opportunity to present results, new
theories, and new technologies to both other researchers and practitioners who
can put them to practice. They can also learn from practitioners of new
research problem domains and of problems encountered in building real systems.
Practitioners have an opportunity to share lessons learned, to learn of new
research, and to influence future research.
Papers should present advances in the theory, design, implementation,
evaluation, or application of high-assurance systems, or report on
experiments, evaluations, and open problems in the use of new technologies for
computer assurance. Special consideration will be given to presentations
(either single papers or paper pairs) by practitioners and researchers who
have worked on the same problem. There will also be a tools fair. Papers,
panel session proposals, tutorial proposals, and tools fair proposals are
solicited in the following areas:
Software Reliability Software Safety Computer Security
Formal Methods Tools Process Models
Real-Time Systems Networks Embedded Systems
V&V Practices Certification Standards
INSTRUCTIONS TO AUTHORS:
Send five copies of your paper, panel session proposal, tutorial proposal, or
tools fair proposal to John McLean, Program Chair, at the address given below.
Abstracts, electronic submissions, late submissions, and papers that cannot be
published in the proceedings will not be accepted. Papers submitted from
outside North America should be sent via overnight courier service.
Papers must be received by January 15, 1994 and must not exceed 7500 words.
Authors are responsible for obtaining prior to acceptance any and all
necessary clearances for publication. Authors will be notified of acceptance
by March 11, 1994. Camera-ready copies are due not later than April 22, 1994.
Papers that use technology presented at a previous COMPASS conference are
eligible for a special award. Papers of exceptional quality and appropriate
subject matter are eligible for inclusion in a special issue of the Journal of
High Integrity Systems or the Journal of Computer Security.
Limited financial assistance will be available for student authors.
PROGRAM COMMITTEE
Paul Ammann, George Mason Univ; John Marciniak, CTA; George Dinolt,
Loral; John McDermid, York Univ; Jan Filsinger, Booz-Allen Hamilton
Jon Millen, Mitre; Virgil Gligor, Univ. of Maryland; John McHugh,
Portland State U; Li Gong, SRI; David Parnas, McMaster Univ. Connie
Heitmeyer, Naval Res. Lab; John Rushby, SRI; Jeremy Jacob, York
Univ; Ravi Sandhu, George Mason Univ.; Carl Landwehr, Naval Res.
Lab; Jeannette Wing, CMU; Teresa Lunt, SRI
FOR FURTHER INFORMATION CONCERNING THE SYMPOSIUM, CONTACT:
Jan Filsinger, General Co-Chair John McLean, Program Chair
Booz-Allen Hamilton, Inc Naval Research Laboratory
8283 Greensboro Dr. Code 5543
McLean, VA 22102 Washington, DC 20375
Tel: (703) 902-5302 Tel: (202)767-3852
Fax: (703) 902-3131 Fax: (202) 404-7942
filsing@itd.nrl.navy.mil mclean@itd.nrl.navy.mil
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The COMPASS '94 Program Committee solicits your interest in presenting a
tutorial at COMPASS '94.
The committee solicits tutorials that are pertinent to the goals of the
conference and of interest to the attendees. We anticipate a full day of
tutorials, the 27th of June 1994. This year we will offer an honorarium for
the tutorial presentations.
Please submit your request to include the following information:
1. Topic and specific focus of the material
2. Length (1/2 and full day tutorials will be considered)
3. Name and background and experience in the area
4. Detailed topical outline
Selection will be made based on the appropriateness of the topic, the
credentials of the presenter and the quality of the outline.
Schedule considerations:
Tutorials submissions: by 15 January, 1994
Response: by 1 February, 1994
Tutorial materials required: by 1 May 1994 *
Send requests to: John Marciniak, CTA, Inc., 6116 Executive Blvd
Rockville, MD 20852
301-816-1439 Fax: 816-1416 marcinik@smtplink.cta.com
* Tutorial materials will be required prior to the conference and
will be subject to quality control procedures.
Please report problems with the web pages to the maintainer
x
Top