The timestamps on Observed Data are the times the observations were made. So if a sensor is “observing” the network connection the time the connection is initiated is the first_observed
and the time the connection is closed is the last_observed. So they would likely be the same as the network connection timestamps in the case of a single observation of a network connection.
How do you think it should work?
From:
Bret Jordan <bret.jordan@bluecoat.com>
Date: Tuesday, August 30, 2016 at 4:56 PM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: John-Mark Gurney <jmg@newcontext.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] [jmg@newcontext.com: Observed Data comments.]
For network-connection though, there are time fields in CybOX land. So how do those relate to the time stamps in the Observed Data object.???
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
When we push a specification for public review we’ll need to reformat it the OASIS templates, and IMO we probably should have another vote to approve that anyway
since it has an additional conformance section. So I feel like we could do that reformat, make any changes we identify and explicitly call them out, then vote to approve that. Gary Katz also had some suggestions, though more minor.
On the issues themselves:
- The
reason first_observed and last_observed might be a range if the count=1 is for events that are not atomic. A network connection might be open for minutes or even hours, so a point time that it was observed may not make sense. So I don’t think we should have
a requirement that they be the same when the count is one.
- I
would be fine making count optional and defaulting to 1. I’m also fine as-is, would like to hear from more people about whether we should change this.
How should we address this? Can we do a simple editorial change or is there something more substantial we need to make and then do another ballot. Keep in mind we can do as many Committee Specification Draft releases
we want before we go to a Committee Specification with Public Review.
Director of Security Architecture and Standards | Office of the CTO
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."
Did this get lost in the shuffle last week? I didn't see any discussion
on this.
----- Forwarded message from John-Mark Gurney <jmg@newcontext.com> -----
Date: Mon, 22 Aug 2016 17:08:44 -0700
From: John-Mark Gurney <jmg@newcontext.com>
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Observed Data comments.
Hello,
Sorry for not getting this in sooner, but I have questions/comments
about the Observed Data object.
There is nothing in the spec that requires first_observed to be equal
to last_observed when number_observed is 1.
How is a tool who receives such an object to handle this?
In the case of when you don't know exactly when the observed data
was recorded, the _presision property added to first_observed can
convey this information correctly, and most acurately.
P.S. IMO, we should also make the number_observed default to 1, and
make it optional. By setting a resonable default, we can reduce
the size of objects in common cases.
--
John-Mark
----- End forwarded message -----
--
John-Mark
---------------------------------------------------------------------
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
|