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
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/securityCo-Chair - Open Cybersecurity Alliance, Project Governing Board
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.
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>
|