Re: [sacm] SACM Architecture Draft

[Shawn Wells <[e-mail]>]

Must admit I have no context. What is SACM? Never heard of it before.

-Shawn



On 2/20/19 11:38 AM, Ruben Oliva wrote:
> David and all:
>
> As we move towards a "repository-focused" model, the thought of a list 
> of repositories appears to make sense.
>
>
> Are you aware of anyone keeping a list of repositories?
>
>
> David Oliva
>
>
> -----Original Message-----
> From: Waltermire, David A. (Fed) 
> <david.waltermire=[e-mail]>
> To: Bill Munyan <[e-mail]>; Sherif Mansour 
> <[e-mail]>
> Cc: Jarrett Lu <[e-mail]>; Adam Montville 
> <[e-mail]>; <[e-mail]> <[e-mail]>
> Sent: Tue, Feb 19, 2019 10:29 am
> Subject: Re: [sacm] SACM Architecture Draft
>
> 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] <mailto:[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..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.png
>     On Fri, Feb 15, 2019 at 12:05 PM Adam Montville
>     <[e-mail] <mailto:[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] <mailto:[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
>
>                       o IT Asset Management could probably stand to be
>                         fleshed out
>                       o Vulnerability Management is reasonable
>                         documented in this draft, but may need work
>                       o 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
>
>                       o Privacy Considerations
>                       o Security Considerations
>
>                   * Flesh out our IANA Considerations
>
>                       o 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  <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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>
>
> _______________________________________________
> sacm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sacm

-- 
Shawn Wells
Chief Security Strategist
North America Public Sector
[e-mail]   |   443-534-0130