[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"
I agree with you 100% that this is the clarity of the semantics we are striving for. The lexicality and syntax of a JSON serialization would never “look” like that but the underlying semantics should be consistent enough to enable that sort of alternate serialization if someone desired. Basically, you are writing in tuple form which an RDF serialization would give you. I think this sort of semantics is supported by what is being proposed here without forcing JSON folks to think or write that way. >What is the difference between Sean? (if Sean is Sean - the only one) >Could Sean be defined only once? Yes, that is absolutely the intent here. You would have one “Sean” Identity object and relate all of those other STIX constructs to it with various relationships (the first four examples would use “has-source” with different “roles” and the last two would be part of what will be tackled in the March tranche when we address identity-based construct consistency. sean On 2/10/16, 10:09 AM, "Jerome Athias" <athiasjerome@gmail.com> wrote: >While STIX is intended to be a language, I see this refactoring >offering a better way for sentences structure "subject–verb–object >(SVO)", and introducing/allowing the use of 'pronouns' (ref by IDs). > >Where subject was suggested/identified as >Organization/Person/Automaton(System/Tool) >(I see it as beneficial; for simplification of the schemas, reduction >of redundancy, easier correlation/analytics, optimization of size, >etc. and not just for 'sources'... ) > >Basically, when writing: >Sean is the producer of indicator A >Sean is the producer of indicator B and C >He is the analyst of Malware B >Sean is the victim of APT666 >Sean is a target of Spear Phishing Campaign Blue Monkeys >... >What is the difference between Sean? (if Sean is Sean - the only one) >Could Sean be defined only once? > >In the same way >Tool X is the producer of indicator Y >Sean is the producer of indicator Z and he is the analyst using Tool X > > > > >2016-02-10 17:42 GMT+03:00 Barnum, Sean D. <sbarnum@mitre.org>: >> Pat, I would agree that sometimes when talking about a tool you are talking >> about a method. Other times a tool may be the source of the information >> itself (e.g. an ML scanning osint and creating STIX asserting that a >> particular TTP was leveraged as part of a Campaign). >> Can you help us see what would be gained by making a distinction a tool as >> method vs source here? Is the same information not captured either way? >> I think we are looking to keep it as simple as possible and still support >> the necessary use cases. >> Having identities, tools and references treated as types of “sources” seems >> to be simpler than breaking tools off into a new concept of “method”. >> >>>Also note that I may use multiple "Tools" to establish the basis for my >>> assertion(s). >> I believe you can still do this with the current proposal simply by >> specifying each tool and asserting a “has-source” relationship (maybe with a >> new “role” value more specific to this sort of case) between your assertion >> and the tools. >> >> Is there something we are missing by doing it the proposed way? I am >> genuinely interested in understanding. >> >> Thanks, >> >> sean >> >> Fro Patrick Maroney <Pmaroney@Specere.org> >> Date: Wednesday, February 10, 2016 at 9:19 AM >> To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Terry MacDonald >> <terry@soltra.com> >> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Barnum, Sean D." >> <sbarnum@mitre.org> >> >> Subject: Re: [cti] Results of today's CTI working call on the topic of >> refactoring "sources" >> >> Isn't "Tool" better related to a Method (i.e.: ==Using==>) relationship? >> (I'm paraphrasing here) >> >> In other words, an entity is still the Source of an assertion, the tool(s) >> used to make that assertion are the Method. Also note that I may use >> multiple "Tools" to establish the basis for my assertion(s). >> >> Patrick Maroney >> President >> Integrated Networking Technologies, Inc. >> Desk: (856)983-0001 >> Cell: (609)841-5104 >> Email: pmaroney@specere.org >> >> _____________________________ >> From: Jordan, Bret <bret.jordan@bluecoat.com> >> Sent: Tuesday, February 9, 2016 7:25 PM >> Subject: Re: [cti] Results of today's CTI working call on the topic of >> refactoring "sources" >> To: Terry MacDonald <terry@soltra.com> >> Cc: <cti@lists.oasis-open.org>, Barnum, Sean D. <sbarnum@mitre.org> >> >> >> "source-tool" does seem to be more clear. >> >> >> 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 9, 2016, at 17:00, Terry MacDonald < terry@soltra.com> wrote: >> >> Hi Sean, >> >> I think you meant Report rather than reference in the Relating TLOs to >> Identities, Tools and References section? Here is the updated structure >> reflecting that: >> >> Identity >> >> ID = id-1 >> Name = MITRE >> >> Report >> >> ID = id-3 >> Title = FooBar Threat Report >> Reference-url = http://mitre.org/foobarreport.html >> >> Indicator >> >> ID = id-4 >> created by ref => id-1 >> >> Relationship >> >> ID = id-5 >> From = id-4 >> To = id-1 >> Nature = Has Source >> Role = Producer >> >> Relationship >> >> ID = id-6 >> From = id-4 >> To = id-3 >> Nature = Has Source >> Role = Derivation Resource >> >> Also, the relationship of ‘has_source’ as described in the ‘Break >> Information Source into Individual Types’ dsection seems ambiguous to me. >> It’s too easy for people to misunderstand its purpose with the name >> ‘has_source’. What do you think of changing the relationship ‘source-tool’? >> Then it is easy to understand what the relationship is expected to apply to. >> >> 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 Barnum, Sean D. >> Sent: Wednesday, 10 February 2016 7:36 AM >> To: cti@lists.oasis-open.org >> Subject: [cti] Results of today's CTI working call on the topic of >> refactoring "sources" >> >> We had a good constructive conversation on today’s CTI working call on the >> topic of refactoring source representations and relationships within STIX. >> We Invite further comments and discussion on this topic with a goal of >> reaching official consensus this week. >> >> On the call, a request was made to break the problem down into a clear >> high-level statement of what is being proposed, some of the value >> propositions asserted for the proposal, and a breakdown of separate more >> detailed sub-issues that will need to be decided. >> >> Here is my stab at a clear high-level statement of what is being proposed. >> I will follow this email with a separate one focused on a breakdown of the >> detailed sub-issues to discuss/decide. >> >> High level statement of what is being proposed: >> >> Break information source out of Top-Level Objects >> Break information source into individual types >> >> Identities: who is the source of the information? >> Tools: from what tool(s) did the information come? >> References: what non-STIX resources were used directly or indirectly >> (background context) as sources for the information >> >> Relate TLOs to identities, tools and references >> >> For anyone who was unclear before, does this help? >> >> >> >> >> >> >> ________________________________ >> >> Here is a little more detail if you find it useful. There is also a simple >> diagram attached showing some more various use case scenarios than just >> those presented below. >> >> >> Break Information Source Out of Top-Level Objects >> In STIX 1.x, Information Source was a field in each top-level object. For >> example: >> >> Indicator >> >> Information Source >> >> Identity = MITRE >> >> Indicator 2 >> >> Information Source >> >> Identity = MITRE >> >> For STIX 2.0, we propose breaking information source into top-level objects, >> for example: >> >> Identity >> >> ID = id-1 >> Name = MITRE >> >> Indicator >> >> (created-by) = id-1 (shorthand does not imply how relationship should be >> represented) >> >> Indicator 2 >> >> (created-by) = id-1 (shorthand does not imply how relationship should be >> represented) >> >> This allows for less repetition, helps prevent consumers from having to >> correlate identities on name, and allows people to easily pivot on sources. >> >> >> Break Information Source into Individual Types >> In STIX 1.x, Information Source covered Identity, Tools, and References. For >> example: >> >> Indicator >> >> Information Source >> >> Identity = MITRE >> Tool = CRITS >> >> While this somewhat made sense since it was embedded in individual >> constructs, with the move to separating them out to top-level objects it >> would be nice to reference them separately. So, for STIX 2.0, we propose >> breaking it apart into individual TLOs: >> >> >> Identity >> >> Name = MITRE >> ID = id-1 >> >> Tool >> >> Name = CRITS 2.3 >> ID = id-2 >> >> Indicator >> >> (created by) => id-1 (shorthand does not imply how relationship should be >> represented) >> (has source) => id-2 (shorthand does not imply how relationship should be >> represented) >> >> This would allow you to track “MITRE” as a separate identity from “CRITS” as >> a tool, etc. If MITRE’s SOC later produced something with a different tool, >> you probably want to be able to separately pivot on “MITRE” as an identity >> and that tool that we used. >> >> >> Relating TLOs to Identities, Tools and References >> In STIX 1.x, we used the “Role” field in information source to describe the >> role of that source in creating the construct. >> For 2.x, we’ve developed a consensus proposal that uses a “Has Source” >> Relationship object to relate TLOs to their various sources. This “Has >> Source” relationship has an extended Roles property serving a similar >> function to the Role field in STIX 1.x. >> In addition, strictly for the creator of the actual STIX content it also >> supports an optional “created_by_ref” property on each TLO. >> >> >> Identity >> >> ID = id-1 >> Name = MITRE >> >> Reference >> >> ID = id-3 >> Title = FooBar Threat Report >> Reference-url = http://mitre.org/foobarreport.html >> >> Indicator >> >> ID = id-4 >> created by ref => id-1 >> >> Relationship >> >> ID = id-5 >> From = id-4 >> To = id-1 >> Nature = Has Source >> Role = Producer >> >> Relationship >> >> ID = id-6 >> From = id-4 >> To = id-3 >> Nature = Has Source >> Role = Derivation Resource >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]