Thursday, July 30, 2009

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)

No comments:

Post a Comment