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] Re: [EXT] [cti] RE: Common repository for STIX CTI objects

Thank you for your insights, Jason.


My interest in this area is based on the need to provide reliable software supply chain risk assessments to the energy industry to protect the bulk electric system from harm/disruption from cyber threats.


I think itâs well known that todays vulnerability search capabilities leave lots of room for improvement. Signal/noise ratio of search results is very poor, lots of false positives. No alignment of SBOM ontologies with Vulnerability data base ontologies make it difficult to perform a âdeep searchâ for vulnerabilities at the sub-component level of an SBOM.


I understand there are alternative approaches to addressing these items and Iâll rely on the good statesmanship and diplomatic skills of those involved to find a solution, in much the same way that OASIS led the convergence of ebXML and SOAP at the W3C negotiating table.


Yesterday, I attended an EEI meeting where a question was asked about plans by NERC E-ISAC to support STIX and was pleased to learn that there is some discussion underway in this regard.


I see more fracturing of the âvulnerability reportingâ world, i.e. AttackerKB is now in beta.


So here is my âwish listâ as a provider of software risk assessment control software for the Energy industry:

  • Find a way to align SBOM and threat reporting data models and ontologies in order to improve search results needed for risk assessments
  • Eliminate the latency of reporting discovery of confirmed risks/threats with the sharing/availability of threat intel in order to stop the spread as efficiently as possible
  • Find a forum where differences can be discussed and negotiated and a single standard solution is possible â there is precedence for this with ebXML and SOAP, which resulted in an OASIS standard that is now an internationally recognized standard ISO 15000.
  • The OASIS leadership are experts in getting these type of matters resolved; leverage their diplomatic and statesmanship skills to find a solution. ebXML and SOAP convergence was successful thanks to the commitment of people like Chris Ferris, formerly with SUN, now with IBM, Andrew Layman of Microsoft, Bob Sutor of IBM and most importantly Jamie and Scott with OASIS who made this happen.




Dick Brooks

Never trust software, always verify and report! â


Email: dick@reliableenergyanalytics.com

Tel: +1 978-696-1788


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Jason Keirstead
Sent: Thursday, July 16, 2020 9:32 AM
To: rpiazza@mitre.org
Cc: cti@lists.oasis-open.org; masuoka.ryusuke@fujitsu.com
Subject: Re: [cti] Re: [EXT] [cti] RE: Common repository for STIX CTI objects


Regarding vulnerabilities - I am wondering if MITRE has simply considered issuing official Vulnerability SDOs w/UUIDs, alongside the CVEs when they are provided by MITRE? Really, they should not exist anywhere else.


Also I am wondering how this entire thread of discussion relates to the ongoing work around SCAP 2.0? 


I do not think the CTI TC should be moving ahead in this area without working closely with these other groups - this idea of a normative source of cybersecurity reference information, spans beyond just threat intelligence, and if the threat intelligence repository is just "yet another source", it is not going to truly help matters.


Jason Keirstead
Chief Architect - IBM Security Threat Management

Co-Chair - Open Cybersecurity Alliance, Project Governing Board



----- Original message -----
From: Rich Piazza <rpiazza@mitre.org>
Sent by: <cti@lists.oasis-open.org>
To: "masuoka.ryusuke@fujitsu.com" <masuoka.ryusuke@fujitsu.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXTERNAL] [cti] Re: [EXT] [cti] RE: Common repository for STIX CTI objects
Date: Thu, Jul 9, 2020 10:28 AM

Hi Ryu,


Thanks for the info, but I was unable to get any useful information from the two URLs you sent.  Do you have other access to this?




From: "masuoka.ryusuke@fujitsu.com" <masuoka.ryusuke@fujitsu.com>
Date: Thursday, July 9, 2020 at 1:42 AM
To: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: RE: [EXT] [cti] RE: Common repository for STIX CTI objects


Hi, Rich,


Thank you for your email.

Please keep me in the loop for the discussion.

But, it may be more important to start the thing rolling

than to keep discussing.



By the way, I remember Mark (Clancy) of Soltra had

a similar idea and had stood up a site when I met him

in Florida, Jan. of 2016.


The idea was to generate generic CTI and use the CTI elements

in the new CTI by referencing them.

For example, Defense Science Board had categorization

of threat actors like Tier I, ..., Tier VI. Create generic

CTI of those categories and use them in your new

STIX by referencing them.


  Resilient Military Systems and the Advanced Cyber Threat



You can use the same idea for generic CTI TTP elements

like Water Hole Attack and Spear Phishing and refer them in your new CTI.


Based on the idea, Mark had a web site and provided CTI reference data at


  Threat Actor Lab



, which unfortunately seems not active any more.






From: Rich Piazza <rpiazza@mitre.org>
Sent: Thursday, July 9, 2020 1:21 AM
To: Masuoka, Ryusuke/
çå çä <masuoka.ryusuke@fujitsu.com>; cti@lists.oasis-open.org
Subject: Re: [EXT] [cti] RE: Common repository for STIX CTI objects


Hi Ryu,


How we manage this repository is completely open for discussion.  Of the top of my head, it might just be fronted by a TAXII server, and consumers and producers just regularly accept a data feed.


As far as versioning goes â my assumption is that all objects would have a common object creator (i.e.,  the maintainers of the repository), so versioning shouldnât be an issue â unless you see some potential problems.


Thanks for your interest!!





Rich Piazza

Lead Cyber Security Engineer

The MITRE Corporation






From: <cti@lists.oasis-open.org> on behalf of "masuoka.ryusuke@fujitsu.com" <masuoka.ryusuke@fujitsu.com>
Date: Monday, July 6, 2020 at 8:08 PM
To: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] [cti] RE: Common repository for STIX CTI objects


Hi Rich,


I like the idea. I believe that usability for machines would

be one of the important keys for it to fly.

I mean machine access to the repository, in particular, search capability.

It is also important, I believe, to consider if/how to deal with versioning. Nothing stays the same forever.






From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Rich Piazza
Sent: Monday, July 6, 2020 11:58 PM
To: cti@lists.oasis-open.org
Subject: [cti] Common repository for STIX CTI objects


Many entities in cyber threat intelligence are common and having many duplicate STIX objects to represent the same concept has always been seen as wasteful and problematic.  Several decisions made when writing the STIX specification tried to take this into account. This includes:  specification defined instances of TLP data markings, kill chain phases referred to by their names and deterministic identifiers for STIX cyber objects (SCOs).  However, having an easily available repository of common CTI objects has always been on the âwish listâ of members of the CTI-TC.   DHS has tasked MITRE with investigating creating such a repository.  


MITRE has already started a similar repository of STIX objects to represent both the ATT&CK and CAPEC frameworks.  It is available at https://github.com/mitre/cti.  It certainly is the case that other organizations might want to do something similar with their cyber threat intellectual property.  However, there are other STIX objects that are general enough to be hosted in a common repository, defined once and re-used by the broader STIX community.  Such a repository would foster consistency across STIX threat sharing efforts. In creating and using this repository, the amount of data transmitted over the wire could be reduced because only identifier references would need to be shared.


Some of the objects types that immediately come to mind to include in this repository are locations (e.g., countries) and identities (e.g., industry sectors).  Others types, like software (e.g., Microsoft Word â version x) or tools (e.g., RDP) might be useful.  Objects like IP addresses, which already can be considered unique if using deterministic identifiers, could be âstoredâ in this repository, so they need not be shared.  Vulnerability objects representing each CVE could be housed there also.  Iâm sure there are other objects that could be included.


There are many issues to be discussed as part of setting up such a repository:


         Where would it be hosted?  It is envisioned that it could be available on the GitHub oasis-open web site, however this is just an initial suggestion.

         How is the content stored?  Is it âfrontedâ by a TAXII server?

         Who maintains it?  MITRE, DHS, OASISâ?

         Who decides what should be in the repository?  The maintainers, a CTI subcommittee?

         Would the STIX community actually use this repository?


If you would like to be involved in making this happen, or just have some ideas, please get in touch.

We can have a kickoff discussion at a future working call.


            Rich P.


Rich Piazza

Lead Cyber Security Engineer

The MITRE Corporation









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