Integration: PoC to enable XMPP integrations between SACM Components

An architecture proposal has been made to the SACM working group, and this repository holds proof of concept code for the scenario described below. The proposed architecture looks something like this:

Scenario 1: New Configuration Assessment Available

1. New configuration assessment content is published (via mockup policy source)
2. Configuration assessment publisher interface puts new content "on the grid"
3. Configuration assessment subscriber receives new content and passes to the assessment engine
4. Assessment engine interprets new content
5. Assessment engine collects data
6. Assessment engine evaluates data
7. Configuration assessment results are put "on the grid"
8. Configuration assessment results subscriber receives new results
9. Results subscriber imports results

We hope to largely configure (using Openfire) an XMPP-Grid with little or no additional coding (per the latest XMPP-Grid specification). Additionally, we intend to use an existing assessment engine and results aggregator (CIS-CAT Pro from CIS). This means we'll be primarily responsible for coding the following components:

1. A mocked content publication engine
2. Configuration assessment content publishing component
3. Configuration assessment content subscriber component
4. Configuration assessment results publishing component
5. Configuration assessment results subscriber component

Follow-on Ideas/Learnings

This flow has been a relatively simple pub/sub model that requires, for out-of-the-box interoperability, some prior understanding of the nodes that are available and what we can expect to go across them. We have not yet explored what the interface ought to be for watching a given configuration item, as one example, nor have we looked at what a fully-specified interface would look like for getting the latest applicable guidance from the policy side.

In face, we have identified that relying only upon the XMPP-grid draft as it has been submitted in MILE is insufficient for our needs in SACM. Our hypothesis looked at what might work for a core messaging infrastructure, now we need to focus on the interfaces for each component.

• Interface to local state assessment policy storage
  • List available content
    • By type (i.e. security purpose)
    • By platform
    • By type and platform
    • By name
    • By date or date range
    • By version
    • By * (some extension that might be proprietary)
    • Others?
• Interface to collector
  • Ad hoc assessment (on-demand processing)
  • State item watch actions (watch, stop watching, etc.)
  • Mandatory periodic reporting
• Interface to evaluator
• Others?

From this type of exploration we hope to arrive at a natural way of describing the abstract interfaces required for each component, and to specify an XMPP binding for that interface. We will also need to specify data models for certain uses and likely the semantics behind the specific "capabilities".

We've also learned a lot more about the possibilities with XMPP and it's set of extensions (XEPs). Specifically, we see some promise in several, if not most, of the following XEPs:

• Entity Capabilities: XEP-0115 - May be used to express the specific capabilities that a particular client embodies.
• Form Discovery and Publishing: XEP-0346 - May be used for datastream examples requiring some expression of a request followed by an expected response.
• Ad Hoc Commands: XEP-0050 - May be usable for simple orchestration (i.e. "do assessment").
• File Repository and Sharing: XEP-0214 - Appears to be needed for handling large amounts of data (if not fragmenting)
• Publishing Stream Initiation Requests: XEP-0137 - Provides ability to stream information between two XMPP entities.
• PubSub Collection Nodes: XEP-0248 - Nested topics for specialization to the leaf node level.
• Security Labels In Pub/Sub: XEP-0314 - Enables tagging data with classification categories.
• PubSub Chaining: XEP-0253 - Federation of publishing nodes enabling a publish node of one server to be a subscriber to a publishing node of another server Easy User Onboarding: XEP-0253 - Simplified client registration

Possibilities For The Future

We'd like to try to get an external policy source federated with a local policy source, which might look something like this.

Then, we will look at what other XMPP extensions (see previous section) might be able to do for us for specific workflows (TBD).

We also recognize the distinct possibility that agents could be direct participants in an XMPP-grid.

And, from that thought process XMPP presence with capabilities (features and items) naturally follow.