OASIS Open Mailing List Archives  ·  All Lists  ·  cti-stix  ·  2015-07

cti-stix — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Re: [cti-stix] Proposal - Top Level Relationship Object


What is ‘time’ is one of those hard concepts to nail down. I would suggest we be explicit: If we (think we) know the thing being reported is over, then the End_Time is a time. If we (think) the thing being reported is still active, then the End_Time is some, not missing, value representing ‘ongoing’. Now things get interesting. Parallel with the ‘confidence’ discussion: If we have no idea when something started or ended, then the End_Time is some value representing ‘unknown’. Even more interesting: If times are irrelevant, then we should either allow for no End_Time or a value representing ‘irrelevant’. My preference is for ‘irrelevant’ as I will describe below. There is a distinction between unknown and irrelevant, just as a confidence of zero is different than no confidence. The reason I am leaning towards explicitly having an irrelevant value and requiring times is because if we make End_Time optional, then some will be lazy not have an End_Time to represent something ongoing. That is information that would be lost as most implementers will presume that a missing End_Time represents an event that ended but the sender did not know when. On Jul 30, 2015, at 12:33 AM, Thompson, Dean < [email protected] > wrote: Hi, Whilst I agree that Start_Time should be made compulsory (although there could be reasons when you don’t know the exact start date), I am not sure that you can make End_Time [1] rather than [0..1].  There are times when you might not know the End_Time (for example a web site is still redirecting Angler malware), a security event of incident may be on-going. If we force End_Time to be compulsory, then that will either force producers to put in some fairy land End_Date, or for them to stamp the time that a STIX document was produced as the End_Time of the incident/indicator or relationship.  This will cause issues later on or those that implement these repositories of data as well as consumers using the data because they may expire or dis-regard valid data primarily on the basis of the current time being greater than End_Time. Regards, Dean Attachment: smime.p7s Description: S/MIME cryptographic signature

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]