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

"Haynes, Dan" <dhaynes@mitre.org> Mon, 22 May 2017 17:24 UTC

Return-Path: <dhaynes@mitre.org>
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 0F5211250B8 for <sacm@ietfa.amsl.com>; Mon, 22 May 2017 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.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 B1HePjbEkxN6 for <sacm@ietfa.amsl.com>; Mon, 22 May 2017 10:24:49 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id D087012EB36 for <sacm@ietf.org>; Mon, 22 May 2017 10:24:48 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3D3B96C00CA; Mon, 22 May 2017 13:25:05 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 24EB56C00B0; Mon, 22 May 2017 13:25:05 -0400 (EDT)
Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 22 May 2017 13:24:47 -0400
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 22 May 2017 13:24:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rRf0Opank6CbAma7Mq7EXSJWpoUwmhcDmgf7D2wZifA=; b=qMnA0gkLVFfRxHrAzQZYPVS2pCn9VqJR/6zB+UFV+vDp25I+Qga5c4kiIW9c9rQc1qCA0cEl5F24IdrxYrAWHksyu7rEIP+xk4n+MQ9pxBNkr7cJnCUtZ9QDJ7gVTqVC2GzNklbinBm5N5Ja/BxWPn0Q+20V6Tm3roGverz2+Lo=
Received: from DM5PR09MB1354.namprd09.prod.outlook.com (10.172.38.135) by DM5PR09MB1355.namprd09.prod.outlook.com (10.172.39.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Mon, 22 May 2017 17:24:41 +0000
Received: from DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) by DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) with mapi id 15.01.1101.019; Mon, 22 May 2017 17:24:41 +0000
From: "Haynes, Dan" <dhaynes@mitre.org>
To: "Haynes, Dan" <dhaynes@mitre.org>, Adam Montville <adam.w.montville@gmail.com>, Jerome Athias <jerome.athias@protonmail.com>
CC: "sacm@ietf.org" <sacm@ietf.org>
Thread-Topic: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)
Thread-Index: AQHSw42MKW8cblClSU+yNLHG1MLueaHiMGmAgADk/QCAFamlcIAAT/QAgAKrbHCABPb2QA==
Date: Mon, 22 May 2017 17:24:40 +0000
Message-ID: <DM5PR09MB135448EED5B0AF26E47C0BC1A5F80@DM5PR09MB1354.namprd09.prod.outlook.com>
References: <CACknUNUNhCCV8LRDpjEm1SvgwpLq+NEEDbc3LOPYzMyRbmfy9w@mail.gmail.com> <CACknUNXtxuHKcO35vzNR79m--UfNP4E5tRMSFr=WXJpbdQOCrw@mail.gmail.com> <CACknUNW9A0dttxjzAymS0CqN3eF7z63GyCecnn4y6QMUcpgt3g@mail.gmail.com> <iFofHfKOzZW3sMvsW6tHUfYfKDFhsCCGQRNwrebcrYJ3xzGcxK4p-2EYUTVnZgD9VjwIqqWGlpqreM0LVVMVy3QTq9Pc6PXAyxQLgOX5kSU=@protonmail.com> <CACknUNXFNPu+SRbGwP0zdr-GQQ8fvyFkfq-E2sMC2uKM1tVOpA@mail.gmail.com> <DM5PR09MB13549D43EE6B18208C39FCF6A5E70@DM5PR09MB1354.namprd09.prod.outlook.com> <CACknUNW7+y6c93y5UNgEVs69sdf6PK7rRpHw-F7GhFanZCFXFQ@mail.gmail.com> <DM5PR09MB1354DE08127393031FFC9F86A5E50@DM5PR09MB1354.namprd09.prod.outlook.com>
In-Reply-To: <DM5PR09MB1354DE08127393031FFC9F86A5E50@DM5PR09MB1354.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mitre.org; dkim=none (message not signed) header.d=none;mitre.org; dmarc=none action=none header.from=mitre.org;
x-originating-ip: [192.160.51.87]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR09MB1355; 7:CUlaWtrn48VMA8SSGLf2qQ6bUVaaz+JRfP+8cayWgAEjFjTd8mxohVJfRocr8rog2rFUNsHt/wCVwK7Z8t59VoC9JLqmvZ1eOMos4p4rCoJKFnkphGd2CLkyptPF2SfCAjB6W6UXEUGdxo6hLVK0FdOkwxwAnTCk0S71P9lSuf7Qtv751xTcxKW0O0fE1I8j2piIairRkSkysGTVzyjJT9mocxD68IVJ9Eau3pw+HNyKaK9jObRnELxGx28EPSYB6Ls54PaeSTvjQT3OA+zvsGC4XeB4uU32AguQ081ULNbt2FQl8fjSFWNFG3jcThvrY0ik4mFJUBqQhMEN3+OBsA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39860400002)(39840400002)(39450400003)(39850400002)(57704003)(53754006)(24454002)(377454003)(13464003)(7906003)(2900100001)(99286003)(74316002)(97736004)(6246003)(7736002)(81166006)(229853002)(2950100002)(19609705001)(6306002)(189998001)(86362001)(50986999)(55016002)(54896002)(5660300001)(93886004)(122556002)(8936002)(5890100001)(8676002)(38730400002)(236005)(33656002)(4326008)(54356999)(9686003)(76176999)(7696004)(966005)(39060400002)(66066001)(102836003)(6116002)(2906002)(53546009)(606005)(3280700002)(3660700001)(6506006)(77096006)(6436002)(478600001)(790700001)(25786009)(53936002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR09MB1355; H:DM5PR09MB1354.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-traffictypediagnostic: DM5PR09MB1355:
x-ms-office365-filtering-correlation-id: 41f6d5e2-00dc-44e5-6830-08d4a1376e34
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM5PR09MB1355;
x-microsoft-antispam-prvs: <DM5PR09MB135569CF1AE3B03E444B7F86A5F80@DM5PR09MB1355.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148); SRVR:DM5PR09MB1355; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1355;
x-forefront-prvs: 03152A99FF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR09MB135448EED5B0AF26E47C0BC1A5F80DM5PR09MB1354namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 17:24:40.8792 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1355
X-OriginatorOrg: mitre.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/i5nIGK_3y94m9PqWC3h_vWWkaag>
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: Mon, 22 May 2017 17:24:52 -0000

I just updated the “Vulnerability Description Information” section in the Vulnerability Assessment Scenario wiki [1] to include the following statement.

“The enterprise is responsible for determining the sources of vulnerability description information as well as which vulnerability description information is converted into vulnerability detection data.”

Jerome, I think this should address your comment about giving the enterprise the flexibility to determine which of the vulnerability description information is converted into vulnerability detection data. Let me know if it is missing anything or if there is anything that could be improved.

Thanks,

Danny

[1] https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan
Sent: Friday, May 19, 2017 9:07 AM
To: Adam Montville <adam.w.montville@gmail.com>; Jerome Athias <jerome.athias@protonmail.com>
Cc: sacm@ietf.org
Subject: Re: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)

Yeah, I can update it next week.

Thanks,

Danny

From: Adam Montville [mailto:adam.w.montville@gmail.com]
Sent: Wednesday, May 17, 2017 4:21 PM
To: Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>>; Jerome Athias <jerome.athias@protonmail.com<mailto:jerome.athias@protonmail.com>>
Cc: sacm@ietf.org<mailto:sacm@ietf.org>
Subject: Re: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)

Yes, I think so. Any chance you can update?
On Wed, May 17, 2017 at 10:35 AM Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>> wrote:
Maybe this should be noted in the wiki somewhere?

Thanks,

Danny

From: sacm [mailto:sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org>] On Behalf Of Adam Montville
Sent: Wednesday, May 03, 2017 4:46 PM
To: Jerome Athias <jerome.athias@protonmail.com<mailto:jerome.athias@protonmail.com>>
Cc: sacm@ietf.org<mailto:sacm@ietf.org>
Subject: Re: [sacm] Component Communication Sequence (Was - Re: Components for Vulnerability Assessment)

That seems like it could be a reasonable optimization, provide the VDI had enough information and structure. I'm not sure they always do and I would suspect that some organizations just take a look at what's been defined in, say, the OVAL repository (a VDD source) and work optimizations from there.

Other thoughts?


On Wed, May 3, 2017 at 2:06 AM Jerome Athias <jerome.athias@protonmail.com<mailto:jerome.athias@protonmail.com>> wrote:
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<mailto:adam.w.montville@gmail.com>
To: sacm@ietf.org<mailto:sacm@ietf.org> <sacm@ietf.org<mailto: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<mailto: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<mailto: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