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…
Ten days after hearing that she had received a 2:1 degree (the second-highest grade available), a University of Edinburgh student (Jennifer McLellan) was told that the degree result was wrongly calculated and that she had actually received a 2:2 (the third-highest grade available). This caused her to lose a job offer and have her plans for the future thrown into considerable disarray.
According to *The Daily Telegraph* (23 Jul 1998, page 1), a total of four students were originally given the wrong degree classification, a mistake the University attributed to "an error made in transferring degree marks to a computer spreadsheet". It is yet known whether this was caused by human error.
Bruce J. McAdam, Postgraduate Student, The Department of Computer Science, The University of EdinburghThe Senate voted 90-10 Thursday to ban Internet gambling, extending the existing federal prohibitions on interstate gambling via telephone or wire. A companion bill is moving through the House. Approximately 140 Web sites offer gambling, and more than $600 million was wagered online last year on sports alone, according to the Justice Department. Sponsoring Senator Jon Kyl (R-Ariz.) says without the ban, the revenues could balloon to $10 billion in the next couple of years. "If we don't stop this activity now, the money that is generated by this kind of illegal activity is going to... become so influential in our political process that we will never get it stopped." The legislation would exempt "fantasy" or rotisserie sports leagues, in which participants bid on rosters of professional athletes to create "fantasy" teams, and money is exchanged based on the players' statistics. (*Los Angeles Times*, 24 Jul 1998; Edupage, 26 July 1998)
IBM de Mexico, the Mexican unit of the International Business Corporation, will pay Mexico City $37.5 million in cash and products to resolve a dispute over a failed database system. Three IBM executives face trial on charges of a conspiracy to defraud the city, which had purchased the system without competitive bidding in 1996. An IBM executive says, "In any complex systems-integration project, technical issues will arise, and we've always been 100% committed to resolving them... This civil agreement allows us to continue to work together with this customer." The rules of commerce have changed markedly since opposition parties began to gain power and challenge the corruption that had often been a normal part of doing business. (*The New York Times*, 24 Jul 1998; Edupage, 26 July 1998)
PacBell suffered a multi-hour failure of its phone mail system for subscribers in California yesterday (Saturday, 25 July 1998).
I've gotten two accounts of the problem. Last night, when the outage was still on-going (and affected subscribers in my area), the people answering the PacBell service number stated the outage was "statewide" and due to "a cable cut." Today's SF Examiner reports that the outage was localized to the Bay Area and due to a failed software upgrade.
Craig Partridge craig@aland.bbn.com or craig@bbn.comI've discovered an interesting problem with bank teller machines. At least with my BankBoston ATM card, only the first four digits of the personal identification number are relevant. I have a five-digit PIN, and I've tried typing just the first four, and I've also tried the first four plus an incorrect fifth digit. In both cases, the machine was more than happy to fork over money. I've tried it in BankBoston and USTrust ATM's.
The Yorktown problems are particularly worrying because they're very reminiscent of problems the British navy suffered a hundred years or so ago.
In the second half of the 19th century, continuing into the first world war, the British navy became extremely dependent on extremely elaborate flag signalling, with a resulting centralisation of command in the flagship, and increasing unwillingness and inability of individual ships' commanders to display initiative.
The signalling system made possible elaborate & impressive peacetime maneuvers, but was liable to failure under battle conditions where smoke could obscure signals, and the whole signalling system — including the human parts of it — operating on the exposed bridge of the ship was extremely vulnerable.
Because officers were trained to obey signals regardless, and not to act without them, a failure in the signalling technology could be very severe. There are (perhaps contentious) examples of this at Jutland in 1916 where the failure to send, receive, or correctly interpret signals, and the failure to act on initiative were noticeable problems for the British.
The technology is different, but the reliance on a particular technology, with no apparent backup, seems to be the same. If a warship uses a computer system for its essential functioning that should be backed up by alternative systems, including manual ones. People need to be trained in the use of those backup systems and willing to use them. They also need to be willing to decide that the computer system is wrong and override it even when it is functioning.
Tim Bradshaw, System Manager, Artificial Intelligence Applications Institute, University of EdinburghThereby hangs a tale.
The "Smart Ship" initiative being piloted aboard the Yorktown is only part of a general migration to NT; US naval bases are currently piloting "Smart Base". The aim is to put in place a seamless service-wide operating environment. (Source: *Government Computer News*, 20 Apr 1998).
This is in line with the current issue of the US Navy's Information Technology Standards Guidance (ITSG), approved in May 1998, which describes NT as "the de facto standard client-server computing technology". The ITSG endorses NT 4.0 as the standard OS for networks and standalone PCs; factors in its favour include functionality, performance and the C2 security rating of NT 3.5. (Source: *Government Computer News*, 29 Jun 1998. And yes, I realise the part about NT 3.5 doesn't follow).
This itself follows from the "IT-21" strategy put forward a year earlier. This was summed up by its chief advocate, Admiral Archie Clemins, in the following seven principles:
(Source: *US Naval Institute Proceedings*, May 1997. There is a cogently sceptical discussion of Clemins' proposals (with the wonderful title "Beware of Geeks bearing Gifts") in the April 1998 issue).
In practical terms, Clemins has stated, this means migrating as much as possible from Unix to NT. (Source: *Federal Computer Week*, 14 Apr 1997)
To sum up: the Yorktown debacle is IT-21 in action - or, to be scrupulously fair, in pilot.
Interestingly, the US Navy's system integration problem reported by Jim Horning in RISKS-19.86 also has an IT-21 element. Quoting from the original story (from *Wired News*, 16 Jul 1998):
The problem is with neither individual system, but rather with the way they interoperate, or work with one another. The problem is compounded by the a new Commercial Off-The-Shelf (COTS) display system also running aboard the vessels. A Navy official said that COTS is more challenging than expected — although the Navy has the license to use the COTS software, they don't have access to its source code. Such code would allows the specialists to "get under the hood" of the software and might help them identify the conflicts.
'COTS', as we've seen, translates as 'market-leading commercial software, as used by VPs of civilian businesses, running on NT'. Unfortunately the acronym seems to have baffled the Wired reporter - "COTS is more challenging than expected" is a story in itself.
Risks? I'll fall back on British understatement and say that there is a distinct chance that software and hardware which is
may not perform consistently to military specifications.
PhilOn the plane back from Europe (Lufthansa appropriately enough), I sat next to a German engineer (actually, chemical and running a company, but that's beside the point) and asked him about the train crash. He said that the wheel had been off the tracks for 5km and the magnitude of the problem was due to having a switch track just before a bridge. Similar accidents had occurred in France but in less damaging locations. The solution is to track the behavior of the wheel (or the proximity to the track) with sensors to discover the problem early. This sounds even better than periodically checking the wheel since it will catch the actual problem as soon as it occurs even if there were a separate cause for a wheel problem.
A ten-day-long test by the Securities Industry Association's Year 2000 project found no problems during a simulation involving 29 brokerage firms, all major stock exchanges, and the corporations that conduct trades for them. Project manager Leslie Tortora hopes that the success of the project will encourage a similar effort by telephone companies, and says: "People are feeling good. An enormous amount of energy and preparation has gone into making this successful." (*The New York Times*, 23 Jul 1998; Edupage, 23 July 1998)
I just heard on the radio that all UK insurance companies have decided not to pay out any household claims arising from y2k issues affecting household items. Considering a lot of people own TV, Video, Hi-Fi all of which have date sensitive internals it seems as though a lot of people may be out of pocket come 1/1/2000. I'm not an expert on the internal systems of household appliances, but I would have thought particularly videos will encounter problems due to their reliance on clocks for recording programs. There is also an increasing trend towards integrating TV/Video functions and on screen menu functions rather than the older analogue (Y2K compliant!) switches.
The risks? Integrating date dependent functions (video programming) with other things (tuning via menu systems) just to get it all on the same remote control. Also a risk is expecting companies / insurance agents to honour claims for "malfunctioning" equipment.
Jonathan Pritchard, Lucent TechnologiesRob Bailey in RISKS-19.88 adds hard data to Frankston's observation that preparations are not being made to handle unexpected problems on 00-01-01. (Apparently, what few bureaucrats admit the problem are not willing to say it can't be completely solved in advance.)
My counter-argument (to the bureaucrats, not my esteemed fellow Risks-contributors) is as follows:
No release of a new version of software has ever gone completely smoothly. Even if no new internal bugs are introduced (ha!), unexpected external conflicts will arise (incompatibility with other software, incorrect user responses to interface changes, etc.)
The more changes are made (between previous versions & a new release), no matter how small, the more unexpected problems there will be, and the harder they will be to find.
(These are from experiences at a critical site running 24/7. After too many call-outs on weekends to fix bugs in new releases, we implemented a policy that production releases ready after twelve noon on Thursday must be delayed until the following Monday.)
00-01-01:00:00 will be the equivalent of the world's biggest release of new software in history. *Every piece of code* will be run for the first time under real-world y2k conditions *simultaneously*.
Even if every application tested perfectly individually under y2k conditions (ha!), unexpected slight changes of operation would cause major, perhaps massive, disruption.
The solution? Continue finding and fixing as many y2k problems as possible, but be sure to have extra (massive?) support available on 00-01-01:00:00 to fix critical problems.
Joe Bednorz <jbednorz@mindspring.com>BKPRMDIN.RVW 980508
"Personal Medical Information", Ross Anderson, 1997, 3-540-63244-1, U$45.00
%E Ross Anderson ross.anderson@cl.cam.ac.uk
%C 175 Fifth Ave., New York, NY 10010
%D 1997
%G 3-540-63244-1
%I Springer-Verlag
%O U$45.00 800-777-4643 fax: 201-348-4505 wborden@springer-ny.com
%P 250 p.
%T "Personal Medical Information: Security, Engineering, and Ethics"
The papers contained in this work were presented at a conference held in Cambridge, UK, in June of 1996. Those attending were from medical, legal, activist, legislative, and data security backgrounds. Most of the material comes from the UK and German experience.
The first paper examines the purpose and ownership of medical information: does the data belong to the patient or the NHS (National Health Service) and what implications does ownership have on policy regarding health information. This question is complicated by the requirement for aggregated details in order to provide the proper quality of service. In Germany, a "smart" card is being developed for patient information and billing purposes and the debate and various options for the card is described in the second essay. Chapter three looks generically (and in rather jargon laden manner) at the distinctives of medical information systems. During rationalization of the medical information systems of the German Democratic Republic (GDR, East Germany) and the Federal Republic of Germany (West Germany) the value of a central repository for cancer information was noted, along with the danger of invasion of privacy in such consolidated systems. The possibility of a distributed information system in which patient information is held locally, but made available for non- identifying epidemiological research is discussed in paper four. The review of the use of information systems by general practitioners, in chapter five, is general and anecdotal, rather than analytical.
The British Medical Association (BMA) has produced a policy paper on the security and confidentiality of patient information. The sixth essay takes issue with aspects of the BMA paper with particular respect to acute care. Implementation of the policy in a multipractitioner practice in Yorkshire is noted in chapter seven. The BMA policy is used as a case study for medical ethics analysis in chapter eleven. Chapter twenty closes off the book with an update on the policy.
Paper number eight is a somewhat simplistic view of a confidential patient information architecture modeled on an ideal patient ward. Unfortunately, it fails to account not only for real world situations, but also for many important uses of medical information. Although titularly involved with risk assessment, chapter nine is essentially a statement of medical ethics in opposition to the surveillance of patients used by for-profit managed care operations. With the introduction of information technologies, wholesale modification of institutions and systems is being undertaken, often with untoward consequences. The aim of essay ten is to propose a model for re-engineering that makes responsibility central to the enterprise in order to avoid confidentiality problems. While the many see patient information as primarily business related, chapter twelve looks at the needs for data as a resource for research and treatment. Electronic commerce tools are used to ensure confidentiality of patient information transfer in paper thirteen. Similarly, public key encryption is examined for the establishment of confidential auditing of medical payments in essay fourteen. Chapter fifteen is a very brief case study of the use of smart cards for medical data. The philosophical review of medical ethics in chapter sixteen has only tenuous connections to technology. Only an abstract is included for presentation seventeen. Chapter eighteen is a review of privacy policy in the United States. Nineteen is a case study from New Zealand.
While the quality of the papers is uneven, the variety of viewpoints is extremely valuable. Although there is a significant bias in favour of patient confidentiality, some of the needs for sharing of information are at least raised.
copyright © Robert M. Slade, 1998 BKPRMDIN.RVW 980508
BKWNTSEC.RVW 980510
"Windows NT Security", Charles B. Rutstein, 1997, 0-07-057833-8, U$34.95
%A Charles B. Rutstein
%C 300 Water Street, Whitby, Ontario L1N 9B6
%D 1997
%G 0-07-057833-8
%I McGraw-Hill Ryerson/Osborne
%O U$34.95 800-565-5758 fax: 905-430-5020 louisea@McGrawHill.ca
%P 332 p.
%T "Windows NT Security"
Windows NT provides a number of tools and functions for securing the system and workstation. Security is also going to mean different things to different people and work environments. This book will help users and new administrators make the system more secure, but there is much ground left uncovered.
Chapter one is a basic overview of the NT security architecture. There are some, but relatively few, specifics. The material also tends to give Microsoft the benefit of the doubt in a number of areas. For example, the fact that the source code for NT is not available is held in many quarters to be a potential security risk, since the system cannot be fully examined. While nobody can deny Microsoft's right to withhold the source for business reasons, the author dismisses this security argument as "completely without merit." The User Manager application is covered in chapter two. While all functions are mentioned, not all implications are fully explained. While implying that it is the case, the author stops short of stating that if access rights are denied by one control they will not be granted because of others. Coverage of file and file system security, in chapter three, is not very clear. The material on viruses is technically sound, but not necessarily immediately helpful. Event logs are discussed briefly in chapter four but probably deserve more space. Chapter five not only looks at the Registry itself, but lists a number of keys to be set. Again, the brief discussions do not provide full information on the implications of these choices. Although all the topics in chapter six do have to do with network security, they are otherwise rather randomly grouped. Not all the sections even have to do with NT. Also, there is, again, some not altogether justified promotion of Microsoft, and some questionable recommendations. (The suggestion to rename the administrator account is fairly standard, but the renamed account may still be vulnerable to attack because of identification of the security ID.) Chapter seven looks at RAID (Redundant Array of Inexpensive Disks) and UPS (Uninterruptible Power Supplies) and it is surprising that it doesn't mention backups. Remote Access Service (RAS) is reviewed in chapter eight, but while recommendations are made the full significance of the advice is not given. Generic advice on Internet service provision is given in chapter nine. Not all of the guidance makes a lot of sense, such as the discussion of passwords in regard to anonymous ftp accounts.
The book does cover a lot more security ground than most general NT administration texts. Some convoluted areas of NT security are explored to a certain extent, and there are a number of helpful pieces of information. Security, however, is a complex undertaking, and requires a more thorough and rigorous background understanding than this book provides.
copyright © Robert M. Slade, 1998 BKWNTSEC.RVW 980510
Boy, did that [the above review] ever open a can of worms! I cannot recall any review that has generated this much response, this fast.
Sorry to those who did not get a personal response, and thanks to the majority of you for your kind words about the reviews, but there were just too many of you, mostly asking the same question. Almost all of you wanted to know of an NT security book that I could recommend.
Well, I am sorry to disappoint you, but *I'd* like to know of an NT security book that I could recommend. I haven't found one yet. (For those incipient authors who are experts in the field, and have about a year to give to the task, there is an apparent market niche.)
The reason for this lack may lie in a number of areas. As one correspondent implied, many think that "NT security" is an oxymoron. I note that while there are a variety of NT security resources out there, and there have been a few attempts to start one, there is no really good NT security FAQ available yet. There are a number of sites with exploit information, and there is one vendor that tries to sell you an NT security file, but the closest I've seen to a good FAQ was a recent "top ten" list of things to do to make NT marginally more secure than it is when it ships.
I suspect that part of the problem lies in the design of NT itself, which does not make security provisions straightforward to implement, but it may also be simply bad luck in the selection of authors who have attempted to address the issue so far. Of the number of NT security books I've reviewed to date, I still haven't found a definitely good one, let alone anything to the standard of Spafford and Garfinkel.
Just to reiterate, here are the titles I've reviewed so far:
"PCWeek Microsoft Windows NT Security", Nevin Lambert/Manish Patel, 1997, 1-56276-457-8, U$39.99/C$56.95/UK#36.99 - good introductory or non-specialist guide, but there are holes
"Windows NT Security Guide", Stephen A. Sutton, 1997, 0-201-41969-6, U$29.95/C$41.00 - too vague for users, lacking detail for administrators
"Windows NT Security", Charles B. Rutstein, 1997, 0-07-057833-8, U$34.95 - reasonable range, but has gaps and lacks analysis
Normally, if I were recommending texts on security in the UNIX field, I would also include works on system administration. However, in the NT arena, while some admin authors have tried to cover the topic it is just too big to handle as a subsection of a larger work.
rslade@sprint.ca rslade@vcn.bc.ca robertslade@usa.netFor back issues:
AV contacts : http://www.victoria.tc.ca/techrev/mnvr.html
list, reviews,: http://www.victoria.tc.ca/techrev/quickref.html
review FAQ and: http://www.victoria.tc.ca/techrev/avrevfaq.html
AV tutorial : http://www.victoria.tc.ca/techrev/mnvrcv.html
http://csrc.ncsl.nist.gov/virus/virrevws/
ftp://ftp.cs.ucr.edu/pub/virus-l/docs/reviews
Viral Morality: http://www.bethel.edu/Ideas/virethic.html
PC Security: http://www.victoria.tc.ca/techrev/mnvrrvsc.html
Book reviews: http://www.victoria.tc.ca/techrev/mnbk.html
http://www.victoria.tc.ca/techrev/review.html
http://www.webwaves.com/books/slade
ftp://x2ftp.oulu.fi/pub/books/slade
http://mag.mechnet.com/mne/books/reviews/slade/
gopher://gopher.technical.powells.portland.or.us:70
http://www.utexas.edu/computer/vcl/bkreviews.html
Please report problems with the web pages to the maintainer