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] STIX 2.0 - Sightings object


1. I agree, sending the sighting multiple times is much cleaner. It also makes the data model easier to understand (sightings counts with timestamps are very tricky). I also question the value of saying “I saw this 132 times” vs. “I saw this 43 times” without any additional context.

2/3. This is a good point…it’s probably harder for people to understand “well sightings are really just a relationship” vs. having a dedicated object called “sighting" for it. That said, nothing should stop us as the modelers from saying “sightings are a lot like relationships” and using that to better understand what they should support and how they should work.

John

On Aug 20, 2015, at 10:12 AM, Bush, Jonathan <jbush@dtcc.com> wrote:

1.      I like the idea of sending a sighting multiple times vs. carrying a count.  Each one can have different context (like who saw it when and where)

2.     (and 3 really) The use of relationship to represent the sighting feels confusing, although I think it is theoretically correct.  It almost, to me, gives us too much flexibility in the spec.  If we try to be everything, we will be nothing.  This is why I started asking questions this morning about “what exactly are we trying to describe” with this Sighting data object.  We need to be crystal clear, or the spec will get abused and/or not adopted.  Just my .02

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Aharon Chernin
Sent: Thursday, August 20, 2015 10:02 AM
To: Wunder, John A.
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX 2.0 - Sightings object

 

John, just working through this with you. I don't have a super strong opinion here.

 

> 1. I’ve noticed that a lot of these exchanges also include a sightings count. For example, it’ll say that org. X saw the indicator 35 times. Is that something we need to support?

 

After a lot of thought over the year, I have started to dislike sightings counts. Every tool has a different definition of what a sighting is or how they are counted. It's so different that I believe sightings will likely be a qualitative measurement that happens to include a number. Does this have a lot of sightings versus a small number of sightings.  If sightings are so qualitative, then let's have systems just send a single sightings 1 time or a sighting 1,000 times. We can do this without a count field.

 

> 2. A lot of times people will want to sight an indicator (or even an observable) and include more details about what exactly was seen. For example, the indicator might be for an IP address but the sighting producer wants to include the actual network connection. So, given that, also consider that you might have sighting as a relationship between a full CybOX observable and the indicator that it matched (with the information source on the observable being who did the sighting) rather than a relationship between the producer and the indicator.

 

You could sight any object using the relationships. While it may not be as powerful as you define here, I think it is easier to implement. I am ok with reducing complexity at the cost of flexibility.

 

> 3. Do you sight indicators or observables (the age old question). Or, both? Can you sight a piece of malware even without an indicator?

 

If we leveraged the relationship object, you could sight any type of STIX object. 

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | achernin@soltra.com

 


From: Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, August 20, 2015 9:21 AM
To: Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX 2.0 - Sightings object

 

It’s funny you say that because I’ve had this same exact thought. I do think this is a good way to think about it.

 

A few complexities / things to think about

 

1. I’ve noticed that a lot of these exchanges also include a sightings count. For example, it’ll say that org. X saw the indicator 35 times. Is that something we need to support?

2. A lot of times people will want to sight an indicator (or even an observable) and include more details about what exactly was seen. For example, the indicator might be for an IP address but the sighting producer wants to include the actual network connection. So, given that, also consider that you might have sighting as a relationship between a full CybOX observable and the indicator that it matched (with the information source on the observable being who did the sighting) rather than a relationship between the producer and the indicator.

3. Do you sight indicators or observables (the age old question). Or, both? Can you sight a piece of malware even without an indicator?

 

John

 

On Aug 20, 2015, at 8:24 AM, Aharon Chernin <achernin@soltra.com> wrote:

 

This should be "sightings object rethought". While coming up with a proposal, I spotted a different way of thinking about Sightings. In my opinion, the most important thing is determining which STIX object is being sighted. However, there is some other bits of information that is useful: sightings producer and date/time of sighting.

 

Now take a look at the recent relationship object discussions:

 

Relationship Object Discussion:

ID [1]: The ID of the relationship, a simple random GUID

Marking[1]:  The ID of the marking object that you should reference 
Version [1]: The version of the relationship; a simple number to be used with the ID for version control 
Type [1]: The “type” of relationship being expressed.  (Not sure of how this works yet)
Description [1]: A single simple and short description
Source [1] : The ID of one or more source entities in the relationship as a URI (not QName)
Targets [1..N]: The ID of one or more targets in the relationship as a URI (not QName)
Start [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
End [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
Reliability/Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale.
Producer [1]:  A simple producer object like what John calls out

Timestamp [1]: A timestamp in UTC stating when the relationship object was created.

 

 

Idea:

 

Could a sighting be a type of Relationship? 

 

Relationship Object Discussion:

ID [1]: <GUID>

Marking[1]:  TLP Green
Version [1]: 1
Type [1]: Sighting
Description [1]: Soltra Edge reported Sighting
Source [1] : Soltra
Targets [1..N]: soltra:indicator-<GUID>
Start [1]:
End [1]:
Reliability/Confidence [1]:
Producer [1]:  Soltra

Timestamp [1]: <timestamp>

 

 

Or is there more meta data we need to collect regarding sightings that a sighting deserves it's own object?

 

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | achernin@soltra.com

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.



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