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


Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).
{
"type": "indicator",
"id": "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29",
"references": {"taxii2": "https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29",
"amqp?": "amqp://user:pass@host:10000/vhost#SomeOtherStuff",
sneakernet": "Ask Mark (555) 555-5555"},
"producer": "MarkDavidson" // Omit field for anonymity
}
Thank you.
-Mark
From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: John Anderson <janderson@soltra.com>, Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object ID format

+1

URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.

John

From: <cti-stix@lists.oasis-open.org> on behalf of "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: John Anderson <janderson@soltra.com>, Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] Object ID format

I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.

 

STIX co-chairs, what’s the plan for gaining consensus on the object id?

 

Alex

 

From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

 

And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.

This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

-
Jason Keirstead
STSM, 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


Inactive hide details for "Jordan, Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX cont"Jordan, Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: John Anderson <janderson@soltra.com>
Cc: Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 01/22/2016 12:03 PM
Subject: Re: [cti-stix] Object ID format
Sent by: <cti-stix@lists.oasis-open.org>





Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.


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 22, 2016, at 07:43, John Anderson <janderson@soltra.com> wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.)

JSA
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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


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.


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