A6 becomes Cloud Audit

Chris Hoff and the intrepid A6 working group (which I'm proud to say I get to participate in) have rebranded A6 to Cloud Audit. The working group will remain known as the A6 working group and will congregate on Google groups here.

Given the work that's happened to date inside the working group, I've retired the documents on scribd.

(as an aside I hope to start posting again in the next month or so)

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

Documenting the A6 REST API

So after a week off (filled with good things like finishing Season 4 of Galactica), I decided I needed to actually document the A6 API. I'm doing this for two reasons:

1. The blog posts are fragmented and make it harder for any potential implementers to follow
2. I like detailed documentation

So here's section 1.0 of draft 0.1 - the three salient elements are the introduction, the license and design philosophy.

A6 API Documentation - Draft 0.1

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

Can we do the Security Stack API RESTfully (are we there yet?)

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:

• Audit - Check - we have /ssapi/compliance/
• Assertion - Check - we have /ssapi/ISO27002/ and /ssapi/environment/
• Assessment - Check - we have /ssapi/element/xccdf/
• And - Check (for the sake of completeness)
• Assurance - sort-of, it's somewhat of an emergent or external property - I'll explain below
• API - Check - we have /ssapi/

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:

• Assertion is a self-issued statement made by one party (the provider) to others (end users) about their state - such as "I have a billion dollars in cash" or "we are secure" - they're not validated by anyone else.
• Assurance is 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)

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:

• Have some trusted mechanism (black box software in a tamperproof appliance) validate the information from the stack and issue a signed XML blob;
• Get a third party auditor to validate the assertions issued by the stack and provide a formal sign-off; and
• Review the information ourselves and see if we can spot inconsistencies (and then call "liar-liar-combusting-pants")

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.

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

Can we do the Security Stack API RESTfully? (Part 5)

In part 4 of security stack API series, the /ssapi/element/xccdf/ URI was described, which allows elements in the environment to express their security status via XCCDF (eXtensible Configuration Checklist Description Format). Now that we have a private part of the stack for data collection, we're going to jump back to the public stack to expose an anonymized aspect of the data.

• /ssapi/environment/registered/ - a GET request will return the total number of elements registered with the aggregator, specifically, how many have uploaded a registration payload.
• /ssapi/environment/validated/ - a GET request will return the total number of registered elements that have uploaded.
• /ssapi/environment/freshness/new/ - a GET request will return how many seconds have passed since any element updated their current XCCDF test result.
• /ssapi/environment/freshness/old/ - a GET request will return the age, in seconds, of the oldest current XCCDF test result for any element.
• /ssapi/environment/freshness/mean/ - a GET request will return the mean age, in seconds, for all elements current XCCDF test result.
• /ssapi/environment/freshness/median/ - a GET request will return the median age, in seconds, for all elements current XCCDF test result.
• /ssapi/environment/freshness/@all - a GET request will return an XML blob containing a list of h(UUID4's) (the arbitrary handle that only the aggregator can connect back to a specific element - SHA-2 hashed along with a secret value to reduce likelihood of correlation) along with the age in seconds of the current XCCDF test result.
• /ssapi/environment/score/current/@all - a GET request will return an XML blob containing a list of h(UUID4's) - described immediately above - along with the current XCCDF score value for each element.
• /ssapi/environment/score/trend/@all - a GET request will return an XML blob containing a list of h(UUID4's) - described immediately above - along with a keyword attribute indicating if the score had "improved", "degraded" or "new". The new keyword is used in cases where a new XCCDF test package has been used (may mean the reporting element itself is new or the package has just changed).
• /ssapi/environment/score/count/@all - a GET request will return an XML blob containing a list of h(UUID4's) - described two URI's above - along with a the total count of XCCDF test results uploaded.

Notes:

• While all of the above URI's are public, none of them expose detailed information about the environment that will tell an attacker what defences they're up against or the specific state that any element is in.
• The /ssapi/environment/ URI's provide anonymized data about the environment, that assuming the stack isn't lying about, tell the requester how broad the providers security efforts are, how much coverage they provide and how frequently they're examining or improving their environment and the elements therein. Ultimately though, it's up to the consuming organization to determine if the providers security efforts, as expressed through the stack, are sufficient.
• Administrators with authenticated access to the private part of the stack, specifically the URI /ssapi/element/xccdf/results/ (described in part 4), can view the actual results.

@mhanco suggested we need to address message level security, I completely agree, but want to defer detailed XML payload structures (or other formats) until we've got the broader structure mapped out.

more to come...

Can we do the Security Stack API RESTfully? (Part 4)

(Mrs Iron Fog is awesome - she does my chores for me so I can blog)

(Part 3 is here)

Using the previously described /ssapi/register/ an element can push up information about their security state. This data is considered private and wouldn't be exposed via the public part of the stack - aggregated or sanitized versions of it might be, but not in its as is form, some of the data could result in damaging information leakage.

In this section we start using another SCAP element, The eXtensible Configuration Checklist Description Format (XCCDF)

• /ssapi/element/xccdf/results/?<uuid4> - an element can POST the results of a configuration check with an XML XCCDF result blob.
• /ssapi/element/xccdf/results/ - an administrative entity can GET a list of elements that have provided test results.
• /ssapi/element/xccdf/results/@all - an administrative entity can GET a list of all available test results for all elements (with URI, date and test type).
• /ssapi/element/xccdf/results/?<uuid4> - an administrative entity can GET the list of recent XCCDF test results, an XML blob is returned with enumerated URI, date and test type.
• /ssapi/element/xccdf/results/current/?<uuid4> - an administrative entity can GET the most recent results from a configuration check. If the original element attempts a GET, an error message is returned (prevents information leakage).
• /ssapi/element/xccdf/results/00000001/?<uuid4> - an administrative entity can GET a specific prior result from a configuration check - exact URI will be provided by the /ssapi/element/xccdf/results/?<uuid4> query.
• /ssapi/element/xccdf/results/current/score/?<uuid4> - an administrative entity can GET the XCCDF standard score from the most recent configuration check.
• /ssapi/element/xccdf/results/00000001/score/?<uuid4> - an administrative entity can GET the XCCDF standard score from a specific prior configuration check

Some additional thoughts:

• elements should be able to upload security information, but not read it. This prevents a malicious entity on the element interrogating the stack aggregator for useful information.
• Within the private part of the stack, there should be URI's that are access restricted to all but high privilege users.
• Again, none of the above is published to the outside world

Next, how to express this information to the public stack without giving the game away...

(minor typo fixed - July 31, 2009)

(fixed incorrect escaping on non-HTML tags)

Can we do the Security Stack API RESTfully? (Part 3)

(Part 1 and Part 2 are here respectively)

(a bit of a shorter post tonight as I was on nephew duty)

So far, I've been focusing on organization elements of the stack, by that I mean things about the provider, specifically policies and compliance.

We're going to start moving into the stack space that deals with individual elements, and where we start using bits of SCAP. Before we can start considering individual elements, we need a way to register an element:

• /ssapi/registration/ - invoked by a POST on an XML payload containing Common Platform Enumeration data, IP address and other unique network identifiers (for example a FQDN - thinking MAC addresses are a problem given network segmentation) returns a UUID and new credentials to be cached by the POSTer. The POSTing element was provided with a limited use credential for the initial registration (consider this an authentication boorstrap). If another element tries to register the same IP address or other unique identifier - note, after having examined CPE, I think my comment earlier this morning about self-asserted URI's into a namespace ("I am 10.45.0.34" & "I am http://www.f5.com/products/...") was slightly off, so I'm changing course a little.
• /ssapi/registration/ - invoked by an authenticated DELETE will unregister the element. Invoked by an authenticated PUT will allow the element to update previously provided data including the network identifier, if and only if that identifier hasn't been claimed by anyone else (if it has, an error message is returned).

The registration payload could look like this:

<registration>

<networkID>

<IP address="10.45.0.24" />

<FQDN name="grump1234.xyz.corp" />

</networkID>

<cpe name="cpe:/o:sun:solaris:5.10" />

</registration>

note: I'm being lazy, this is not fully formed XML, pseudo XML at best

A few more thoughts:

• this is a RESTful API, which implies web servers, but I don't think we want to start running embedded web servers all over the place (not a fan of increasing attack surfaces). So most elements in an environment would push information to a purpose built aggregator.
• Much of the data that could be returned by the stack is not for public (or valued customer) consumption. That means part of this stack will be a generalized security information collection and sharing mechanism - I want to avoid repeating the wheel. The other part, and I think this is the most important thing we can accomplish, the stack provides cloud users with a tool and shared meaning to be confident in their cloud providers security.
• I haven't said anything about authenticating access to the stack or access restrictions to parts of the stack - I'm thinking OAuth for the former and something akin to SNMP's public/private for the access restrictions (keep it simple for now, refine in v2.x).
• The unique network identifier used by the element should be strongly bound to the element, that is we need some way to prevent impersonation of one element by a malicious element - client side x509 certs are the easy answer but impose deployment overhead, will need to think more on this. Once registration is complete, the unique network identifier must be bound to the issued credentials and UUID.
• I've avoided discovery for now, you could use a trusted feed from NMAP to populate some of your data set, but you still need to register the element for future conversation, although I suppose one feature implementation could be an agentless aggregator that also provides element security state using remote scanning.

Thanks to @lmacvittie for some thoughts on unique identifiers which led to a discussion on auto-discovery and other goodness - the bad news is that the security stack has a lot more work to be put in, so maybe the squirrel won't get his Friday wish, the goods news is Monday is a public holiday, so lots of thinking time this long weekend.

more to follow...

note: made some minor changes post a reread - removed incorrect reference to shared secret and revised URI to include UUID.

Can we do the Security Stack API RESTfully? (Part 2)

the Uber-Squirrel demanded I be done by TGIF...

part one is here; background detail is here.

This section deals with expressing the actual policies of the provider organization, obviously a complex information set to represent, so this will require a lot more detail and thinking. I think it's best that we use ISO27002 (the next version of ISO17799) given that it's the root standard from which all other compliance standards are derived; additionally

• /ssapi/ISO27002/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/ISO27002/@all - returns an XML payload with values and freshness for all descendants

The following list enumerates the eleven clauses:

• /ssapi/ISO27002/1/ - Security Policy
• /ssapi/ISO27002/2/ - Organizing Information Security
• /ssapi/ISO27002/3/ - Asset Management
• /ssapi/ISO27002/4/ - Human Resources Security
• /ssapi/ISO27002/5/ - Physical and Environmental Security
• /ssapi/ISO27002/6/ - Communications and Operations Management
• /ssapi/ISO27002/7/ - Access Control
• /ssapi/ISO27002/8/ - Information Systems Acquisition, Development and Maintenance
• /ssapi/ISO27002/9/ - Information Security Incident Management
• /ssapi/ISO27002/10/ - Business Continuity Management
• /ssapi/ISO27002/11/ - Compliance

One can iterate through the provider's policies and security behaviours as follows:

• /ssapi/ISO27002/1/ - returns a list of available security categories for the clause, immediate descendants only
• /ssapi/ISO27002/1/1/ - returns a list of available controls within a given category
• /ssapi/ISO27002/1/1/1/ - returns a list of available control statements
• /ssapi/ISO27002/1/1/1/@all - returns an XML payload with values and freshness for the control set
• /ssapi/ISO27002/2/@all - returns an XML payload with values and freshness for all descendants of the clause

An XML fragment from /ssapi/ISO27002/1/1/1/@all might look like this:

<standard name="ISO27002:2005"> <clause number="1"> <category number="1"> <control number="1" freshness="2009-29-02"> <summary>"We are compliant because of..." </summary> <state >implemented</state> <details>

"xyz cloud corp uses a multi-tiered approach to..."

</details> <reference>

http://www.xyz.com/policies/policy1.pdf

</reference> <reference>

http://www.xyz.com/policies/policy2.pdf

</reference> </control> </category> </clause> </standard>

Some additional thoughts on the Security Stack API (or A6):

• this API should be a generic interface for exposing both technical and organizational security information
• the API is a standardized framework for exposing information and while it won't replace existing approaches, it will ease users ability to ask for that information and get an answer that matches their expectations
• vendors will populate data to different parts of the stack, vendors that can't respond to certain parts of the API (for example, a Cisco ASA firewall can't opine on your policy for asset management) shouldn't be considered non-compliant
• there exists a need for an aggregator entity that collects stack information from distributed elements (maybe a firewall here, an IPS there, a compliance system somewhere else)
• the stack should not explicitly disclose information about the security state of system (at least not to guests in the environment or the unwashed masses), that's pointedly unsafe. However, the stack may unintentionally leak information that could be useful to an attacker. For example, the stack should never say - "I'm not patched against CVE-2012-435", but it may say "my patching policy is within 4 hours", which tells an attacker their window of opportunity - we'll have to think about this topic a lot more.

more to come tomorrow...

Can we do the Security Stack API RESTfully? (Part 1)

Been thinking about the Security Stack API (A6), wondering if we can do as a RESTful API, something about the URI structuring appeals to me and I think relates well to the many different sections one would need to cover, here's part the first blob:

• /ssapi/compliance/ - returns a list of compliance regimes the provider operates under and their
• /ssapi/compliance/PCI/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/@all - returns an XML payload with values and freshness for all descendants
• /ssapi/compliance/PCI/1/1/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/2/1/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/2/1/a - returns answer and freshness attribute
• /ssapi/compliance/HIPAA/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/HIPAA/@all - returns an XML payload with values and freshness for all descendants
• /ssapi/compliance/SOX/ - returns a list of sub-elements for the standard, immediate descendants only

Working on layout for policy expression, will share tomorrow.