Re: [sacm] ECP Architecture Diagram Feedback

Sherif Mansour <cherifmansour@gmail.com> Tue, 03 April 2018 21:36 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 CFD8112D87F for <sacm@ietfa.amsl.com>; Tue, 3 Apr 2018 14:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 C2jIZQJXSFnH for <sacm@ietfa.amsl.com>; Tue, 3 Apr 2018 14:36:04 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 CF7AF126C2F for <sacm@ietf.org>; Tue, 3 Apr 2018 14:36:02 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id h134so11160821vke.2 for <sacm@ietf.org>; Tue, 03 Apr 2018 14:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oQwGt9WdKY7Id6oE+h16RSbaneIyqDGjCjNSWtJOkr0=; b=Uu0ccYyaQZktJpTlzzIu5PDEH5lv8EIFHqL8MV25k30MnB7oeeBsQGGCtRmhfUyfLa 7Fi4gX0Xu4eDDDHgYozeME7XYBdKUFbyNDZDJ6WwNkZVSsNUnMaUf4ZvnD1FSnCpWMTj A8NFUl+YYy9grvdH+RySxQvDPGfpYeg5mH9VM+YgfGw/2qhvbAAWPKvDQ43ga44ZTLno kVY381eaynATv05Sh9vzenz/nj9yo2lP/tPxzuk3bWZ3R8R1eN2dF8Wg6/rMC5Az3JYp 8APwrKQHS9SspOX+5+iZ7HHTdPRpbX6yiZtPTF7tDv+9NVZ4xp6dH9ydcYgK0yNqLy/Y oa0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oQwGt9WdKY7Id6oE+h16RSbaneIyqDGjCjNSWtJOkr0=; b=Uu+sVfAaRHkEo7EhEf0peUXw308E4548D8zor7zW+CdHpVF+LEK4USw5No120qukRM ovKsbL3FmHyLkFo4zpZjE7diuC/k3KJoU0yB8BetuErLEbxdv2XH3zXv4EWnBIIbi4q+ QQ3LuFDJ9oreK1Ujl4ODX2JfjF+DpR/xFuZXXDB/eDZB+tIr+vfcZj7nGwm0nF7O8nFm CN0Kfk36C4JpQXFwsgd1QegO+AfoQZA4E7QS8RuhA364FKrJgHlXrdiSzhakA0hS9bxV oHYt2Rykm+B+4UD7uepqI4wdV13y59IyEqhpZsW6PnJkDEqOF8YlLrcwY4+ARaV3ygnD o7cA==
X-Gm-Message-State: ALQs6tCa7KN0RlxDJvQWWj//uIxidwOXiMlxrpxwJ9KAqlsXxOjDW3+e M0Dg7FVW5h/4DdD6Rvbz3sUKTsNgUOA/pSfIhwM=
X-Google-Smtp-Source: AIpwx4//9j2Df+GKY0Zp97FhPGL6QC0eZViTxupSXn3ziiEqNrgwpfVRkDxrGMeWppH2e8B97y3ceyJ6YMHrangxxIs=
X-Received: by 10.31.110.71 with SMTP id j68mr9419789vkc.66.1522791361848; Tue, 03 Apr 2018 14:36:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.219.24 with HTTP; Tue, 3 Apr 2018 14:36:01 -0700 (PDT)
In-Reply-To: <DM5PR0901MB2197CA6B3C285DD17A0D1C04A5A50@DM5PR0901MB2197.namprd09.prod.outlook.com>
References: <DM5PR0901MB2197070C2CF8BA9A4283251CA5A60@DM5PR0901MB2197.namprd09.prod.outlook.com> <D0D3E5A5-2D22-4B3A-AD3E-27386CC43887@gmail.com> <DM5PR0901MB2197CA6B3C285DD17A0D1C04A5A50@DM5PR0901MB2197.namprd09.prod.outlook.com>
From: Sherif Mansour <cherifmansour@gmail.com>
Date: Tue, 03 Apr 2018 22:36:01 +0100
Message-ID: <CAOxmg6tbzQBpqubuxn5DPFe1mcB7gjhX3hr5g8A4hMoexyki-A@mail.gmail.com>
To: "Haynes Jr., Dan" <dhaynes@mitre.org>
Cc: "Montville, Adam W" <adam.w.montville@gmail.com>, "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1437fe30aa6e0568f87e16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/8UFcXi35D3TWnq3IpWmJeIE0ovg>
Subject: Re: [sacm] ECP Architecture Diagram Feedback
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 03 Apr 2018 21:36:06 -0000

Hi Danny,

I would recommend that the Orchestrator sits between the posture manager
and repository. This is for a few reasons, some tactical and some strategic:

   - Strategically (Long term), it allows you to switch between posture
   managers without having to do much (if any) changes on the repository, in
   their all it means is it will be pulling data through the orchatrator, it
   just happens to be from a different tool.
   - Tactically (short term), is is because these connections currently do
   not exist, so if you have many posture managers you need to develop
   different integration in several areas (one connection for the orchestrator
   & repository). By leveraging the orchastrator, you only need to create a
   singe integration with the posture manager, it simply just needs more
   features (i.e. the ability to pull security end point findings, both in raw
   vendor specific data or in a uniform agreed data model).

The second point is that there are a few "invisible" boxes. The first is
reference data, a lot of the repository data would be enriched with
information that is specific to the organization such as the team which
owns specific assets or the context to which they are used. Now, on thing
that is out of scope is the reporting, I am aware this is out of scope, but
an organisation has not moved the needle in terms of security if they have
detected security issues but not resolved them. It is therefore natural
that there is an interface somewhere between the repository and a reporting
system.

Finally one key benefit of the orchestrator is automation and self service,
there for an interface to allow it to work in a devops model would also
increase its value, if the interface can (easily) integrate with
Jenkins/Bamboo, or chef recipes / Ansible playbooks, this would go a long
way for adoption.

-Sherif





On Tue, Apr 3, 2018 at 7:36 PM, Haynes Jr., Dan <dhaynes@mitre.org> wrote:

> Hi Adam,
>
>
>
> I hope it was a good trip out there and that you were able to see some of
> the sights!
>
>
>
> As far as scoping and the diagram, I think it’s worth nothing that all the
> components in it are in scope for ECP. It is just a matter of when we
> actually get to creating drafts for them (if that makes any sense). I think
> what you are looking for is a diagram that shows what we are currently
> working on? Or, maybe I am misunderstanding your comments?
>
>
>
> Thanks,
>
> Danny
>
>
>
> *From:* Adam Montville [mailto:adam.w.montville@gmail.com]
> *Sent:* Monday, April 02, 2018 3:33 PM
> *To:* Haynes Jr., Dan <dhaynes@mitre.org>
> *Cc:* sacm@ietf.org
> *Subject:* Re: [sacm] ECP Architecture Diagram Feedback
>
>
>
> Hi Danny,
>
>
>
> We missed you in London. I think the diagram is ok, but I do have scoping
> questions (just sent to the list) which may suggest some modification to
> the diagram once resolved. If the way I'm interpreting the ECP draft at
> this point is close to accurate, then it might be a good idea to add a
> horizontal scoping line between the left hand and the right hand of the
> diagram, where the posture manager is the first component on the right-hand
> side. Alternatively, an in-scope boundary box could be drawn around the
> appropriate components.
>
>
>
> What really matters is whether the diagram accurately depicts the intended
> scope of the draft from the authors' perspectives, and whether a typical
> reader would see it that way.
>
>
>
> Adam
>
>
>
> On Apr 2, 2018, at 1:32 PM, Haynes Jr., Dan <dhaynes@mitre.org> wrote:
>
>
>
> Hi Everyone,
>
> At IETF 101, we presented an updated architecture diagram [1] that was
> based on feedback from the September virtual interim [2][3] and was
> included in the ECP -01 draft [4]. During the meeting, we did not receive
> any feedback on the architecture diagram.
>
>
>
> As a result, we just wanted to follow-up on the list and see if there was
> any feedback or objections to the updated ECP architecture diagram that was
> proposed.
>
>
>
> Thanks,
>
> Danny
>
>
>
>
>
> [1] https://datatracker.ietf.org/meeting/101/materials/
> slides-101-sacm-endpoint-compliance-profile-00 (see slide 4)
>
> [2] https://datatracker.ietf.org/doc/slides-interim-2017-
> sacm-03-sessa-ecp/00/ (see slide 5)
>
> [3] https://datatracker.ietf.org/meeting/interim-2017-sacm-
> 03/materials/minutes-interim-2017-sacm-03-201709260900-00 (see page 1 and
> 2)
>
> [4] https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/
>
>
>
> _______________________________________________
> 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
>
>