Just finished draft 0.1 of the XSRL-compliance schema, a sub-namespace of XSRL (eXtensible Security Reporting Language).
The draft schema looks like this:
The draft XSD file is located on Box.net.
Auto-generated schema documentation is up on scribd.
XSRLCompliance_0.1An updated version of XSRL-Policy has also been uploaded.
Ruv Cohen, over at Elastic Vapor, proposed an interesting idea for a Cloud Service Rating Agency. The idea was further defined as a "Cloud Performance Ability (CPA) that estimates it's ability to meet certain service levels"; similar in intent to Standard & Poor's Claims-Paying Ability rating for an insurance provider explained as the "financial capacity to meet its insurance obligations".
I love the concept of some standard, some metric that allows us all to look at a complex issue and agree what we're looking at, but there are a few problems:
(more issues with credit rating agencies can be found on wikipedia)
Now, before you think I pick on rating agencies unfairly, other public trusts (such as public audit firms) have suffered from conflict of interest problems, that have led to bad decision making (Arthur Andersen's involvement in Enron is a canonical example and one of the reasons for the existence of Sarbanes-Oxley legislation).
So bottom line, if you establish for-profit providing rating services, ultimately the integrity (intentionally or otherwise) will come into question.
Experience has also taught us that self-administered assessments - unless exceptionally detailed - are at best somewhat informative, at worst theatre (the early days of PCI-DSS come to mind).
If we were to build a Cloud Service Rating Agency, what we would really need is an independent, non-profit entity, something like the North American Electric Reliability Corporation (NERC). An entity with claws and a focus on assurance, so while I agree with James Urquhart that data is not electricity, I think it's an interesting industry to draw lessons from.
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:
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).
I've been working on the A6 API for the past week and I'm certain Mrs IronFog is wondering when I might be done (she's graciously been giving up about two hours of quality time each night - something I am immensely appreciative of).
A6 stands for The Audit, Assertion, Assessment, and Assurance API (a term coined by @CSOAndy via Chris Hoff's Rationale Survivability), so I figured I would know if I was done when I could put a check mark next to each aspect of the 6 A's (this feels like the start of a buffer overflow joke).
So here we go:
Ok, so 5.0 out of 6 is pretty good, but here's why I think we're complete enough to consider this a first draft. The terms Assertion ad Assurance are financial audit terms:
Assertions are easy, anyone can make a statement about anything - that's what our stack does - however, we just have to trust that the statements are true and good.
For assurance, we have three options:
Barring perfectly trustable computing, we cannot provide true Assurance functions through technology alone - we can just make it easier to share what we know in an easily interpretable fashion.
So basically, the stack as it stands, is structurally complete enough for a first draft release (which I'll start packaging up shortly). Ofcourse, there's still specifications, nuances, details and documentation to get done; I know other things will emerge as I review and cleanup what I've done, but that will be iterative, not net new.
