I would agree with John. This sounds like a particular use case for the Reference object. It sounds like what we are talking about is some sort of reference resource.
We would need to think through exactly how the Reference object would capture and convey this information.
BTW, while I think that the Report object is intended to be able to capture a STIX version of what is currently done via “report” documents, I believe that the impetus behind the Report object was not limited to this obvious corollary. I believe it was
also intended to convey shared context of content which exists only within a TIP and not as a separate document somewhere. We need to be careful and recognize we aren’t just talking about capturing unstructured “report” documents into structured form.
sean
From: <
cti@lists.oasis-open.org > on behalf of John Wunder <
jwunder@mitre.org >
Date: Monday, February 15, 2016 at 9:26 AM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Proposed normative text available for Report object refactoring - (Goal: Reach official consensus by Monday)
Pat, what would you use this capability for? Providing a PDF version of the report, or something else? Is that something that the “Reference” object might do?
Back to Bret’s original comment, I can see both approaches for the Report object working. The relationship-based approach is more powerful and allows for a lot of flexibility for a report to evolve over time, have ad-hoc producers relating things, and
relate objects with some confidence assertion.
OTOH, the idref-based approach is a bit simpler conceptually and seems to better align with where the industry is now: reports are issued once, have defined producers, and objects are either in (mentioned) or out (not mentioned).
John
From: <
cti@lists.oasis-open.org > on behalf of Patrick Maroney <
Pmaroney@Specere.org >
Date: Monday, February 15, 2016 at 9:17 AM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >, Sean Barnum <
sbarnum@mitre.org >,
Terry MacDonald <
terry@soltra.com >, "Jordan, Bret" <
bret.jordan@bluecoat.com >
Subject: RE: [cti] Proposed normative text available for Report object refactoring - (Goal: Reach official consensus by Monday)
We should also ensure that the Report construct can be used to pass other types of external objects by reference (providing metadata such as IANA Media Types, Media subtypes, URI?).
Not sure where we've ended up on the concept of passing a BLOB in a STIX package now that we've stepped away from embedded objects. So if we have not provided for inclusion of a standardized way to pass the content of a binary object with a header describing
it's contents, we should.
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk:
(856)983-0001
Cell:
(609)841-5104
Email:
pmaroney@specere.org _____________________________
From: Terry MacDonald <
terry@soltra.com >
Sent: Sunday, February 14, 2016 10:47 PM
Subject: RE: [cti] Proposed normative text available for Report object refactoring - (Goal: Reach official consensus by Monday)
To: Jordan, Bret <
bret.jordan@bluecoat.com >, Barnum, Sean D. <
sbarnum@mitre.org >,
<
cti@lists.oasis-open.org >
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
+61 (407)
203 206
terry@soltra.com From:
cti@lists.oasis-open.org [ mailto:
cti@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Monday, 15 February 2016 2:27 PM
To: Barnum, Sean D. <
sbarnum@mitre.org >;
cti@lists.oasis-open.org Subject: Re: [cti] Proposed normative text available for Report object refactoring - (Goal: Reach official consensus by Monday)
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",
"descriptions": [
"A simple report"
],
"intents": ["Threat Report"],
"created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
"reported_objects": [
"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"
]
}
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."
On Feb 11, 2016, at 08:17, Barnum, Sean D. <
sbarnum@mitre.org > wrote:
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.
Proposed normative text is now available for your review in the
STIX 2.0 Specification Pre-draft document.
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
The Indicator object would inherit the
CTI Core Properties and the
CTI Descriptive Properties .
Proposed Fields
Property Name
Type
Description
intents (required)
array of type
report-intent-type
Specifies the intended purposes or uses of
this Report.
intents_ext
(optional)
array of type
vocab-ext
Specifies alternate intended purposes or uses of
this Report.
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",
}
],
"reports": [
{
"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"
}
],
"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-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"
},
{
"type": "relationship",
"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"
},
{
"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"
},
{
"type": "relationship",
"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"
},
]
}