All,
Two things:
1) If we force ID's to be tied to the domain name then we do not require a producer field, as we can work it out from the namespace of the ID. We can then also work out the location of the producer of the source object from the Source_ID, and the producer of the target object from the Target_ID, meaning the producer information wouldn't be required. If the consumer required more information about the target or destination objects and they don't have them then they can do subsequent requests for the objects to the producer directly. We wouldn't require a separate producer field as it would be inherent in the namespace.
Hence why I'm a fan of moving away from IDs being QNames and moving to URIs, and forcing people to only publish under their domain name namespace.
2) The relationships do not need a bi-directional flag in my opinion. Searches should be able to be accomplished without needing a relationship to be one way or the other. We shouldn't require a direction to enable a relationship to be traversed as it just makes things more complicated. I like the way neo4j does things - where queries can use this relationship (a)-->(b) or this relationship (a)<--(b) or this relationship (a)--(b) and it will still walk the graph correctly. We just need our relationships to be 'named' well.
And here is my take on a structure, based on everyone else's comments:
- ID [1] [Required]: The ID of the relationship
- Version [1] [Required]: The version of the relationship; a simple number to be used with the ID for version control (instead of timestamp)
- Type [1] [Required]: The “type” of relationship being expressed.
- Source_ID [1..N] [Required] : The ID of one or more source entities in the relationship as a URI (not QName)
- Target_ID [1..N] [Required]: The ID of one or more targets in the relationship as a URI (not QName)
- Confidence [1] [Required]: A measure of confidence in the relationship.
- Timestamp [0..1] [Required]: A timestamp in UTC stating when the relationship object was created.
- Relationship_Start [0..1] [Required]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
- Relationship_End [0..1] [Required]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
- Source [0..N] [Optional]: A URL pointing to source of the information that allowed the relationship to be created (not the producer as that is inherently in the ID's).
- Description [0..N] [Optional]: Words about the relationship.
Notes:
- The ID field and Version field together represent that specific version of the relationship. Any future version of that relationship object would increment the version by one. If the consumer receives an object with the ID the same and the version a higher number, then it 'replaces' the previous version of the object within their system.
- The Source_ID would allow multiple IDs to be listed - meaning that we would potentially allow multiple relationships (multiple sources to multiple targets) to be conveyed in a single relationship object. This could aid in reducing the number of relationship objects that would need to be sent on the wire.
- The Confidence is required. In my view a confidence must be asserted when a relationship is made. Without it, a consumer is unable to make a determination as to how much value they should put into that information. Threat intelligence analysis is all about making sense of rumour and guesses, so the ability for the producer of the relationship to identify how much they trust the information is key. The consumers level of trust of the information will of course be different, but knowing how much confidence the producer has in the information then allows the consumer to apply their own filtering mechanism on top of that.
- The Relationship_Start and Relationship_End fields are there to allow historical relationships to be described, or to record ongoing relationships that started a while ago. They must be present, as either the time, or an indication that the times are 'unknown', or 'ongoing'.
- All times must be in UTC. It should be up to the systems that provide visibility of the data to convert the data into the local users timezone. All STIX v2.0 times should be in UTC for avoidance of doubt.
Comments?
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
On 29 July 2015 at 07:24, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
Great.... Can someone mock it up in a table format so we can see what it would look like? It makes it easier to think through.Thanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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 Jul 28, 2015, at 14:59, Aharon Chernin <achernin@soltra.com> wrote:I agree with this relationship approach. We can't make it easier, as a relationship in some cases is an assertion (as the confidence field implies).* I would argue that if we are including source in the relationship then we also need to include a relationship producer. It's more likely that we will share the producer than the source.* What about a description? We may want to include analyst prose describing why the relationship exists in the first place (it's an assertion, why should we believe you).I know this add fields <OutlookEmoji-☹.png> But, I think Producer and Description provides value.Aharon Chernin
CTOSOLTRA | An FS-ISAC & DTCC Company18301 Bermuda green DrTampa, fl 33647813.470.2173 | achernin@soltra.comFrom: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Tuesday, July 28, 2015 4:28 PM
To: Wunder, John A.; Jordan, Bret
Cc: JG on CTI-TC; Chris O'Brien; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal - Top Level Relationship ObjectResending this because I think it originally got bounced due to me being an Observer. I think John and I are largely in agreement, BTW.From my perspective, most relationships are unidirectional, so it’s easier to think of them in terms of a directed graph (i.e., source->target). Therefore, I’d say we’d need:
- Type [1]: The “type” of relationship being expressed.
- Source_ID [1] : The ID of the source entity in the relationship.
- Target_ID [1..N]: The ID of one or more targets in the relationship.
- Is_Bidirectional [0..1]: A Boolean statement of whether the relationship is bidirectional (e.g., source->target and target->source).
- Timestamp [0..1]: A timestamp stating when the relationship was created.
- Source [0..1]: The source of the relationship.
- Confidence [0..1]: A measure of confidence in the relationship.
Regards,IvanFrom: <cti-stix@lists.oasis-open.org> on behalf of John Wunder
Date: Tuesday, July 28, 2015 at 4:15 PM
To: Bret Jordan
Cc: JG on CTI-TC, Chris O'Brien, "cti-stix@lists.oasis-open.org"
Subject: Re: [cti-stix] Proposal - Top Level Relationship ObjectSure...personally I would do this, which is almost identical to what we do now (other than being at the top level rather than within an object):RelationshipID (for the relationship) [required]From IDREF [required]To IDREF [required]Relationship Qualifier [required]Confidence [optional]I'm undecided on whether information source information belongs in the STIX data model at all. By virtue of being in the data model it means someone is asserting it so it's impossible to verify. Digital signatures or something else out of the data model (relying on TAXII, etc.) seem like a better approach to me. But I don't have strong opinions on this and if we do include information source in the data model I would add that here.JohnFrom: "Jordan, Bret"
Date: Tuesday, July 28, 2015 at 4:05 PM
To: "Wunder, John A."
Cc: JG on CTI-TC, Chris O'Brien, "cti-stix@lists.oasis-open.org"
Subject: Re: [cti-stix] Proposal - Top Level Relationship ObjectGreat... Now we are discussing it... Please spell out what that would look like.Thanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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 Jul 28, 2015, at 13:51, Wunder, John A. <jwunder@mitre.org> wrote:No directionality or description/qualifier? It seems like you want to be able to say *what* a relationship is describing and also which direction it goes in.I.e. TTP malware "is variant of" other TTP malwarevs. TTP malware "is same as" other TTP malware given a different name by a different vendorFrom: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
Date: Tuesday, July 28, 2015 at 3:41 PM
To: JG on CTI-TC
Cc: Chris O'Brien, "cti-stix@lists.oasis-open.org"
Subject: Re: [cti-stix] Proposal - Top Level Relationship ObjectI see the relationship object being pretty simple and straight forward:RelationshipIDREF (1-n)SourceConfidenceThanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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 Jul 28, 2015, at 13:16, JG on CTI-TC <jg@ctin.us> wrote:Chris:
You are not going insane...we are all dealing with these same issues.
Some of the more recent discussions (after you made this post) with
respect to 'Sightings' seem to make a lot of sense to me...that is, to
push the Sighting functionality further down in the data model...That
is, down to the CybOX level...
And I think we need to think about the Relationship object with respect
to 'Communities of Interest'... For example, a malware research
Community of Interest that is using Indicator, Observable, TTP and
ExploitTarget may seek to express Relationships in a way that shows the
Static and Behavioral characteristics of the malware (deep in the data
model and at a very refined level of granularity)
...Whereas an Incident Response Community of Interest that is using
Indicator, Incident and CourseOfAction may need the Relationship object
defined in a separate way.... that is, one that is more tied to
"actionable intelligence" which may then tie into ExploitTarget,
ThreatActor, and Campaign...which then becomes of interest to a law
enforcement Community of Interest.
Of course... handling this may take us back into the debate on Profiles...
Jane Ginn
CTIN
On 7/27/2015 3:44 AM, Chris O'Brien wrote:For what it's worth, from me, I think this would be pretty huge (coupled with the sightings object as well). As an analyst trying to identify useful data for my customers on large data sets, I'm interested in being able to produce top-level, automated assessments on data quality of feeds/dbs of stix data, and one of the ways that I'd suggest that a specific data point is of a 'high quality' is if it has multiple relationships and/or sightings. Add in to that the ability to rank producers, and even analytical assertion confidence, and you've got all the makings of a an algorithm for a heuristic grading scheme that could feed something even more awesome...like a machine learning project that can conduct threat pattern detection... As you say, Bret, this also gives scope for those relationships to have their own concept of 'quality' based on their related analytical assertions / confidence.
I'd perhaps throw in to the discussion that it may not need to be a standalone object in its own right - we're currently experimenting with using the existing stix architecture relationships (with a little extra meta data) to achieve the desired effect, but it gets messy quickly and direct references to the relationships are by-way-of the object that they sit on (then you ask...which end of the relationship is the 'master' for that relationship, or must they both be updated when a change is made...what happens if one of them isn't in your namespace, etc, etc). Jimmy-rigging solutions to those issues feels feasible, but messy, prescriptive and makes anyone with a coding background have a little cry to themselves. It's something we're having to think about here at the moment - just wanted to mention that it's still possible and would be less impactful to existing deployments.
Cheers,
cob
PS: If anyone else is looking in to this sort of heuristic / predictive / minority report-esque implementation, it'd be good to hear from you. If only to confirm that I'm not going completely insane.
-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: 24 July 2015 22:57
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Proposal - Top Level Relationship Object
I would like to see a top level relationship object that just contains references to the times that are related. This needs its own ID so people can reference it and disagree with it or sight it or enrich it with other data.
Bret
Sent from my Commodore 64
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
jg@ctin.us
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php