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…
The front page of the *Yorkshire Evening Press* Web site (http://www.thisisyork.co.uk) is declaring today to be Wednesday, January 1 2002. The JavaScript on the page is: document.write(dayNames[day] + ", " + monthNames[month] + " " + date + ", 2002"); Happy *NEW* year! Dr Dave Stringer-Calvert, Assistant Director, Computer Science Laboratory SRI International, Menlo Park CA 94025-3493 1-650-859-3291
I would like to report an incident which made me feel dizzy at this otherwise tranquil days at the end of the year. In Japan, a national system to coordinate citizen's private information stored in government computer is being prepared amid vocal opposition from various parties. Basically, a single number, 11 decimal digits number is assigned to each individual and this will be used as the search key in accessing various data bases. (Some kind of mapping table would be prepared by local government agencies with this nationally unique number to access individual's record in local government databases .) There would be a nation-wide network where the key would be used as the primary key for accessing various databases scattered across the nation. The danger for abuse is obvious and the fear is so much that some cities and jurisdictions decided to challenge the national policy by declaring that they would not be online with the system, etc. when the final preparation for the full-scale deployment began this summer. (The city of Yokohama where I live decided to allow the citizen to decide if the personal number assigned to them would be delivered to the prefectural level data center or not unless sufficient assurance for protection is forthcoming from the national government. About 30% of the population asked the number not be sent, and this popular demand made national newspaper headlines : Yokohama has about 3 million population and is a big city in Japanese scale of things. Obviously the government agency which is pushing the national policy and the construction of the network has PR problems now. The risk is now huge since the diet (national parliament) failed to enact a privacy protection law which should have been prepared along with such a numbering system. Anyway, the national government has been trying to assure that the system would be safe with computer security protection, etc.. However, it has already been criticized for such mundane thing as slow anti-virus data update which would take place once a few months(!) [makes me wonder where on earth they have been living in the last few years.], which the government agency claims is not a serious threat since the network in question is not directly connected to Internet, etc.. But, of course, some town offices seem to use the same computer for internal LAN and accessing the national network in question. (There must be some form of physical switches in place, but we never know what happens. Murphy's law always strikes.) Probably the last straw which might break the pro-numbering support is the theft of backup magnetic tapes that happened in a town north east of Tokyo. There, five backup DAT tapes of the town office computer systems containing privacy data of approximately 9600 were stolen from a parked car of a computer maintenance service company. The tapes were on the way for off-site storage, and were in a metalic attache case. It seems that whoever stole the case mistook it for one containing money or some other valuables. (On the other hand, since the parking lot belongs to the computer maintenance company, we should not rule out that a serious cracker (or two?) stole the tapes to gain foothold into the national network.) The newspaper articles aren't clear what are on the tapes and in what form, but the city spokesman stated that the data did include the national numbers for the citizens and privacy data such as address, name, gender, birth date, qualification status for the various national health insurance plans, and pensions. The data is claimed to be in encrypted form (but no detail) and won't be easy to read according to the statement. However, given the risks, the city officials decided to ask the permission of each citizen to change the numbers assigned to them so that the numbers themselves won't be used for some malicious tampering in the future. (The law requires that the change of numbers needs the consent of the citizen.) Numbers aside, the rest of the information, if decrypted, would be the staggering source for privacy theft, etc. I can't say for sure but some say that backups were made using ARCserver backup software or something. I have no idea what type of cryptography it supports, but I surely hope the algorithm is a good one and the key length is long enough if ARCserver is indeed used for this national network. The tapes were stolen on 26th, and found scattered on a river bank on 30th. Three tapes were found outside the opened metallic case. The lock to the attache case was forced open. (So two of the DATs were still missing, it seems. Again the newspaper article that I read was not very clear on this point.) Using encryption for backup data is a common sense. But then I have no idea how the key for the encryption is managed and what type of algorithms are used in this particular case, and if I were the citizen of the town of Iwashiro, I would have been disturbed very much. One thing I don't like about this national network being built is the apparent lack of security policy. Since there is no clearly written national security policy, this type of problems, like the maintenance person leaving the valuable data tape in an attache case inside a car parked at company parking lot, may happen in the future. The way the network is built and the apparent lack of nation-wide security policy of this network force me to think that information leak caused by computers that are linked to the network and also have outside connection inside the town/city office LAN, which in turn, may have unexpected Internet link via somebody's modem, or even caused by simple eavesdropping via wireless LAN may happen not in the distant future. I hate to think that the government has to go through such incidents before learning the basic of security management. After writing this, I realize the above may look unbelievable to security consultants who read Risks today, but is true and is happening now in Japan. Only in the last few months, some government agencies learned the danger of wireless LAN: some drive-by inspection caught the contents of the unencrypted traffic easily. I hate to think about the mess caused by large-scale identity theft, etc.. This incident of stolen tapes wiped out the last trust I had in this national numbering system and I am no longer in the mood of festive holiday season.
TSA Documents' Protection Easily Circumvented
Several restricted U.S. Transportation Security Administration (TSA)
documents are accessible to anyone with an Internet connection. While
they are password protected within Microsoft Word, once they are
downloaded, they can be attacked with password cracking software at
the user's leisure.
[Source: reuters 24 Dec 2002, in SANS NewsBites, 30 Dec 2002, Vol 4 no 53]
http://reuters.com/newsArticle.jhtml?type=internetNews&storyID=1958544
So how risky is it to provide insecure "encryption", that misleads uses into
thinking that their documents are safe? It appears to be RISKy for the user,
to rely on such labelled "features" in the software they choose to use.
M Taylor http://www.mctaylor.com/
[Geoff Kuenning noted this quote in the article:
"We think it's safe," a spokesman said. "From our
standpoint it's very workable and secure."
PGN]
I have noticed a trend in the past 6 months of increasing numbers of
Web sites that will not work correctly with my browser. The most
common symptom is a blank page, presumably because some bit of
JavaScript failed to execute the way they assumed it would. (In one
case, I took the trouble to diagnose the failure and found that a null
URL was expected to load the referring page; replacing it with a
proper URL cured the problem.)
What amazes me is that most of these bugs are caused by unnecessary
use of new (i.e., not widespread) features, and that they cost
companies business. For example, this evening I tried to buy Kevin
Mitnick's book, as recommended by Don Norman in RISKS. Try as I
might, I could not get buy.com's site to allow me to enter an updated
credit-card number. I finally gave up, started the search over, and
purchased the book elsewhere.
One has to wonder how much business has been lost because gadget-loving
programmers are more fascinated with the latest features than with
compatibility.
Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
In reference to a Nigerian scam, "Sidney Markowitz" <sidney@sidney.com> says
that "It is common for check transactions to be held until the check clears,
to ensure that the check is good. Now we see that the time it takes for a
check to clear is determined by US law that sets a limit on how long a bank
can delay paying for a deposited check. But that limit does not make it any
faster for the bank to really determine if the check is good. The unintended
consequence of the law is that a cleared check may not be a cleared check."
Some years ago I once was in a situation where I wanted to be certain that a
check "was good" and "had cleared."
I had a lengthy discussion with a bank vice-president, and I understood him
to say that the clearinghouse system does not provide any way to ever know
for certain that any particular check has cleared. If a check FAILS to
clear, everyone finds out about it. But when a check clears successfully,
there is no traceable information about the transaction. He said that,
theoretically, there was no way to know that a particular check had cleared.
I was told that it "was safe to ASSUME" that if the check had not bounced
within two weeks, that it "must have cleared," but that there was no
positive guarantee and no way to check the status of any particular check.
Daniel P.B. Smith dpbsmith@world.std.com dpbsmith@alum.mit.edu
[Similar comments from Brian Reynolds ("This is not a new scam."), Tony
Lima, Ron Bean ("Could be a big risk for banks as well, given their
Clinton-esque definition of the word "cleared"). PGN]
I would strengthen Dorothy Denning's objections, for they redescribe terrorist surveillance as a "daunting task." Unfortunately this shares with the TIA the assumption that the task, of surveillance, is one that can be solved at all. The literary critic, and Palestinian moderate activist, Edward Said, has pointed out that the US State Department tends to hire people with easily measured skills in development economics to work on Mideast problems. He has contrasted this with the older practice of Britain's foreign and colonial desks, which was to hire literary dons who had specialized in topics such as Persian poetry. The most recent example of this mindset was the termination of several Arabic speakers at the Defense Language Institute because of their sexual orientation; for there is a linkage between hatred of "soft" skills and homophobia. There are drawbacks to both practices, but Said does point to a bias...in favor of the technological quick fix of which the Total Information Awareness program is an example. Furthermore, solid technical arguments lead one to conclude that the TIA will not work. First of all, Groove is a commercial software product, and, if my guess (that the TIA is in part a bit of a bailout for Bush's friends in the IT industry, suffering as it is in a depression), the design of the TIA will emphasise commercial and off-the-shelf solutions. The problem is that this MEANS that the ill-defined "enemy" can acquire the same software being used to surveille him, run it to detect what it, in turn, detects, then change his patterns. In a sense, a Turing machine (the Groove system running on TIA computers) is examining a social Turing machine (the bad guys and their copy of Groove) to see whether it will arrive at a "halt" state (an attack.) This Turing problem is independent of hardware and software. We can be certain that terrorists will no longer try to carry box cutters on board airplanes and overwhelm the passengers and crew in what seems a "conventional" hostage situation but what is a suicide attack, for such behavior will now be coded, by the passengers, as a suicide attack. Unfortunately, Professor Denning's objection, that it's a "daunting" task, can be met by the language of go-ahead problem-solving in which the person who says it's a "daunting" task is placed at a disadvantage, rhetorically. She makes it sound as if we're not up to it. Unfortunately, negative results (such as Turing's) stay true and are not disproved by technical progress, any more than perpetual motion becomes true. In algorithmic terms, a "computer" (the US defense establishment) is examining another "computer" (al-Qaeda) to find its halt state, and, to complicate matters, the examinee knows of the monitoring. Even if a data base existed with full optics and sound that replicated ALL activity in Eurasia alone, any one action could, or might not, be an encoding of terrorist intelligence and for this reason, interpretation would become the job of the same people who failed to bring in the "twentieth highjacker" for questioning. Our government would have to refute, at the level of basic science, Alonzo Church's thesis to the effect that all computers are Turing machines, and it would have to make or buy a Turing+n system that could defeat other Turing+0 systems. Nor can our government "scale up" for adding cycles doesn't change the math. The near-demise of supercomputing as big iron shows us that the bad guys can use networks in place of centralized big iron. Of course, this is the point at which truly rational men and women throw down their gear and advance across wastelands with ancient symbols of peace. This is the point at which Ronald Reagan, a quite ordinary man, abandoned the equivalent insanity of Mutual Assured Destruction and went to Reykjavik. However, what American politician has the courage to solve the Mideast problem by raising our gasoline taxes, and announcing that the US should be considered an alternate homeland for Jews worldwide (boy, that was easy)? The problem is that the United States is engaged (like it or not) in a dialogue with terrorists. If like Sharon in Israel and Cheney here, our statesmen play to the gallery, and "refuse" to "dialog" with "terrorists", they discover that violence becomes the language of choice. "Hackerz" already change the spelling of code words faster than they can be defeated by scanners. Unless the US develops (at considerable expense) a proprietary technology-of-surveillance which cannot be reverse engineered, the TIA is at best a boon doggle and at worst a replacement for a needed dialog.
Why not read the book? Because the author is a con artist and you are sending him $s? OK - so Don makes the point that: "I'm a student of human psychology... I read books by ex-criminals:... I learn a lot." Fair enough. If you are studying criminal behavior, reading books by crooks is probably a good idea. But if you want to know about cons, far better books are: "Flim-Flam" by James Randi "Scam School" by Chuck Whitlock and "Rip-Off" by Fay Faron All three are by legitimate researchers who present results taken from scores to hundreds of incidents and present how and why scams work, the techniques used, the different plots, and so forth. They present many excellent examples of how these sorts of crimes work, how they impact the victims, the psychology of the criminals, and so forth. > I learned a lot from ... I was impressed by his approaches. They > are not as simple and easy to do as a quick reading would make them > appear. After the fact, everything always looks obvious. But I, for > example, would find it difficult to even think of the schemes, let alone > carry them out successfully. One of the major problems we face in information protection is people who just don't think cleverly of bad things that could happen. It might serve Don well to take an introductory course in the subject matter. He will learn a lot more than from a book by a crook and he will be supporting defenders rather than attackers. Fred Cohen - http://all.net/ - fc@all.net - fc@unhca.com tel/fax: 925-454-0171 Fred Cohen & Associates - University of New Haven
BKSFTENG.RVW 20020916 "Software Engineering", Ian Sommerville, 2001, 0-201-39815-X, C$104.95 %A Ian Sommerville ian@software-engin.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2001 %G 0-201-39815-X %I Addison-Wesley Publishing Co. %O C$104.95 416-447-5101 fax: 416-443-0948 %O http://www.amazon.com/exec/obidos/ASIN/020139815X/robsladesinterne %P 693 p. %T "Software Engineering, Sixth Edition" Part one is an overview. Chapter one is an introduction, a FAQ (Frequently Asked Questions list), definitions, and, interestingly, a section on ethics. A broad review of system development concepts (such as emergent properties) is presented as computer based software engineering, in chapter two. Stages in the software development process, none detailed, are listed in chapter three. Project management is discussed in chapter four. Part two looks at software requirements. Chapter five examines different types of requirements. Requirements engineering is software engineering in miniature, as chapter six points out. There is a heavy emphasis on the Universal Modeling Language (UML) in chapter seven's explanation of system models. The benefits and dangers of software prototyping are examined in chapter eight. Chapter nine points out that formal specification does require special training on the part of users, but can identify problems in requirements specifications. (More extensive examples would be helpful in making this point more convincing.) Part three reviews design, and the chapters are mostly divided by system type. Chapter ten explains architectural design, and reviews tools and models. (Security, and other concerns, are addressed throughout the book: an example in this chapter points out that interrupt driven architectures are complex and difficult to validate.) Distributed systems architecture itself gets oddly short shrift in chapter eleven, which concentrates on client/server and CORBA (Common Object Request Broker Architecture). Object-oriented design is shown to be very much like modular design in chapter twelve. (The stated objective of the text is to introduce UML, but the explanations are not very clear.) Chapter thirteen looks at real-time software design but does not seem to be as complete as other topics. Design with code reuse is a good overview, but chapter fourteen starts out with the statement that electrical and mechanical engineers rely on component reuse, ignoring the lack of a broad range of standard components in the software environment. There are good, basic suggestions for user interface design, in chapter fifteen, although the discussion is limited. For example, the recommended principles suggest confirmation of destructive actions, but don't note the fact that even such confirmations become automatic over time, and therefore are not particularly useful. Part four deals with critical systems. Chapter sixteen looks at dependability in terms of availability, reliability, safety, and security. Critical systems specification, in chapter seventeen, examines dependability (and failure) metrics. Risk analysis is discussed, but not in the usual combination of probability and severity. Critical systems development is examined both in terms of fault avoidance and fault tolerance in chapter eighteen. Part five covers verification and validation. Chapter nineteen concentrates on code inspection and the Cleanroom process. Software testing, in chapter twenty, looks at types, cases, and procedures. Critical systems validation, in chapter twenty one, is basically the same process as the previous chapter, but more important. Part six, on management, is mostly a precis or list of principles from other sections. Chapter twenty two deals with managing people, looking at limits, motivation, group dynamics, recruiting, and keeping, as well as a quick overview of the People Capability Maturity Model (P-CMM). It's not a large section, but it is nice to see the importance of personnel recognized in this way. Software cost estimating, in chapter twenty three, is interesting, but possibly not terribly useful. Quality management is dealt with in chapter twenty four. Chapter twenty five reviews process improvement and the Capability Maturity Model (CMM), mentioning the work of Walter Deming but not, intriguingly, dealing with the fact that Deming's later work suggested that business had gone overboard in the pursuit of quality. Part seven deals with evolution and change. Chapter twenty six discusses legacy systems with a description of mainframe program structures and guidelines for the assessment of the possibilities for updating the system. Software change is reviewed in chapter twenty seven, with maintenance and re-architecting leading to a description of re-engineering in chapter twenty eight. Chapter twenty nine finishes off with configuration management, emphasizing version documentation more than change control. The book is written as a textbook, with a summary of key points and a very decent set of exercises at the end of every chapter. It certainly stands above the other systems development texts that I have experienced. However, this work also has value beyond the classroom. A great many professionals, such as information security officers, need to know the operations, procedures and concepts of software engineering without necessarily being programmers themselves. For these people, this volume makes a clear and excellent reference. copyright Robert M. Slade, 2002 BKSFTENG.RVW 20020916 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
BKTRCMPL.RVW 20020916 "Trusted Computing Platforms", Siani Pearson, 2003, 0-13-009220-7, U$49.99/C$77.99 %E Siani Pearson %C One Lake St., Upper Saddle River, NJ 07458 %D 2003 %G 0-13-009220-7 %I Prentice Hall %O U$49.99/C$77.99 +1-201-236-7139 fax: +1-201-236-7131 %O http://www.amazon.com/exec/obidos/ASIN/0130092207/robsladesinterne %P 322 p. %T "Trusted Computing Platforms: TCPA Technology in Context" Part one introduces trusted platform technology, as a kind of public key infrastructure implemented in hardware. (Which begs the question: what do you do about key revocation?) Chapter one, an overview of the trusted computing platform concept, is not very clear on basic ideas beyond hardware implementation involvement and the notion of measurement, or assurance. There are usage scenarios of applications that can be done, or done better, with trusted platforms, in chapter two. Not all of these cases are convincing evidence that trusted platforms are better. The cryptographic underpinnings of trusted platforms are examined in chapter three, but it would be clearer if the basics of asymmetric cryptography were covered and standard cryptographic and certificate authority terms were used. Part two concerns trust mechanisms in a trusted platform, but is basically a list of commands. Chapter four deals with access control, to do with physical presence requirements, ownership, and authorization. Platform identification and endorsement is covered in chapter five. Chapter six discusses integrity recording, reporting, and secure boot. Protected storage of keys is in chapter seven, migration and maintenance methods in chapter eight, and other assorted functions in chapter nine. Part three reviews trusted platforms in practice and operation. Chapter ten describes the setup of a new trusted platform, chapter eleven deals with what would elsewhere be known as trust relationships, and challenging a trusted platform--authentication of a server--is in chapter twelve. Part four presents the benefits of trusted platforms, first to organizations and corporations, in chapter thirteen, and then to individuals and users, in chapter fourteen. This book is not clear, either about what TCPA (Trusted Computing Platform Alliance) technology is, nor how it can effectively be used. Although the authors occasionally admit that there may be problems with the system, there seems to be a kind of background arrogance in operation, that assumes everyone will have to use this technology, so they might was well learn the commands. copyright Robert M. Slade, 2002 BKTRCMPL.RVW 20020916 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer