Re: [OPSAWG] [EXTERNAL SOURCE] Re: [ntia-sbom-framing] Fw: Re: Fwd: ?? WG Adoption Call on draft-lear-opsawg-sbom-access-00

Tony Turner <tturner@fortressinfosec.com> Tue, 05 January 2021 16:02 UTC

Return-Path: <tturner@fortressinfosec.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4193A0DE4 for <opsawg@ietfa.amsl.com>; Tue, 5 Jan 2021 08:02:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=fortressinfosec.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 dDjp3OxdaqKh for <opsawg@ietfa.amsl.com>; Tue, 5 Jan 2021 08:02:08 -0800 (PST)
Received: from zh-gw.zixsmbhosted.com (spfaus-b.zixsmbhosted.com [74.203.184.41]) (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 94CE03A0DBF for <opsawg@ietf.org>; Tue, 5 Jan 2021 08:02:08 -0800 (PST)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.zh-gw.zixsmbhosted.com (Proprietary) with SMTP id CA2EB1C46A5 for <opsawg@ietf.org>; Tue, 5 Jan 2021 10:02:00 -0600 (CST)
Received: from encrouter04.b.smb.prod.austin.zixnet.com (encrouter04.b.smb.prod.austin.zixnet.com [10.155.130.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zh-gw.zixsmbhosted.com (Proprietary) with ESMTPS id 7FC111C4686 for <opsawg@ietf.org>; Tue, 5 Jan 2021 10:01:59 -0600 (CST)
Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by encrouter04.b.smb.prod.austin.zixnet.com (Postfix) with ESMTPS id 89E6A9E2 for <opsawg@ietf.org>; Tue, 5 Jan 2021 10:01:47 -0600 (CST)
Received: by mail-pg1-f197.google.com with SMTP id 18so24318706pgp.22 for <opsawg@ietf.org>; Tue, 05 Jan 2021 08:01:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fortressinfosec.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oze8K60CO+4i9rqvuyze1mBybAob/EdHY25WKAnaTCo=; b=HvXRISacgcloZ8gtIncTn9pN+R0HSuvnCWyWC1qujWJDiAIzKCh6+YkdD2E9yp7ZR9 Gdq4KXEnqXWRY5RlK7uNuqQv+KC0PsOMc9ILojjTZ1G/qTzCO0p8ISBXtJ8F9OuQPYf2 +lgfg2TwWXb+RCrB2fWUA0dFelPGrKRlfJ9es=
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=oze8K60CO+4i9rqvuyze1mBybAob/EdHY25WKAnaTCo=; b=pS+AaByQeDN78NRrLy7C9lRBJTtPxQOI4pgrvDRF4efiemcVuiSeOdSCuDJqpXn//c dRvENC9nL7YXTWrWN5MkpTkpDuE2ZnLu+UJYkObhmxqJ6HV/bBVLo5NBSXxBJtpU2UWK OCEgcC782u5nnyPF+N+mzWK217XHtMvjjL0fXBCoHh/QPh5mOzeluy9mgTLZe7XcXxU6 NvBvFz6d+UrRcc4fwzj7DE/V5SrhNZyZIAXWZPRvR0v4Bzkt65rdMEYLFnzF/kee2k3e pzLb9qPRCY69zjfRH+ozEBNfprGMn8sPXsvLmHHtgCgxqcwOSv+I9adhX/wtKEy1LL6a dEIA==
X-Gm-Message-State: AOAM530jTAV6Ptl48wcgRkfyDZt7mSDsQ4/1yb+WO4yKrjo5XfYLI377 bs9d+bZWWCg5HRDdo/pqsBQfuvqzq5MA3yapvq0HKbF2fUEh8Pngidxlf6mykx5YGkwy6RcIOrP ePlBaLLvlyOo9koW8JFiOwgkV8BGfvQXZ+RIjjWZKC8Xfr18=
X-Received: by 2002:a17:90a:de03:: with SMTP id m3mr6098pjv.20.1609862506280; Tue, 05 Jan 2021 08:01:46 -0800 (PST)
X-Google-Smtp-Source: ABdhPJy0XaZrau74lE3R2j6KlenndlfiJ4mfuE4jX6KFF1Va91v0lioh25liRmP3ppFeTRfvRl5r1y2809/Ror8jx6c=
X-Received: by 2002:a17:90a:de03:: with SMTP id m3mr6056pjv.20.1609862505768; Tue, 05 Jan 2021 08:01:45 -0800 (PST)
MIME-Version: 1.0
References: <ema9be735c-1725-4ceb-8ca1-bc90f895f94e@vwdl7400-36262r2> <27fb01d6e37a$b376a220$1a63e660$@reliableenergyanalytics.com> <E1A6BF55-6E1C-42EF-BB7C-7FEF43D5A362@cisco.com> <283501d6e37b$344d1dc0$9ce75940$@reliableenergyanalytics.com>
In-Reply-To: <283501d6e37b$344d1dc0$9ce75940$@reliableenergyanalytics.com>
From: Tony Turner <tturner@fortressinfosec.com>
Date: Tue, 05 Jan 2021 11:01:34 -0500
Message-ID: <CANRyRchM=GT-2dqUa9cAY7j2ickUYh7XaQ2fP2_9imxw99th-A@mail.gmail.com>
To: Dick Brooks <dick@reliableenergyanalytics.com>
Cc: Eliot Lear <lear@cisco.com>, Christopher Gates <chris.gates@velentium.com>, opsawg@ietf.org, ntia-sbom-framing@cert.org
Content-Type: multipart/related; boundary="000000000000cb5a4905b8295235"
X-ZIXHOSTED-CUSTOMER: for32801
X-VPM-MSG-ID: 7aaf6e7b-4c67-40af-a94c-93b7af8991b6
X-VPM-HOST: zgw-for32801.b.smb.prod.austin.zixnet.com
X-VPM-GROUP-ID: 18383ebc-33fc-4605-b3f4-d35cfb984620
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/y4eY_DUt-d6lMXFxOc36CniXeQo>
X-Mailman-Approved-At: Sun, 10 Jan 2021 17:23:09 -0800
Subject: Re: [OPSAWG] [EXTERNAL SOURCE] Re: [ntia-sbom-framing] Fw: Re: Fwd: ?? WG Adoption Call on draft-lear-opsawg-sbom-access-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 16:05:24 -0000

I think you have to support both and have ability to map between the two if
you want to have any hope of interoperability because the standards
universe here is very fragmented. I see more appsec products supporting
CycloneDX while I see more software providers supporting SPDX. And then
multiple other providers doing their own proprietary thing, either a
variation of SPDX or something entirely new. Some SBOMs I see are nothing
more than a software (not component) inventory as discovered on disk, or
just a basic table with supplier, component, version.

On Tue, Jan 5, 2021 at 10:56 AM Dick Brooks <
dick@reliableenergyanalytics.com> wrote:

> I would support having both SPDX and CycloneDX. Both have proven viable in
> my testing.
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: dick@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788
>
>
>
> *From:* Eliot Lear <lear@cisco.com>
> *Sent:* Tuesday, January 05, 2021 10:53 AM
> *To:* Dick Brooks <dick@reliableenergyanalytics.com>
> *Cc:* Christopher Gates <chris.gates@velentium.com>; opsawg@ietf.org;
> ntia-sbom-framing@cert.org
> *Subject:* Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption
> Call on draft-lear-opsawg-sbom-access-00
>
>
>
> Ok.  Should I add something for CycloneDX?
>
>
>
> Eliot
>
>
>
> On 5 Jan 2021, at 16:51, Dick Brooks <dick@reliableenergyanalytics.com>
> wrote:
>
>
>
> I concur with Chris. I’ve heard reports of people trying to use SWID to
> communicate SBOM information and they are having to make some “brave”
> assumptions in the process.  SPDX and CycloneDX seem  to be the only viable
> SBOM formats, based on my testing experience with both formats.
>
>
>
> There remain several issues on naming and identification conventions. A
> lot of the challenges I’ve experienced could be addressed if NIST NVD and
> NTIA SBOM parties could reach an agreement on how names/identifiers will be
> represented in their respective domains. It would only require a few
> elements to be agreed to, like Publisher name, Product name and Version
> identifier to make an impactful improvement in vulnerability search
> results, using SBOM data as inputs.
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
> <image001.jpg>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: dick@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788
>
>
>
> *From:* OPSAWG <opsawg-bounces@ietf.org> *On Behalf Of *Christopher Gates
> *Sent:* Tuesday, January 05, 2021 10:27 AM
> *To:* opsawg@ietf.org
> *Subject:* [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: 🔔 WG Adoption Call
> on draft-lear-opsawg-sbom-access-00
>
>
>
>
>
> ------ Forwarded Message ------
>
> From: "Christopher Gates" <chris.gates@velentium.com>
>
> To: "Eliot Lear" <lear@cisco.com>; "ntia-sbom-framing@cert.org" <
> ntia-sbom-framing@cert.org>
>
> Sent: 1/4/2021 2:48:51 PM
>
> Subject: Re: [ntia-sbom-framing] Fwd: [OPSAWG] 🔔 WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
>
>
>
> Eliot,
>
>
>
> I joined the IETF WG, and I have some feedback....
>
>
>
> <image002.png>
>
> A "SWID tag" isn't an SBOM format, as stated here. It is an element inside
> of an SBOM.
>
> Since we have removed SWID as a format we in the "NTIA SBOM WG are
> supporting for SBOM use, shouldn't this reference be removed from the IETF
> draft as well?
>
>
>
>
>
> Also, I still think that creating a Bluetooth Low Energy SBOM Adopted
> Profile (via the Bluetooth SIG) that is harmonized with this would be a
> good thing:
>
> <image003.png>
>
>
>
> Due the the low bandwidth of BLE we wouldn't attempt to provide the SBOM
> via BLE, just the link to a URI that can deliver the SBOM.
>
> It would create a standardized UUID (16 bit) for the SBOM Adopted Profile,
> and have a consistent set of characteristics being exposed via BLE.
>
> This is exactly how an Adopted Profile is supposed to be defined and
> utilized.
>
>
>
>
>
> Christopher Gates
>
> --------------------------------
>
> Director of Product Security
>
> www.velentium.com
>
> (805)750-0171
>
> 520 Courtney Way Suite 110
>
> Lafayette CO. 80026
>
> (GMT-7)
>
>
>
> Our new book is now shipping:
>
> *Medical Device Cybersecurity for Engineers and Manufacturers*
>
> U.S.
> <https://us.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-Engineers-and-Manufacturers-P2128.aspx>
>  | Worldwide
> <https://uk.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-Engineers-and-Manufacturers-P2073.aspx>
>
> Amazon
> <https://www.amazon.com/Medical-Device-Cybersecurity-Engineers-Manufacturers/dp/1630818151/ref=sr_1_1?dchild=1&keywords=Axel+Wirth&qid=1592335625&sr=8-1>
> & Digital
> <https://us.artechhouse.com/Medical-Device-Cybersecurity-for-Engineers-and-Manufacturers-P2174.aspx>
>
> Security Book Of The Year!
> <https://engineering.tapad.com/the-best-information-security-books-of-2020-e7430444fbd4>
>
>
>
> “If everyone is thinking alike, then somebody isn't thinking.” -George S.
> Patton
>
> "Facts are stubborn things."  -John Adams, 1770
>
>
>
> ------ Original Message ------
>
> From: "Eliot Lear via ntia-sbom-framing" <ntia-sbom-framing@cert.org>
>
> To: ntia-sbom-framing@cert.org
>
> Sent: 1/4/2021 9:57:22 AM
>
> Subject: [ntia-sbom-framing] Fwd: [OPSAWG] 🔔 WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
>
>
>
> FYI- this is your opportunity to contribute to the IETF.  If you think
> sharing of SBOMs is important, this is a *starting point* for the IETF to
> begin work on that aspect, not an end point.  Please feel free to
> contribute by joining the opsawg IETF list at
> https://www.ietf.org/mailman/listinfo/opsawg.
>
>
>
> Eliot
>
>
>
>
> Begin forwarded message:
>
>
>
> *From: *Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
>
> *Subject: [OPSAWG] **🔔* *WG Adoption Call on
> draft-lear-opsawg-sbom-access-00*
>
> *Date: *4 January 2021 at 17:10:19 CET
>
> *To: *opsawg <opsawg@ietf.org>
>
>
>
> Dear OPSAWG members,
>
> this starts a call for Working Group Adoption on
> https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on
> Monday, January 25.
>
> As a reminder, this I-D describes different ways to acquire Software Bills
> of Material (SBOM) about distinguishable managed entities. The work was
> updated by the authors on October 13th and now elaborates on three ways
> SBOM can be found, including a MUD URI as one of the options.
>
> Please reply with your support and especially any substantive comments you
> may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
>
> Disclaimer: The information and attachments transmitted by this e-mail are
> proprietary to Velentium, LLC and the information and attachments may be
> confidential and legally protected under applicable law and are intended
> for use only by the individual or entity to whom it was addressed. If you
> are not the intended recipient, you are hereby notified that any use,
> forwarding, dissemination, or reproduction of this message and attachments
> is strictly prohibited and may be unlawful. If you are not the intended
> recipient, please contact the sender by return e-mail and delete this
> message from your system immediately hereafter.
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
>


-- 
*Tony Turner*
VP, Security Solutions
*Fortress Information Security*
*Cell * 321-634-4886 *Main* 855.FORTRESS
189 S. Orange Ave., Suite 1950, Orlando, FL 32801
*fortressinfosec.com <http://fortressinfosec.com/>*

-- 
_CONFIDENTIAL: 

The information transmitted is intended only for the 
person or entity to which it is addressed. The content may contain 
confidential and/or privileged material, and it may be reviewed and logged 
for archival purposes by parties at Fortress Information Security other 
than those named in the message header. Any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of the company. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by 
persons or entities other than the intended recipient is prohibited. If you 
received this in error, please contact the sender and delete the material 
from any computer._