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…
An article in the 7 Mar 2007 *Toronto Star* (1) states that due to errors in the electronic filing system, Canada Revenue Agency will be unable to accept any tax filings electronically or corrections to prior filings. The Agency's electronic systems apparently transposed the birth date and the user's Social Insurance Number (the Canadian equivalent to the U.S. Social Security Number) and thus corrupted all electronic databases. A reference to the incident in Slashdot (2) states that no returns - not even paper ones - can be accepted, "based returns will be stacking up in the mail room, as returns cannot be filed at all until the problem is fixed." This could be inferred from the first paragraph of the article in the *Star*, which reads "a problem with electronic filing is making it impossible even to submit tax returns to the Canada Revenue Agency." The remainder of the article in the *Star* says nothing about their system for accepting paper returns, only about the on-line and telephone systems. A check of the taxing authority's website(3) regarding the issue states "We have temporarily shut down public access to electronic services to ensure the integrity of taxpayer information." and that "We have now traced the source of the problem to software maintenance conducted on 4 Mar 2007. We are currently working to bring all systems back online gradually." A CRA press release dated March 6 (4) states "Commissioner of the Canada Revenue Agency (CRA) Michel Dorais today instructed some computer applications related to personal income tax filing to be temporarily halted." Mr. Dorais also stated "there is no indication that this situation was caused by intrusion, hacking, or computer virus", i.e. the agency messed things up all by their lonesome, they didn't need any help from anyone else. The press release also says, "These applications include online services like Efile, Netfile, and My Account. Mr. Dorais said that he instructed that this preventative measure be taken following indications that CRA computer systems have run into infrastructure problems. In order to safeguard existing systems and to maintain the integrity of CRA's taxpayer information holdings, Mr Dorais ordered tax filing processes halted." Again, while this may imply that the agency is unable to process all returns - even ones filed on paper - that is not explicitly stated, e.g. don't get your hopes up that you'll get away with a long delay in filing, considering that Canada's tax deadline is April 30, Canadians have even more time than people here in the U.S. However, an article in *The Globe and Mail* (5) states that taxpayers "can wait for Netfile to return to service, or they can print their returns and mail them to the CRA" which indicates that the paper-based systems are unaffected. (1) http://www.thestar.com/News/article/189175 (2) http://it.slashdot.org/article.pl?sid=07/03/08/0417247 (3) http://www.cra-arc.gc.ca/agency/updates/eservices-e.html (4) http://www.cra-arc.gc.ca/newsroom/releases/2007/march/nr070306-e.html (5) http://www.theglobeandmail.com/servlet/story/RTGAM.20070307.wtaxes0307/BNStory/Technology/home [Also noted by Henry Troup, who noted that 17 of 75 databases were reportedly impacted. PGN]
A US networked lottery system was overtaxed by demand and had at least two operational problems: A record $370M jackpot in the US "Mega Millions" lottery overwhelmed systems used for tracking lottery purchases and ticket numbers. http://edition.cnn.com/2007/US/03/07/megamillions.ap/index.html In one state (Ohio), the purchasing system went down 25 minutes before the deadline. In another state (California), they could not confirm by the morning after the draw if there were any winners. Loss of sales revenue is one problem, but the delays in authentication open opportunities for more serious fraud. Benjamin Jun, Vice President of Technology, Cryptography Research, Inc. [After California results were finally generated, no new winners were discovered — leaving the two East-coast winners to split the pot. PGN]
In the 1 Mar 2007 *InformationWeek* Paul McDougall reports that utility giant Pacific Gas & Electric says its meters won't work properly on 11 Mar 2007 because of this year's new daylight-saving rules and that reprogramming them would cost $38 million. The problem is time-of-use billing, where the end-user rates change depending on time of day. PG&E has worked around the problem by getting permission from the California Public Utilities Commission to change the cutover times instead of upgrading its meters. For example, from 11 Mar through 31 Mar a peak usage period that would ordinarily end at 6pm will instead end at 5pm to compensate for the meters being off by an hour. PG&E announced this workaround in April 2006. Presumably the workaround will continue through the life of the existing meters. The workaround encourages power usage in the 5pm-6pm hour. This undermines a primary justification for the 2007 change to U.S. daylight-saving rules, which is to conserve electricity by shifting consumption from late afternoon to early morning. Here's a reference: Paul McDougall, "PG&E Says Patching Meters For An Early Daylight-Saving Time Will Cost $38 Million", InformationWeek 1 Mar 2007 <http://www.informationweek.com/news/showArticle.jhtml?articleID=197700487>
FYI: There are lots of dates in modern medical equipment including DST changes, leap years, and device dependent dates, e.g. the next required preventive maintenance. The alert was not issued because of a theoretical possibility but because of actual user experience. Just when you thought that Y2K was safely behind you... Date: Fri, 2 Mar 2007 15:57:45 -0500 From: CDER MEDWATCH LISTSERV Subject: FDA - MedWatch - Medical Device Safety - Change in Daylight Savings Time May Affect Medical Equipment in Unpredictable Ways FDA notified healthcare professionals and consumers of the possibility that some medical devices/equipment, hospital networks and associated information technology systems may generate adverse events because of the upcoming change in the start and end dates for Daylight Savings Time (DST), and suggested actions to prevent such occurrences. Medical equipment that uses, creates or records time information about a patient's diagnosis or treatment and has not been updated by the manufacturer, may not work properly when the new DST starts three weeks earlier and ends one week later this year. Medical equipment currently in use was likely made before the DST rules were changed and may cause patient's equipment to register the wrong dates for the start and end of daylight savings time this year. Additionally, if a medical device or medical device network are adversely affected by the new DST date changes, a patient's treatment or diagnostic result could be: * incorrectly prescribed * provided at the wrong time * missed * given more than once * given for longer or shorter durations than intended * incorrectly recorded Related CDRH release: Unpredictable Events in Medical Equipment due to New Daylight Savings Time Change: http://www.fda.gov/cdrh/safety/030107-dst.html [Also noted by Paul Eggert:] http://www.fda.gov/cdrh/medicaldevicesafety/atp/030107-dst.html
Perhaps the worst that will happen in millions of offices on the second Monday in March is that caffeine-deprived workers will wonder why their automatic coffeemakers failed to perk on schedule. In less lucky workplaces, however, employees might miss meetings, overbook conference rooms or inaccurately record the time or date of important financial transactions. For the first time in 20 years, daylight saving time will not start on the first Sunday in April. Instead, it will begin three weeks earlier, at 2 a.m. on the second Sunday in March, the 11th. Devices from the tiniest BlackBerry to the largest mainframe computer must be updated to ensure their internal clocks "spring forward" by one hour at the right moment rather than on the old date, which has been written into countless programs. Similarly, they must be reprogrammed to revert to standard time a week later than usual, on Nov. 4. Congress decided in 2005 to expand daylight saving time by four weeks, starting this year, in hopes of conserving energy by pushing more human activity into sunlit hours. ... [Source: Charles Babington and Tomoeh Murakami Tse Countdown to Confusion: Daylight Saving Time Comes Early This Year, But Will Your Computer Know When to Switch?, *The Washington Post*, 3 Mar 2007] http://www.washingtonpost.com/wp-dyn/content/article/2007/03/02/AR2007030201346.html [Marc Sachs mentioned to me that Kerberos-based systems were subject to failure on 11 March because of a maximum-permitted 10-minute clock divergence. PGN]
Background: In the UK, motor vehicle details have been stored on the Driver
& Vehicle Licensing Agency (DVLA) computer for decades. This includes a
record that the annual Vehicle Excise Duty ("tax disc") is current. For the
last year or two, the annual vehicle inspection ("MoT test") is captured
on-line as it's done, and insurance companies provide details for a database
of insured vehicles. These allow the police to do real-time road-side
checks on passing traffic. Drivers are not required to carry documents with
them, but the police can require them to be produced ("a producer") at a
police station nominated by the driver within 7 days.
In one case, a car was allegedly towed by police and crushed for having no
insurance, despite having a valid policy. There are questions about this
case, but here are some general comments on the matter from people at the
company where I work:
>> A police statement said: "It is the responsibility of insurance
>> companies, not police forces, to ensure that insurance policy details
>> are updated on the national motor insurance database. When deciding if a
>> car should be towed for insurance or licence violations, officers must
>> show `reasonable belief' that an offence has taken place. "Due to
>> inaccuracies on the motor insurance database officers should not only
>> rely on details held there to constitute `reasonable belief'".
>
> Having been involved in our attempts to keep the motor insurers database
> up to date with details of the company fleet, I can't say I'm surprised
> that it's sometimes out of date. It seems totally ridiculous that the
> police use this as the sole evidence that a vehicle should be towed away.
>
>> Gives you great confidence in the ability of the `authorities' to use
>> databases in he pursuit of their version of justice. Imagine them using a
>> database covering ID cards, they'd be hauling us off instead of cars
>> then....
>
> Can't help wondering why the police impounded the car instead of simply
> issuing a producer. Was there something else dodgy about the car or the
> driver that we weren't told about?
The idea is the computer says no, the journey ends there. The police will
not allow you to continue in an uninsured car.
There was something on one of those `fly on the wall' police programs that
made me wonder. They stopped someone because the computer said the car was
untaxed and uninsured and the driver tried to show them an insurance
certificate. The officers were singularly unimpressed saying anyone with a
computer can knock up a `valid' certificate of insurance preferring to
believe what the database told them. At the end of the program we were
updated and the driver was insured but his tax was 6 weeks out of date.
Looks like the (rather familiar) RISKs here are (a) ambiguity as to what is
regarded as the definitive record — in this case, computer database or
paper insurance certificate? — and (b) how individuals can find themselves
in trouble for others' errors and omissions, e.g. if your insurance company
makes a mistake in updating the database. Presumably you could prove in
court that you have a valid policy, but that's not much good if you're
detained by police at the side of the road a long way from home.
Back in Aug 2006 there was a threat of a strike, which caused Los Angeles officials to restrict access to traffic-control computers. However, beginning on 21 Aug 2006, two traffic engineers were able to access those computers anyway, lengthening the red light cycles on major routes, and allegedly causing massive traffic tie-ups for several days at different intersections (LAX Airport, Studio City, the Glendale Freeway, Little Tokyo, and the L.A. Civic Center). Both men pleaded not guilty to felony charges on 8 Jan 2007. [Source: Sharon Bernstein and Andrew Blankstein, Los Angeles Times, 9 Jan 2007; PGN-ed] http://www.latimes.com/news/local/state/la-me-trafficlights9jan09,1,899433.story?coll=la-news-state [Clifford Neuman is quoted at the end of the article, saying that there are two primary ways to design computers to guard against malicious activity by insiders, but each can interfere with employees' ability to do their tasks and would probably be prohibitively expensive for the city.]
[Marcus H. Sachs sent this to me at the end of October, but it slipped through the crack. It is never too late for such items to appear in RISKS, even though some of them may have been overtaken by other events.] An infected laptop gave hackers access to computer systems at a Harrisburg, Pennsylvania, water treatment plant. The plant's systems were accessed in early October 2006 after an employee's laptop computer was compromised via the Internet (apparently from abroad), and then used as an entry point to install a computer virus and spyware on the plant's computer system. The FBI was investigating. The motive appears to have been the use of the laptop as a zombie, rather than an attempt to subvert the water system. However, more serious risks are obvious. [Source: Robert McMillan, Hackers break into water system network, IDG News Service, 31 Oct 2006; PGN-ed] http://www.networkworld.com/news/2006/110106-hackers-break-into-water-system.html
When a system of components is under disparate control like the Internet, it only works reliably when everybody plays by the rules. E-Mail behavior is specified in rfc2822 and related documents maintained by the IETF. While I can't find it clearly in that document, the general rule is that you should be liberal in what you accept and strict in what you generate. Here I report on an e-mail address which fails because of a trailing blank. Notice that it can be difficult to see a blank by the naked eye when it is followed by white space. It should not be there. There should be no space after .COM or .NET in an e-mail address. Still, many e-mail programs make it easy to put one there by mistake. In this case, the Apple Macintosh OS X application Mail happily uses such an address and passes the blank along. No matter; the next recipient will trim it off and there will be no problem. In my case, the e-mail went to the ISP supported by what used to be Pacific Bell, which became SBC and then became AT&T by further corporate manipulations. They use Yahoo to provide outgoing e-mail service for their DSL customers. Yahoo, too, apparently passes the trailing blank along, presumably to a Domain Name Server. No matter. The DNS will trim off the blank and all will be well. But no. MAILER-DAEMON@yahoo.com says: Sorry, I couldn't find any host named bzwebtech.com?. (#5.1.2) And the mail is returned to the sender. Perhaps the DNS is actually OK; I can't tell from the messages I get. Still, I believe that at least Mail and Yahoo are not really playing by the rules. Now a nitpicker is fully equipped to track such a problem down, at least to the point of discovering the unwanted blank, but other e-mail users may not have the resources and may simply assume that the part to the left of the .COM is in error and give up entirely on reaching that company or person. Too bad, since that introduces unnecessary friction and loss in a vital facility. Surely Apple and Yahoo are wrong in their treatment of a problem originally caused by my own mistake. If the DNS is also wrong, then we may have more to worry about than I knew. The problem is exacerbated by the lack of any convenient way to report problems to any of those entities. Richard Karpinski, World Class Nitpicker, 148 Sequoia Circle, Santa Rosa, CA 95401 dick@cfcl.com Home +1 707-546-6760 Cell +1 707-228-9716
> less common to do date arithmetic, and I've never seen anyone doing date > arithmetic as far back as 1900. Genealogists — or the software they use — does it a lot; the one I use (Brother's Keeper — somewhat clunky by today's standards, but I have a *lot* of records in it and am not translating it all now! It also is excellent at encouraging you to record *source* and *quality* data for all your data), for example, shows the age of anyone it can (by subtracting birth from death if both are recorded, otherwise birth from today — and no I don't know what cutoff it imposes). It may do other date calculations too. OK, for giving ages in years, this only has a 1 in (about) 365 chance of giving the wrong answer if there's a day funny around 1900, but I just thought I'd mention it as something which regularly does date calculations "as far back as" 1900.
Larry Koved and I are co-chairing a workshop on 24 May 2007 on web security (W2SP) that will be co-located with and following the IEEE Symposium on Security & Privacy in Oakland, CA. We're asking for one-page position papers, and our hope is to attract more industrial participation than you'd otherwise get at an academic conference. The goal is to bring together researchers and practitioners from academia and industry to focus on understanding Web 2.0 security and privacy issues, and establishing new collaborations in these areas. Position papers are due March 23. Here's the full CFP: http://www.ieee-security.org/Calendar/cfps/cfp-W2SP.html
Review by Rob Slade <rMslade@shaw.ca> of "Code Quality: The Open Source Perspective", Spinellis. > Nonfunctional requirements (including such > characteristics as reliability, portability, usability, interoperability, > adaptability, dependability, and maintainability) are much harder > to assess, and yet may be more important. [...] > Chapter one introduces the structure of the text by mapping > characteristics from the ISO 9126 quality standard to the chapters and > sections of the book. ISO/IEC 9126 has now been superseded by a set of standards referred to as SQuaRE, but the new standards are still flawed, in the same way that 9126 was (and are direct derivatives of it). The problem arose back in 1992 when the joint technical committee (JTC1) set up to ensure compatibility between ISO (International Standards Organisation) and IEC (International Electrotechnical Commission) took on a life of its own and began to write standards without reference to either of its parent bodies. In particular, ISO/IEC JTC1/SC7/WG6 began to draft standards (the ISO/IEC 9126 series) on "software quality" in which it misused terms defined by IEC/TC56 (Technical Committee 56: Dependability). In particular, terms such as "reliability", "availability" and "maintaintability" were defined as "subcharacteristics" of "software quality" without any regard to the standard definitions of these terms in the field of system dependability. (At the time, the working group responsible had not even heard of the standard definitions as stated in IEC 60050 (191): International Electrotechnical Vocabulary Section 191: Dependability and Quality of Service.) I would advise anyone who is interested in the dependability of systems (i.e., their reliability, availability and maintainability as correctly defined) to take anything emanating from ISO/IEC JTC1/SC7 (Joint Technical Committee 1, committee on "Software Quality") with a very large pinch of salt. Peter Mellor (UK Principal Expert on Dependability Terminology, IEC/TC56/WG1: Working Group 1, Definitions of Terms.) +44 (0)20 8459 7669
BKFISMAC.RVW 20070113 "FISMA Certification and Accreditation Handbook", Laura Taylor, 2007, 1-59749-116-0, U$69.95/C$90.95 %A Laura Taylor %C 800 Hingham Street, Rockland, MA 02370 %D 2007 %G 1-59749-116-0 978-1-59749-116-7 %I Syngress Media, Inc. %O U$69.95/C$90.95 781-681-5151 fax: 781-681-3585 www.syngress.com %O http://www.amazon.com/exec/obidos/ASIN/1597491160/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1597491160/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1597491160/robsladesin03-20 %O Audience a- Tech 1 Writing 1 (see revfaq.htm for explanation) %P 498 p. %T "FISMA Certification and Accreditation Handbook" The United States' Federal Information Systems Management Act mandates certain standards of information security and controls for US federal agencies. It extends to contractors and other sources that support the assets of federal government departments. However, it may have wider application yet, since it provides a solid basis for security management, assessment, and assurance for large corporations as well. Chapter one looks at definitions of various terms surrounding security and controls. It is interesting to note that to the usual certification (assessment) and accreditation (acceptance) phases the feds add an audit/evaluation phase between the two. The National Information Assurance Certification and Accreditation Process (NIACAP), National Institute of Standards and Technology outline, Defense Information Technology Systems Certification and Accreditation Process (DITSCAP), and Director of Central Intelligence Directive 6/3 (DCID 6/3), all directions on how to follow FISMA, are briefly compared in chapter two. A list of job descriptions, and a brief outline of general project management steps makes up chapter three. Chapter four examines components of a certification and accreditation program, mostly in terms of documentation. Chapter five returns to project management, with a quick look at the initiation phase. An even shorter mention of creating a hardware and software inventory is in chapter six. Chapter seven is nominally about determining the proper level for certification (which is, again, primarily related to the number of documents produced), but turns into an interesting and valuable outline of information classification. Much of chapter eight, on self-assessment, is a reprinting of the NIST 800-26 guideline on that topic. Security awareness and training is touched on briefly in chapter nine. Chapter ten, on rules of behaviour, is a terse mix of acceptable use and incident response, but it leads rather nicely into the longer examination of incident response in chapter eleven. Chapter twelve lists various types of assessment tools, such as vulnerability scanners and code analyzers. I found the privacy impact assessment, in chapter thirteen, to be an interesting perspective. Chapter fourteen's material on business risk assessment is concise but reasonable. Business impact assessment, in fifteen, is not quite as good, since it neglects the analysis of criticality of operations. Contingency planning is outlined well in chapter sixteen. Chapter seventeen takes a brief look at risk assessment, but manages to hit all the high points. Change management is reviewed in chapter eighteen. An overview system security plan document is described in chapter nineteen. The certification package is detailed from the perspective of those submitting it (in chapter twenty) and those evaluating or auditing it (chapter twenty-one). Preparation of a plan to correct residual weaknesses is addressed in chapter twenty-two. Chapter twenty-three looks at improving the standings and grading on a Federal Computer Security Report Card. There is much that is useful and helpful in this book, both in terms of general information security management structure and process, and in terms of references for those involved with FISMA related programs. However, for those who are new to the operation of US government certification and accreditation, the basic requirements, and the relation of the ancillary programs to FISMA itself, could have been more fully explained. copyright Robert M. Slade, 2007 BKFISMAC.RVW 20070113 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer