Would it make sense to have Report as a relationshipType rather than a separate object?
Example
(using only created_by_ref for brevity)
{
"type": "package",
"id": "package--44af6c39-c09b-49c5-9de2-394224b04982",
"sources":
{
"type": "identity",
"id": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
"name": "Symantec",
}
],
"indicators": [
{
"type": "indicator",
"id": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
"created_at": "2015-12-21T19:59:17.000000+00:00",
"title": "Some indicator",
"indicator_types": ["IP Watchlist"],
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
}
],
"campaigns": [
{
"type": "campaign",
"id": "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",
"created_at": "2015-12-21T19:59:17.000000+00:00",
"title": "Some Campaign",
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
}
],
"relationships": [
{
"type": "relationship",
"id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68b",
"created_at": "2015-12-21T19:59:17.000000+00:00",
"from": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",
"to": ["indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2"
"campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",
"relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a"
],
"relationship_nature": "Report Contains",
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
"report_context":{
"type": "report",
"id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",
"created_at": "2015-12-21T19:59:11.000000+00:00",
"title": "The Black Vine Cyberespionage Group",
"description": "A simple report with an indicator, campaign and a relationship between them",
"intents": ["Threat Report"],
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
}
},
{
"type": "relationship",
"id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",
"created_at": "2015-12-21T19:59:17.000000+00:00",
"from": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
"to": "campaign--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
"relationship_nature": "Related Campaign",
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
}
]
}
The following could be removed (debatable) within the report_context:
"type": "report", // implied by the “report_context” parent/key
"id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd", // implied by the relationship “from” key
"created_at": "2015-12-21T19:59:11.000000+00:00", // implied by the relationship “created_at” key
What do you think?
-Marlon
definitely in favor of #2 as well based on the examples (thanks for them as they really help explain) on github.
its simple, avoids unnecessary relationship object where its not required.
My vote is for option #2...
With option #1 there is no way to guarantee that a consumer will get all of the relationships and thus no way to guarantee that the consumer will get the full report. So that is a show stopper for me.
Option #3 radically increases the complexity of what we are trying to do and greatly increases the amount of transactions and content that has to flow over the wire.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Hey all,
We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich
Piazza, John Mark-Gurney, and Sean Barnum.
The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed:
1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains"
2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report.
3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1.
4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3.
#3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible.
By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt:
- The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is
- Changes to what’s in the report are versioned with the report itself
- Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report)
- There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report
- #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice
On the other hand, one or more people also felt that #1 was the right approach, because they felt that:
- Signatures and versioning are just as doable in #1
- Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources
- Reports may evolve over time and relationships enable
- That objects should “belong” to the report with some level of confidence
- It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful)
- It’s one way of doing things to have all references between TLOs happen via a relationship object
What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it.
<reports.pptx>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php