Risk Factor

Protesting the Program: Activists gathered in Washington D.C. on June 14th to rally against U.S government surveillance programs.

We’re now well into the second stage of the controversy surrounding the allegations that the NSA is conducting large-scale surveillance of U.S. citizens. Whistleblower/leaker/traitor (the exact term varying according to individual opinion.) Edward Snowden is being scrutinized, as are the articles written by Glenn Greenwald for The Guardian newspaper.

That Snowden’s perceived reliability, or lack thereof, has become a major part of the story is an entirely predictable consequence of his decision to reveal his identity. Back in 2004, Dina Rasor, then working under the auspices of the National Whistleblower Center in Washington D.C., told IEEE Spectrum that going public in this way was like “setting your hair on fire for one glorious minute.” Whistleblowers were well advised to remain anonymous so that the revelation “becomes the issue, and not you.” (As has been pointed out in several places, if we’d known that Deep Throat was an FBI director angry at being passed over for promotion, his accusations about Watergate might not have been taken so seriously.)

That the focus of the discussion has also shifted to Greenwald’s reporting is also not surprising in the light of that 2004 article. IEEE Fellow Stephen H. Unger, a former chairman of the IEEE Ethics Committee cautioned against the dangers of hastiness, or making the slightest factual error, when bringing any revelations to light: “Don't exaggerate at all… You could be 99 percent right, but if you make one little mistake, they'll focus on that to discredit you.”

The biggest substantive criticisms of Greenwald’s reporting so far have centered on his contention that companies like Google and Apple provided “direct access,” so that the NSA could come in and snoop around however they liked, grabbing information in real time if need be.

This week, the U.S. National Emergency Number Association (NENA) holds its annual conference to discuss 911 policy, technology, operations, and related education issues. I would guess that high on the list of informal conversations among conference attendees will be the increasing controversy engulfing New York City’s new 911 dispatch system, as well as the problems that several other cities and towns recently have reported with their own emergency management systems.

Heated Arguments Over Whether New York City 911 System Contributed to Young Girl’s Death

It is a situation reminiscent of the disastrous London Ambulance Service dispatch system meltdown in 1992 that was blamed for contributing to the deaths of up to 20 or more persons waiting for ambulances that arrived horribly late.

About two weeks ago, four-year-old Ariel Russo was walking to school with her grandmother in New York City’s Upper West Side when they were struck by a car driven by an unlicensed 17-year-old trying to elude the police. According to the New York Daily News, it took “an unusually long 4 minutes and 18 seconds from the time of the first request for an ambulance from police at the scene to a 911 operator, until the time an ambulance was finally dispatched. Once FDNY and EMS dispatchers received and acknowledged the transmission, it took 3 minutes and 52 seconds to dispatch an ambulance and for it to arrive at the scene.”

Ms. Russo was said to still be alive after the crash, but in cardiac arrest; she died on the way to the hospital. It is unclear whether the time delay made a difference in whether she would have survived or not. The grandmother survived, but suffered a broken back and leg.

The FDNY admitted that it shouldn’t have taken four minutes to dispatch an ambulance, but it placed the blame squarely on “human error,” claiming that, “An EMS dispatcher apparently got up from his desk at some point for several minutes and missed the transmission for an ambulance that had been sent by the NYPD operator on a relay. We’ve interviewed the dispatcher and he’s admitted he missed it.”

However, that explanation was immediately challenged on a couple of counts. For one, it was a female dispatcher who supposedly took the call.  We say supposedly because the dispatcher, a 23-year veteran, claimed that the call never crossed her screen before she got up to take her scheduled break and was replaced by another dispatcher. In addition, the call was supposed to be displayed not only that dispatcher’s display, but all of the other 39 dispatchers’ screens as well as on a “giant, wall-mounted screen,” the Daily News reported in a follow-on story. Why didn't any of the other dispatchers say they saw the call, the Daily News asked.

First: Do No Harm. Second: Keep Others From Doing It.

In the wake of discoveries that some medical devices are vulnerable to remote tampering via the Internet, the U.S. Food and Drug Administration (FDA) issued new guidelines this week that are meant to direct medical device manufacturers in beefing up security. The hope is that we'll never have to read about—or worse, personally experience—death or injury because some malware-infected gadget didn't work the way it should.

The FDA recommendations call for device makers to review their cybersecurity practices and test their products with an eye toward ensuring that their authentication setups can limit access to authorized users only. The guidelines also urge health care facilities to be more vigilant in updating their antivirus software, to set stricter controls on who accesses their networks, and to cooperate with device makers to investigate and fix security breaches.

The FDA says that although no deaths or injuries associated with these vulnerabilities or malfunctions have been reported, the rise in cybercrime makes such an outcome “increasingly likely.” The guidelines, though not legally enforceable, put device makers and medical facilities on notice that they need to step up their efforts to keep diagnostic machines from being taken over by attackers, prevent pacemakers from being reset so that they deliver fatal shocks, and to keep insulin pumps from being tampered with.

The FDA action was prompted by the U.S. Government Accountability Office, which asked it to “develop and implement a plan expanding its focus on information security risks.” It’s about time. Just imagine someone undergoing a surgical procedure where an advanced robot is doing the cutting as proxy for a surgeon in another part of the world. Malware in the system that controls a mechanical arm—or a man-in-the-middle-attack—could be deadly. And even banal mash-ups of technology and medicine could put patients at risk. Computerized drug dispensaries, meant to keep people from receiving the wrong prescription or the wrong dose, could be targets.

A few weeks ago, I wrote about the BBC blowing £98.4 million (about US $150 million at current exchange rates) on its failed Digital Media Initiative project meant to develop digital production technology that would fundamentally transform how the BBC operated internally. The story gets more and more interesting, and has now leaped across the Atlantic to snare the head of the New York Times in its net.

To quickly recap, the DMI project began in February 2008 with the expectation that the project’s contractor Siemens Information Solutions and Services (SIS) group would have the “transformational” technology ready for operation by May 2009. Siemens, however, consistently missed the project’s schedule from the beginning, and in September 2009, the BBC and Siemens cancelled the contract by mutual agreement.

The BBC then brought the DMI project in-house with a new date for the rollout of DMI’s production technology across the BBC during the summer of 2011. When the National Audit Office, an independent Parliamentary body, took a look at the project’s status in late 2010, BBC management told it that “delivery of the system has progressed well, and users have responded positively” to it. BBC management also convinced BBC Trust's Anthony Fry, a member of the governing body of the BBC, that the “delivery [of the DMI system] was progressing as planned.”

However, progress didn’t go as planned. Users thought it was “clunky” and needed a significant redesign, and by October of last year, the DMI project was suspended pending a review. Last month, the new BBC Director General Tony Hall decided to pull the plug on the project, as it had created, in Trustee Fry’s assessment, “little or no assets.” Lord Hall immediately suspended (with pay) the BBC’s Chief Technology Officer John Linwood, who oversaw the DMI effort, and MP Margaret Hodge, chair of the House of Commons Public Accounts Committee called the cancellation, “a terrible shock and clearly completely shambolic.”

Here's where it gets really interesting.

A decade ago, I wrote an article about the efforts of automotive technologists to make up for the fact that “we get sleepy while driving at night, do dumb things like put on makeup or shave while creeping along in bumper-to-bumper traffic, or look away from the road to adjust our car radios.” Automakers were introducing safety systems such as adaptive cruise control, which maintains a safe distance between a car and the one ahead of it even if the driver is asleep at the wheel. Advancing just as rapidly along a parallel plane was technology aimed at keeping drivers connected to the world outside the passenger cabin. (To be sure, its unlikely that engineers back then were imagining drivers updating their social media profiles while traveling at highway speeds.)

Some of the innovations—routing mobile phone conversations through a car’s speakers to ensure that a driver could keep both hands on the steering wheel, for one—were specifically intended to combat the inattention to the road that results from looking down at a small screen. But even back then, researchers understood that these improvements, though laudable, were not enough to safely limit the cognitive demands that keep a driver from focusing on the main task—operating heavy machinery.

A new study released today by the AAA’s Foundation for Highway Safety reinforces that understanding. Most alarming is its conclusion that systems designed to allow drivers to dictate e-mail or text messages, or that translate text to speech then read the messages aloud—ostensibly meant to promote safety—actually worsen driver distraction.

This is a big deal when you consider that, according to electronics consulting firm IMS Research, more than half of all new cars will have voice recognition functionality.

This past week saw an uptick in the number of IT-related malfunctions, mishaps and mayhem in comparison to the previous few weeks. We start off with a lesson from Irish Rail on how not to endear yourself with your passengers when fixing a software problem.

Irish Rail Gives Scant Warning to Passengers for Belated Billing on Uncharged Trips

Last Friday, Irish Rail announced in a press release on its website that a March 2013 software upgrade to its Ticket Vending Machines (TVMs) didn’t work as planned, resulting in tickets being issued and payments being authorized against payment cards. But unfortunately for the transit authority, the payments weren’t actually deducted from passenger accounts. Over 9000 individual payment cards were affected by the error,  nearly all attached to Maestro Debit cards, Irish Rail said. The incomplete transactions occurred for train tickets purchased between 28 March and 31 May 2013 and came to about €331 000 (US $438 000) in uncollected fares.

Irish Rail also announced in its press release that I am sure all of its riders read on a daily basis that, beginning today, it would begin to collect the monies owed it. There’s nothing like giving your customers a lot of advanced notice.

Naturally, Irish Rail’s decision did not sit well with many of those affected customers, with the spokesperson of Rail Users Ireland logically asking why Irish Rail couldn’t have waited a week at least to allow customers some time to hear about the news, and also let customers ensure that they had enough money in their bank accounts to cover the charges so that they wouldn't become inadvertently overdrawn.

Irish Rail said that it recognized “that processing cumulative payments at one time may cause difficulties for some customers,” and so it set up a somewhat convoluted payment scheme to reduce the pain. However, the railroad also admits that 60 to 70 percent of those owing money will see charges to their bank accounts beginning today.

Irish Rail added in its press release, “We apologies [sic] for any inconvenience this fault causes customers.”

Let’s hope that Irish Rail’s augmented reality app released today doesn’t have similar software issues.

Given this week's revelations about the privacy—and the lack thereof—of our personal communications, maybe it's time to reconsider what former Principal Deputy Director of National Intelligence, Dr. Donald Kerr, meant when he said back in 2007 that,

Too often, privacy has been equated with anonymity; and it’s an idea that is deeply rooted in American culture… We need to move beyond the construct that equates anonymity with privacy and focus more on how we can protect essential privacy in this interconnected environment.”

And maybe we can even anticipate the next privacy crisis by taking a good look now at the ongoing assault on what I think most people agree remains an “essential privacy,” i.e., their private medical information.

Coincident with the NSA privacy flap, Bloomberg News ran a story this week on how many U.S. state health organizations are selling supposedly “anonymous” patient information to pharmaceutical companies, insurance companies and researchers that can, using other publicly available data and well-known analytical techniques, personally re-identify those patients. Bloomberg gave an example of a Washington State resident who went into diabetic shock and, as a result, had a motorcycle accident. The accident was covered in a local paper but only the most basic details were given of the person involved and the cause.

Yet another quiet week in the land of IT snafus. The most interesting story to crop up involved the problems plaguing the roll out of the New York City Police Department’s new emergency 911 dispatch system.  

New York City’s New Emergency Dispatch System Fails 4 Times in First 48 hours

The Big Apple’s long-troubled effort to modernize its 911 emergency call system ran into additional difficulties when its new, US $88 million NYPD emergency dispatch system suffered four outages within two days of its Wednesday debut.

The dispatch system first went out Wednesday afternoon for 16 minutes beginning at 4:21 pm, the New York Daily News reported. Emergency service operators had to revert to capturing the call information on slips of paper, which were then taken by runners to the separate NYPD and EMS radio rooms where the proper emergency units could be assigned to the call. The scene was described by one experienced operator as sheer “pandemonium.”

A City Hall spokesman down played the incident, saying that the manual back-up system worked and that no calls were missed.

Then, early Thursday morning, the dispatch system suffered a six minute outage, said Police Commissioner Ray Kelly in an interview with CBS News New York. Kelly also felt the need to note that the new system had been “tested for six months.”

I am not sure whether Kelly was trying to vouch for the dispatch system’s reliability, but if he was, his efforts were soon undone. Shortly after Kelley's morning interview, the dispatch system went out again, at 12:09 pm. That time, the outage went on intermittently for about an hour, the Daily News once more reported. Out came the paper, pens, and runners again.

Then at 7:00 Thursday evening, the dispatch system went out one last time—but only for two minutes.

Mayor Michael Bloomberg shrugged off all the outages, saying that, “There are a few bugs in the system. We'll fix them and there'll be more. Every computer system has bugs in it; there's none that does not.”

Those remarks probably didn’t go over well with the emergency system operators who were told that the “new system would never go down.”

At least there have been no reported outages the past three days. But if another one happens, at least the emergency dispatch system operators have now had plenty of practice in how to deal with it.

What U.S. Defense System Details Have Hackers Accessed?

In the past year, the U.S. government has gone from making thinly-veiled accusations about nation-state sponsored cyberattacks to pointing fingers directly at China as the entity behind a string of hacks in which intellectual property and other sensitive information has been stolen from private firms and government agencies. That was the tone of a report released earlier this month by the U.S. Department of Defense. The 92-page report says the stolen information is helping China build “a picture of U.S. defense networks, logistics and related military capabilities that could be exploited during a crisis.” And this week we learned, courtesy of the Washington Post, some of the elements in that picture. The Post says it obtained a copy of a previously undisclosed section of a report written by the Defense Science Board (DSB), a committee of experts that advises the U.S. Department of Defense on technical and scientific matters.

That report, which was released in January, provided the Pentagon and defense contractors details regarding the data to which cyberthieves gained access. It said that the “DoD and its contractor base have already sustained staggering losses of system design information incorporating decades of combat knowledge and experience that provide adversaries insight to technical designs and system use.” But the public version of the report did not list the weapons whose plans had been stolen. According to an article in the Washington Post, the pilfered information included plans and technical details on several missile defense systems such as the PAC-3 Patriot missile system, the Terminal High Altitude Area Defense (THAAD) system and the U.S. Navy's Aegis ballistic-missile defense system. The cyberthieves—who U.S. government officials say were working at China’s behest—also saw design plans for the F/A-18 fighter jet, the F-35 multirole combat aircraft, the V-22 Osprey aircraft, the Black Hawk helicopter and the Navy's Littoral Combat Ship (LCS) class of vessels.

The announcement last week that the BBC pulled the plug on its overly ambitious and admittedly poorly managed Digital Media Initiative (DMI), probably drew a smile from the folks who originally worked for Siemens Information Solutions and Services (SIS) group, now owned by ATOS. The BBC admitted that the project, which was said by BBC Trust's Anthony Fry to have created “little or no assets,” cost license fee holders £98.4 million (about US $150 million at current exchange rates).

To understand the former Siemen’s workers presumptive glee, you need to go back a few years.

In February 2008, the BBC directly awarded a £79 million, fix-priced contract to Siemens under an existing outsourcing contract to implement, roll out, and operate through March 2015 what the BBC called its Digital Media Initiative. According to a 2011 National Audit Office (NAO) review, “DMI is a technology transformation project designed to allow BBC staff to develop, create, share, and manage [all] video and audio content and programming on their desktop, and intended to improve production efficiency across the BBC,” anywhere the BBC operated. In other words, DMI was meant to radically change the way the BBC operated internally.

The BBC's business case put the total DMI project investment, including its management and other administrative costs, at £81.7 million, and claimed that the project would end up generating a total benefit of £99.6 million. The benefit, the NAO indicated, would come from reduced operating costs, the avoidance of some future production costs, and a “creative dividend” savings that would accrue from being able to reuse material instead of having to produce entirely new content.