OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] End Time (was Proposal - Top Level Relationship Object)


Really good points Eric...  


Thanks,

Bret



Bret Jordan CISSP
Director 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." 

On Jul 30, 2015, at 06:16, Eric Burger <Eric.Burger@georgetown.edu> wrote:

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: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]