Improve Private Sector Cybersecurity Thompson, Langevin Release GAO Cybercrime Report, Announce Plans to Improve Private Sector Cybersecurity July 23, 2007 (WASHINGTON) - Today, Congressman Bennie G. Thompson (D-MS), Chairman of the Committee on Homeland Security, and Congressman James R. Langevin (D-RI), Chairman of the Subcommittee on Emerging Threats, Cybersecurity, Science and Technology released a report conducted by the Government Accountability Office (GAO) on public and private challenges in addressing cybercrime. The GAO reaffirms the threat that cybercrime poses to U.S. national and economic security interests. In 2005, the Federal Bureau of Investigation estimated American businesses lost $67.2 billion due to computer crime. Threats come both from at home and abroad; though many cyberattacks originate on U.S. soil, foreign adversaries continue to make public statements about exploiting vulnerabilities in technology to their advantage. According to the GAO, the public and private sectors face numerous challenges to secure cyberspace, both in operational security and in law enforcement. Both public and private sectors have run into difficulties detecting or reporting cybercrime; the sectors have struggled to implement strong information security programs; there is a lack of adequate law enforcement analytical and technical capabilities to confront these challenges; and the borderless environment of cybersecurity makes it difficult for law enforcement to hold accountable those who break laws. Chairman Thompson issued the following statement regarding the findings: "When it comes to cyber, we have two worlds to secure - the public and the private sector. In order to provide leadership to the private sector, the Department of Homeland Security must demonstrate control of its networks. Unfortunately, previous GAO engagements and our own investigations into the Department have shown that 'information security' has become an oxymoron. This is simply unacceptable. This Administration and the Department's leadership may continue to disregard these problems, but this Committee will continue to demand accountability from the government contractors and employees charged with securing information networks." Chairman Langevin added: "I encourage all businesses - small and large - to take a very close look at their cybersecurity practices. Though 100% security may be unattainable, there are many policies and procedures that businesses can implement to better safeguard their data. Just as the government must improve its cybersecurity posture, so too must the private sector. The private sector is the nation's economic engine and the owner of a great majority of the national critical infrastructure. American businesses must come to realize that the security of the information that they keep is as important as the bottom line. In the upcoming months, this Committee will lead the conversation about ways to spur private sector investment in cybersecurity. Recently, Assistant Secretary for Cybersecurity and Telecommunications Greg Garcia asked us to consider legislation to help make the case for private investment. In addition to our efforts designed to improve Federal network security, I will work with Chairman Thompson to identify plans for incentives and liabilities that will improve private sector cybersecurity." FOR MORE INFORMATION: Please contact Dena Graziano or Todd Levett at (202) 225-9978. United States House of Representatives Committee on Homeland Security H2-176, Ford House Office Building, Washington, D.C. 20515 Phone: (202) 226-2616 | Fax: (202) 226-4499 <http://homeland.house.gov/>
Here's a nice little problem with "Vista Mail". It appears that in some circumstances a "550" permanent rejection SMTP response is ignored and Vista Mail shows the mail as haven't been sent, even though the mail server rejected it. http://lists.exim.org/lurker/message/20070718.140135.4765aa65.en.html The reason seems to be that Vista mail can't handle multiline responses correctly. http://lists.exim.org/lurker/message/20070719.161335.f220a4a6.en.html The risks of MS being unable to implement a simple protocol correctly are obvious. Neil Youngman, Developer, Wirefast Limited +44 (0)20 7592 1258
Air Force investigators are probing a security breach at Science Applications International Corp. (SAIC) of San Diego, which handles sensitive health information for 867,000 U.S. service members and their families. SAIC has acknowledged that some of its employees sent data over the Internet unencrypted, including medical appointments, treatments, and diagnoses. Two years ago, SAIC had a computer intrusion that resulted in the leakage of SSNs and other personal info on tens of thousands of its employees — including former SAIC executive David A. Kay, who was the chief U.N. weapons inspector in Iraq, and a former director who was a top CIA official. [Source: Ellen Nakashima and Renae Merle, Military Medical Breach Revealed: Unencrypted Data Sent Via Internet, *The Washington Post*, 21 Jul 2007, D01; PGN-ed] http://www.washingtonpost.com/wp-dyn/content/article/2007/07/20/AR2007072001422.html?hpid=sec-health
[The files have been deleted since my story went up, but, unfortunately for the governor's office, are still available on Google's cache: http://www.google.com/search?q=site%3Alistserv.nv.gov] Declan McCullagh [via Politech distribution], Nevada governor accidentally posts Outlook password, 20 Jul 2007 http://news.com.com/8301-10784_3-9747705-7.html If you ever wanted to be Nevada's governor for a day, it doesn't seem to be that hard. In what could be a whopping security hole, Nevada has posted the password to the gubernatorial e-mail account on its official state Web site. It appears in a Microsoft Word file giving step-by-step instructions on how aides should send out the governor's weekly e-mail updates, which has, as a second file shows, 13,105 subscribers. The Outlook username is, by the way, "governor" and the password is "kennyc". We should note at this point that the former Nevada governor, a Republican, is Kenny C. Guinn, which hardly says much about password security. [...] Archived at http://www.politechbot.com/
Not a lot to do with each other, one might have thought. But PGN's comment in RISKS-24.74 about "proof by simulation" struck a chord. I'm referring particularly to this year's Wimbledon tennis tournament. For some years, the BBC has used simulations to show a virtual image of the ball's path, and in particular where it has bounced. I've wondered periodically how accurate these were - presumably /something/ has to track the ball in real time and model its trajectory. I've no idea how it's done. What I /do/ remember from the last year or so is that the Beeb once played back in close succession both a real video replay close-up of the ball bouncing, and then the simulation: it was quite clear that the simulation was at least 2 or 3 inches adrift, more than enough to make the difference between a line call being 'in' or 'out' This year, they actually relied on Hawkeye [the simulator] as final arbiter in line calls - an umpire refused to over-rule it on at least one occasion. Separately, a BBC commentator said something like, "if we question Hawkeye, whatever next?". One of the finalists, IIRC, went so far as to question the system's accuracy however. Interestingly, the BBC used a lot of Hawkeye simulation replays to show the bounce of the ball - but I don't recall seeing a single close-up /video/ replay of the bounce this year. Of course, tennis line calls are notoriously difficult, and Hawkeye may be more accurate overall than people's judgment; nevertheless, the blind faith in it is worrying. Hawkeye at least has the benefit that it can't be intimidated by the "brats" of the game :-) [There were several Hawkeye simulations that seemed obviously wrong to the commentators, spectators, and TV viewers. RISKS has often warned about people overendowing the infallibility of technology. Despite being steeped in old traditions, Wimbledon seems to be the latest victim. PGN]
I suppose it was inevitable - someone has found a security vulnerability in the iPhone: Dan Goodin, "Jesus Phone" needs an exorcist; security flaw means demonic possession for Apple iPhone, *The Register*, 24 Jul 2007 http://www.theregister.co.uk/2007/07/24/iphone_security_vulnerability/ If a person visits a malicious website, then the phone can be infected with malware. Not a direct attack (in other words, launchable from the person sitting next to you), but I expect that is coming... I remember the days when the only thing you could do with a mobile phone was ring people...
Companies Claim Right to Interfere with eBay Auctions for Charging Too Little Greg Beck, 17 Jul 2007 http://pubcit.typepad.com/clpblog/2007/07/leegin-and-ebay.html I predicted that companies would soon rely on the Supreme Court's decision in Leegin Creative Leather Products v. PSKS to justify interfering with competition from less expensive products sold online. It did not take long for that prediction to come true. Although interference with eBay sales is nothing new, companies in two recently filed federal cases explicitly invoke Leegin as a justification for terminating the eBay auctions of competitors that charge lower prices online. These cases not only show Leegin's likely effect on Internet sales, but are also, unfortunately, fairly typical examples of the sort of anticompetitive actions companies take to fight lower-priced competition online.
Comair pilot instructors testified that the crew of Comair Flight 5191 committed numerous procedural violations relating to briefing, taxiing, and "sterile cockpit" rules (maintaining a distraction-free cockpit) before taking off from the wrong runway and crashing near the Lexington KY airport 27 Aug 2006, killing 49 people (see RISKS-24.41). Their testimony is apparently consistent with evidence released by the NTSB showing that the pilots violated company and Federal Aviation Administration rules by talking about their families, work and other subjects while preparing for takeoff. However, Comair maintains pilots were ``confronted with inaccurate and inadequate airport charts, maps, signs, barriers, markings, and lighting". [Source: *Lexington Herald-Leader*, 23 Jul 2007; PGN-ed. Also, only one air traffic controller was on duty (RISKS-24.43).] http://www.kentucky.com/471/story/127516.html
I was looking at the recent interim Chemical Facility Anti-Terrorism Standards, 6CFR27, while preparing a briefing on audit possibilities. The Standard contains the following provisions: 27.230 (a) (7) Sabotage. Deter insider sabotage; 27.255 (d) Records required by this section may be kept in electronic format. If kept in an electronic format, they must be protected against unauthorized access, deletion, destruction, amendment, and disclosure. These requirements seem pretty straightforward. However, there is a risk in counting on regulators to fully think through requirements such as these. How can a facility protect electronic records from deletion, destruction, or amendment by disgruntled insiders such as management, IT personnel, security personnel, or onsite fire-fighters who all have access to the rooms housing the electronic equipment? Two server rooms with separate IT staff could work for the IT group and possibly management, but it likely isn't feasible to block access to security or first response personnel. (I once worked as an Operations Supervisor at a commercial nuclear plant. Management decided that a block of offices contained material too sensitive to allow the fire brigade access after hours. A smoldering trash can which convinced us to break down a door in the middle of the night quickly pointed out the flaw in that thinking, and we got keys the next day.) The only easy (partial) solution I could think of involves offsite storage, with the storage company personnel having read-only access to the onsite records and onsite staff having read-only access to the offsite files. However this only reduces but doesn't eliminate the risk, especially for alteration. (The offsite backup would likely mirror any unauthorized onsite alteration. This seems to call for incremental backups with retention of all versions.) And of course the offsite backup solution increases the risk of disclosure. Maybe the key is in the requirement to deter and protect rather than prevent insider sabotage, but this quickly turns into an audit nightmare of how much deterrence is enough.
When I established my cell phone account I saw no reason to provide my social security number, so I gave them random digits, which I then forgot. So I couldn't make account changes (since last four SSN digits are used for PIN!) no matter how I explained that they didn't have my real SSN so I couldn't tell them the what their screen displayed for my account. Today I called and simply said there was a problem with my account, the record had the wrong SSN, and I'd like to fix it. No problem, no identity verification, the rep happily accepted four new digits, which I then used on their Web site to update my account.
In RISKS-24.74 PGN rightly casts doubt on the validity of 'proof by simulation'. I'm a fan of well designed simulations. In a former life I was involved in the testing of a control system for a chemical plant. We created a faithful simulation of the plant, then arranged for our simulator to output voltages that mimicked the sensors that were in the real plant. We then plugged these outputs into the control system and went through a series of tests. The results were totally unexpected. It failed, in some cases the simulated plant responded too slowly. We assumed that the problem was the simulation or the interfaces. After much study we concluded it wasn't. The control system was at fault, and in a subtle way, the control blocks covering the most time critical loops had been spread over multiple processors and the inter-processor communication was introducing a significant delay. The manufacturer 're-optimized' the loops and the problem was fixed. Used appropriately simulations (or stimulations ?) can tell you things you couldn't easily find any other way, so should be in the toolbox of any serious tester.
Consider the risks of live-testing the backup software. If it has a bug, you've potentially lost a shuttle and crew. Brings a whole new meaning to "live testing", doesn't it? Since the backup software isn't going to ever be used until after the fecal matter has hit the rotary impeller at high velocity (does the shuttle toilet have a rotary impeller? IIRC it does...), not testing it under live conditions may well be the lower-risk path. Sometimes the risks of testing outweigh the benefits. [Added note: Well, I was struck by the meta-risk. Or maybe it's better classed as a "reentrant risk" (smirk). RW]
"The picture clearly shows the firing handle." Yes, of a Mk.10LH seat. It looks different on a Mk.10LS seat as can be seen here: http://www.canit.se/%7Egriffon/aviation/img/ljungbyhed96/mbmk10.jpg Photo shows a A/B version seat, the C/D was given a stiffer handle. Saab says they were able to duplicate the initiation using test subjects with large thighs, the temporary fix was to restrict flying to 3G and the air force has said the permanent fix is to fit more flexible handles. Doesn't seem like there's any doubt as to what happened although the official investigation is still listed as ongoing.
[seat firing handle] >The handle itself is flexible and can be deformed; it's like stiff wire, so >if the anti-g suit is responsible then it must impart at least 15 pounds of >force upwards after deforming the handle and move the handle at least one >inch. Something which I really can't see happening. >Typhoon uses the Martin-Baker Mk16A seat Please note the handle has been changed in the Gripen C/D-versions: the "wire" is replaced with a heart-formed ring on a short stick. So, the Typhoon comparison isn't relevant. A picture of the handle versions can be found at http://www.nyteknik.se/art/51034 [text in Swedish only]. A SAAB spokesman says in the article (from June 5th) the handle has been found slightly pushed upwards and not always full retracted after repeated occasions of high G-load in performed tests after the crash, and that all handles now should be replaced with a more soft handle like the one in earlier Gripen versions.
There may be a way the ejection handle can get pulled. Start with a high-g turn, pitch up, causing the suit to inflate and grip the handle. Follow it with a high-g turn, pitch down, causing the pilot to be pulled up into the belts while the suit is still inflated. If the belts are loose or if they stretch, the pilot could move up by an inch.
BKBAKREC.RVW 20070302 "Backup and Recovery", W. Curtis Preston, 2007, 0-596-10246-1, U$49.99/C$64.99 %A W. Curtis Preston www.backupcentral.com firstname.lastname@example.org %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2007 %G 0-596-10246-1 978-0-596-10246-3 %I O'Reilly & Associates, Inc. %O U$49.99/C$64.99 800-998-9938 fax: 707-829-0104 email@example.com %O http://www.amazon.com/exec/obidos/ASIN/0596102461/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596102461/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596102461/robsladesin03-20 %O Audience a Tech 2 Writing 1 (see revfaq.htm for explanation) %P 729 p. %T "Backup and Recovery" We tell people to make backups. Occasionally we might mention the difference between full, differential, and incremental backups. If we are turning out hotshot forensics specialists we might even go into the difference between file image backups and disk image backups. But how often do we tell people that operational databases (which is most of them) have open files, and generally prevent you from backing up with the usual utilities? Part one is an introduction. Chapter one is an overview of some quick aspects about backups, but primarily is a suggestion to do it, and do it properly. Basic types of backups, and the factors affecting backup procedures, are outlined in chapter two. (The material will probably feel very familiar to those who have worked in the business continuity field: not just because of the importance of backups in recovery operations, but also because of the analysis of the complex and interdependent linkages that can cause disasters.) Part two examines open source backup utilities. (Most of them are open source: a few are just "free.") Chapter three reviews some of the utilities for UNIX, Linux, Windows, and the Mac that can provide fundamental backup capabilities, and which can also be used by other applications for more sophisticated backup systems. Amanda (the Advanced Maryland Automated Network Disk Archiver), an open source, cross-platform, client/server architecture (Windows servers do not appear to be available, but clients are) backup system that uses some of these underlying tools is described in chapter four. Amanda has some very interesting security and scheduling provisions. BackupPC, a network-based backup system for UNIX (client or server) and Windows (client) is briefly described in chapter five. Chapter six explains another distributed system, Bacula, in a rather haphazard manner. Rsnapshot, which does near-continuous backup, is delineated in chapter seven. Part three supposedly turns to commercial backup products. In fact, the contents are simply a list of factors to be used when evaluating software products (chapter eight) and various types of hardware (nine). Bare-metal recovery (what you do to restore the system when you've lost the whole thing, rather than just a few files) is described in part four. The Solaris flash archive is intended for cloning of systems, but chapter ten tells how to use it for recovery. Chapter eleven explains tools and procedures for Linux, and a little tiny bit for Windows as well. Procedures for HP-UX are in twelve, AIX in thirteen, and Mac OS X (which basically has a version of BSD under the graphical user interface) is in fourteen. Database systems have a) lots and lots of data, b) special backup requirements, and c) a special importance to most companies, so this application gets special attention in part five. General concepts are discussed in chapter fifteen, with the particulars of backup and recovery for Oracle, Sybase, DB2, SQL Server, Microsoft's Exchange (well, an email server certainly *uses* a database ...), PostgreSQL, and MySQL in chapters sixteen to twenty-two. Part six covers miscellaneous topics. Actually, it is chapter twenty-three that contains miscellaneous topics (starting out with how to back up VMWare servers). Chapter twenty-four is a justification for the book (or, for having a backup process, anyhow). Preston's work is directed at inexpensive backup solutions for open systems, so it is not surprising that UNIX utilities get the most space and the greatest attention to detail. Windows is certainly not ignored, and the author even bends his own rules to accommodate some helpful utilities in the Windows realm, but there simply isn't a lot of material to work with. Backups are important for everyone. This book is not for everyone. The text will be very valuable for those who have large systems, or large numbers of systems, with backup needs complicated by special situations. Now go make a backup. copyright Robert M. Slade, 2007 BKBAKREC.RVW 20070302 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer