Re: [sacm] SACM Architecture Draft

[Sherif Mansour <[e-mail]>]

Hello David,

Do you think there should be a distinction between reference data feeds
such as NVD/Mitre/Other Threat Intel feeds, Inventory, and a security
repository? I was assuming the repository in an authoritative data source
which maps an asset to a security result and enriched with external feed
sources e.g. NVD.
The reason being you would need a data model and the ability of
consistently tie the data sets together. I wasn't to focused on the
interface, but it would be helpful to have an ADS that provides a source of
truth of the security posture for any given point in time.

I dug up an old diagram I sent out last year - it can use an update to give
you an idea where I was going with this.
The light blue boxes are end clients or CI/CD systems which would leverage
SCAM orchestration
The pink and orange boxes are inventories/datafeed/reference data which all
feed into a repo which acts as a source of truth of the security posture
for any given point in time.

[image: image.png]




On Tue, Feb 19, 2019 at 3:28 PM Waltermire, David A. (Fed) <
[e-mail]> wrote:

> Organizations will need to interact with repositories operated by other
> organizations (e.g., the National Vulnerability Database, CVE project,
> etc.) as well as local repositories that host historic information. In some
> cases, clients might not know what to specifically query, but may instead
> need to browse through hosted data to find what information they are
> interested in. A request/response communication pattern is ideal for this
> type of interaction.
>
>
>
> A message bus is ideal for exchanging up-to-date information or for
> notifying participating clients when new information is available from a
> service. It might be best to allow for both types of solutions in the SACM
> architecture. There are numerous ways to provide for a common
> authentication model without performing all authentication/communications
> through a message bus.
>
>
>
> Where I see value in a message bus is for discovery of services, for
> notifications of new data being available in a service, and to flow new
> data through the system. I don’t think it is practical to force all
> components to communicate only through the message bus.
>
>
>
> Here is a potential flow with a hybrid of both types of communications.
>
>
>
> 1) Client authenticates to the message bus and subscribes to notifications
> of new configuration checklist data.
>
> 2) A ROLIE server syndicates new checklist data from the NVD, from the
> national checklist program repository using the ROLIE protocol.
>
> 3) The ROLIE server notifies all clients that this data is available over
> the message bus.
>
> 4) A collection client queries the ROLIE server to retrieve new checklist
> data, and to find relevant historic checklist data it needs to collect for.
> It may also request SWID tags, OVAL definitions, and other supporting
> information from local or remote services to determine what to collect.
>
> 5) Collection in performed, perhaps on an ongoing basis, and collected
> data can then be published over the message bus and also stored to directly
> associated storage locations (e.g., CMDBs).
>
>
>
> A message bus only solution would complicate the communication in #4
> above, and would not account for remote communications in #2 and #4 at all.
> In all cases above, communication can occur using standardized interfaces.
> Some use a message bus, others use interfaces provided by other protocols
> like ROLIE. This also allows for a cooperative ecosystem, and doesn’t
> diminish from vendors providing solutions that can plug in.
>
>
>
> Regards,
>
> Dave
>
>
>
> *From:* sacm <[e-mail]> *On Behalf Of * Bill Munyan
> *Sent:* Tuesday, February 19, 2019 9:54 AM
> *To:* Sherif Mansour <[e-mail]>
> *Cc:* Jarrett Lu <[e-mail]>; Adam Montville <
> [e-mail]>; <[e-mail]> <[e-mail]>
> *Subject:* Re: [sacm] SACM Architecture Draft
>
>
>
> Sherif,
>
>
>
> Thanks for reading the draft and providing feedback!  We really appreciate
> it...  I have some comments/questions in-line:
>
>
>
> > Should the downstream users pull their data from the repo (an
> authoritative data source) instead of the message bus?
>
> > That way, there is a consistent view of that the current state of an
> end-point security posture and analysis can be built on top if it. I would
> not think it can be > done directly from the message bus. I also would
> think the information from the repo would be bi directional?
>
>
>
> [Bill M]:
>
> The idea behind the message transfer system is to help define the
> interfaces between components..  The intent here is really to help create a
> "cooperative ecosystem", enabling vendors to plug in components where they
> fit in the architecture, develop custom components where necessary, etc.
>
>
>
> Whether the "message transfer system" exists over a message bus,
> integration pattern, REST interface, or other, the downstream functions
> would have access to the repository (or repositories) over some sort of
> "query" interface.  In the case of XMPP being used as the message transfer
> system, that interface could be a request using a custom IQ stanza with
> query information, and a response with the requested information.  In a
> solution which consolidates a results repository with reporting, there may
> just be a simple web application to visualize the data.
>
>
>
> I agree the information in the repository is bi-directional, and the
> diagram is intended to reflect that.
>
>
>
> > Equally had some question on the data ingest (message bus) I assume
> there is an Access model as not everything on the message bus is to be
> accessible by > everyone, is that taken into consideration?
>
>
>
> [Bill M]:
>
> I would also agree there would be an access model necessary, but that can
> be solution-specific.  Again using the XMPP-based solution, that access
> model could be maintained through the orchestrator's roster, roster groups,
> various pub-sub nodes, etc.  Is there a particular access model you had in
> mind when asking this question?  Any solution-based ideas on this certainly
> help me personally in visualizing all the concepts.
>
>
>
> > Should the Orchstrator have a direct connection to the Repo, there are
> cases where the orchestrator needs reference data in order to tell the
> posture > managers what to do and not just react to them. Additionally
> there are cases where what the posture manager finds from the collectors
> will be different than > what is on file in inventory and the discrepancy.
>
>
>
> [Bill M]:
>
> In the first diagram, the orchestrator would have a connection to the repo
> via the message transfer system.  This is a great question that will help
> us discover more about the interfaces we need to describe further in the
> document.  That "query" interface from the orchestrator can assist in
> getting the necessary reference data before sending collection requests off
> to the various collectors in the ecosystem.
>
>
>
> Hope that helps!  Glad to keep the conversation going as well, so thank
> you again for your review and feedback.
>
>
>
> Cheers,
>
> Bill M.
>
>
>
>
>
> On Mon, Feb 18, 2019 at 2:06 PM Sherif Mansour <[e-mail]>
> wrote:
>
> Hey Everyone,
>
> Sorry for popping in so infrequently. I have taken a brief look at the
> architecture, and I have some feedback:
>
> Should the downstream users pull their data from the repo (an
> authoritative data source) instead of the message bus?
>
> That way, there is a consistent view of that the current state of an
> end-point security posture and analysis can be built on top if it. I would
> not think it can be done directly from the message bus. I also would think
> the information from the repo would be bi directional?
>
> Equally had some question on the data ingest (message bus) I assume there
> is an Access model as not everything on the message bus is to be accessible
> by everyone, is that taken into consideration?
>
> [image: image..png]
>
> Should the Orchstrator have a direct connection to the Repo, there are
> cases where the orchestrator needs reference data in order to tell the
> posture managers what to do and not just react to them. Additionally there
> are cases where what the posture manager finds from the collectors will be
> different than what is on file in inventory and the discrepancy.
>
> [image: image.png]
>
>
>
> On Fri, Feb 15, 2019 at 12:05 PM Adam Montville <
> [e-mail]> wrote:
>
> Hi Jarret,
>
>
>
> Thank you for reading through the draft. Happy to talk about some of these
> things today during the interim. I think we would prefer that
> interfaces/capabilities are first described abstractly — irrespective of
> any specific messaging solution — and then use XMPP-Grid+ as an
> implementation example.
>
>
>
> Kind regards,
>
>
>
> Adam
>
>
>
> On Feb 14, 2019, at 7:27 PM, Jarrett Lu <[e-mail]> wrote:
>
>
>
> Hi Adam & SACM,
>
> I read the (active) architecture draft, and I believe it's a good one. The
> hackathon work reflected in the draft definitely carries some weight.
>
> Some architecture entities could be expanded and described at a more
> abstract level. For example, this draft appears to equate "capabilities"
> with set of interfaces. Are SACM capabilities supposed to be discoverable?
> If so, how should it be represented? If capabilities/functional interfaces
> are described in more general terms, and use XMPP-grid+ as an example of
> how it meets the functional requirements, this may make it appear less
> solution-centric.
>
> I vote for including workflows in the architecture document. It just reads
> better that way. It will increase the document size and takes longer to
> finish. As long as good progress is being made, is it really urgent to
> finish and publisher the architecture document.
>
> I think the Security Consideration section of the old architecture draft
> is pretty good. Do XMPP-grid XEPs adress the MitM, transport integrity and
> confidentiality concerns mentioned there?
>
> Regards.
>
> - Jarrett
>
>
>
> On 12/27/18 01:29 PM, Adam Montville wrote:
>
> Dear SACM,
>
>
>
> Happy (belated) Holidays and a Happy New Year to you!
>
>
>
> At our recent virtual interim meeting I promised to post a note to the
> list regarding our architecture draft to do three things:
>
>    1. Request review
>    2. Indicate whether we (the authors) believe it's on the right track
>    3. Assuming 2 is good, a list of what's left to be done.
>
> So, we're going to start with 2, move on to 3, and then end with 1...
>
>
>
> Bill and I both believe that the architecture draft is, indeed, on the
> right track. Henk, and possibly others (Nancy?), have described this draft
> as being too solutions-specific. Section 3, "Architectural Overview" is
> intended to be the place in this draft to describe the abstract ideas in
> the architecture. Section 3.1 talks a little bit about the roles of the
> SACM Components, and Section 3.2 provides the known information about an
> XMPP-based instantiation of the architecture (note Appendix A maps this
> instantiation back to our SACM requirements, RFC8248).
>
>
>
> Assuming that we are on the right track, then here's what we think yet
> needs to be done:
>
>
>
>    - Document specific Components, Capabilities, Interfaces, and Workflows
>
>
>    - IT Asset Management could probably stand to be fleshed out
>       - Vulnerability Management is reasonable documented in this draft,
>       but may need work
>       - Configuration management probably needs to be fleshed out as well
>       (needs to be tied to SACM Use Cases)
>
>
>    - Determine where to document the above (in this draft or in new
>    drafts), which will determine how long this draft takes to complete.
>    - Prague hackathon to continue the trend of discovering an XMPP-based
>    solution
>    - TODOs in the draft
>
>
>    - Privacy Considerations
>       - Security Considerations
>
>
>    - Flesh out our IANA Considerations
>
>
>    - Will likely result in additional draft work
>
>
>
>
>
> Clearly, there's a lot to be done here, and we really need your specific,
> actionable feedback on this draft. Feel free to reach out here or to either
> of us directly.
>
>
>
> This draft in GitHub: https://github.com/sacmwg/draft-ietf-sacm-arch
>
>
>
> This draft on the SACM documents page:
> https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-arch%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106737807&sdata=mgt4EPWcuBsLx3DR1sx01TbCEUlt6F37FpqKroSJNjI%3D&reserved=0>
>
>
>
>
>
> Kind regards,
>
>
>
> Adam & Bill
>
>
>
> _______________________________________________
>
> sacm mailing list
>
> sacm@ietf..org <[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/sacm <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106747816&sdata=YVjK0x2u12K9Ds3GWE4ekxjJrQsGu7CxVlEXHyLduik%3D&reserved=0>
>
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106757821&sdata=g%2Bt4sWCXGlkpiUnrQcAUFZir6pSmRODJgcOSYI%2FWrZs%3D&reserved=0>
>
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106757821&sdata=g%2Bt4sWCXGlkpiUnrQcAUFZir6pSmRODJgcOSYI%2FWrZs%3D&reserved=0>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106767830&sdata=RDvylTUYEQKBFEyoecw35wfzIIBRGG7K4YxJ5250Lw8%3D&reserved=0>
>
>