Re: [cti-taxii] RE: [cti-stix] STIX 2.0 - Sightings object

[Patrick Maroney <Pmaroney@Specere.org>]

Suggest we need to include the whole set of prior discussions on how we represent non-linear/multi-path/concurrent temporal relationships between events/state changes and objects (in both absolute and relative representations).  This globally applies to sightings and observables/patterns and should therefore be consistently represented (per our new consensus "One Way to do 'Things'" Doctrine).

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

On Thu, Aug 20, 2015 at 6:49 AM -0700, "Davidson II, Mark S" <mdavidson@mitre.org> wrote:

> For example, it’ll say that org. X saw the indicator 35 times. Is that something we need to support?

I think in some way shape or form the answer has to be yes, but maybe that’s a TAXII thing.

 

For TAXII, one of the recent thoughts is pipelining. Let’s say for the sake of argument, TAXII 2.0 is done over HTTP, and assume a scenario where a TAXII Client connects to a TAXII Server and has multiple messages waiting for it. Two options for delivery are 1) one HTTP request/response per message; and 2) pipelining - deliver all messages in one HTTP response (assuming some kind of max_size limit is not exceeded). If there’s 300 small messages (e.g., what sightings could be) then one HTTP request/response per message is a ton of overhead. Putting all the messages into one HTTP response (aka – pipelining) could make that issue a non-factor.

 

So maybe there’s something like <sighting id=’1’ count=’35’/> or maybe it’s just <sighting id=’1’/> repeated 35 times and TAXII is efficient enough that multiple sightings are a non-issue.

 

Thank you.

-Mark

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Thursday, August 20, 2015 9:22 AM
To: Aharon Chernin <achernin@soltra.com>
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

www.soltra.com