[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"
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]