cti-taxii message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-taxii] Re: [EXT] Re: [cti-taxii] Proposal to relax language in section 3.4 version URL query parameter
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Tue, 3 Apr 2018 13:35:08 -0300
I will just take this opportunity again
to plug TAXII Information Request and Response from Terry and myself
https://docs.google.com/document/d/1Cy_9Bh5tKEkDHGg2iv5c3AwriqVr7ygbKXWOv4-uHxs/edit#
I was able to add a filter type to handle
this use case in about 1 minute, demonstrating the flexability of our approach.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
From:
Bret Jordan <Bret_Jordan@symantec.com>
To:
"Wunder, John
A." <jwunder@mitre.org>, "cti-taxii@lists.oasis-open.org"
<cti-taxii@lists.oasis-open.org>
Date:
04/03/2018 12:21 PM
Subject:
[cti-taxii]
Re: [EXT] Re: [cti-taxii] Proposal to relax language in section 3.4 version
URL query parameter
Sent by:
<cti-taxii@lists.oasis-open.org>
A client, automated or human, is doing
research on a specific threat actor or intrusion set. It believes
the first campaign started in Nov 2017 using Malware Foo and Attack Pattern
Bar with Indicators X, Y, and Z. What the client wants to know, as
it queries many different systems, is did the threat actor do similar attacks
using a similar modus operandi in Sept or Oct 2017.
Right now we have no way of doing this
and this seems like a very simple way of providing that functionality.
Let me rephrase, the only functionality
we currently provide is to forward synchronize an entire data feed from
a certain point in time (added_after).. But the added_after is NOT
tied to the modified time / version in STIX at all. Since a TAXII
server may get 2017 content in 2019, a client would have to sync the entire
dataset. There is no way of just asking for versions of content that were
modified in say 2017 or 2017-10 for example.
Bret
From: cti-taxii@lists.oasis-open.org
<cti-taxii@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Tuesday, April 3, 2018 7:03:54 AM
To: cti-taxii@lists.oasis-open.org
Subject: [EXT] Re: [cti-taxii] Proposal to relax language in section
3.4 version URL query parameter
Do you ever imagine wanting to do queries
like “versions between June 4 to June 16”? If so I would say don’t make
this change, because once you add that additional capability (to provide
a start/stop date for a range of versions) it would introduce two ways
of doing things (“2018-06” vs. “2018-06-01” to “2018-06-30”).
If on the other hand the common use case
is “modified this day” or “modified this year” then the approach below
makes sense. Along those lines, what’s the use case for this wildcarding?
Like I get the functionality, “I want to see any versions from June”
but when would a client system want to make that request?
John
From: <cti-taxii@lists.oasis-open.org>
on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Monday, April 2, 2018 at 4:09 PM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: [cti-taxii] Proposal to relax language in section 3.4 version
URL query parameter
All,
Right now in the URL Query Parameter section 3.4.1 (https://docs.google.com/document/d/1EsiWY7TGqt9yH6QUXv4c-opXSr3wR0TDMt8Q0yJjpoo/edit#)
for specifying a version, we have the following text for calling out a
specific value.
-
- <value>
- - requests a specific version of an object.
-
For
STIX objects, this requests objects whose modified time matches exactly
the provided value. This value MUST follow the rules for timestampas defined in [STIX™
Version 2.0. Part 1: STIX Core Concepts].
I propose that we change this text to be:
-
- <value>
- - requests a specific version of an object.
-
For
STIX objects, this requests objects whose modified time matches exactly
the provided value. This value MUSTfollow the rules for timestampas defined in [STIX™
Version 2.0. Part 1: STIX Core Concepts].
The reason for this change is to allow a
client to ask for "?match[version]=2017-01" and get all of the
STIX objects and their versions from January 2017 but not from December
2016 or earlier or from February 2017 or later.
This is documented here: https://github.com/oasis-tcs/cti-taxii2/issues/61
Bret
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]