Some thoughts for addressing the Assurance component of A6

The A6 API is a security stack designed to provide Audit, Assertion, Assessment, and Assurance capabilities. There's one problem, providing assurance can't be done by machines alone - you need a human element, one that stands up and says "these results are true and good". Outside of wild notions about black box mechanisms and trusted computing, I'm hard pressed to find a technology solution to achieve this. What we really need is human participation in the stack, but the difficult part about humans is that we all have our own unique perspective on what is or isn't accurate, what's correct and ultimately how one defines security.

What we need is a standardized way of reporting on complex concepts dealt with in security assessments and audits. If we had a standard security reporting language, we could reduce variation in security reporting and improve interpretability. We can look to financial reporting for an approach.

In financial reporting there are two parts to the process, one is the assertion and the other assurance - one done by the public company and the other done by a public audit company. The public company says, we have X million dollars of this and that, the public audit company confirms that it is indeed true.

Ofcourse, we all know that financial reports are subject to manipulation and there's always some grey area in what a term means, this is further compounded by the various forms financial reporting is published (human readable for sure, but set in any order and dressed up in many different ways).

To address this, the International Accounting Standards Board (IASB) issued a standard known as International Financial Reporting Standards (IFRS) which has a taxonomy defining terms and for situations where a term is not defined, the new term can be described from atomic components and concepts within the taxonomy. There's a standard known as an eXtensible Business Reporting Language (XBRL) which allows for the clear meaning of financial numbers to be articulated in a way that is both machine readable but also IFRS compliant.

Here's a snippet of XBRL (reporting on Operating Income, Administrative Expenses, Operating Expenses):

<ifrs-gp:OtherOperatingIncomeTotalFinancialInstitutions contextRef="J2004" decimals="0" unitRef="EUR">38679000000</ifrs-gp:OtherOperatingIncomeTotalFinancialInstitutions>

   <ifrs-gp:OtherAdministrativeExpenses contextRef="J2004" decimals="0" unitRef="EUR">35996000000</ifrs-gp:OtherAdministrativeExpenses>

   <ifrs-gp:OtherOperatingExpenses contextRef="J2004" decimals="0" unitRef="EUR">870000000</ifrs-gp:OtherOperatingExpenses>

   <ifrs-gp:OtherOperatingIncomeTotalByNature contextRef="J2004" decimals="0" unitRef="EUR">10430000000</ifrs-gp:OtherOperatingIncomeTotalByNature>

If we had an IT Security Reporting standard similar to XBRL, which requires detailed exposure of information and provided clear definitions of terms, cloud providers could self-issue reports that while open to manipulation, become that much harder to subvert - let's call it eXtensible Security Reporting Language (XSRL). With an XSRL report, we'd all use consistent terms and consistent inputs

The three big challenges with the XSRL concept are:

• It's perfectly fine (in fact expected) for a public company to disclose their finances, but the same cannot be said of security vulnerabilities or perimeter defences (even though I'm a strong believer in Shannon's maxim or Kirchoff's principle, it's important to understand that the maxim does not advocate broadcasting details, but rather assuming the enemy will learn them and that the knowledge should not make them a more effective attacker).
• If you lie in a financial statements, you go to jail (usually) - if you lie in a security report (as long you don't breach section 404 of Sarbanes Oxley or equivalent), you'll probably just get your hand slapped (or bad press).
• Most security experts disagree on some aspect of security - financial reporters have IFRS (International Financial Reporting Standards) - so it would be a lot of work to get people to agree on a canonical definition of what constitutes secure and security.

That said, I still think we should try, it's hard, but it will be worth it - A6 could work without it, but I think we need to need to bring a formalism and maturity to security reporting that doesn't exist now, something akin to what financial auditors have today (Lehman Brothers and the like aside).

The value curve for the Cloud and what it means to security

I'm taking a small break from the A6 API work I've been doing. I've been pondering about the business side of security as it applies to the cloud. Indirectly, this is the rationale for something like A6.

This post is meant for business types, not my fellow cloud believers.

Recently my benevolent overlords sent me off for some training at a business school, now being a survivor of another business school, I was rather skeptical of what I might learn, but learn I did (to my surprise quite a few times). One of the topics covered was blue ocean strategy, succinctly described as (see Wikipedia for more details):

"Blue oceans, in contrast, denote all the industries not in existence today—the unknown market space, untainted by competition. In blue oceans, demand is created rather than fought over. There is ample opportunity for growth that is both profitable and rapid. In blue oceans, competition is irrelevant because the rules of the game are waiting to be set. Blue ocean is an analogy to describe the wider, deeper potential of market space that is not yet explored"

In practice this means, take something that exists today and modifying it's parameters to give the customer what they need while eliminating the attributes they don't care about. The canonical examples are Cirque Du Soleil, South Western Airlines and Formule 1 hotels, whom respectively, reinvisioned circus as theatre, airplanes as competing with buses and trains, and hotels being about a place to sleep and nothing more.

The Blue Ocean concept is not without it's flaws, but it provides a number of interesting tools for analysing a market and potential new offerings. One of those tools is a value curve, a visual representation of what's important to the customer and how much the solution or product provides of that value. Here's an analysis of what's important to a consumer of breakfast cereal:

The value curve isn't an analysis of which one is better, but rather what each product provides to a customer:

• Captain Crunch - covered in sugar, low in fibre, sugar equals lots of calories and comes with the standard decoder ring
• All-Bran - taste is acceptable, loaded with fibre, very healthy and comes with a discount coupon for another box of cereal or orange juice - it comes in slightly larger quantities than it's sugar laden competitor.

Most competitors in the breakfast cereal market space will vary around taste, price or caloric content and promotional elements as they attempt to win customers from their competitors.

Now imagine someone came up with a cereal that tastes great, lots of fibre, is healthier than a gym commercial and decided to forego coupons or decoder rings altogether (ok, its a simplified example) - more importantly, it doesn't require milk at all. The value curve would like something like this:

That product, and the market it instantiated (having broken the inverse relationship between taste and healthy eating), would be an example of a blue ocean - they've improved on certain aspects of the product (taste, fibre content and caloric count), got rid of things they don't think the customer values (decoder rings), reduce attributes that aren't as important (quantity) and introduced something completely new (no need for milk). While they are in reality competing with the other cereals, they also created an effectively new market (through technological innovation) that existing players would require a lot of repositioning to participate in, potentially at the cost of their existing customers.

So what's this got to do with security and cloud computing. A few years ago (and still today), enterprise computing power, specifically that in data centres or collocated, looked like this:

The curves shown here are averages for vendors like Dell, HP, Sun and IBM or collocation providers such as Rackspace, IBM, EDS or SunGard and also aggregates in the sense that a data centre includes a number of other vendors (EMC, Cisco, Juniper etc...). While some vendors into the data centre might be more cost effective, others may allow you to do more with less hardware; these are generalized representations.

Then Amazon came along and said, let's compete and do this data centre/collocation thing differently - here's what you get:

The points of the new value curve for Cloud IaaS are:

• improved cost effectiveness (I know the jury is still out on that);
• less control (for example governance) or ability to customize the environment - Amazon or public IaaS just aren't going to negotiate with you;
• extremely fast deployment (minutes not days);
• the flexibility to repurpose assets at will;
• eliminating hardware that you own;
• about the same security - let's assume that Amazon runs a relatively tight shop (they just don't tell us how in any great detail); and
• and a new ability to buy computing power for only when you actually need it

What this means to the business is you're dealing with a new beast, and because you value things like on-demand computing, elimination of CAPEX (the expense of owning assets), improved cost effectiveness and rapid deployment, you have to be willing to give certain things up. That's not to say you shouldn't expect, want or demand great security, it's just not under your control - more importantly, your security officers have to realize the same thing.

That said, even if you don't control something, it's not unreasonable to ask the people that do to tell you what's going on - that way you have a meaningful way to assess the risk you're carrying - which is the reason I think A6 is so important.

(BTW, graphs were done with OmniGraphSketch, quite useful for creating arbitrary graphs).