[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Kinds of Sources
|
I’m trying to understand the “source” use cases first – independent of how to represent them. So here is my improved list (avoiding using the loaded terms: relationship
and reference): ·
The creator of the STIX/CybOX object
o
An individual/organization (created manually via something like Soltra Edge)
o
Software, that creates STIX/CybOX objects automatically – no manual input ·
A similar object from outside the STIX model (used to be
external_ID in STIX 1.2) – NOT a CTI ID ·
A citation, like in a bibliography, which might be accessible via a URL – NOT a CTI object ·
An association to another STIX object as the source of information – the “chain” use case. I dropped the CVE case, as per John’s suggestion, especially because there seems to be some movement away from representing such things in TLOs – from Sean’s
earlier email: I believe this presumption of applicability across other STIX objects was confirmed during recent discussions on the Exploit_Target refactoring where it was suggested that the CVE_ID, OSVDB_ID, CWE_ID and similarly
CAPEC_ID on TTP should likely just be implemented using the external_ids structure rather than separate purpose built fields. Getting back to the proposed Relationship object… A “source” relationship between two reports, I think is the use case Sarah was referring to, which is a sub use case of the chain use case Bret mentioned. A
“source” relationship means referring to another STIX object as the source of (some of) the information included in the current STIX object. This would be something like: { "type": "relationship", "id": "relationship--1", "source_ref": "report--1", "target_ref": "report--2", "confidence": "high", "value": "information-source", -- or whatever "created_by_ref": "identity--1" } The question is – how different is that from the some of the other relationships we know and love, but may not fit into one of the four “source” use cases above. John mentioned wanting a source relationship from “an indicator to a report”. In his recent JSON examples he expressed this in a relationship object whose “value”
property was “in-report”. Is “in-report” a kind of “source” relationship? I think that is a stretch.
I think we need to understand when we want two STIX objects to be in a “source” relationship. Rich From: Wunder, John A.
Hm I think see, yeah. I’d just reword that last one to make it clear that you’re talking about a source association, not just any relationship between STIX objects.
I seems to me like an incident pointing to a CVE isn’t really a source relationship….it’d be more like one report to another report (or one indicator to another indicator, or an indicator to a report, etc). From:
Rich Piazza <rpiazza@mitre.org> Comments below: From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Wunder, John A. Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object? This seems like one of the “chain” use case from Bret. I think this would be handled by relationships. For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity. I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]