Re: [cti-stix] Re: Object ID format

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Agree - this is key and it is also needed for a proper AA system for threat intel.

IE, this threat object is sourced from this InformationSource, and it is digitally signed within the InformationSource - so you know (a) it hasn't been altered, (b) it came from who you think it came from, (c) the person who sent it was authorized to sign it as coming from that source. You simply can't communicate all of this in a URL (well unless the URL is ridiculously long).

-
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


"Jordan, Bret" ---01/22/2016 09:29:11 PM---Along these lines, I also envision long-term having well known InformationSource objects. Like once

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Terry MacDonald <terry@soltra.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 01/22/2016 09:29 PM
Subject: Re: [cti-stix] Re: Object ID format
Sent by: <cti-stix@lists.oasis-open.org>

---

Along these lines, I also envision long-term having well known InformationSource objects.  Like once for a CERT or MITRE or major vendor XYZ.


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 14:52, Terry MacDonald <terry@soltra.com> wrote:

Hi John,

Companies are bought by other companies. Organizations rebrand. Groups replace and redesign networks. All of these real-world things affect where things are located and reachable in the Internet. I would still trust these companies, as what they are doing is normal behaviour - and yet they are still changing their Resources.

'Hard linking' the Object-IDs directly to any destination (i.e. using URLs) is a bad idea, as it means that that Object is tied to the location forever. If a company moves to a new network design and we use hard-linking, then the consumer is no longer able to ask for help, unless there is some kind of translation web proxy created that understands Object IDs.

I prefer a 'look it up at the time' mechanism for resolving the actual 'real' location of Object IDs. If an ID is in the format [Object]-[UUID], and it links to an InformationSource Object, and that object has a domain name in it, then I will be able to look up the TAXII Domain Service record, and that can then tell me what the current latest (and valid) location is to get more information. In fact we could even include the TAXII server location in the InformationSource Object itself, and if our domain name changes then we can update the InformationSource Object and republish it out to the community.

Cheers

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com



-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of John Anderson
Sent: Saturday, 23 January 2016 1:43 AM
To: Trey Darley <trey@soltra.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Re: Object ID format

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


---------------------------------------------------------------------
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]