oasis-open/cti-stix2-json-schemas

Missing Relationship direction for JSON formats and single vs multiple

StephenOTT opened this issue · 5 comments

Under section 3.5: http://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html#_Toc496709280

It outlines common relationships for SDOs, and in as a example; Attack Pattern: http://docs.oasis-open.org/cti/stix/v2.0/cs01/part2-stix-objects/stix-v2.0-cs01-part2-stix-objects.html#_Toc496714301 it shows the common relationships as duplicate-of, derived-from, related-to. But there does not appear to be any examples or direction on how the structure of those relationships should be defined in the SDO.

Should these only be single relationships or lists?
What are the property names? the doc outlines duplicate-of, derived-from, related-to, but there is not examples or specific formatting. I am guessing it is a error as all other fields use underscores, but these show as -.

Thanks!

Additionally looking at the relationships of Attack pattern as a example:
http://docs.oasis-open.org/cti/stix/v2.0/cs01/part2-stix-objects/stix-v2.0-cs01-part2-stix-objects.html#_Toc496714301

attack-pattern targets identity, vulnerability This Relationship describes that this Attack Pattern typically targets the type of victims or vulnerability represented by the related Identity or Vulnerability object. For example, a targets Relationship linking an Attack Pattern for SQL injection to an Identity object representing domain administrators means that the form of SQL injection characterized by the Attack Pattern targets domain administrators in order to achieve its objectives.  Another example is a Relationship linking an Attack Pattern for SQL injection to a Vulnerability in blogging software means that the particular SQL injection attack exploits that vulnerability.

Does this mean that Attack-Pattern SDO has a single relationship that can link to a single Identity or a single vulnerability?
vs
Does this mean that the SDO can have a relationship for targets to a identity and a vulnerability at the same time?
vs
Does this mean that any number of identities and vulnerabilities can be associated with the "targets" relationship?

Given the description one could argue any of those styles of relationships as the correct based on the writing.

If only a single 1-1 relationships (the attack pattern "targets" a Identity OR a attack pattern "targets" a vulnerability) how does a attack pattern get related to multiple targets and/or multiple identities?

Thanks

cc: @clenk

Also noticing the same potential confusion around the common relationships for the SDOs. These read as a single 1-1 relationship, but in examples such as derived-from, could you not have two SDOs that are merged into 1 or two SDOs that are used to generate a new SDO instance? thus the new SDO instance derived from multiple SDOs ?

ooookay! making progress here... Found the data:

finally found a exmaple under the Attack pattern using the object type relationship. and from there lots of copy and search page to find other examples.

I would recomend that the Common Relationships section be beefed up to explain the proper JSON structure in a very explicit way. Its very nuanced at the moment without clear instructions. You have to really read carefully and "notice" the embedded relationship example.

So the direciton i am taking based on the docs are:

Many Relationships can be added for each SDO. Example a "targets" or "duplicate of" can have many links to other SDOs

clenk commented

Hi @StephenOTT, this repo is just for the JSON schemas; the issue tracker for the spec itself is here: https://github.com/oasis-tcs/cti-stix2/issues

That said, relationships are defined in Part 2, Section 3 of the spec. You can have multiple Relationship objects with the same source_ref or with the same target_ref. So you could have two derived-from Relationship objects with the same source_ref but different target_refs if the SDO is derived from multiple SDOs.

@clenk if you transfer this issue into that other repo happy to continue the discussion.