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