Re: [cti] Re: [EXT] [cti] STIX 2.1 Extension Examples

Rich,

Iâm not very engaged in the development of STIX/TAXII, however I am an interested party and have a vested interest in seeing greater alignment of SBOM standards with Vulnerability reporting standards and entities.

I want to raise your attention to an award winning paper from the ACM CPSIoTSec 2020 workshop held on 11/9/2020 that identifies some of the difficult challenges facing companies with regard to risk management and vulnerability reporting services. My software, SAG-PM, provides the energy industry with a software supply chain risk assessment control, and this paper highlights several of the issues that Iâve encountered with vulnerability reporting for software objects during risk assessments. I believe the âimpedance mismatchesâ, identified in the paper, between software objects and CVE databases/standards can be resolved, if the right people work together, especially software vendors, to address these issues as part of an SBOM standard, i.e. NTIA SBOM.

Here is a link to my summary of the paper I mention; https://energycentral.com/c/ec/one-more-reason-why-industry-needs-synchronize-sbom-standards-and-cve-reporting Â

I believe the complete paper is accessible from the ACM Digital Library.

My apologies, if coordination is already underway between SBOM and CVE initiatives, but Iâm not aware of any such efforts. This paper identifies just how important coordination between CVE/SBOM initiatives is to helping parties manage software risk. I would be happy to participate in any coordination efforts in this regard.

Thanks,

Dick Brooks

Never trust software, always verify and report! â

http://www.reliableenergyanalytics.com

Email: dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Rich Piazza
Sent: Sunday, November 15, 2020 11:00 AM
To: Bret Jordan <bret.jordan@broadcom.com>; Paul Patrick <ppatrick@darklight.ai>
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Re: [EXT] [cti] STIX 2.1 Extension Examples

MITRE is considering setting up a repository for common objects for DHS.Â We are just at the planning stages, but that might be a good place for the execution-definition objects to âliveâ.Â We could have more information there about the extension, or individuals could just follow the URL in the schema property.

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <bret.jordan@broadcom.com>
Date: Friday, November 13, 2020 at 6:54 PM
To: Paul Patrick <ppatrick@darklight.ai>
Cc: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] [cti] STIX 2.1 Extension Examples

I like that idea.Â

Thanks,

Bret

PGP Fingerprint:Â63B4 FC53 680A 6B7D 1447 ÂF2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Fri, Nov 13, 2020 at 4:33 PM Paul Patrick <ppatrick@darklight.ai> wrote:

Rich,

Â

This latest exchange between Jeff Mates and myself about an Incident object made me reflect back on this email you sent me. ÂÂÂIf you recall, there was a similar type of exchange with Chris Ricard about Vulnerabilities.

Â

It got me thinking, what if we used the GitHub SEP Repository to be that place where people can go to see what extensions have been proposed, whoâs also working with them on, perhaps whoâs adopting.

Â

This way people can find others with a similar interest that are committed enough to work on a definition together.Â Rather than trying to convince everyone to agree, we use this as a sandbox.Â Then may when we see enough collaboration and interest, an extension could be brought to the TC for formal adoption into the specification.

Â

The hope being awareness of other parties interested in the same concept will help minimize the number of one-off extensions that are trying to define the same concept.

Â

Just a thought â

Â

Â

Paul Patrick

Â

From: Rich Piazza <rpiazza@mitre.org>
Date: Monday, October 19, 2020 at 11:33 AM
To: Paul Patrick <ppatrick@darklight.ai>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [EXT] [cti] STIX 2.1 Extension Examples

Â

Hi Paul,

Â

I really like your examples for Vulnerability and Data Marking Definition extensions.Â

Â

One of the things that stands out is that there are pre-existing json schemas for a lot of these ideas.Â It would seem to me that having a repository of STIX Extension Definitions makes a lot of sense â a community known place to look for extension definitions.

Â

DHS has asked us to look into creating a common STIX object repository for the community.Â It would seem like Extension Definitions would be a natural fit for such a repository.

Â

BTW â I noticed on your IEP example â the property âend_dateâ has a value of null.Â The STIX spec generally would make a property optional if it could be null or emptyâ

Â

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Rich

Â

--Â

Rich Piazza

Lead Cyber Security Engineer

The MITRE Corporation

781-271-3760

Â

Â

From: <cti@lists.oasis-open.org> on behalf of Paul Patrick <ppatrick@darklight.ai>
Date: Friday, October 16, 2020 at 1:10 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] [cti] STIX 2.1 Extension Examples

Â

I wanted to share with the community some of the various examples of using the proposed STIX Extensions.

Â

Attached is a sample that illustrates:

ÂÂÂÂÂÂÂÂÂ extend the STIX Vulnerability object with both CVSS scoring using the JSONscheme directly from FIRST

ÂÂÂÂÂÂÂÂÂ extend the STIX Marking Definition object to create new data marking for IEP

ÂÂÂÂÂÂÂÂÂ convert a couple of MITRE ATT&CK as STIX Attack Patterns representing the current MITRE custom extension using STIX Extensions

Â

Â

Paul Patrick

Â

cti message