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