I really like where this is going and I want to personally thank everyone that has contributed to this thread. This is how we make #progress, this is how we #succeed. Lets take each issue, one at a time, run them to the ground and solve them. Then rinse and repeat. We will all be amazed at how fast this process will go and how much #progress we will end up making.
<back to your regularly scheduled program>
I thought Terry had suggested that we use the ID as the source of who it was coming from? If that is not the case, then use, we need to look at that.
In regards to the End_Time and Start_Time I think we might need to have some further discussion. Dean makes some really good points.. And so does Eric in another thread..
For the Marking element as Aharon calls out, I think all top level elements should have the idea of having a Marking_IDREF (or some other shorter name) reference, that relates back to a TopLevel Marking blob that gives context. I do not want to try and shoe-horn in the entire Marking stuff inside of each object. Along these lines I also see the value of our group publishing some well known and standard Marking BLOBs. Yes, these will not work for some users that need very elaborate markings.. However, I am hoping that a small list of say 5-10 standard marking blobs will work for 70% or maybe 80% of the market.
Thanks,
Bret Bret Jordan CISSPDirector 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."
Shouldn't there be a statement of who is asserting the relationship? "created_by" or "asserted_by" or similar?
Otherwise, as a STIX document gets passed around with people asserting more and more relationships with data, how do you know the originator of that information.
Is this assumed to be a component of the ID somehow?
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<graycol.gif>"Wunder, John A." ---2015/07/30 09:04:36 AM---Thanks Bret, good points. Updated and removed the redundancy of both occurrence and optional/require
From: "Wunder, John A." <jwunder@mitre.org>
To: "Thompson, Dean" <Dean.Thompson@anz.com>, "'Jordan, Bret'" <bret.jordan@bluecoat.com>
Cc: "'Patrick Maroney'" <Pmaroney@Specere.org>, "'Terry MacDonald'" <terry.macdonald@threatloop.com>, Jason Keirstead/CanEast/IBM@IBMCA, "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org>, "'Chris O'Brien'" <cobrien@cert.gov.uk>, "'JG on CTI-TC'" <jg@ctin.us>, "Baker, Jon" <bakerj@mitre.org>, "'Aharon Chernin'" <achernin@soltra.com>
Date: 2015/07/30 09:04 AM
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
Sent by: <cti-stix@lists.oasis-open.org>
Thanks Bret, good points. Updated and removed the redundancy of both occurrence and optional/required statements.ID [1]: The ID of the relationship
Version [1]: The version of the relationship; a simple number to be used with the ID for version control (instead of timestamp)
Type [1]: The “type” of relationship being expressed. (Not sure of how this works yet)
Descriptions [0..N]: Words about the relationship.
Source_ID [1] : The ID of one or more source entities in the relationship as a URI (not QName)
Target_IDs [1..N]: The ID of one or more targets in the relationship as a URI (not QName)
Start_Time [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
End_Time [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
Reliability/Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale.
Timestamp [1]: A timestamp in UTC stating when the relationship object was created.
Also I apparently missed that Description is multiple elements. Is the intent behind that multiple languages? Multiple markings? Multiple paragraphs? If we do that, does that mean description needs to be something other than a plain array of strings?Keep in mind that STIX 1.2 is complicated for a reason. If we try to do everything that STIX 1.2 does we will end up with something just as complicated. Sometimes a simple 90% solution is better than a very complicated 99.9% solution. (If you can't tell, I would prefer to allow a single string description.)John
|