It is not mentioned directly, but this $500 million dollar computer system owned by the Ontario government is incapable of adjusting the social assistance rates. Recipients will be receiving two lump sum payments, one this summer and one in the fall, to make up the 3% increase that the government has decided on. How can a computer system cost $500,000,000? Just how can training by itself consume hundreds of millions of dollars? Why if a program cost $500,000,000 to produce does it not work? [I guess you have not followed the IRS and FAA modernization fiascos, each over $4 Billion, discussed in RISKS... The more money spent, the less likely it seems success will follow. PGN] http://www.thestar.com/NASApp/cs/ContentServer?pagename=thestar/Layout/ Article_Type1&c=Article&cid=1089411015907&call_pageid=968332188492&col=9 68793972154 How costly computer sparked a `nightmare': Social services system `inflexible from Day 1,' expert says; Government estimates fixing flaws could top $10 million Richard Brennan and Robert Benzie, Queen's Park Bureau It seemed like a good idea at the time. An ideologically driven, cash-strapped Conservative administration wanted to reduce social assistance costs and increase the role of the private sector in government. In Jan 1997 then-premier Mike Harris contracted with Andersen Consulting to revamp the Ministry of Community and Social Services' outdated computer system. But a two-year independent study of the $500 million computer system has concluded that it has been seriously flawed from the very beginning and virtually incapable of making timely changes. That became clear when it was learned the system, responsible for distributing welfare and disability benefits to 670,000 Ontarians, is unable to calculate a 3 per cent increase, the first rise in 11 years. It's going to cost at least $10 million to fix the problem — $3 million to correct the computer system and an additional $7 million to test it.
Increasingly we hear sagas of entire shopping center parking lots (and less widespread cases) in which keyless remote entry devices for automobiles are inoperative. For those of you with such systems, an article by Joshua Partlow with the above caption may be of particular interest. Waldorf (15 miles from Andrews Air Force Base in Charles County MD), Bremerton Washington, Las Vegas, etc. (The Florida Panhandle garage-door openers jammed from Eglin Air Force is also mentioned, noted previously in RISKS.) [PGN; county/state correction in archive; mea culpa] "Keyless entry remotes have become standard in new cars in recent years. Of the more than 14 million cars and light trucks produced in the United States last year, 77 percent came with the remotes, up from 32 percent in 1996." "... unlike other more powerful radio signals, keyless entry remotes are not licensed by the Federal Communications Commission. They are allowed to operate on frequencies used by licensed customers as long as their signals are sufficiently weak and don't interfere with others. But because of this outlaw status, their own signals can be jeopardized." [Source: Joshua Partlow, *The Washington Post*, 5 Jul 2004; PGN-ed] http://www.washingtonpost.com/wp-dyn/articles/A28217-2004Jul4.html
The Business Software Alliance, a trade group, says that 36% of all the software in the world has been pirated, costing the industry $29 billion in lost revenue. The five countries with the highest incidence of pirated software are: China (92%), Vietnam (92%) and Indonesia (88%), Ukraine (91%), and Russia (87%). (AP/*San Jose Mercury News*, 7 Jul 2004; NewsScan Daily, 7 Jul 2004] http://www.siliconvalley.com/mld/siliconvalley/9097724.htm
AT&T says it expects to have 1 million customers for its voice-over-Internet-protocol (VoIP) phone service by the end of next year, and cable-TV company Comcast expects to offer VoIP all its customers by the end of 2006; however, Mark Main of the British consulting firm Ovum warns that — although everyone will be using VoIP 10 or 15 years from now — the road to that point "will be quite varied, quite torturous [tortuous?] and not at all clean." Some obstacles in the way: only 27% of U.S. online users have even heard of it; a VoIP subscriber needs a broadband connection, and phone service will be only as good as that broadband connection; prices may go up in the future due to increased regulation and taxes; and VoIP service, which depends on the regular power grid, will fail if grid should fail. [AP/*San Jose Mercury News*, 6 Jul 2004; NewsScan Daily, 6 Jul 2004] http://www.siliconvalley.com/mld/siliconvalley/9089156.htm
The zinc coating on the underside of datacenter floors can emit tiny metallic whiskers, which could lead to abnormally high rates of electronic equipment failure: http://nepp.nasa.gov/whisker/other_whisker/ The State of Colorado recently suffered a non-trivial outage, apparently due to zinc whiskers: http://www.denverpost.com/Stories/0,1413,36%257E33%257E2245069,00.html
http://isc.incidents.org/diary.php?date=2004-06-29 Describes an attack on IE where a file named img1big.gif installs and runs an IE Browser Helper Object that steals information before SSL transmission and sends copies to http://www.refestltd.com/cgi-bin/yes.pl Visit the wrong website and your IE is invisibly bugged.
Ambushing registrars and tracking down executives at their homes and offices, Harris, 52, has uncovered conflicts of interests and security laws inside the companies that make electronic ballot machines. Searching the Web and poring over newspaper clippings, Harris has unearthed obscure arrest records, ties to conservative political groups and other embarrassing secrets of senior executives at voting companies. http://www.cnn.com/2004/TECH/07/05/profile.e.voting.ap/index.html Her conclusion: there will be so many problems with the more than 100,000 paperless voting terminals to be used in the November presidential election that the fiasco will dwarf Florida's hanging chad debacle of 2000.
California's Secretary of State has won a victory in federal court and new agreements from counties with touch-screen machines to make extra security arrangements. U.S. District Judge Florence-Marie Cooper denied requests by disability rights activists and four California counties to overturn the Secretary's conditional April 30 ban on touch screens for the November election. In the suit, disability groups argued that banning electronic voting will deny hundreds of thousands of people the right to vote in private, but the judge ruled the Americans With Disabilities Act requires only that disabled voters be given the opportunity to vote. [Bloomberg News/*San Jose Mercury News* 7 Jul 2004; NewsScan Daily, 8 Jul 2004] http://www.siliconvalley.com/mld/siliconvalley/9100600.htm
(if a bunch of people haven't sent this already) The New York Times reports this morning <http://www.nytimes.com/2004/07/10/national/10florida.html?hp=&pagewanted=print&position=> that the reason for the extraordinary paucity of hispanic voters on the latest Florida felon-purge list was the lack of a "hispanic" category in the felon database, so that race-matching against voters who identified themselves as hispanic would automatically fail. (This on top of not having bothered to check whether any of the felons had has their rights restored.) "The method uses race as one of several factors in determining whether a felon has registered to vote. If a voter's first name, last name and date of birth are the same as those of a convicted felon but the race is different, the name is not put on the list for potential purging. But the database of felons has only five variables for race: white, black, Asian, Indian and unknown. And a voter registered as Hispanic whose name and birth date matched a felon's would be left off the purge list unless his race was listed as unknown. ... The paucity of Hispanic voters on the felon list was first reported Wednesday, by The Sarasota Herald-Tribune, but officials said then that the problem was not systematic. After The New York Times examined the data, state officials acknowledged that the method for matching lists of felons to those of voters automatically exempted all felons who identified themselves as Hispanic. ...The exclusion of Hispanics from the purge list explains some of the wide discrepancies in party affiliation of voters on the felon list, which bears the names of 28,025 Democrats and just 9,521 Republicans, with most of the rest unaffiliated." Pretty much anyone who has ever tried to match items in one database against those in another knows that your have to get the record formats and categories right for the results to mean anything. In this case, even the simplest of properly-prepared test data sets would have uncovered the screwup. (And now I'm trying to decide whether it's scarier to think that there was malice involved or that a bunch of ostensible paid professionals with more than two years two work on the problem could hand over a list like this with straight faces.) PS. And these are some of the same folks who are supposedly evaluating the quality of paperless voting machines?
The 28 Jun 2004 issue of Mass. High Tech ("The Journal of New England Technology") has a page 1 story about LocatePlus of Beverly, MA. The news angle is that a unit of the Massachusetts State Police will upgrade their use of LocatePlus from CD-ROMs of vehicle records to wireless access (via Blackberry) to all LocatePlus data. Checking locateplus.com reveals that they offer some data (public records) to the public and more to licensed private investigators and the like, but law enforcement customers get everything, including non-public information. The website does not say (where I could see it, at least) how to opt out or correct erroneous information about oneself. The MHT article says that LocatePlus claims to have information on 98% of the U.S. population (note: not just adults), including residence data, "court filings" and "restricted government data." Banks can "verify" Social Security numbers against whatever data LocatePlus has, and can use the service to screen for illegal money laundering or funneling. There are nearly 16000 LocatePlus customers in all. The RISKS are many. Wireless communication can be intercepted, and what happens if a cop's Blackberry falls into the wrong hands? Data aggregation depends on correctly matching the person across databases. If a private company has "restricted government data", how did they get it, and are they obligated to protect it and cleanse it as zealously as the agency from which it came? Are the customers obligated to provide their data to LocatePlus to help it amass information? As we know from credit bureaus, the standard for data accuracy is set by the satisfaction level of the paying customers rather than the data subjects; in the case of credit data, those paying customers seem to tolerate a 20% error rate year after year. They believe someone is a law enforcement agency on the strength of a printed letterhead. Add on the standard set of security concerns.
In the 3 Jul 2004 issue of RISKS, there were several articles about the recent court decision that e-mail is not private. Surprisingly, I mus take a contrarian position: this is a good decision. One cannot legislate privacy; one can only give most users a false sense of security. Consider, for example, the results of another legislated-privacy "solution": analog cellphones use normal, unencrypted broadcast radio to transmit conversations, so it is now illegal (in the U.S.A.) to build or buy a radio scanner that receives on those frequencies. As a result, a black market developed in radio scanners that were capable of receiving that frequency range. Meanwhile, people with analog cellphones continued for many years to hold private conversations on the airwaves, with occasionally hilarious results as scofflaws listened in anyway. The problem of broken privacy would be much less, if the cellphone companies had instead been forced to educate their users that they were essentially bellowing their conversation from a rooftop. (Of course, most people now use some sort of encryption as a side-effect of using digital cellphones.) Long-time readers may recall that, as a younger and angrier man, I have ranted about similar discrepancies between the law and reality in the satellite-communications market: it is illegal (again, in the U.S.A.) to build a radio receiver that can receive satellite television. This despite the fact that (for many years) the television signals were being beamed directly into your backyard, unencrypted. If the proprietors don't want you to receive their radio signals, they should not be bombarding you with them in the first place — or should encrypt them. It's best to call a spade a spade: non-secure communications are non-secure, and people who use them should be aware of what they are getting. After all, truly private solutions (PGP, GPG and the like) do exist, and folks who expect privacy should use them.
Implementation quirks in Voice over IP are making it easy for hackers to spoof Caller I.D., and to unmask blocked numbers. By Kevin Poulsen, SecurityFocus Jul 6 2004 1:54PM Caller I.D. isn't what it used to be. Hackers have discovered that the handy feature that tells you who's calling before you answer the phone is easily manipulated through weaknesses in Voice over IP (VoIP) programs and networks. They can make their phone calls appear to be from any number they want, and even pierce the veil of Caller I.D. blocking to unmask an anonymous phoner's unlisted number. At root, the issue is one of what happens to a nugget of authentication data when it leaves the tightly-regulated realm of traditional telephony, and passes into the unregulated domain of the Internet. On the old-fashioned phone network, Caller I.D. works this way: your local phone company or cell phone carrier sends your "Calling Party Number" (CPN) with every call, like a return address on an envelope. Transmitted along with your CPN is a privacy flag that tells the telephone switch at the receiving end of the call whether or not to share your number with the recipient: if you have blocking on your line, the phone company you're dialing into knows your number, but won't share it with the person you're calling. This arrangement relies on telephone equipment at both ends of the call being trusted: the phone switch providing you with dial tone promises not to lie about your number to other switches, and the switch on the receiving end promises not to reveal your number if you've asked that it be blocked. In the U.S. that trust is backed by FCC regulations that dictate precisely how telephone carriers handle CPNs, Caller I.D. and blocking. Most subscribers have come to take Caller I.D. for granted, and some financial institutions even use Caller I.D. to authenticate customers over the phone. ... http://securityfocus.com/news/9061
Good news for the spammers!! As most of us are aware that Google provides various options/operators for writing effective queries. One of the operator is the "site:" option, which restricts the search to the website specified with this tag. Just tried googling for some gmail accounts with site:gmail.google.com and the results were a list of urls with the title "Link Already Used". The area of concern is that all these pages are actually error pages with a valid gmail user accounts.... so with a small script its very easy for some one to glean a list of _valid_ gmail accounts. Do you have a gmail account? ....check if your name is already harvested ;-)
The immediate RISKs to US national security are minimal - apart from anything else, the GPS signal won't work inside most office buildings - but taking it on trust that Coke has issued exactly 120 of these cans seems optimistic, and assuming that more than 100 or so will ever be found, even more so. One would hope that either this promotion, or similar ones in the future, will have some sort of self-limiting features to the technology - for example, limiting the time validity of the SIM cards.
BKNTSCJS.RVW 20030604 "Network Security Jumpstart", Matthew Strebe, 2002, 0-7821-4120-X, U$24.99/C$39.95/UK#18.99 %A Matthew Strebe firstname.lastname@example.org %C 1151 Marina Village Parkway, Alameda, CA 94501 %D 2002 %G 0-7821-4120-X %I Sybex Computer Books %O U$24.99/C$39.95/UK#18.99 800-227-2346 email@example.com %O http://www.amazon.com/exec/obidos/ASIN/078214120X/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/078214120X/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/078214120X/robsladesin03-20 %P 365 p. %T "Network Security Jumpstart" The introduction states that this book is suitable for anyone from the home user to the network administrator to the CEO. Which is a pretty tall order. Chapter one has a decent overview of why computers aren't secure, a scant computer security history, a few security concepts, and a fairly trivial set of "review" questions. There is a media level exposition on "hackers," in chapter two, a rough outline of intrusion procedures, and a list of specific attacks that I'm not sure the author fully understands. (Immediately following "Denial of Service" comes a separate entry for "Floods": flooding being a type of denial of service.) There is a terse introduction to cryptography, and not much more than chapter one gave us about authentication, in chapter three. The suggestions for policy creation, in chapter four, aren't bad for simple cases, but seriously understate the difficulty of establishing a full policy, even for home users. Chapter five describes firewalls (and seven tells a little bit more about using them at home). Chapter six makes the common mistake of assuming that all VPNs (Virtual Private Networks) are about confidentiality: some are merely about managing communications configurations. There is some correct and useful information about viruses in chapter eight, but it is unfortunately mixed in with a lot of garbage. Windows NT and its subsequent versions are *not* immune to viruses, although a rigorous set of file permissions can reduce your risk of file infectors (which are no longer a major category anyway). Signature scanners are *not* the only type of antiviral software. Viruses were *not* invented by accident, BRAIN *never* had an onscreen display and didn't infect program files, and neither Stoned nor Jerusalem (Friday the 13th is one variant) were based on BRAIN. Neither Stoned nor BRAIN relied on program sharing to propagate: data disks were quite sufficient. Viruses that only replicate are *not* benign (anybody ever have problems with Stoned? Melissa? Loveletter?), *will* be discovered, and scanning signatures *are* created. Fault tolerance, in chapter nine, is not quite business continuity planning (BCP), but does go beyond the usual UPS (Uninterruptible Power Supply) and backup recommendations. Although chapter ten lists a number of security mechanisms in Windows, a practical understanding of their use is not presented. The UNIX tools in eleven are described more usefully--but they only relate to file permissions. The network security tools for UNIX are in twelve--but are only enumerated. Chapter thirteen has good suggestions for Web server security--but doesn't say how to implement them. A random collection of e-mail security tools and threats makes up chapter fourteen. IDS (Intrusion Detection System) concepts are not explained very well in chapter fifteen: Strebe apparently doesn't understand that all forms use audit data of one type or another, and doesn't list the major distinctions between either the engine type or sensor location. Even given all the faults, one has to admit that Strebe has not done a bad job with his ambitious intent. Certainly home users and CEOs can find better explanations here than in many of the other works aimed at them, however much I might wish that the book as a whole was more accurate. And, yes, even the network administrators might find some helpful points in the more conceptual material at the beginning of the book: most of them could do with a better understanding of the need for policy. This work isn't great, by any means, but it can fulfill a need for a quick guide to network threats, for a variety of audiences. copyright Robert M. Slade, 2004 BKNTSCJS.RVW 20030604 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer