End Time (was Proposal - Top Level Relationship Object)

[Eric Burger <Eric.Burger@georgetown.edu>]

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 <Dean.Thompson@ANZ.COM> 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