I don’t think having this done with relationships changes your report at all.
It simply empowers the collaborative ebb and flow of information/understanding evolution between parties.
If you produced the Report then the “official” version of the Report is the actual Report object and the set of relationships that YOU have asserted for it.
The richer version of that report is your actual Report object, your set of relationships for it AND other relationships that have been asserted by others that any consumer including you can take into consideration.
Think about how the APT1 report came out and then 20-30 other groups started adding in their bits and pieces to the puzzle. Unfortunately, this was all done via blog posts and separate documents with nothing to tie them together other than well thought
out Google searches. With the Report object done as proposed here we could have explicit and clear evolution of understanding on the intent/topic of the report.
>It is my understanding that the reason Soltra proposed the Report object to begin with is to give context around a grouping of objects.
I think this is still very much true. A Report specifies a context for correlating some group of STIX objects while a Package simply contains objects. The difference between how we originally structured Report and how it is proposed now is that we have
now STIX-wide broken out assertions of relationships between objects to separate constructs that are more flexible and given the power that Terry describes. This has not changed the intended purpose of the Report object it has simply changed the assertion
of shared context from a file folder with a title page to just the title page that can be asserted as relevant to content anywhere and does not require it to be shoved only within the file folder.
sean
The thing I do NOT like about what you have proposed is the idea that someone else can update my report. A report that I produce should be, IMHO, viewed as a PDF equivalent of something. I do not think I would want to allow people to add extra content to
my report or heaven forbid remove something from my report.
Without this, a report is really meaningless in our new world order of relationships. There would then be NO difference between a report and a package. It is my understanding that the reason Soltra proposed the Report object to begin with is
to give context around a grouping of objects.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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."
I’d still prefer in this case for the report to use the relationship objects. The reason is that when reports are generated, they are still someone’s assertion
of the truth. Having independent relationship objects allows third parties to generate opinion objects that refer to the relationships – such that the third parties can comment on the individual items that they don’t think belong in the report. This will allow
the report producer to independently remove the bits of the report that they don’t want to have in there.
Conversely, if there is an object that a thirdparty believes that the report producer missed, they can create their own independent relationship to link that
report to the object. It is of course up to the consumers if they accept that independent relationship (or maybe its marked internally as different). If the original report producer accepts that content as being correct (i.e. it is something they missed) then
they can issue their own relationship connecting their report to the object – effectively giving it the ‘official’ stamp of approval.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
For reports, do we really want to create a report object with nothing in it and then have a series of relationships where so much of the meta-data is replicated? I had kind of envisioned the Report object being a bit "special". Meaning that
you would be able to include a series of references to objects that were all PART of the report. The report object is just a special object and differs from other objects in STIX and the package.
{
"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",
],
"intents": ["Threat Report"],
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
"indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
"indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d3",
"campaign--26ffb872-1dd9-446e-b6f5-d58527e5b523"
"ttp--26ffb872-1dd9-446e-b6f5-d58527e5b5d4",
"threat-actor--26ffb872-1dd9-446e-b6f5-d58527e5b5d5"
]
}
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."
Refactoring of the Report object based on our breaking out of relationships is one of the issues that we seem to have general consensus on but have not yet agreed to normative text.
It is fairly straightforward and should not take long to consider.
Please review the normative text and add comments to the document for any concerns, questions or ideas you may have.
If we do not see any significant concerns/objections to the normative text by Monday we will consider this issues to have officially achieved consensus and move on to others.
For the quick convenience of anyone having difficulty accessing the live specification pre-draft document the relevant text is included below.
Report Object
The Report Object is a mechanism for relating a collection of STIX TLOs together according to some shared context.
Inherited Fields
Proposed Fields
|
|
|
|
|
|
array of
type report-intent-type
|
Specifies the intended purposes or uses of
this Report.
|
|
|
|
Specifies alternate intended purposes or uses of
this Report.
|
Example (using
only created_by_ref for brevity)
"id": "package--44af6c39-c09b-49c5-9de2-394224b04982",
"id": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
"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"
"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"
"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"
"id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",
"created_at": "2015-12-21T19:59:17.000000+00:00",
"from": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",
"to": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
"relationship_nature": "Report Contains",
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
"id": "relationship--72f666b6-f1db-4b2c-82e3-71ab49a84be1",
"created_at": "2015-12-21T19:59:17.000000+00:00",
"from": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",
"to": "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",
"relationship_nature": "Report Contains",
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
"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"
"id": "relationship--a05d8c6a-ccea-4a0a-a8e0-68dfe85fbfa9",
"created_at":"2015-12-21T19:59:17.000000+00:00",
"from": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",
"to": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",
"relationship_nature": "Report Contains",
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
|