Apple’s map “errors could prove deadly”

The Australian police have been rescuing people who become stranded after blindly following Apple devices into unfamiliar wilderness and getting lost or stuck. A public warning has been issued to try and help avoid catastrophe:

“If it was a 45-degree day, someone could actually die,” Mildura’s Local Area Commander Inspector Simon Clemence told state broadcaster ABC.

“It’s quite a dangerous situation, so we would be calling for people not to use the new Apple iPhone mapping system if they’re travelling from South Australia to Mildura.”

Police said at least five vehicles had become stranded in the park after drivers followed directions on their Apple iPhones, some of them after being stranded for up to 24 hours without food or water.

It seems a bit extreme to tell people not to use the system at all. I’d have said use it with extreme caution or use it as a secondary device to local knowledge or recently verified information.

What the Australian incident news I have read fails to mention is that this is a long-standing problem. Not only are map devices prone to error but local authorities have previously warned about people relying on them too much.

I have spoken about this many times when presenting on the security risks of Big Data. Integrity issues of the data that people rely upon are a major problem. Here’s the most recent version of a slide from my deck:

The tiny white URL at the bottom of the slide takes you to the story.

Three young women escaped the sinking Mercedes-Benz SUV after the vehicle’s GPS directed them down a boat launch and into the Mercer Slough in Bellevue, Washington.

The driver thought she was on a road while following her GPS unit just after midnight, but she was actually heading down the boat launch.

Just last year after a conference in Las Vegas I started driving through the vast desert to the south of Death Valley. I noticed warnings both from Garmin and from law enforcement about over-reliance on any electronic map. The most common problem, they explained at that time, was taking a turn onto a road that no longer (or never) existed and becoming stuck in the sand.

It was true. As I drove down roads narrowed by soft and dangerous shoulders I could see on my map several turns where there was nothing but drifting sand.

The real story is thus that Apple is not doing enough to warn users of the risks of trusting their maps, leaving it up to small and local community budgets to carry the weight of education as well as rescue of outsiders arriving with flawed technology.

And it’s not just Apple.

This point was driven home to me (pun not intended) when I watched a Google speaker last week present on the future of big data applications. The presentation painted an almost nauseatingly rosy picture of transportation entirely dependent on their service. It was one of those moments when I knew the security industry was not being integrated enough and there would be a lot of work ahead.

Is there a song called “Let’s go everywhere man, only if we can get out again?”

MySQL 0-Days: CVE-2012-5611 to 5615

A set of MySQL 0-Day vulnerabilities has been posted on the full-disclosure list with CVEs already assigned, as explained by Red Hat’s SRT

So normally for MySQL issues Oracle would assign the CVE #. However in this case we have a bit of a time constraint (it’s a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I’ve spoken with some other Red Hat SRT members and we feel it is best to get CVE #’s assigned for these issues quickly so we can refer to them properly.

If Oracle security has already assigned CVE’s for these please let us and the public know so we can use the correct numbers. Also if Oracle can let the public know which versions of MySQL are affected (e.g. 5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am sure.

So far it appears from the MariaDB response and update notice (Oracle has yet to respond) that CVE-2012-5611 will be deprecated as a duplicate of CVE-2012-5579 but 5612 and 5614 require patches. 5615, a user disclosure issue, received this response from MariaDB

hardly a ‘zeroday’ issue, it was known for, like, ten years

And, last but not least, 5613 is a point of configuration.

The MySQL 5.0 Reference Manual Security Guidelines clearly state “Do not grant the FILE privilege to nonadministrative users” but someone may still make that mistake, as demonstrated in this video by Eric Romang

Still no word from Oracle…but MariaDB speculates on their behalf that their next releases shouldn’t be vulnerable to the CVE that they know about.

At a time when trust and transparency are more in demand than ever, security lists indicate a continuing trend in what some have described as this:

Oracle’s lack of communication regarding the future…

Algorithms, DVD CSS and Haiku

My mother dropped off a book for me to read called “Coding Freedom: The Ethics and Aesthetics of Hacking” by Gabriella Coleman.

The section on poetic protest within the chapter “Code is Speech” reminded me of the haiku called

How to decrypt a
DVD, in haiku form
Thanks, Prof. D. S. T.

A quick search for the original text of the poem brought me to an interesting backstory by its author, Seth Schoen:

A strange tradition current among programmers calls for the use of the 5-7-5 pattern — preferably cleverly — to express technology, or jokes about technology, or really anything at all, just for the fun or the challenge of writing within the constraint. I remember particularly that the UC Berkeley Computer Science Undergraduate Association has a mysterious tradition of writing haiku poems about the chemical element zinc. The tradition seemed to start with a 1995 transcript of a conversation in which CS students began to write poems about zinc, but it continued within and without the Berkeley CSUA, and I know that I personally helped spread the tradition to other forums and communities.

[…]

It’s clear that the practice of writing 5-7-5 verses and calling them “haiku” seizes on only one aspect of the haiku form and entirely removes it from its original cultural context. I freely admit that my poem has no cultural continuity with the ancient Japanese haiku artform, although I think it has its own sort of literary merit.

Well, maybe if the ancient Japanese had DVD CSS to deal with…but seriously, poetry often can be revealing and controversial through indirect methods. It can be a backdoor of communication on subjects where the front door is sealed. There is perhaps more continuity than Schoen realizes.

Why South Carolina’s Governor wants encryption NOW

The leader of an American state is in the news advocating encryption be added to government compliance requirements. She has pointed blame for a serious breach of confidentiality, under her watch, towards her regulators.

Gov. Nikki Haley’s remarks on Tuesday came after a report into the breach revealed that 74.7 GB was stolen from computers belonging to South Carolina’s Department of Revenue (DOR) after an employee fell victim to a phishing email.

First, her remarks feel slightly off the mark to me. The incident response report released by her office asserts only a correlation between a phishing email and the breach.

The report very cleary states causation was not found.

The malware likely stole the user’s username and password. This theory is based on other facts discovered during the investigation; however, Mandiant was unable to conclusively determine if this is how the user’s credentials were obtained by the attacker.

The news I have seen consistently refers to a case of malware through phishing, even though the IR report warns that it is only “likely.”

Beware the difference.

Why does certainty matter so much here? Because encryption has a well-known and significant weakness: an attacker who can compromise credentials needed for decryption still can steal 74.7GB of confidential data. The strength of a safe’s walls are far less relevant if a front door is left open.

Second, if an executive passing the blame on to regulators sounds familiar it might be because Heartland’s CEO used similar rhetoric.

In the post-Enron environment, the auditors have contracts with clients that essentially absolve them of gross negligence. The false reports we got for 6 years, we have no recourse. No grounds for litigation. That was a stunning thing to learn. In fairness to QSAs, their job is very difficult, but up until this point, we certainly didn’t understand the limitations of PCI and the entire assessment process. PCI compliance doesn’t mean secure. We and others were declared PCI compliant shortly before the intrusions.

Most people might think Enron was a lesson in detecting executive negligence and fraud. A CEO saying the case centers on “gross negligence” by auditors paints an interesting perspective on management responsibility as well as history.

Consider this brief definition of gross negligence for a physician:

Gross negligence evinces a reckless disregard for the rights of others or smacks of intentional wrongdoing. In other words, gross negligence is an act or omission of an aggravated character, as distinguished from the failure to exercise ordinary care.

Heartland’s CEO appears to equate a breach of his systems to this kind of intentional wrongdoing, perhaps even intent to decieve, by those meant to help him assess his compliance with a regulation.

Enron, however, was a very different case. As Time magazine explained in 2002, auditors were found guilty of charges they helped executives of Enron hide risk from the regulators. Executives and auditors were thought to be in cahoots.

Said prosecutor Andrew Weissman: “This is a perfect example of Arthur Andersen sanitizing the record so the SEC would have less information.”

It might be useful to also mention that Enron’s auditing firm later was found not-guilty and the conviction overturned by unanimous Supreme Court decision (Andersen v. U.S., 04-368).

At trial, Andersen argued that employees who shredded tons of documents followed the policy and there was no intent to thwart the SEC investigation.
[…]
A ruling against Andersen could have had onerous consequences for businesses, whose discarding of files is an everyday occurrence. Experts say companies would have had to keep all files for fear that any disposal, however innocent, could subject them to potential prosecution.

In other words the core Enron lesson has to do with the executives intentionally misleading regulators with the help of those working for them. The Andersen case related to questions of client-independence and retention policies with oversight by regulators. The Heartland CEO characterizes the problem as executives who didn’t realize they were comitting fraud rather than asking why no one blew the whistle on Enron executives.

Back to South Carolina’s Governor, she was quick to throw mud at her regulators: “This is a new era in time where you can’t work with 1970 equipment. You can’t go with compliance standards of the federal government.” See the whole mud-slinging event here:

What she says is true to some degree, you can’t go with compliance standards of the federal government to be safe any more than you can take the South Carolina driving test and assume you will be safe on the road. A fair amount of driver intervention is required.

So if a driver has an accident should we expect them to say “…you can’t work with 1970 vehicles. You can’t just follow government driving compliance standards…?”

Third, given that (1) encryption isn’t a proper solution to the loss of credentials and (2) those in charge at the time of a breach sometimes spin blame onto those who try to guide them, do I agree with a Governor’s demand that encryption be added to regulation?

Actually, yes.

I’m obviously pro-regulation for a number of reasons but as I’ve stated for years encryption is neither difficult nor costly to implement properly. The reasons not to encrypt are fast disappearing, which begs the question of why the Governor wasn’t already adopting it. Why did she think she had to wait for regulation by the federal government before she could act?

In 2005 I presented at a conference to card brands and retailers a solution that would allow end-to-end encryption of their customer data.

Although we made great technical progress I will never forget the words of a CFO who reviewed our proposal: “Davi, we don’t want to be bleeding edge.” That used to be a typical reaction eight years ago and one of the reasons I set out to present to people around the world how to do encryption.

Most recently I ran into this sort of reaction in China, but it seems to have started to wane in America. More and more demand for encryption is starting and regulators have already written it into state laws (e.g. Nevada’s 2009 law SB 227 and Massachusetts’ 2009 law 201 CMR 17).

And while some states have moved towards explicit encryption, others have implied or suggested encryption laws. Notice, for example, that the 2009 South Carolina breach law offers an encryption safe-harbor clause:

Definition of Personal Information: The first name or first initial and last name in combination with and linked to any one or more of the following data elements that relate to a resident of this State, when the data elements are neither encrypted nor redacted

We can thank California’s 2003 SB 1386 for the rise in breach laws and encryption clauses over the past nine years but actually we can thank Heartland for most of the mindset shift after 2008 (more than just coincidence with the timing of encryption laws). In other words, I also will never forget (five years after my presentation on end-to-end encryption for PCI) the CEO of Heartland asking why no one had forced him to spend money on end-to-end encryption.

Heartland Payment Systems, the victim last year of a massive data breach of sensitive card data, vowed after that devastating event to develop new security gear based on end-to-end encryption between itself and its merchants to prevent such a breach from occurring again. That’s now taking shape, but slowly.

The fact was no matter how I characterized encryption in terms of a long history of deployment and use (don’t get me started on the Roman empire) if the regulators did not demand it now, there were always some executives I consulted with who said they didn’t see the “pressure” to do it. There were those who wanted encryption to be so far behind their adoption curve that they could hold up a requirement to prove to their constituents that it was necessary (e.g. low risk to them).

So yes, I think regulators should force South Carolina’s Governor to adopt the aging encryption controls because, as with Heartland, some leaders haven’t been able to take that step before a breach hits the fan. I also think regulators should demand South Carolina’s Governor explain how she will use encryption to protect data if keys to encryption have been stolen (e.g. as described in her incident report).

And try not to look suprised when she asks “What do the requirements say…?”


Updated to add: The IRS apparently has responded with a statement that encryption is required, as reported by WMBF news.

The governor says she’s meeting with the state’s congressmen to have the IRS require encryption in its standards. But the IRS says that’s already on the books.

Unfortunately WMBF has a vague and diplomatic quote from the IRS — no specific requirement is cited.

We have many different systems with a variety of safeguards — including encryption — to protect taxpayer data. The IRS has in a place a robust cyber security of technology, people and processes to monitor IRS systems and networks.

We work closely with the states to ensure the protection of federal tax data. We have a long list of requirements for states to handle and protect federal tax information.