[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
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.
{ "descriptions": [ "A simple report" ], "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."
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]