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]