The Office of the Information and Privacy Commissioner of Alberta, Canada has published a news release with a decision on the Epsilon data breach.

Commissioner [Frank] Work reviewed the incident reports by Best Buy and Air Miles and concluded that although the information at issue (name, email addresses and organization membership (in the Best Buy case) was relatively minor compared to other data breaches which involve the unauthorized access of financial or other sensitive information, the sheer magnitude of the breach and the evidence that the information will likely be used for malicious purposes indicated there was a real risk of significant harm to affected individuals.

[…]

The Commissioner stated that the number of affected individuals increases the likelihood that spear phishing attempts will be successful and significant harm to individuals could occur as a result of the breach.

If you can find the missing parenthesis you win.

This could be huge. It certainly will make charge-back harder to manage with customers.

“We’re really not saying these are a ‘people without time’ or ‘outside time’,” said Chris Sinha, a professor of psychology of language at the University of Portsmouth.

“Amondawa people, like any other people, can talk about events and sequences of events,” he told BBC News.

“What we don’t find is a notion of time as being independent of the events which are occuring; they don’t have a notion of time which is something the events occur in.”

Oh, oops, wrong Amazon. But it’s still interesting.

If I understand the theory correctly, events define the passing of time rather than a system of equal units. A sequence would be first I did this, then I did that, instead of I did this at mark 110 and I did that at mark 215. They could even have longer events and shorter events by definition. I look forward to the full report.

At first glance I am reminded that I rarely tell stories with a notion of independent time. Casual conversation with friends is not tightly bound by units “…so I left my house at 5:15pm and mounted my horse at 5:45pm, rode down to your house and arrived at 6:10pm”. I speak in more general terms of first this, then that, then this.

It is only at times (pun not intended) when others are trying to make reference that they ask about an independent time system. “What time did you arrive at my house?” The purpose seems to be for them to align their events with my events on a system that we both comply with.

Time as we know it is an example of compliance.

Consider the fact that a lot of software still is written without “notion of time as being independent of the events which are occuring”. You might look in a log and find event 1 then event 2, but no clear reference to an independent clock’s time, let alone an official time server linked to an external time source.

I am obviously speculating on the report, but it makes me wonder if what these scientists are really saying is that they believe they have found a tribe in the Amazon that behaves a lot like software developers or systems that may be found on Amazon. Fascinating.

I believe this image comes from what they refer to as a “Microsoft event”:

A male tribe member stands near his unusual-looking sequencing tool

John D. Halamka, a healthcare CIO and practising emergency physician, gives some good perspective on triage and disaster scenarios in “Is it time to abandon cloud computing?” — a detailed and honest look at infrastructure failures.

I know what it takes to provide 99.999 percent uptime.

[…]

With all of this amazing infrastructure comes complexity. With complexity comes unanticipated consequences, change control challenges and human causes of failure.

Let’s look at the downtime I’ve had this year.

For a minute there I thought he was talking about a human body. The outages he lists are

1. Changes made in production – DNS changes
2. Changes made in production – Bad app code that filled storage
3. Changes made in production – OS upgrade
4. Changes made in production – Primary power taken offline, secondary failed
5. “bugs in the network operating system”

I suspect some money might be in his budget forecast for change control technology, people and procedures. A succinct conclusion is offered to sum the above experiences:

These examples illustrate that even the most well engineered infrastructure can fail due to human mistakes, operating system bugs and unanticipated consequences of change.

We could argue whether operating system bugs are still human mistakes but I agree with his overall point — the success of security depends on people and processes. Unfortunately, he then turns and attacks a straw man argument:

The cloud is truly no different. Believing that Microsoft, Google, Amazon or anyone else can engineer perfection at low cost is fantasy. Technology is changing so fast and increasing demand requires so much change that every day is like replacing the wings on a 747 while it’s flying. On occasion bad things will happen. We need to have robust downtime procedures and business continuity planning to respond to failures when they occur.

Yes, engineered perfection is fantasy. I think we can all agree on that. Who is asking for perfection? I want to go back to the start of the post:

I know what it takes to provide 99.999 percent uptime.

I don’t see anyone asking or promising 100 percent uptime, even here. More to the point, this is the classic IT operations perspective: Technology is fast changing. Demand is increasing. Nothing cloudy yet. Every day is…wait, wings on a 747 while flying? I love a good risk simile but why must IT operations be like changing the wings while flying?

I mean who would buy a plane ticket if the pilot said “Welcome on board. We will have a chance of landing this aircraft but we’re not sure yet if the wings will even last the trip”? The answer is probably no one (except perhaps wing developers wearing parachutes).

Ok, but what if a pilot said there was a high-probability like 99.999%? The answer is someone in a developing airline industry, where they do not have an option to improve their chances of landing any higher. To put it in real terms, who would fly on a jet in Africa? Someone who has no choice but to fly in Africa. They take the risk because it is worth it to them:

African carriers are 2% of global traffic, but 23% of global western-built jet hull losses.

The Wall Street Journal provides insight based on a UN report on air safety for aid workers. They decided the risk of flying had become too high and researched reasons for failure.

Flying is so dangerous that it even impaired the United Nations World Food Program’s efforts to deliver aid to suffering populations around the continent. After a spate of crashes killed several WFP workers, the agency five years ago ordered a broad review of safety conditions on its flights.

[…]

At the root of Africa’s dismal air-safety record are low investment, crumbling infrastructure and lax national authorities. Across much of the continent, there is minimal air-traffic control or regulation, and pilots often fly without basic navigational aids like radar. National air authorities in many impoverished sub-Saharan states struggle to pay their bills, retain good staff and meet the minimal air-safety standards set by the U.N.’s International Civil Aviation Organization.

In some lawless regions, almost anyone with an airplane can fly with no oversight. In countries like Sudan and Congo, unpaved airstrips often double as soccer fields where children mark goal posts with piles of rocks — into which planes hurtle upon landing — according to WFP safety officials.

Note the heavy emphasis on authorities, regulation, staff, standards, oversight…technology is only briefly mentioned and it is in regard to navigational aids. The emphasis in prevention programs seems to be on improvements in procedures and training.

Back to the post on cloud, I see a similar theme emerge at the end of Halamka’s lament.

Problems on a centralized cloud architecture that is homogenous, well documented and highly staffed can be more rapidly resolved than problems in distributed, poorly staffed, one-off installations.

That seems to be a comparison between cloud and non-cloud.

First, of course anything can have advantages if it is homogeneous, documented and staffed well. Cloud does not automatically achieve those aims; he does not say what will prevent a cloud architecture from becoming heterogeneous, undocumented and without sufficient staff. This becomes especially pertinent as failures always push some to advocate for more heterogeneity — survival through diversity — so cloud may be under more pressure to be less homogeneous because of its problems.

Second, diversity may be reduced to help with other variables like staffing and documentation. Thus the advantage of a homogeneous environment over a homogeneous environment (documentation and staff being equal) is a different question, which he leaves unanswered. The typical response to this from an operations perspective is that heterogeneity is expensive. Yet, an expense can pay for itself quickly if it delivers higher availability. Heterogeneity should not be assumed always to be bad for security.

Third, Halamka points to his limited staff as a reason to use public cloud, and highlights his priorities.

The reason to use the public cloud is so that my limited staff can spend their time innovating – creating infrastructure and applications that the public cloud has not yet envisioned or refuses to support because of regulatory requirements (such as HIPAA).

I think that brings us back to the question of people and process failure in services rather than events unique to a cloud. In other words, his airline offers planes and routes, but they could have a partner fly you to Africa so they can focus on their own flights. If you want to manage the risk of being on a partner’s flight, make certain you look carefully at the role and track record of authorities, regulation, staff, standards, and oversight.

Abandon is a harsh word and hard to define in the world of technology (e.g. rapid change, high demand) yet Halamka’s post emphasises to me that it’s a really good time to increase the ability of cloud to meet standards and pass oversight.

It’s the money. The NYT reports that next week a paper at the IEEE security and privacy symposium will reveal the results of research into the global financial and technical architecture of spam.

“It is the banking component of the spam value chain that is both the least studied and, we believe, the most critical,” the researchers write.

The computer scientists say that because the spam system relies on just a few banks and an even smaller number of credit card processors, the business is highly vulnerable to disruption by regulators and law enforcement agencies.

Hard to believe the banking component is the least studied. Maybe that just means that everyone (myself included) focus on the technical weeds of spam linguistics.

The NYT highlights the use of diverse international paths to slip through law enforcement and regulation.

Note that the server was in China. This might set off alarm bells and be the focus for some, especially if they already are prone to believe China is the source of most attacks, but the team does an excellent job continuing further with their research and analysis.

On Oct. 27, 2010, for instance, a network of zombie computers called the Grum botnet delivered an e-mail with “Viagra Official Site” in the subject line. Users who responded to the message were directed to a Web site that had been registered nine days earlier.

The Internet system that supported the Web site was spread around the globe: the domain registrar was in Russia, the server computer was in China, and a proxy server computer was in Brazil. When a purchase was made from the Web site, the shopper was redirected from a computer in Turkey to the Azerigazbank Joint-Stock Investment Bank in Baku, Azerbaijan. The drugs themselves were sent directly from a manufacturer in India.

The weak link in the system, the researchers noted, was that the Visa payment system handled the transaction between the customer’s bank in the United States and the bank in Azerbaijan.

The infiltration of the system seems to be the key to how they built an accurate and detailed model.

As I said in my 2011 BSidesSF presentation, insider information brings investigations far closer and with better closure than from an outsider perspective. Response to attacks must include methods of surveillance and infiltration to be most effective.