RE: [cti] Identity objects in the STIX common object repository

["Chenta Lee" <chenta@ibm.com>]

I brought up this topic with JK when we were discussing the TIP capabilities.  In the context of IoC enrichment, all the TIPs consolidate 3rd-party TI feeds/sources to provide a holistic view. To use STIX at the data layer, the Identity object is needed to identify the TI vendor providing the assessment.  At the minimum, each TI vendor should have a unique Identity object on the same TIP because TIP needs deterministic ID in Identity objects to build the linkages.  It will be nice if all the TIPs can share the same Identify objects representing the TI vendors.  The question is, how do we encourage TI vendors to make PRs? Can we create identity objects for the TI vendors?

 

Regarding authentication, we should validate the data sources providing the STIX bundle.  For example, we should trust the TIP we use, so we don't need to worry about bad actors using pre-defined Identify objects.  Every TIP should also validate and trust the TI feeds/sources it integrates, so we shouldn't need to worry about the fake VirusTotal scenario.  It is an interesting idea if TI vendors can "sign" STIX objects, but I think it is out of the scope of STIX.

 

 

Regards,

Chenta Lee

Chief Architect of Threat Intelligence Orchestration

 

 

----- Original message -----
From: aa tt <atcyber1000@gmail.com>
Sent by: <cti@lists.oasis-open.org>
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXTERNAL] Re: [cti] Identity objects in the STIX common object repository
Date: Fri, Jun 11, 2021 10:45
 
For content that originally came from Virustotal and another org/entity is just republishing unchanged, then the rules in STIX are clear that these objects must use the VirusTotal identity object and not the republisher. Having a central repo ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

For content that originally came from Virustotal and another org/entity is just republishing unchanged, then the rules in STIX are clear that these objects must use the VirusTotal identity object and not the republisher.

 

Having a central repo hosted somewhere for the community to be able to lookup an identity object for X, Y, Z orgsâ.etc is akin to a centralized certificate authority (kind-of) that can be used to reference root certs. It makes a lot of sense but comes with a responsibility and set of requirements for security of its use and the content within the central repo, and making sure that this central repo canât be undermined or modified by malicious intent. Imagine if an attacker could modify the content of the repo to change the organization represented by an identity UUID to be a completely different org. This might seem far-fetched but this is exactly the kind of thing that we should not allow.

 

If OASIS/MITRE understand that and are willing to put in the effort to make sure its not just another repo that can become a target for malicious content then the central repo can become something that is very useful for the community.

 

Allan

 

On Jun 11, 2021, at 4:51 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

 

Agree with all of below - I just wanted to add that the reason we are proposing this is not just for extensions - it is so that vendors / products can have public, published identity objects, so that we have consistency across the ecosystem when people generate their STIX, without having to re-send identity objects all the time.

 

For example - lets say we enrich some data with a Virus Total lookup in one of our products, and then let's also Allan's organization does the same. We really should be using the same Identity SDO for those objects as they both came from Virus Total, as opposed to making up our own identity object with different UUIDs, which is what would happen right now.

 

-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management
www.ibm.com/security

Co-Chair - Open Cybersecurity Alliance, Project Governing Board

www.opencybersecurityalliance.org
 

 

-----<cti@lists.oasis-open.org> wrote: -----

To: Rich Piazza <rpiazza@mitre.org>
From: aa tt
Sent by:
Date: 06/10/2021 08:14PM
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXTERNAL] Re: [cti] Identity objects in the STIX common object repository

Rich - I was primarily suggesting that identity of producers of extensions be published so that others can know where the extension comes from and in cases where they would like to contact the producers (or people forking changes) can reach out to them. This would be akin to a userid in GitHub of the submitter but would be the STIX2 identity object. 

 

So it could be as simple as when someone submits a PR to the repo that they include both the extension and their identity object they wish to use as âcreated_by_refâ. 

 

Any vetting on the identity object validity could be done as part of accepting the PR to the repo.

 

I donât see why this needs to be related to âconsumptionâ at all and certainly removes the concern of anonymity as an entity that is publishing an extension is presumably doing that because they want the community to use it and naturally would want to be associated with that content. I canât imagine a case where someone would publish an extension and not want to be associated with it by remaining anonymous. But I can imagine lots of cases where using extensions would be kept private because entities donât want to share that they are using them for specific applications or uses. 

 

Allan

 

On Jun 10, 2021, at 11:52 AM, Rich Piazza <rpiazza@mitre.org> wrote:

 

HI everyone,

 

 

 

Both Jason and Allan have proposed storing identity objects for producers and consumers in the STIX common object repository.

 

 

 

This sounds like a good idea to me.  The repo could act as a âwhite pagesâ for STIX users. 

 

 

 

If you receive some content but it doesnât include the Identity object referred to in the created_by_ref property, not knowing who created the content could be an impediment to trusting/using it.  Additionally, if an extension definition is stored in the repository, you might want contact information of the creator to discuss how to use the extension.

 

 

 

Of course, some STIX users will prefer to remain anonymous â so this would not be for them. There is the problem of having a common place to find Identity objects to facilitate spoofing the creator of a submission, although there is nothing to prevent that currently.

 

 

 

There would need to be some protocol to vet any Identity object submissions to the repository and there might be multiple identities for an individual/organization, but those details can be worked out.

 

 

 

Comments??

 

 

 

                Rich P.

 

 

 

--

 

Rich Piazza

 

Lead Cyber Security Engineer

 

The MITRE Corporation

 

781-271-3760

 

 

 

<image001.png>