OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [cti] [EXT] [cti] STIX 2.1 Extension Examples

Thank you, Allan.

 

I would hope that this group may be willing to take a lead in promoting consistent naming by recommending the use of vendor Legal Name for the vendor property, to put a stake in the ground which others would, hopefully follow.

 

https://csrc.nist.gov/projects/security-content-automation-protocol/specifications/cpe/name-matching

 

https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf

 

Which would the propagate into the NVD/CPE CVE data element: cpe23Uri

i.e. "cpe:2.3:a:cherokee-project:cherokee:*:*:*:*:*:*:*:*"

 

Then all data stores could be aligned with the same vendor legal name data; eliminating the inconsistencies identified in the cited paper.

 

Coordination among bodies OASIS, NTIA and NIST is key to achieving broad adoption of standard nomenclatures for items such as vendor names, product names within the CPE/SBOM/STIX/CVE domains. If we could just start with agreeing on vendor name standards, that would address some of the identified problems.

 

 

From: aa tt <atcyber1000@gmail.com>
Sent: Tuesday, November 17, 2020 4:38 PM
To: Dick Brooks <dick@reliableenergyanalytics.com>
Cc: JG @ OASIS <jg@ctin.us>; cti@lists.oasis-open.org
Subject: Re: [cti] [EXT] [cti] STIX 2.1 Extension Examples

 

I think your suggestion on the addition of legal name verbiage in the description of that property is a good suggestion. We might want to add a reference to the standard definition of what âlegal nameâ is, so that international/national members have a clear definition of what that actually means in their region. But otherwise I think it's a good thing to add. It wonât solve all problems but at least for intel providers it might raise awareness for them to populate the field with the legal name rather than just taking what an intel analyst types at a console of a TIP (not that would ever happen without validation :-))

 

Allan



On Nov 17, 2020, at 1:30 PM, Dick Brooks <dick@reliableenergyanalytics.com> wrote:

 

Thanks for your insights, Allan.

 

Perhaps, Iâm relying on wishful thinking, but I do see the potential for this body to initiate a discussion on âcontent standardsâ for STIX that would help launch a discussion on the need for alignment of content models used in STIX, CVE, CPE and SBOM artifacts. One simple example of SBOM/STIX alignment might be to put a stake in the ground indicating that Vendor names MUST contain legal entity names, for consistency across artifacts. This would ensure that companies like IBM with numerous products would be always identified as âInternational Business Machines Corporationâ in all SBOM, STIX, CVE, CPE artifacts, making it much easier for Companies, such as mine, to accurately identify vulnerabilities in IBM products, starting with SBOM contents, knowing that the entire âchain of custodyâ where this information flows into (STIX, CVE, CPE) are adhering to the same nomenclature.

 

Here is an example from the 2.1 spec (page 184) where this forum could offer some guidance for greater precision i.e. âSpecifies the name of the vendor of the software.â could be replaced with something more definitive âSpecifies the Legal name of the vendor of the software.â

6.14.1 Properties

vendor (optional)

string

Specifies the name of the vendor of the software.

 

 

Typical Software Instance

{

  "type": "software",

  "spec_version": "2.1",

  "id": "software--a1827f6d-ca53-5605-9e93-4316cd22a00a",

  "name": "Word",

  "cpe": "cpe:2.3:a:microsoft:word:2000:*:*:*:*:*:*:*",   

  "version": "2002",

  "vendor": "Microsoft"

}

 

Using the above example to make my point; During my time running software supply chain risk assessments Iâve found two different representations for Microsoft in software objects: Microsoft and Microsoft Corporation. It would be truly beneficial if the CPE contained such definitive requirements across the data flow chain of custody.

 

I hope you or others will provide insights if the justification Iâve provided is totally off base in this regard. Also, I sent my email in response to Richâs email stating â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â. â

 

 

From: aa tt <atcyber1000@gmail.com> 
Sent: Tuesday, November 17, 2020 3:56 PM
To: Dick Brooks <dick@reliableenergyanalytics.com>
Cc: JG @ OASIS <jg@ctin.us>; cti@lists.oasis-open.org
Subject: Re: [cti] [EXT] [cti] STIX 2.1 Extension Examples

 

Dick 

 

If I understand the issue - âThe right peopleâ appears to me to be vendors who create software and how they identify, report and publish vulnerabilities in their software. 

 

Threat Intelligence vendors (either creating intelligence or using intelligence), for the most part are downstream from where those âright peopleâ are. 

 

So if you want to fix the root cause then I think you need to find a forum or interest group where vendors building software sit *and* have a motivation to incorporate changes so that they can address the problem consistently across all of them.

 

Iâm not sure anyone in this forum will fix the problem you state.

 

That said, if you disagree with my assessment and think this forum is appropriate please reach out to the TC leadership team to schedule some time to propose what changes should be considered for CTI. 

 

Specifically around STIX and/or TAXII.

 

Allan




On Nov 17, 2020, at 11:02 AM, Dick Brooks <dick@reliableenergyanalytics.com> wrote:

 

Thank you, Jane.

 

The issues/obstacles pointed out in the referenced paper (ACM best paper CPSIoTSec 2020) are genuinely inhibiting parties from properly identifying vulnerabilities during software supply chain risk assessments. SBOM alignment with CVE databases will be key to addressing many of the issues cited in the paper, e.g. inconsistent supplier names is a big issue at present.

 

My hope is that by raising this issue now, the right people will be able to influence a solution to the cited problems, or at least begin a conversation to deal with these issues. 

 

 

 

From: JG @ OASIS <jg@ctin.us> 
Sent: Tuesday, November 17, 2020 1:44 PM
To: cti@lists.oasis-open.org; Dick Brooks <dick@reliableenergyanalytics.com>
Subject: Re: [cti] Re: [EXT] [cti] STIX 2.1 Extension Examples

 

Dick:

Thanks for the heads up on this.  For those that are not familiar with SBOM I've attached a 2-page overview of the Software Bill of Materials (SBOM) inventory from the US Department of Commerce's National Telecommunications and Information Administration.  

Jane Ginn

 

On 11/15/2020 12:30 PM, Dick Brooks wrote:

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. 

 

 

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. 

 

 

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

 

<image002.png>

 

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

 

-- 
**********************************
R. Jane Ginn, MSIA, MRP
OASIS, CTI TC Secretary
OASIS, TAC TC Secretary
jg@ctin.us
**********************************

 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]