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-taxii] Fwd: Proposal - Allow a client to request an object based on its ID


Hi Jane,

There wouldn't be an impact as far as I can see. The idea would work something like this:

1. Consumer receives a STIX data object, say an indicator from org A with ID x
2. Consumer receives a top level relationship from org B saying there is a relationship between ID x and an indicator called ID y.
3. The consumer doesn't have a copy of the STIX data object with ID y (apart from knowing the id), so it contacts the original producer (which it knows from the namespace in the ID) and requests the STIX data object with ID y
4. The original producer of ID y object decides to allow the consumer to access the STIX object ID y, and so sends a copy of the o object to the consumer.

As far as the report object being links only, I would think the report object in this case would be the summary and overview information, and that it would user the top level relationship object to link to ask of the STIX data objects that are referenced in the report itself. I mentally see the difference as the report being the APT1 report itself, and the STIX objects and relationship objects being all those appendixes that contained IOCs (although STIX can describe much more than just the IOCs listed in the actual APT1 report.

Does that help clarify?

Cheers
Terry MacDonald

On 28 Jul 2015 2:58 pm, "Jane Ginn - jg@ctin.us" <jg@ctin.us> wrote:

So Terry:

How would this Use Case deal with a 'Confidence' rating... or a 'Sighting' ... and..., as you have probably noted... there is some discussion of having the 'Report' object be devoid of data... What would be the impact there with respect to this 'Relationship' object you are proposing?

Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
jg@ctin.us



-------- Original Message --------
From: Terry MacDonald <terry.macdonald@threatloop.com>
Sent: Monday, July 27, 2015 09:01 PM
To: cti-taxii@lists.oasis-open.org,cti-stix@lists.oasis-open.org
Subject: [cti-taxii] Fwd: Proposal - Allow a client to request an object based on its ID

Hi All,

I'd like to propose that TAXII and STIX querying abilities are reviewed and checked to make sure that a client is able to request an object based on its ID, and be returned it (if it is authorised by the producer). This must directly support proposal to allow a top-level relationship object. It would mean that if a user received just the relationship object they would know that there was a relationship with an object with a certain ID, but they wouldn't necessarily have the object itself. This functionality would allow a client to then subsequently request which ever data nodes' it wishes at either end of the relationship.

Note: This has the knock on effect of forcing the ID namespace to be tied back to the organisations domain name. If we did that, and mandated what services need to be provided by TAXII at what location, then it would be easy for a client to know how to request get from the relationship to actually contacting a TAXII server to request the actual object from the original source.

This would also work if an organisation wanted to be anonymous. It would need to provide the details through a 'broker' service which would translate the original ID sent by the anonymous producer to an ID within the broker's namespace. Then if any external consumers wanted more information then they would contact the broker, who would then forward that request to the original consumer. If the original producer says yes they can have it, then the broker says yes, and the consumer gets the information. Its a win/win.

I am aware that TAXII/STIX can do this already, but this is really about making sure that this use case is noted and supported.

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.


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