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] Object ID format


Most objects will be local to an internal system and will never be on an http server, especially on a publicly assessable web server.. Even Pat made reference to some STIX content gets shipped on CDs via FedEx.  Further, just because you have a URI or URL does not mean you will have access to that content.  

We need to accept the fact that security teams and threat researchers work in enclaves.  And if you get a relationship object from someone, and it references content that you do not already have, it may be hard or impossible for you to dereference it.  In fact, you may not be allowed to dereference it at all.  

Your best option is to try and contact the person that sent you the relationship object and ask them, if they can tell you who they got the content from.  If they can, then you can turn around and ask them. But you may not have a legal contracts to be able to access, use, or even know about that content.  

IDs for STIX objects should be simple and light weight.  [object-type]::[uuid]

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Jan 21, 2016, at 16:57, John Anderson <janderson@soltra.com> wrote:

I have to ask: Why would you do such a thing? 

HTTP to the rescue!

If you want to look up an object by it's URL, just GET that URL.

Now, if you want my copy of an object, you use the URL my server uses.
Example: https://andersoninnovative.com/a/completely/different/url/

How do you know that my Object is related to the other one? Because it includes an HTTP "Content-Location" header with the original FS-ISAC URL-as-ID. <OutlookEmoji-&amp;#X1f60a.png>

Or...(and this is where I really start to geek out)...you could use the "Derived-From" header to say that your object is based on an original somewhere else. Relationships as top-level objects is cool. Relationships at the HTTP Resource level is even more amazing!

Querying by ID...another take:
"But I really want to know if you know about this particular FS-ISAC indicator," you might say. No problem.

Bret's answer is really close. However, encoding a URL in a URL to make a URL is somewhat contorted. And, it befuddles the meaning. (Which is the URL-as-ID? Which is the URL? Huh?)

Let's take it one step further. If you want to query what I know about a URL not on my server, then just hit my Search Resource.



That entire URL now points to a unique HTTP Resource. In English, its name is "What My Server Knows about http://fs-isac.org/indicator/deadbeef1234". (Everything in a URL except for the fragment contributes to the URL. Including the stuff after "?".)

What could such a Resource be? The possibilities are amazing!

Option 1. It returns HTTP Redirect to my own URL-as-ID for my copy.
Option B. It returns a CTI Relationship Object(!) that shows how my own URL-as-ID is related to the original.
Option III. Whatever you want. Maybe a 404 if I don't let you search my site.

JSA 



From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Foley, Alexander - GIS <alexander.foley@bankofamerica.com>
Sent: Thursday, January 21, 2016 2:56 PM
To: Jordan, Bret; Barnum, Sean D.
Cc: Jason Keirstead; Paul Patrick; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Object ID format
 
I’m probably on the other side of the fence on this one, but it would still be possible to handle a URI using encoding:

 

 

Thanks,

 

Alex

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, January 21, 2016 2:54 PM
To: Barnum, Sean D.
Cc: Jason Keirstead; Paul Patrick; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

 

There are many problems with using a URI.  But one is TAXII needs to support the idea of look up by ID...  How are you going to do that with a URI???

 

 

Example:  Your data collection sits at:

 

 

So with your proposal, that URL will just blow up, for example:

 

 

That is a recipe for disaster.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jan 21, 2016, at 12:26, Barnum, Sean D. <sbarnum@mitre.org> wrote:

 

I don’t think anyone said that it would not include a UUID.

 

It could easily be something like : http://fs-isac.org/indicator/#UUID

 

I do not see any downside to it but do see lots of upside.
It meets the uniqueness criterion. 
It meets the object type indication criterion. 
It supports the use cases Terry describes with the domain name criterion. 
It supports use cases requiring URI/URL iDs (including those brought up by JSA).
And it is unambiguous, simple and consistent.

 

Like I said, going into the f2f the URI approach made the most sense to me but I did not see an overriding need to the point where it was worth me arguing with folks wanting the different approach. Conversations since the f2f have changed my opinion to one where a URI/URL approach clearly makes the most sense to me.

 

sean

 

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, January 21, 2016 at 2:16 PM
To: "Barnum, Sean D." <sbarnum@mitre.org>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object ID format

 

The ID needs to be globally unique and I thought we had consensus on using Ver4 UUID or the likes. I would disagree that it MUST be a URI / URL.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jan 21, 2016, at 12:09, Barnum, Sean D. <sbarnum@mitre.org> wrote:

 

The point that I and others are making here is that the “URL” should not be a separate thing. That the ID itself can be in the form of a URI. For those who do not wish to make it resolvable, cool they don’t have to. For those who do, they can.

 

sean

 

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, January 21, 2016 at 2:07 PM
To: "Barnum, Sean D." <sbarnum@mitre.org>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object ID format

 

What do you do with all of the groups that are NOT going to include the URL?  It seems like having it be part of the ID, but at the end, makes it super ease to parse or not parse.  A simple split on "::" would give you the three tokens.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jan 21, 2016, at 12:04, Barnum, Sean D. <sbarnum@mitre.org> wrote:

 

I do not see the value in the inconsistency.

 

Why not simply make it one way of doing things (one that supports all the use cases described so far including enabling use as URI/URL)?

 

sean

 

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, January 21, 2016 at 1:56 PM
To: "Barnum, Sean D." <sbarnum@mitre.org>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object ID format

 

What about: 

 

[object type]::[UUID]::[ID Domain Authority OR URL] and this last part could be optional. This would solve everyone's concern?

 

Anon Use Case 1:
Intel Group Foo shares an Indicator "indicator::UUID" with ISAO Bar.  When Bar sends you a relationship object they can tack on their ID Domain to the end, so that people know they MIGHT be able to go back to ISAO Bar and get more information.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jan 21, 2016, at 11:45, Barnum, Sean D. <sbarnum@mitre.org> wrote:

 

The problem with burying the URL inside the object is it does not really support many of the use cases being discussed.
The point is that the ID for the content can be used in an unambiguous resolvable way without having to parse into the object which for many use cases (e.g. A relationship without both end objects) you won’t have that object to parse into.

 

I agree with a fixed format codified into the spec. 
My opinion is that the fixed format should be [ID authority domain name]/[object type]/[UUID] in such a way to support URI/URL use.

 

sean

 

From:  "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, January 21, 2016 at 1:36 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, "Barnum, Sean D." <sbarnum@mitre.org>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object ID format

 

I would really prefer the ID be a fixed format codified in the spec, and any URL be moved to an optional "external_reference" property. Or utilize the "external_ID" property discussed previously. 

Or, Brett's #2 suggestion and just have a relationship to a "collection" object.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown 


<graycol.gif>"Jordan, Bret" ---01/21/2016 02:32:18 PM---So the real question is, do we want to use a URI/URL or a [namespace]:[object-type]:[UUID]? What if

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Paul Patrick <ppatrick@isightpartners.com>
Cc: "Barnum, Sean D." <sbarnum@mitre.org>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 01/21/2016 02:32 PM
Subject: Re: [cti-stix] Object ID format
Sent by: <cti-stix@lists.oasis-open.org>




So the real question is, do we want to use a URI/URL or a [namespace]:[object-type]:[UUID]? What if we did both? Like maybe this:

All discreet objects in CTI MUST include an ID that defined as an object-type plus a version 4 UUID, example "indicator:104abc69-509e-4bf9-b64c-81255292c433". You MAY also include an optional URL at the end of the ID if you want to map this object back to an actual resource found on a TAXII server, example "indicator:104abc69-509e-4bf9-b64c-81255292c433:https://taxii.somecompany.com/taxii2/collections/neat-indicators/id/104abc69-509e-4bf9-b64c-81255292c433"

OR even better.. We pull this ID UUID stuff in to TAXII land and make sure that objects can be found by their ID. Then you do not need to include a full URL, but just collection location, example "
https://taxii.somecompany.com/taxii2/collections/neat-indicators/"





Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Jan 21, 2016, at 09:16, Paul Patrick <ppatrick@isightpartners.com> wrote:

I’m supportive of standardizing Object ID format to be based on the form [producer-namespace]:[object-type]:[UUID], especially if that doesn’t prevent the use of URI. 

I think Terry correct captured many of the concerns that I had with the F2F proposed solution and I definitely in agreement with John A. about the value of being able to use URLs.


Paul Patrick
iSIGHT Partners

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] 

<graycol.gif>

 

 

 

 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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