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.