A power blackout shut down the Los Angeles Air Route Traffic Control Center in Palmdale CA for three hours on the evening of 18 July 2006, following a power outage and the failure of the backup power system. The original power outage was caused by a pickup truck hitting a utility pole. This automatically caused a cutover to the backup power system, but the switching system failed an hour later. The Palmdale ATC was without phones (!), computers, and radar for two hours, and another hour was required to get things running again. As a result, 348 flights around the U.S. were canceled, delayed, or diverted, 221 of them at LAX. One flight from Canada to LAX was diverted to San Jose. The problem even delayed a test launch of a Minuteman III missile from Vandenberg Air Force Base, which would have required controlled access to the airspace. [Source: Daisy Nguyen, Associated Press, seen in the *Palo Alto Daily News*, 20 July 2006; PGN-ed]
The Massachusetts public safety commissioner yesterday suspended 20 state building and engineering inspectors for refusing to accept cellphones equipped with global positioning systems. Only two inspectors accepted the phones; another two were out on vacation when Commissioner Thomas Gatzunis tried to distribute the phones, which supervisors want to use to keep track of the inspectors during the work day. ... [Source: Andrea Estes, 20 inspectors suspended over GPS: Public safety chief metes out discipline, *The Boston Globe*, 11 Jul 2006] http://www.boston.com/news/local/articles/2006/07/11/20_inspectors_suspended_over_gps/
[Source: Chris Williams, PlusNet obliterates customer e-mails; Punters cut-off by bungling storage update, *The Register*, 11 Jul 2006; PGN-ed] http://www.theregister.co.uk/2006/07/11/plusnet_email_fiasco/ In the process of upgrading its storage management, PlusNet deleted more than 700GB of its customers' e-mail and disabled the ability of about half its 140,000 users to send and receive new e-mail. "At the time of making this change the engineer had two management console sessions open one to the backup storage system and one to live storage. These both have the same interface, and until [then] it was impossible to open more than one connection to any part of the storage system at once." Patches were installed, but the engineer assumed he was working with the backup rather than the live server. Thus, "the command to reconfigure the disk pack and remove all data therein was made to the wrong server."
As necessary as it is, blacklisting purportedly for SPAM control has terrible potential for abuse and mischief, especially when Internet service providers outsource the function to third parties, such as BrightMail, and entrust them with screening decisions. In my own recent experience, known good legitimate e-mail messages from a critical vendor (OrCAD software) were deleted without a trace, without recourse, without explanation, and neither I nor my ISP nor my address forwarder could to a damn thing about it — we couldn't even get logs evidence of the deletion, nor rules documenting whether or not the deletion should take place (but we could prove it by sending the same messages to a different address). Worse, I have seen skewing of issue-oriented (political, etc.) e-mail being filtered or not -- should this be in the hands of unaccountable third parties? Dear IEEE Alias User, ... The IEEE became aware that "comcast.net" was blacklisting IEEE's e-mail servers. As a result "ieee.org" e-mail forwarded to "comcast.net" e-mail accounts was being rejected. ... Peter F. Klammer, P.E., NETRONICS Professional Engineering, Inc. 3200 Routt Street, Wheat Ridge, Colorado 80033-5452 (303)274-6182 [If anyone sent e-mail to me at firstname.lastname@example.org, it should be good again.]
Blogger Arve Bersvendsen, back in February of this year, posted a summary of a Swedish magazine article mentioning that the MSN Messenger service (or Live Messenger, as it's known now) has been automatically blocking the transmission of certain messages based on very primitive keyword matching <http://virtuelvis.com/archives/ 2006/02/microsoft-censoring-msn-messenger>. The post went largely unnoticed for much of the year, but recently it surfaced on Digg.com, where it suddenly garnered a lot more attention. <http://digg.com/software/Microsoft_censors_MSN_Messenger> The concept underlying MSN's block was perfectly reasonable-- they were simply trying to prevent the spread of certain worms via malicious web links. The execution, on the other hand, was severely lacking. There's absolutely no notification to the receiver that anything was blocked, and only an extremely delayed notification to the sender. The worst part of the execution, however, is the actual choice of strings that MSN deemed worthy of blocking. Though no master list has been made public, various users have discovered that "download.php", "gallery.php", "profile.php?", and even ".pif" and ".scr" contained anywhere in a message will prevent that entire message from going through. Apologists will rightly claim that every one of these strings has been used in the URLs of malicious worms at some point-- but there's far more potential for false positives, as a cursory Google search for "download.php" will quickly reveal, and besides, the worm writers can easily stay ahead of the block by just changing a few filenames before their next release. The Risks here should be obvious to anyone who wishes to send a link to Dave Winer's blog at <http://www.scripting.com/>, the Scranton Times-Tribune at <http://www.scrantontimes.com/>, or any one of numerous other perfectly legitimate URLs that happen to contain one of the blocked strings. Cody "codeman38" Boisclair email@example.com http://www.zone38.net/
Companies can be plagued with bad dirty data. Companies make business decisions based on their data. The soundness of those decisions is negatively affected by the degree to which there is bad data. The degree to which various CASE tools, spread sheets, queries, etc. have helped just anyone get at data, has also had the effect of lowering quality control on data going into reports, because while many people are skilled at data processing, and testing veracity of data, many are not. http://www.itjungle.com/tfh/tfh071006-story08.html
What are the odds? 1 in 6 of laptop or PDA stolen 4 in 5 data files stored unencrypted 2 in 3 data files transferred unencrypted 1 in 2 limits users ability to install whatever they please, irrespective of risks 1 in 5 suffered data or network sabotage 1 in 4 not know if computers have been illegally accessed 2 in 5 not keep log of computer security incidents 9 in 10 suffered a computer security incident during the past year ALL enterprises have some software installed on desk tops that computer staff not know are there, and would not approve of if they did know Other common problems * Systems for security, that are so complicated that no one uses them, are as bad as having no security at all, * Computer systems functionality depends on various configuration files ... who has access to them? * Security needs to be documented, otherwise investigators will assume you did not do it * Employees bring unsecure home systems to the office, plug them into corporate systems and guess what? now the corporate systems are unsecure. Example, some employee at a financial institution had a lap top from home with the wireless port wide open, plugs it into the system at work, which is now wide open over the wireless port * Each new technology has new security weaknesses unknown to people installing them * Executives consider corporate security rules do not apply to them, they are free to break any of them * People think the laptop breach laws do not apply to other portable devices that can carry corporate data ... they are wrong * Data is backed up, but can it also be restored in a crisis ... there should be periodic checks that backups are getting everything they ought to What keeps IT up at night? http://www.infoworld.com/article/06/07/17/79603_29FEnightsweats_1.html
I got a call this week from a Florida number. When I answered a recorded voice said that the fraud early warning dept of Citibank had a detected activity on my card and would I call them back at 888-...-.... RISKS readers will no doubt see the problem here - I could be calling anybody. Since the first thing the Citibank system asks is that you touch tone or speak your card number customers are already expecting to give this information. It would be trivial to also then ask for the CVV number and exp date. Combine this with a name and address obtainable from numerous databases to complete the data needed for fraud. With PC based VOIP systems constructing such a scam that would call hundreds of people, trolling for numbers, would be close to trivial and very hard to track. I suspect it would actually work better than having a real human ask for the info in that we are all conditioned to provide whatever the auto attendant says it needs ... The answer is simple customers should call the number on the back of the card never a number given on the phone and banks should not ask customer to call unknown numbers. (P.S. as it happens this call was real but a false positive, the Citibank system has a lot of those, but that's another risk entirely)
Retro computing, also known as "computation for old guys" is all rather charming, and creates a valuable historical record. As an old guy who started on the IBM 1401, I suppose I should support the (re)building of a working 1401 at the Computer History Museum in Mountain View. But I have serious reservations. The hardware system is being rebuilt down to the bare metal using original technology including devices of some toxicity. This adds a somewhat useless object to the world's stock of useless objects in view of the fact that the IBM 1401 can be completely simulated on a modern computer without additional toxicity: without making a new artifact of questionable usability. It will when complete demonstrate what old computing was like, which was noisy and rather satisfying if you were a young guy which I was. However, this presents as an "important document" just one of many computers, a computer which even in 1959 had significant limitations. The 1401 was slow even in 1959 with an 11.5 ms cycle time. It used a strange technique for addition and subtraction, called CADT (cannot add and does not try) in which transistors essentially acted as decimal addition tables. Modular programming was discouraged because there was no indirect addressing. The 1401 was aggressively marketed by IBM worldwide in a rather dishonest campaign in which fearful, uncertain and doubtful managers were told it was nothing more than a glorified printer, an accounting machine, and not really a computer. Unfortunately it was and had marvelously arcane secrets. But, these secrets also constituted a waste of time. What's needed in place of weekend projects for retired engineers would be a truly global encyclopedia in the form of software simulators (perhaps in the form of a computer game) for all or most early world computers. I don't think that recreating the actual hardware of the 1401 will damage silicon valley's water table any more that it has been damaged; yet I cannot escape a sense of recursive inelegance in the idea of having to rebuild a system. Scaling up into the future, will more and more Old Guys be involved in recreating more and more outdated systems until we're all so busy doing retro computing we have no time for lunch? When I visited the Computer Museum, I sensed somehow its psychology to be hardware oriented, oriented toward a work ethic in which reification, making a concept into a thing, reigned supreme. Lost in the reified history is of course the programmers who had to write a divide routine because IBM was too greedy to appropriately bundle the "extra cost hardware" into the system. Lost in the reified history is the code that simulated divide incorrectly, and lost too is the Fortran compiler in which I discovered a handcoded multiply divide routine, inserted as a machine-language patch, by an IBM customer engineer who thought the machine had no multiply/divide hardware (it did) but didn't realize that there was no memory for the patch at all on a minimal Fortran machine. Lost in the reified history is the story of Labor. Resources currently wasted in building working models of old devices could be used to create oral histories of early computing. Of course, such an history would be necessarily a critical history offensive to the sensitivities of the Computer Museum's corporate sponsors.bouffant Such an history would include not the professional models who pose so elegantly in front of advertising snapshots of the 1401 in business suits and bouffant hairdos but also operators in tears and exhausted programmers (whose IBM training course was silent on Modify Address). Cf. David Noble, Forces of Production. History is herstory and history, not itsstory, the story of devices. What's being reassembled is a device driven too much by exchange value and not enough by use value. It deserves to be simulated but, perhaps, not rebuilt.
Another Australian in Beirut says the Australian consulate refused to register his presence in Lebanon, instead referring him to a website. Austin Mackell has been living in Lebanon since February and says that with electricity out in much of Beirut it is almost impossible to register his presence online. (The Australian Government closed the consulate as soon as the bombing started.) http://www.theage.com.au/news/world/downer-defends-evacuation/2006/07/20/1153166495858.html Tim Chmielewski, Webmaster, Human Edge Software http://www.humanedge.biz <http://www.humanedge.biz/>
(Emigh, RISKS-24.34) I once received a TIF file of a document that was exactly that: a scanned faxed image. But since the faxed printout was intended as a temporary step, the sender used the back side of old printed pages for that. When I noticed that the background of the sent TIF file was not completely white, it only took a few b&w enhancement steps in a graphics application, to clearly reveal what the sender did not intend to send! There is even a risk in using blank paper for that, keeping in mind the "secret" yellow-dot identification code which is generated by many printers...
> .. the attempt to attribute human characteristics to machines is bound to > cause problems. Er, not quite. The UK Government web site says "Revised offence of obtaining services dishonestly (to fill a legal loophole, since a machine cannot be 'deceived') with a maximum penalty of five years' imprisonment." http://www.commonsleader.gov.uk/output/page1221.asp Frazer-Nash Consultancy Limited, Stonebridge House, Dorking Business Park, Dorking, Surrey RH4 1HJ +44 (0) 1306 885050
BKINSTHR.RVW 20060615 "Insider Threat", Eric Cole/Sandra Ring, 2006, 1-59749-048-2, U$34.95/C$48.95 %A Eric Cole %A Sandra Ring %C 800 Hingham Street, Rockland, MA 02370 %D 2006 %G 1-59749-048-2 %I Syngress Media, Inc. %O U$34.95/C$48.95 781-681-5151 fax: 781-681-3585 www.syngress.com %O http://www.amazon.com/exec/obidos/ASIN/1597490482/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1597490482/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1597490482/robsladesin03-20 %O Audience n- Tech 1 Writing 1 (see revfaq.htm for explanation) %P 397 p. %T "Insider Threat" Abuse of your systems by insiders, those who have intimate knowledge of an enterprise and its protective controls because they are either employees or close partners, has always been a great security risk. In most cases these people are aware of the existing safeguards, and usually some means to get around them: in a large number of situations inside people actually operate and manage security countermeasures and auditing functions. Protecting yourself against insider attack is tricky. (However, while we all know about insider attacks, insider abuse, and that these are major problems, the term "insider threat" may be incorrect, and the phrase itself an obstacle. In viewing employees, staff, contractors, and partners as threats, instead of assets, we are making a serious mistake in our definitions, and one that can have serious negative consequences for the overall security of the enterprise.) Part one examines insider threat basics. Chapter one points out that insiders are threats. Various technologies for carrying or hiding information are described in chapter two (although the text does admit that one possibility for info release is the fact your employees simply leave the building every night with everything they know). Part two looks at government. Chapter three, about state and local authorities, notes the type of functions that are managed at this level, and the damage that can be done if this information is misused. The material seems to be bundled together in a random fashion. There are a number of "case studies," which are really just stories of situations where an insider has abused his or her position. Much the same is done with the federal government in chapter four. Part three turns to corporations. Chapter five starts off with an extremely odd statement, seeming to imply that nobody was much aware of the insider threat until a 1998 study. (However, this may signal one of the major problems with the book: the term "insider threat" was first used in a classified paper in 1997.) It has a brief, but useful, examination of various types of damage that an insider can do in a commercial enterprise (sabotage, theft of intellectual property, theft of customer data, damage to reputation, and direct financial fraud), and then we are back to the stories again. More case studies are given regarding the banking and financial sector, in chapter six, and government subcontractors, in seven. Part four is entitled "Analysis," but there isn't all that much. Chapter eight looks at profiles, despite the fact that the second last case study (in chapter seven) noted that the insider was so successful because he didn't fit the commonly perceived profile. The basic profile provided may be helpful in distinguishing low-end threats who may deserve further examination: the "high-end" profile identifies most senior managers. The responses suggested in chapter nine are primarily basic protections (and mostly suitable for defending against outside threats); some of the additional measures are only effective if you already have a suspect. Most of the content in chapter ten relates to fundamental risk analysis. The risks posed by insider knowledge are important. Unfortunately, other than providing a fund of illustrative stories, this book does not provide much material that would be of assistance to those concerned with protection. And, as noted previously, the title, and the general tone of paranoia pervading the work, are risks in themselves. copyright Robert M. Slade, 2006 BKINSTHR.RVW 20060615 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
BKPVOIPS.RVW 2060602 "Practical VoIP Security", Thomas Porter et al., 2006, 1-59749-060-1, U$49.95/C$69.95 %A Thomas Porter %C 800 Hingham Street, Rockland, MA 02370 %D 2006 %G 1-59749-060-1 %I Syngress Media, Inc. %O U$49.95/C$69.95 781-681-5151 fax: 781-681-3585 email@example.com %O http://www.amazon.com/exec/obidos/ASIN/1597490601/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1597490601/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1597490601/robsladesin03-20 %O Audience i- Tech 2 Writing 1 (see revfaq.htm for explanation) %P 563 p. %T "Practical VoIP Security" VoIP (Voice over Internet Protocol) is something of the new kid on the technology block, and computer folks may have limited experience with telephony. It therefore seems a bit strange that chapter one, as an introduction to VoIP security, starts out by talking about computer security and attacks. However, the structure of the book is rather odd in any case. The basics of telephony, and the Public Switched Telephone Network (PSTN), are not covered until chapter four. Even then, while there is some useful trivia, most of the content is a list of telephony protocols. Chapter three covers some of the basic hardware and element information, discussing PBX (Private Branch eXchange) systems, VoIP components, and even power supplies. That material, in turn, would be helpful to those who try to understand chapter two, which is supposed to be about the Asterisk PBX software package. Although the text purports to deal with configuration and features of Asterisk, most of the section's content covers PBX operations and functions, dial plans, telephony numbering plans, and even a terse piece on the vital aspect of circuit versus packet switching. With chapter five, the book moves into some of the specifics of VoIP, discussing H.323, a protocol to specify data formats that is used extensively in commercial IP telephony products. SIP, the Session Initiation Protocol (used to negotiate interactive sessions over the net), gets a more detailed treatment (along with examination of related protocols) in chapter six. Other IP telephony architectures are briefly listed in chapter seven: the very popular Skype, H.248, IAX (Inter Asterisk eXchange), and Microsoft's Live Communications Server 2005 (MLCS). Diverse protocols used in support of VoIP are discussed in chapter eight. Most of these are commonly used in other Internet applications: some; such as RSVP (Resource reSerVation Protocol), SDP (Session Description Protocol), and Skinny; are more specialized. All the listed protocols have some review of security implications, which marks the first time in the book that security seems to be a major issue. Chapter nine examines specific threats and attacks, mostly related to denial of service and hijacking. Securing the infrastructure used for VoIP is important, although the material in chapter ten is fairly standard information security. Chapter eleven reviews a number of ordinary authentication tools that are frequently used in VoIP. "Active Security Monitoring," in chapter twelve, is the traditional intrusion detection and penetration testing, and has nothing specific to IP telephony applications. Similarly, chapter thirteen examines normal traffic management and LAN segregation issues: the only telephony related content is in regard to VoIP aware firewalls. The IETF (Internet Engineering Task Force) has recommended certain existing security protocols in regard to IP telephony, and one addition (SRTP, Secure Real-time Transfer Protocol): these are outlined in chapter fourteen. Chapter fifteen lists various (United States) data security related regulations and the European Union privacy directive. The IP Multimedia Subsystem (IMS) structure is reviewed in chapter sixteen. Chapter seventeen repeats the recommendations made in chapters ten through fourteen. It is handy to have a number of the issues related to VoIP addressed in one work. There is some depth to the content of the text as well, and those dealing with system internals may find that useful. However, for those who need to manage or make policy or purchasing decisions in regard to VoIP, this book may not have the forcefulness of complete analysis, or a structure that would assist in learning the background. While there is a considerable amount of helpful information, it reads more like an accumulation of miscellaneous facts than a directed study. copyright Robert M. Slade, 2006 BKPVOIPS.RVW 2060602 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