XSRL Compliance drafted

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.1

An updated version of XSRL-Policy has also been uploaded.

Starting XSRL

A brief announcement, I've temporarily paused documenting A6 to put together a draft set of XML schema for XSRL (eXtensible Security Reporting Language).

Draft 0.1 of the XSRL-Policy is the first release, to be followed by:

• XSRL-events - for reporting on events such as breaches or virus outbreaks

• XSRL-compliance - for reporting compliance with stated XSRL-Policy or external XSRL-Policy such as PCI-DSS (my lazy example)

• XSRL-state - for reporting on the security state of your environment, systems and applications - will leverage SCAP

The schema looks like this (some child elements not shown):

The draft XSD file is on box.net.

Auto-generated documentation is below on Scribd iPaper below.

XSRLPolicy_0.1

BTW Just got listed on AllTop

Closing the gaps on A6 (not the Audi)

I've started writing the A6 API document and I'm bothered by two areas of incompleteness (voids, gaping voids):

1. No Assurance function (specifically my treatment of the assurance function as either emergent or orthogonal)
2. The unconnected dots that each URI represents

I think I can close both of these gaps by cheating a little bit, I'm going to repurpose /ssapi/ISO27002/ to serve as the Assurance function, then use it as the point that we ultimately tie everything together.

This won't be as good as an independent and trusted third party standing up and saying everything is kosher and I still hold that Assurance is best described as follows:

"a validated statement, specifically validated by a trusted third party (like an audit firm) reviews the supporting facts behind an assertion and confirms they are true, have integrity and have the correct scope (or completeness)"

However, I don't believe A6 was supposed to be the cure for all that ails our security world, its purpose it to provide transparency, so let's work on sharing security state information and we can circle back to the golden standard in a future standard.

By modifying the return of /ssapi/ISO27002/ method we can not only use it to expose policy information, but also expose the level of compliance with the policy by providing references back to the /ssapi/environment/ results or the existence of control elements (the latter will need to be self-asserted by a given element, as in "I do this")

There are two sticky bits:

• avoiding exposing sensitive information as follows: "our policy is to have firewalls" followed by "the following elements have very bad scores" and because they're referenced by that policy the intelligent attacker can conclude "their firewalls are poorly configured, let me attack"
• there's a missing input covering the procedural/non-technical elements that we can't use /ssapi/element/xccdf/ to collect (which is my ever-so-clever way of circling back to the need for an eXtensible Security Reporting Language)

Here's version 0.11 of the A6 API documentation - it's showing off a bit more structure, only a page more of content though.

A6 API Documentation - Draft 0.11

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).