Re: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)

Jerome Athias <jerome.athias@protonmail.com> Wed, 03 May 2017 07:08 UTC

Return-Path: <jerome.athias@protonmail.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 F1971129B07 for <sacm@ietfa.amsl.com>; Wed, 3 May 2017 00:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 Vbm1SyWwVnT7 for <sacm@ietfa.amsl.com>; Wed, 3 May 2017 00:08:42 -0700 (PDT)
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E5C129534 for <sacm@ietf.org>; Wed, 3 May 2017 00:06:24 -0700 (PDT)
Date: Wed, 03 May 2017 03:06:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1493795180; bh=jFpN4a3VzqA3raIvlqqEe1wUKwT7jPWwqolZ5WVZjYw=; h=To:From:Cc:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=mMAuGAbnlyQ4cSQ07MkAH8sx4ASl/NMk3TB9LsDQwRT4cTYPQhiJDsrAnW65zf4Wp WpBHWiKCavITbxxlVfr6HhVCz/5D8pM6WDIhE5s06o3NZLxPw6GkPr5qXlois0nDw8 V9rvJ9+XPcIA8AcdW7UHwLJgRZ/LL/TvuRgAGN2Y=
To: Adam Montville <adam.w.montville@gmail.com>
From: Jerome Athias <jerome.athias@protonmail.com>
Cc: "sacm@ietf.org" <sacm@ietf.org>
Reply-To: Jerome Athias <jerome.athias@protonmail.com>
Message-ID: <iFofHfKOzZW3sMvsW6tHUfYfKDFhsCCGQRNwrebcrYJ3xzGcxK4p-2EYUTVnZgD9VjwIqqWGlpqreM0LVVMVy3QTq9Pc6PXAyxQLgOX5kSU=@protonmail.com>
In-Reply-To: <CACknUNW9A0dttxjzAymS0CqN3eF7z63GyCecnn4y6QMUcpgt3g@mail.gmail.com>
References: <CACknUNUNhCCV8LRDpjEm1SvgwpLq+NEEDbc3LOPYzMyRbmfy9w@mail.gmail.com> <CACknUNXtxuHKcO35vzNR79m--UfNP4E5tRMSFr=WXJpbdQOCrw@mail.gmail.com> <CACknUNW9A0dttxjzAymS0CqN3eF7z63GyCecnn4y6QMUcpgt3g@mail.gmail.com>
Feedback-ID: 0pNaUpQyJcJ_FqKgvRh59kNH9tw1YU9Hb7-41TF1UFya4DA0ft6-ejYSrPjLLQWz-KcGUoHsZH8z6Hzy-ZW3EA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_26484be9e65b6a2609b669da8c798f4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/V3H5hfpPm2elzg_PKje4euFltGM>
Subject: Re: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)
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: Wed, 03 May 2017 07:08:49 -0000

Hi,

For now what is unclear for me is when/where it is determined that a VDI/VDD is interesting for me (applies to my endpoints).

For example:
I am retrieving everyday the latest CVE content from NVD.
Option 1: (apparently the current one) each new CVE/VDI is transformed and inserted in the VDD repository, which will trigger the flow. So for each and every CVE, I would enter the flow, and it will get/evaluate if I have endpoints that need to be evaluated before the assessment. - not optimized because they are more vulnerabilities released -not- affecting my endpoints than applicable ones

Option 2: (the one I'm using) each new CVE/VDI is evaluated by my Endpoint Manager (assets inventory/portfolio/cmdb) and ONLY IF it is relevant, it will be transformed and inserted in the VDD repository, which will trigger the flow. - more optimized, I will just assess what is relevant

Note that #2 could be assumed to be done up front, but imho would be nice to mention it.

Would this make sense?

Best regards

-------- Original Message --------
Subject: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)
Local Time: May 3, 2017 12:42 AM
UTC Time: May 2, 2017 9:42 PM
From: adam.w.montville@gmail.com
To: sacm@ietf.org <sacm@ietf.org>

Has anyone had time to take a look at the communication sequence here? I know we've not yet completely settled on goals, but I feel like we should still be able to have this discussion as well.

Thanks for your time.

Adam

On Fri, Apr 21, 2017 at 8:00 AM Adam Montville <adam.w.montville@gmail.com> wrote:

Hello Everyone,

After some discussion on this topic, I feel like we've got no real objection to this proposed list of components. As such, this brings us back to the second version of the sequence diagram that some of us were working with not too long ago (see attached PDF vector diagram).

Given that set of components, we can now start talking about the expected communications between them in an ideal case through the system. Remember that the VDI (vulnerability information) is assumed to have been transformed and placed into the VDD (vulnerability detection) Repository. I've numbered the flows in the attached sequence diagram to show the proposed order and so that we can talk about each flow by that number.

Does this flow feel right to everyone on the list? What needs to be different? What alternate flows may exist for the basic case of checking inventory against a new vulnerability?

Let's carry this discussion on for a week or so. (Do we need longer?)

Kind regards,

Adam

On Tue, Apr 18, 2017 at 8:03 AM Adam Montville <adam.w.montville@gmail.com> wrote:

Hi All:

We've got a list of components we think we care about for our vulnerability assessment scenario (focusing on the narrowest "ideal case" through the scenario for the time being.

These are:

* Vulnerability Detection Data Repository
* Vulnerability Assessor
* Endpoint Repository
* Collector
* Target Endpoint
* Assessment Results Repository

For reference, see our wiki [1] and/or the slides from IETF 98 [2] and/or the minutes from IETF 98 [3]

Question to the WG: Is this an appropriate initial list of components?

Please opine within the next few days (say by end of your day on Thursday, wherever you may be), so that we can generate some momentum on this effort.

Kind regards,

Adam

[1] https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario
[2] https://www.ietf.org/proceedings/98/slides/slides-98-sacm-vulnerability-scenario-discussion-00.pdf
[3] https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00.txt