Re: [Suit] Ripple20

Dick Brooks <dick@reliableenergyanalytics.com> Tue, 16 June 2020 21:52 UTC

Return-Path: <dick@reliableenergyanalytics.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01EA3A07E3 for <suit@ietfa.amsl.com>; Tue, 16 Jun 2020 14:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.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 QMCJASWUyTTE for <suit@ietfa.amsl.com>; Tue, 16 Jun 2020 14:52:32 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461D63A083A for <suit@ietf.org>; Tue, 16 Jun 2020 14:52:32 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 98E1F5C00CF; Tue, 16 Jun 2020 17:52:31 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 16 Jun 2020 17:52:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ErPuanRy4rLdLV8DDR9bsP42oQ2vuqaZyxXg0Eoqv Ek=; b=NsTJnlE4a1Pj3gaWSKfB57azKJlh+10UypZCGOEPb39hVEpHKeog+wizB 5inPGnHHQ1lKxjzbgAVKe3ZFdMwugP4H4RDFkxy5ZeFl9m+F8+bfAJ/SJA/Lr+3x LwBxvL1tBUEj9yJoufW2kMXCys/vCbxUU7jp1J34ZJ2rgLYp67bhrvMepTwwg4d9 hHiseyyEs+fT0LpTzaBW3pSJMKj/1RX6VkhIJQGV+kpqegSCja9p3XjTR+PKmNWr 60d2po3Y42gMTQig6ieS/HS2Lrg26B4i3882nUdHnJhxHyYqL8CZtStKUrE+RnuI petU9bCfavG4/OOSbM7AQmrm8Naaw==
X-ME-Sender: <xms:Hz_pXkElOxN23OOoXwbEgwdvC15s9eplhc5A2gxQZ1Eq6lcxIxvoDg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejuddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtgffothesthhqghdtvddtjeenucfhrhhomhepfdff ihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrg hlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepgeejtdetheduudehudeihffh feetheetueelfedugffftdefveegjefhhefhheefnecuffhomhgrihhnpegvvghirdhorh hgpdhorghsihhsqdhophgvnhdrohhrghdprhgvlhhirggslhgvvghnvghrghihrghnrghl hihtihgtshdrtghomhenucfkphepvdduiedrudelfedrudegvddrvddvnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughitghksehrvghlihgr sghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhm
X-ME-Proxy: <xmx:Hz_pXtVeiVF5YM-UeJGZOOj3ke50kWnj_xnlfxsUQodjw2WNTKFAMg> <xmx:Hz_pXuIWbTyGESjFk5Bo_9gnnHHmvnqgNWtIjaYgpQcXM5pNKkqTjQ> <xmx:Hz_pXmE2PRaMzsgVg3lcs160xbwhBGTaejsXcyd0iCdw0-RhO5Ke5w> <xmx:Hz_pXjduPWB_X5LnGahDQXX8128bCP8bM2lZ1uY2wQ2Qculgtmrz_Q>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 118753061856; Tue, 16 Jun 2020 17:52:31 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Roman Danyliw'" <rdd@cert.org>, "'Eliot Lear'" <lear=40cisco.com@dmarc.ietf.org>
Cc: "'suit'" <suit@ietf.org>, "'Russ Housley'" <housley@vigilsec.com>, "'Friedman, Allan'" <AFriedman@ntia.gov>
References: <F6BDED6E-B812-4CE8-9CDF-FC0CC2D4DB38@vigilsec.com> <9D9F401F-3DD8-48F7-92F5-9B5AAEF1D8E0@cisco.com> <44c701d64401$415e3f40$c41abdc0$@reliableenergyanalytics.com> <A3E64275-F85F-4706-A69B-2A4C4C9AD02A@cisco.com> <6e24de15cc5e4477aed5ec9914893e6c@cert.org>
In-Reply-To: <6e24de15cc5e4477aed5ec9914893e6c@cert.org>
Date: Tue, 16 Jun 2020 17:52:26 -0400
Organization: Reliable Energy Analytics
Message-ID: <016501d64428$6f2dc720$4d895560$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG+wxrzAypCg1McIomWLtn0vlY2pAG9USWcAje9f/8A0CEt1QJZ4WjnqNHLqiA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/ISZ3aaw7oyR3p0Q8OTufYK0vvc8>
Subject: Re: [Suit] Ripple20
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2020 21:52:36 -0000

Thank you, Roman.

The focus on SBOM took an interesting twist in May when Edison Electric Institute released boilerplate procurement language specifying that software vendors supply SBOM's as part of the NERC Supply Chain standards that are scheduled to go into effect on 10/1/2020. 
https://www.eei.org/issuesandpolicy/Documents/EEI%20Law%20-%20Model%20Procurement%20Contract%20Language.pdf

Excerpt from EEI procurement language I'm referring to: 
Requirement R1.2.5 Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System. Proposed EEI Contract Language
Hardware, Firmware, Software, and Patch Integrity and Authenticity:
...
(e) Contractor shall provide a software bill of materials for procured (including licensed) products consisting of a list of components and associated metadata that make up a component.

With regard to vulnerability reporting: I'm currently working with the Oasis-Open CTI workgroup developing STIX and TAXII standards; https://www.oasis-open.org/apps/org/workgroup/cti/index.php 

I've also heard that NIST is working on some enhancements to the NVD that may offer some improved search results with a better signal/noise ratio (less false positives).

The ideal scenario would be to have standardized SBOM data and semantics that are also used in the vulnerability search criteria of the vulnerability databases; this would provide a level of interoperability that the energy industry could really benefit from in their software risk assessment controls. 

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Roman Danyliw <rdd@cert.org> 
Sent: Tuesday, June 16, 2020 5:23 PM
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>rg>; Dick Brooks <dick@reliableenergyanalytics.com>
Cc: suit <suit@ietf.org>rg>; Russ Housley <housley@vigilsec.com>
Subject: RE: [Suit] Ripple20

Hi!

[snip]

> I do have a question for the chairs/AD.  I realize that this is a bit 
> out of scope for SUIT. Is there a more appropriate list we should be vectored to?  Thanks for the group’s indulgence to this point.

A timely and important topic here.  Indeed, solving SBOM directly is out of scope for the current SUIT charter, but this list seems like the closest we currently have to discussing security issues in the software supply chain.  I'm fine with it staying on suit@ietf.  If the volume increases, we can certainly make a dedicated list.

As exchanging CVE data was discussed too, the MILE WG has work in exchanging vulnerability data, but not with the lens suggested here.

Thanks for checking

Regards,
Roman