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] Timestamps - Proposal


I would like to see us do what we did in TAXII land.  As we made decisions they went on the HTTP landing page for TAXII 2.0

http://taxiiproject.github.io/taxii2/

This way it was VERY clear what we had decided on.  In the issue tracker things get lost and issues are for issues not for resolutions.  And the co-chairs did not decide to use the issue tracker to track resolutions.  

I want things to be on the up and up.  I want our decisions to be very visible.  


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 Dec 3, 2015, at 12:57, Wunder, John A. <jwunder@mitre.org> wrote:

I’m going to go ahead and do it for now because as Terry posted that's what the co-chairs laid out.

I do wonder how much the specific timestamp format issue is a model issue vs. a binding issue (binary formats may have specific timestamp representations we’ll use) so my comment is just going to be that in the model we'll have a time + required timezone and in the JSON binding we’ll use the format we all agreed to.

On Dec 3, 2015, at 2:38 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

We should NOT use Github Issues for things we have decided on.  That is bad form.  


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 Dec 3, 2015, at 12:19, Wunder, John A. <jwunder@mitre.org> wrote:

So it appears that we have rough consensus and IMO can move on without a vote.

How do we document this? Should I add an issue & a comment w/ the accepted solution?

On Dec 1, 2015, at 4:55 PM, Struse, Richard <Richard.Struse@HQ.DHS.GOV> wrote:

+1. Microseconds are enough. Let's move on.
 
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Tuesday, December 01, 2015 04:54 PM Eastern Standard Time
To: Terry MacDonald <terry@soltra.com>
Cc: tony@yaanatech.com <tony@yaanatech.com>; Patrick Maroney <Pmaroney@Specere.org>; cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Timestamps - Proposal
 
This is generally why we decided to place some table stakes in the ground and call it good. The proposal on the floor is for microsecond level precision, meaning 6 sub-second digits (most modern tools can and do support this, older tools may be limited).  

We can debate esoteric requirements and corner cases forever.  I would much rather get STIX 2.0 out the door and if we need to add something like nano seconds later, we can do that.  People that can only do millisecond level precision should just zero out the last three digits.  And given jitter in NTP it does not really matter that they are zeroed because your accuracy is only to about a second anyway.

The way this would look is like:

{
  "timestamp": "2015-12-01T14:52:12.123456-06:00"
}

or 

{
  "timestamp": "2015-12-01T14:00:00.000000-06:00",
  "timestamp-precision": "hour"
}


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 Dec 1, 2015, at 14:28, Terry MacDonald <terry@soltra.com> wrote:

I'm sure millisecond will be good enough for now.

We will never be able to cover every governments exact specific requirements, so I don't think we should start. I'm sure that the EU, China, Japan, Australia and NZ all have their own requirements in this space, and all we can expect to do is cover the main 80%. We get into trouble trying to shoehorn the last 20% in.

Cheers

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
 

-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Tony Rutkowski
Sent: Wednesday, 2 December 2015 8:07 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>; Patrick Maroney <Pmaroney@Specere.org>
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Timestamps - Proposal

SEC Rule 613 requires millisecond or better timestamps for its event observables. See https://www.sec.gov/divisions/marketreg/rule613-info.htm

A precision is trivial.  Getting the uncertainty value underpinning the data element is more difficult.
In a NFV world, sub millisecond uncertainties are essential.
-t

On 2015-12-01 03:07 PM, Jordan, Bret wrote:
10Gig/40Gig/100Gig networks will have support for nano second, but
there did not seem to be any solid use-cases for mili second
precision.  If I am wrong, PLEASE speak up.




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php






Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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