Re: [sacm] SACM Architecture Draft

Sherif Mansour <cherifmansour@gmail.com> Mon, 18 February 2019 19:06 UTC

Return-Path: <cherifmansour@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AE6130E72 for <sacm@ietfa.amsl.com>; Mon, 18 Feb 2019 11:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJaVzKWE8V1M for <sacm@ietfa.amsl.com>; Mon, 18 Feb 2019 11:05:59 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C69128AFB for <sacm@ietf.org>; Mon, 18 Feb 2019 11:05:57 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id j19so14500042ljg.5 for <sacm@ietf.org>; Mon, 18 Feb 2019 11:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AP2eAEVth9d7v7LnVAuzJIJy0ZFplGTCOhgPMc0LCDo=; b=qazNjLn43XdoI+eJxkVh16HSlgZl2AKlkKBZ5Wq53sj5ryBPBZt84mgcnPMmSYHaId MX3OFljXmrA/Lu4hEYDwtOP1w7f5ZiGnpGEk3WN0N9Eqm2BR4Q1Nr1RdopLJgjMxFDA5 zWKY61y07m6jq//f0QKF3mH9K/tA/ljJqKX45Jg0AEvzUG7D3yUzPY4C2fLUlnXHp4VG VqN3SHXxvSFnWegNMFCduy3y2r9ivAaI2wSMYyVjXCv03kFT+mg2eRv1MxVBdLQTNloY s9h2SgQ/BgeNjvbG7mU1j3iUu5zyPZyRg3rbwrozFdWEp6umRvcah8Tv41Ya6/H0H90c ag9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AP2eAEVth9d7v7LnVAuzJIJy0ZFplGTCOhgPMc0LCDo=; b=XZQ8U09chTcGOnj3CWb08cbh/tpyXTPP7rjeOIUwvqkLboWoCJG66Aro4h6ZDyOKsf lY+c9Wh1SaLJG/VFzHZGLc5sRXG7J8YfRUtNyH/2qLTCkpRVIrDCXK08w0NQt1iEzoxa lzAyL3RTZ8EQkz8Evj8pj5dqCivGzk2hE86xSnGVYHk8FulKfLHBnp1aRJ6CeJL9lZpa gIU6NV1fWri9rnccd1JyBuw/jk+S2TAkcOvmqwz0mkpy2KWOtPH0iEAqj2nM6y442rpJ jcQjtJr8YVh1n1eic/3b7oSIQxTqXKI+8WK5g5abiRPKKROxuaaz6gp/4isdDOzdWju+ 52Ew==
X-Gm-Message-State: AHQUAuYNteO3BUuDfWOlXQ+JRyHpCz8C7lXyAnLnEwChvezClWYhuCgc Z8Xpjt0hD+zXJG7rwmGN6ZxVXaQ8vwFTcLDFJ4o=
X-Google-Smtp-Source: AHgI3IYYLnVZotuYmpEHdCF1gJldnATMAbdmhmAuiUJENpf5otHtiFSW9yigOzVL7mAfxl6dYv6QE1wIIRlRLOqIcSw=
X-Received: by 2002:a2e:a0cb:: with SMTP id f11mr16450839ljm.55.1550516755315; Mon, 18 Feb 2019 11:05:55 -0800 (PST)
MIME-Version: 1.0
References: <0AE1CB07-A9CF-4821-9F1B-4FCCF53C4AA3@gmail.com> <9e8f4cb9-d893-66cd-2900-183a6b0cc9e5@oracle.com> <332612F4-C281-42CE-85DD-5A2D862293F9@gmail.com>
In-Reply-To: <332612F4-C281-42CE-85DD-5A2D862293F9@gmail.com>
From: Sherif Mansour <cherifmansour@gmail.com>
Date: Mon, 18 Feb 2019 19:05:41 +0000
Message-ID: <CAOxmg6sGHR8e0wf0wGXEutNcPFY7sCzCw2H8oXScaP5Yurnm=g@mail.gmail.com>
To: Adam Montville <adam.w.montville@gmail.com>
Cc: Jarrett Lu <jarrett.lu@oracle.com>, sacm@ietf.org
Content-Type: multipart/related; boundary="0000000000006b67aa05822fd00c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/11n3OzNBwl-NGOoSnwyFrNXrysE>
Subject: Re: [sacm] SACM Architecture Draft
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 19:06:02 -0000

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 <adam.w.montville@gmail.com>;
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 <jarrett.lu@oracle.com>; 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/
>
>
> Kind regards,
>
> Adam & Bill
>
>
> _______________________________________________
> sacm mailing listsacm@ietf.orghttps://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>