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] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters


I liked the originally proposed wording. The original wording is clear and concise, which is a strong plus for me. The proposed rewording is a little more difficult for me to understand.

 

Thank you.

-Mark

 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, September 1, 2017 at 3:42 PM
To: Sean Barnum <sean.barnum@FireEye.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters

 

Sean – I have issues with the words ‘asserted are true’ and how ‘time window’ is described.

 

The terms “Asserted are true” implies that its purely an analyst making that ‘assertion’. For the same reasons that you have concerns about ‘exist/determined/occurred’ I would say I have the flip concerns on the words asserted. I have tried to propose terms that might be acceptable to both parties.

 

I suggest we can better potentially achieve consensus with a higher bandwidth conversation on a TC call.

 

I don’t want to fill up people’s inboxes with a lot of emails debating as it seems like the suggested text won’t come together over email after all.

 

Have a good holiday weekend.

 

regards

 

Allan Thomson,

CTO, Lookingglass Cyber Solutions

This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed.  If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited

 

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Friday, September 1, 2017 at 12:37 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters

 

 

I think the term “established” has many of the same issues as “determined” and “occurred” in the original definitions.

 

The primary concern is that they are open to misinterpretation that these timestamps are conveying details of the process used to develop the intelligence rather than the intelligence itself. This is my core concern with first/last_seen as well.

 

“Established” also has the same concern I described about “occurred” in that they are implying that the time frame of a relationship being true is an action rather than a state of being and further that it is past tense.

 

The other key concern I think we need to consider is recognition that specifying a time window for an asserted relationship is an assertion that the relationship held/holds true during that time window. It is not in any way an assertion that the relationship does NOT hold true outside that time window. I believe it is dangerous to make assumptions that such a converse is implied.

If Org A sees ThreatActor X using Malware Y against them from Jan-Mar, they can make a relationship assertion that ThreatActor X uses Malware Y with a time window of Jan-Mar. This would not be an assertion that ThreatActor X never used Malware Y before Jan or after Mar. They may have no evidence of either such assertion. What they do have evidence for is the positive assertion Jan-Mar. They may just not have discovered its use against them outside that window or that it is being used against other orgs outside that window.

For these reasons, terminology like “exists” or even more so “ceases to exist” make me very nervous.

 

Bottom line is that I do not believe “established” or “exist” are appropriate here for the reasons outlined above.

 

I am interested to know what you think was clunky about the suggestions.

To me the consistent use (thoughout) of commonly used terms for such time ranges (earliest, latest, lower bound, upper bound) is less clunky than using different terms in the two definitions.

Obviously, determination of “clunky” is subjective to each person. ;-)

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, September 1, 2017 at 3:01 PM
To: Sean Barnum <sean.barnum@FireEye.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters

 

Sorry that last sentence was copy/paste error.

 

Review this one:

 

  1. Relationship Timestamp Field #1
    1. This optional timestamp represents the earliest time at which the relationship between the objects is established. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified then there is no determination of when that the relationship between the objects was established.
  2. Relationship Timestamp Field #2
    1. This optional timestamp represents the latest time at which the relationship between the objects exists. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified then there is no determination of when that the relationship between the objects ceases to exist.

 

 

Allan Thomson,

CTO, Lookingglass Cyber Solutions

This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed.  If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited

 

 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, September 1, 2017 at 11:59 AM
To: Sean Barnum <sean.barnum@FireEye.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters

 

Sean – I don’t love the time window sentences that you changed. I get the concept of time windows and what you are trying to convey but I think the suggestion is clunky and we can improve it.

 

Here’s another update to hopefully address the concerns:

 

  1. Relationship Timestamp Field #1
    1. This optional timestamp represents the earliest time at which the relationship between the objects is established. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified then there is no determination of when that the relationship between the objects was established.
  2. Relationship Timestamp Field #2
    1. This optional timestamp represents the latest time at which the relationship between the objects exists. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified then there is no determination of when that the relationship between the objects was established.
    2.  

 

 

Allan Thomson,

CTO, Lookingglass Cyber Solutions

This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed.  If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited

 

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Friday, September 1, 2017 at 11:50 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters

 

I have a few issues with the way they are defined here.

 

I believe that some people reading “the first time that the relationship between the objects was determined to have occurred” will interpret it to mean what was determined to be the initial time that the relationship is true while others might read it as the time that a determination of the beginning of the time window occurred. These are significantly different things. It is even more unclear in “the last time that this relationship between the objects was determined to connect those 2 objects”.

 

I would also take issue with the use of “the first time” and “the last time” in the definitions as they imply discrete time events when in reality these fields on a relationship represent the bounds of a continuous time region.

I would suggest that more continuous terminology be used such as “earliest time” and “latest time”.

 

I believe the term “occurred” is also somewhat troublesome. First it implies that a relationship is something that happens (as in an action) rather than an assertion on a state of being. I would assert Relationship objects are the former and not the latter. Second, it implies that it is past tense which while the common case is certainly not always the case.

 

The second sentence of the Field #1 definition looks fine.

 

I think the third sentence of the Field #1 definition could be better worded. I think what an absence of a starting time stamp for the window really says is that there is no beginning bound to the window. If you specify an end time but no start time then you are saying any time before the end time. If you specify a start time and no end time then you are saying any time from the start time onward.

 

The second sentence of the Field #2 definition has an issue in its use of “no longer exist”. This wording implies that the producer is making an explicit assertion that the relationship will not be true after the end time. I would suggest that in common practice these sorts of time windows on relationships are intended to convey that the relationship will be true at least until the end time. There is typically not enough evidence to make a hard assertion that it does not hold true after a given time as proving a negative is very difficult.

 

The third sentence of the Field #2 definition is good.

 

 

I am sure that it sounds like I am being very picky. I am just concerned that ambiguity in these definitions is very likely to lead to confusion and inconsistent use.

 

One of my main concerns here, as I have said before, is that we avoid any confusion that the timestamps might convey when an observation occurred or when a decision occurred on the beginning of the time window rather than the window itself.

This might seem like splitting hairs but based on the active debates over first/last_seen, I think that this is a valid concern.

 

As the comments above show, I am also concerned with making it very clear what we mean when using these fields to bound the time window associated with the assertion of a Relationship.

 

 

So, to avoid being the guy who complains but offers no alternatives, here would be my suggested improvements:

 

  1. Relationship Timestamp Field #1
    1. This optional timestamp represents the earliest time at which the relationship between the objects is asserted to be true. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified then there is no lower bound on the time window that the relationship between the objects is asserted to be true.
  2. Relationship Timestamp Field #2
    1. This optional timestamp represents the latest time at which the relationship between the objects is asserted to be true. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified then there is no upper bound on the time window that the relationship between the objects is asserted to be true.

 

I believe this more clearly and accurately conveys the meaning of these fields and uses consistent terminology and structure across the sentences and across the two field definitions which should help reduce potential confusion.

 

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, September 1, 2017 at 1:53 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Relationship Timestamp Properties: proposed description for the 2 timestamp parameters

 

Hi –

 

I had taken an action item to propose the descriptions for 2 relationship timestamp properties. Please review below and suggest changes or acknowledge that these descriptions would be acceptable.

 

To avoid folks focusing on the name of the property I’ve chosen to just call them Relationship Timestamp Field #1 and #2.

 

  1. Relationship Timestamp Field #1
    1. This optional timestamp represents the first time that the relationship between the objects was determined to have occurred. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on when that relationship will exist. If not specified then the relationship between those objects has no determined timestamp.
  2. Relationship Timestamp Field #2
    1. This optional timestamp represents the last time that this relationship between the objects was determined to connect those 2 objects. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on when that relationship will no longer exist. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified then the relationship between those objects is considered a persistent relationship.

 

 

Regards

 

Allan

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.


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