[Do you recall "Hospital operates on wrong patient?" (lead item in RISKS-24.11)? This is the other side of the coin. TNX to Lauren Weinstein for sending this one to me. PGN] Hospitals Cut Lethal Errors Rate, Mike Stobbe, AP item,*Newsday*, 14 Jun 2006 http://www.newsday.com/news/nationworld/wire/sns-ap-hospital-lifesavers,0,6425411.story?coll=sns-ap-nationworld-headlines A campaign to reduce lethal errors and unnecessary deaths in U.S. hospitals has saved an estimated 122,300 lives in the last 18 months. About 3,100 hospitals participated in the project, sharing mortality data and carrying out study-tested procedures that prevent infections and mistakes. Experts say the cooperative effort was unusual for a competitive industry that traditionally doesn't like to publicly focus on patient-killing problems. Medical mistakes were the focus of a widely noted 1999 national report that estimated 44,000 to 98,000 Americans die each year as a result of errors and low-quality care. Perhaps the best known of the six changes was to deploy rapid response teams for emergency care of patients whose vital signs suddenly deteriorate. ... Another urged checks and rechecks of patient medications to protect against drug errors. A third focused on preventing surgical site infections by following certain guidelines, including giving patients antibiotics before their operations.
Dick Smith  is warning  that the new ADS-B air traffic system  uses unverified data to plot what (supposedly real) aircraft are doing: > But Mr Smith, who is campaigning against the scheme and has raised safety > and security concerns about the design, said the system had no way of > verifying whether a plane was where it claimed to be or if it existed at > all. > > He said the FAA was looking at ways of encrypting signals or setting up > multiple ground stations at each location to allow the traffic controllers > to determine whether a signal came from a moving aircraft. The main advantage of the system is that radar (which is expensive to buy and run) is not needed since aircraft broadcast their (supposed) position, and that data can be received using less expensive equipment. Aircraft determine their position by GPS. I'm sure the disadvantages of an unauthenticated positioning system don't have to be spelled out.  http://en.wikipedia.org/wiki/Dick_Smith  http://www.theaustralian.news.com.au/story/0,20867,19378061-23349,00.html  http://en.wikipedia.org/wiki/Automatic_Dependent_Surveillance-Broadcast
Below you'll find an executive summary of "Security Implications of Applying the Communications Assistance for Law Enforcement Act to Voice over IP." The full report is at http://www.itaa.org/news/docs/CALEAVOIPreport.pdf . Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP Steven Bellovin, Columbia University Matt Blaze, University of Pennsylvania Ernest Brickell, Intel Corporation Clinton Brooks, NSA (retired) Vinton Cerf, Google Whitfield Diffie, Sun Microsystems Susan Landau, Sun Microsystems Jon Peterson, NeuStar John Treichler, Applied Signal Technology Executive Summary For many people, Voice over Internet Protocol (VoIP) looks like a nimble way of using a computer to make phone calls. Download the software, pick an identifier and then wherever there is an Internet connection, you can make a phone call. From this perspective, it makes perfect sense that anything that can be done with a telephone, including the graceful accommodation of wiretapping, should be able to be done readily with VoIP as well. The FCC has issued an order for all ``interconnected'' and all broadband access VoIP services to comply with Communications Assistance for Law Enforcement Act (CALEA) --- without specific regulations on what compliance would mean. The FBI has suggested that CALEA should apply to all forms of VoIP, regardless of the technology involved in the VoIP implementation. Intercept against a VoIP call made from a fixed location with a fixed IP address directly to a big Internet provider's access router is equivalent to wiretapping a normal phone call, and classical PSTN-style CALEA concepts can be applied directly. In fact, these intercept capabilities can be exactly the same in the VoIP case if the ISP properly secures its infrastructure and wiretap control process as the PSTN's central offices are assumed to do. However, the network architectures of the Internet and the Public Switched Telephone Network (PSTN) are substantially different, and these differences lead to security risks in applying the CALEA to VoIP. VoIP, like most Internet communications, are communications for a mobile environment. The feasibility of applying CALEA to more decentralized VoIP services is quite problematic. Neither the manageability of such a wiretapping regime nor whether it can be made secure against subversion seem clear. The real danger is that a CALEA-type regimen is likely to introduce serious vulnerabilities through its ``architected security breach.'' Potential problems include the difficulty of determining where the traffic is coming from (the VoIP provider enables the connection but may not provide the services for the actual conversation), the difficulty of ensuring safe transport of the signals to the law-enforcement facility, the risk of introducing new vulnerabilities into Internet communications, and the difficulty of ensuring proper minimization. VOIP implementations vary substantially across the Internet making it impossible to implement CALEA uniformly. Mobility and the ease of creating new identities on the Internet exacerbate the problem. Building a comprehensive VoIP intercept capability into the Internet appears to require the cooperation of a very large portion of the routing infrastructure, and the fact that packets are carrying voice is largely irrelevant. Indeed, most of the provisions of the wiretap law do not distinguish among different types of electronic communications. Currently the FBI is focused on applying CALEA's design mandates to VoIP, but there is nothing in wiretapping law that would argue against the extension of intercept design mandates to all types of Internet communications. Indeed, the changes necessary to meet CALEA requirements for VoIP would likely have to be implemented in a way that covered all forms of Internet communication. In order to extend authorized interception much beyond the easy scenario, it is necessary either to eliminate the flexibility that Internet communications allow, or else introduce serious security risks to domestic VoIP implementations. The former would have significant negative effects on U.S. ability to innovate, while the latter is simply dangerous. The current FBI and FCC direction on CALEA applied to VoIP carries great risks.
go.eweek.com/tiaa IT Manager seeks redress for firing, claiming SARBOX Whistleblower protection http://www.eweek.com/article2/0,1759,1969518,00.asp US Supreme Court lowers Whistleblower protection for employees reporting fraud or criminal misconduct to the proper authorities, but employees have more protection if they go straight to the news media http://www.accountingweb.com/cgi-bin/item.cgi?id=102230&d=815&h=817&f=816&dateformat=%25B%20%25e,%20%25Y http://www.forbes.com/technology/feeds/ap/2006/05/30/ap2780736.html http://civilliberty.about.com/b/a/257515.htm This is a familiar and disturbing picture. Personnel find security problems with employer systems, report them, nothing happens. Computer staff exhaust what can be done in-house to get the security problems resolved, but leadership resistance is too strong. A year later there is a serious security breach. Top Managers claim nothing much at risk, but ask computer staff to help the feds find out exactly what was breached, which turns out to be practically everything. Computer staff gets fired. What makes this worse is the news that the Feds apparently support the coverup, when the whistleblowers appeal the employer punitive action. Had computer staff lied to investigators, claiming no problem, like management had wanted, they would still have their jobs. Thus computer workers have to balance behavior that will help career integrity vs. what is in the best interests of protecting customers and investors. However, there are lots of news stories of whistleblowers who successfully prevail, so we should wait and see what happens in this case.
I just read the new plan for funding information security at the Federal level and it was pathetic. The most notable element of it is the fact that they claim to align between several different things but in fact they don't align at all. The things they identify as worth doing are the very things that don't need to be done and the things they identify as not worth doing are the things we most desperately need. But fear not - they won't put any real money behind anything worthwhile in any case. The plan - if fully implemented - would not even stop the large-scale theft of identity information of all the people getting clearances or all the folks in the military. So we won't be getting much in the way of help from the federal government in advancing the field for the next few years at least. www.nitrd.gov/pubs/csia/csia_federal_plan.pdf Fred Cohen & Associates; Security Posture; University of New Haven; ASP Press all.net, securityposture.com, unhca.com, asp-press.com, 1-925-454-0171
An Internal Revenue Service employee lost an agency laptop early last month that contained sensitive personal information on 291 workers and job applicants, a spokesman said yesterday. The IRS's Terry L. Lemons said the employee checked the laptop as luggage aboard a commercial flight while traveling to a job fair and never saw it again. The computer contained unencrypted names, birth dates, Social Security numbers and fingerprints of the employees and applicants, Lemons said. Slightly more than 100 of the people affected were IRS employees, he said. No tax return information was in the laptop, he said. "The data was not encrypted, but it was protected by a double-password system," Lemons said. "To get in to this personal data on there, you would have to have two separate passwords." Lemons said the Treasury Department's inspector general for tax administration is investigating the loss. The IRS is notifying affected individuals and advising them on steps to guard against identity theft. Lemons declined to name the airline or the employee, or to say whether the worker was disciplined, citing the ongoing investigation. ... [Source: Christopher Lee, *The Washington Post*, 8 Jun2006, A04; PGN-ed] http://www.washingtonpost.com/wp-dyn/content/article/2006/06/07/AR2006060701987.html
There have been some murmurs about this in other forums, but since I've now independently verified I figured I'd better report here. A recent Microsoft update to Windows XP, which modifies the tool that verifies the "validity" of XP installations to ensure that they are not illicit, may itself be considered to be spyware under commonly accepted definitions. The new version of the "Microsoft Genuine Advantage" tool reportedly will repeatedly nag users of systems it declares to be invalid, and will then apparently deny such users various "non-critical" updates. Apparently various parties have already found ways to bypass this tool, though the effects of this on later updating capabilities remain to be seen. However, I've noted a much more serious issue on local XP systems, all of which are legit and pass the MS validity tests with flying colors. It appears that even on such systems, the MS tool will now attempt to contact Microsoft over the Internet *every time you boot*. At least, I'm seeing these contacts on every boot after the tool update so far, and I've allowed them to proceed to completion each time. Perhaps it stops after some number of boots, but there's no indication of such a limit so far. The connections occur even if you do not have Windows "automatic update" enabled. ... http://www.interesting-people.org/archives/interesting-people/200606/msg00030.html
An anonymous Slashdot user gives virus writers a worrying idea: "A virus could use one of the 'Product-Key Changer' scripts ... to install a pirated product key on every infected computer (wiping all traces of the original key). This would render millions of genuine installations indistinguishable from pirated installations. What a mess for Microsoft! They would have to immediately 'kill forever' the WGA helper, and maybe even remove the WGA check on Windows Update. Such a virus would be a hard lesson to learn for the writers of all kinds of automated 'genuine' checks."
Foot dragging on an incident which occurred in September 2005... [and was not reported until 8 June 2006. PGN] Energy Dept. Discloses Data Theft Victims, Top Officials Were Not Told About 2005 Hacking A hacker stole a file containing the names and Social Security numbers of 1,500 people working for the Energy Department's nuclear weapons agency. [Source: Associated Press item, *The Washington Post*, 10 Jun 2006, A04] http://www.washingtonpost.com/wp-dyn/content/article/2006/06/09/AR2006060901505.html
The credit card companies publish what is colloquially known as as the PCI standard. For the standard itself, see: http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf This covers various aspects of security for organisations that are involved in the processing of credit cards. I'm surprised to see however that where they suggest that cardholder data is secured: Render sensitive cardholder data unreadable anywhere it is stored (including data on portable media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches. -One-way hashes (hashed indexes), such as SHA-1 -Truncation -Index tokens and PADs, with the PADs being securely stored -Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key management processes and procedures. They omit to mention that one-way hashes of cardholder data are of little use without applying a salt. They should - as has been documented here before many programmers see no problem in wrapping a bare md5 function around a sensitive value. For instance - as is well known 16 digit credit card numbers start with a 6 digit bank code and end with a checksum. A reverse hash dictionary for all unsalted MD5 codes for one bank code only needs to cover 16-6-1=9 digits of possibilities - or one thousand million entries. This could be done for a storage cost of: 9 digit number = 4 bytes MD5 checksum = 16 bytes number Total = 20 bytes * 1,000,000,000 possibilites = 20Gb As a result its completely feasible a program that asks for unsalted MD5 or SHA-1 Hash of a credit card number and the 6 digit bank code could generate the original credit card number after waiting for that bank code's 20gb dictionary to be generated. Mark Ennis, NetCommute Ltd. <firstname.lastname@example.org> 00-353-1-8569539
In my Inbox: > CONGRATULATIONS: YOU WON -1,000,000.00 EUROS. I'm sure they'd like me to give them 1 million Euros, but I think not. With my permission, they'll even enter me into a drawing for -5 Million Euros! Wow, my lucky day! :-)
Personal experience, with my dentist yesterday evening. It was a typical visit, except now my dentist is using a new digital x-ray machine (from Kodak) that runs on a standard PC (probably this system: http://www.kodak.com/global/en/health/dental/documentation/sysReqs/KDIS.pdf ). The process to take the X-Ray is relatively the same as the old analog method. Noticeable differences: 1) the X-Ray machine is physically smaller, 2) there is no film, but in its place is a reusable digital sensor with a trailing wire leading out of the patients mouth. 3) images are rendered immediately on a screen, so the tech can determine if the shot taken is OK or needs to be re-taken. 4) the images are very clear and noticeably sharper then the analog X-Rays (to my untrained eye). Now the not so fun part. After the tech completes the set of 6 pictures, the dentist comes in to review. A few clicks and pop ups appear, a few too quick clicks, and poof, the images are accidentally deleted and not retrievable. The tech admitted afterward that she usually does a save before the dentist comes in. OK, lets do it again. Take a second set of images. The tech does the save, but an hour glass comes up and the PC freezes. The images are mostly still visible on the screen, except there are a couple of pop-ups that are blocking one of the images of my teeth and they can not be moved. The dentist comes in to review the images, but can not access the application, since it is not functioning. The obvious thing to do is a CTL-ALT-DEL to see what is going on. The CPU is idle, but the app is "not responding". The dentist claims that this is the first problem he has had in the few months he has been using the system. Since most of the images are actually still viewable, he does his assessment, then starts to end the hung processes. Eventually a "Send Error Report" window appears giving the user the option to send in an error report to the software maker, which he elects not to send. He reboots, then brings up the application, and then tries to access my patient record and see if the X-Ray images were actually saved, but the app gives him an error. My guess is that a file corruption occurred. Of Note: The PC is Internet enabled, via dial-up access. I believe it is used to transmit data for insurance processing (as confirmed via link below). Aside from the obvious application issues described above, I started to wonder about HIPAA issues and how well my data/info is protected by this PC linked to the Internet. Also, thinking about what backup systems are in use, etc. Another thought--how easy would it be to manipulate the digital images to sabotage a forensics investigation (another great use of PhotoShop!)? Delete the images to prevent the positive ID of a body, or better yet, cause a body to be incorrectly identified (e.g., fake ones death). Do these images have digital signatures? (Doubt it!) While I didn't dig into it deeply, its just a matter of time before ... Here is a link to an online article (WSJ reprint?): http://www.mindfully.org/Technology/2005/Dental-X-Ray-Digital29nov05.htm It highlights some pros/cons of going digital. Howard Israel, CEO, Secure Systems Consulting, LLC 1-732-613-9464
The second edition of the Silver Bullet Security Podcast with Gary McGraw (hey, that's me) went up just a few seconds ago: http://www.cigital.com/silverbullet/ The first show (with Avi Rubin) proved to be pretty popular. Hope you all like this one too! Feedback welcome through the website. Marcus Ranum is on deck and Dana Epp is on the list. Who else do you want to hear from in Silver Bullet? gem www.cigital.com www.swsec.com
BKSWSBSI.RVW 20060518 "Software Security: Building Security In", Gary McGraw, 2006, 0-321-35670-5, U$49.99/C$66.99 %A Gary McGraw swsec.com www.buildingsecurityin.com email@example.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2006 %G 0-321-35670-5 %I Addison-Wesley Publishing Co. %O U$49.99/C$66.99 416-447-5101 800-822-6339 firstname.lastname@example.org %O http://www.amazon.com/exec/obidos/ASIN/0321356705/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321356705/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321356705/robsladesin03-20 %O Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation) %P 408 p. + CD-ROM %T "Software Security: Building Security In" The preface states that the audience for the book is comprised of developers (particularly those interested in secure software), security professionals (in places), managers (in places), and academics (there are a couple of chapters that indicate where further research might be useful). McGraw also introduces the major components of the book. His "thee pillars" are not the usual confidentiality, integrity and availability, but risk management, "touchpoints," and knowledge. The touchpoints are code analysis, risk analysis, penetration (vulnerability) testing, security tests, abuse cases, security requirements, and security operations. Part one outlines the basics of software security. Chapter one informs us that problems exist in software, and notes the differences between bugs (due to careless implementation) and flaws (due to poor design). McGraw also suggests his three pillars as a means of addressing the difficulty. Using an example software project, chapter two takes us through a risk management framework in some detail. Part two examines the touchpoints. Chapter three introduces them in a diagram related to the steps in the software development process (they are numbered, although in a seemingly random pattern which turns out to be the suggested order of effectiveness). (The latter half of the chapter seems to be more of a sermon on software security.) Source code review tools (for finding bugs) are described in chapter four. Chapter five starts off with traditional risk analysis definitions and then extends the concept with details of the application of the process to software design. (Sidebars on software tools for program risk analysis, and other related items, are dropped in seemingly at random. The information is valuable, but the reading flow is somewhat disjointed.) Penetration testing of software sounds like a good idea, but chapter six doesn't really define what the topic involves. (The sidebar on tools is a case in point: the tools are listed and recommended, but the descriptions don't say what they actually do.) Risk-based security testing seems, by the end of chapter seven, to be a special case of spanning tree analysis, but along the way a number of the other touchpoints seem to overlap with it. "Abuse cases" is the application of known common vulnerabilities and attacks (perpetrated on systems similar to yours), and analysis of means of protection while still in the design phase. Chapter eight provides a handy list of such attacks (if you are building a Web application). "Security operations," in chapter nine, appears to be a discussion of how software developers and security professionals should relate to each other. (Touchpoint six, "security requirements," is not covered.) Part three covers additional topics. Chapter ten outlines advice for a software security program in a large company. "Knowledge for software security," in chapter eleven, is mostly an overview of material already covered, but does include some additional tools. Chapter twelve is a taxonomy of coding errors, which should be valuable both for those working on analysis of their own program security, and also researchers in the field. One fairly consistent weakness is that the book seems to assume that all software applications are network-based, and that all software problems result from malicious attacks. While Web-based applications are definitely of great importance, and also subject to a larger range of difficulties, this does limit the application of some of the material of the text in regard to standalone programs where the major concern is integrity of data, prevention of errors, and reliability of operation. The writing and structure could use some work: in many situations it is not easy to follow the thread of McGraw's argument. However, there is no denying the value of having all these ideas about software security brought together in one volume. There is a great deal of useful and interesting material here, and, with commitment from the reader, much that will be helpful in building more robust and reliable software. copyright Robert M. Slade, 2006 BKSWSBSI.RVW 20060518 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer