Hey, Jason -
In this configuration the spokes pull from the hub and push back to it. The hub itself doesn't make outbound connections.
Sent: Wednesday, July 15, 2015 14:20
To: Trey Darley
Cc: Terry MacDonald; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Goals for TAXII 2.0
Sorry maybe I am misunderstanding... maybe I have always misunderstood this! What I am referring to is the TAXII push to INBOX which contains a subscription ID... this implies that the client hosting that INBOX service, previously subscribed to something
on that TAXII hub... which by nature (since it is subscriber based) implies it is a PUSH from the hub to the spoke.
If you had a hub and spoke configuration.. the hub would not be the subscriber.. the spokes would be subscribers... no?
I am having a hard time envisioning a model where there is a hub and spoke configuration where the hub subscribes to feeds on the spokes when the spokes don't allow inbond connections... how does that work?
-
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
Trey
Darley ---2015/07/15 09:11:21 AM---Hey, Jason - While it might not be immediately apparent, there are institutions which use both the p
From: Trey Darley <trey@soltra.com>
To: Jason Keirstead/CanEast/IBM@IBMCA, Terry MacDonald <terry.macdonald@threatloop.com>
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/07/15 09:11 AM
Subject: Re: [cti-taxii] Goals for TAXII 2.0
Sent by: <cti-taxii@lists.oasis-open.org>
Hey, Jason -
While it might not be immediately apparent, there are institutions which use both the poll and push due to site security policy. Basically, where you'd normally have a hub and spoke with peer-to-peer polling, in these cases no inbound connections are allowed on the edge node. Instead, these nodes are configured to a) poll a centrally accessible hub and b) push outbound to that same node.
I generally agree with the notion of stripping away "needless" flexibility but I don't think that applies in this particular case.
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
From: cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Wednesday, July 15, 2015 14:06
To: Terry MacDonald
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Goals for TAXII 2.0
Does Tenant 1 mean that TAXII 2.0 will only do either a PUSH model or a POLL/PULL model, but not both?
That would be great... to me this was one of the "needlessly flexible" facets of TAXII 1.X.
-
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
Terry MacDonald ---2015/07/15 12:45:00 AM---Hi All, As per earlier discussions I really think it would be beneficial to discuss
From: Terry MacDonald <terry.macdonald@threatloop.com>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/07/15 12:45 AM
Subject: [cti-taxii] Goals for TAXII 2.0
Sent by: <cti-taxii@lists.oasis-open.org>
Hi All,
As per earlier discussions I really think it would be beneficial to discuss some key goals that we want TAXII 2.0 to adhere to. As such I've tried to incorporate the discussions we've had over the past year or so, and distill them into the following list.
Please note, this is a 'starter for 10', just to prompt further discussion. Please do not consider it official, final, or authoritative in any way :) (I should be a lawyer).
Goals for TAXII v2.0:
- Tenet 1 - Only One Way To Do It
TAXII v1.x allows for a lot of flexibility in how you implement it. It was designed to allow people to implement parts of the standard across multiple different nodes in multiple different locations. This has turned out to not be necessary, and in fact potentially a hinderance to the development of implementations (e.g. taxii discovery).
I would like us to have a core tenet that there will be only one way to perform a particular task. This should make it easier for implementers to generate and process TAXII, and will make it easier to test for conformance in the future. - Tenet 2 - Minimise Size
I know of at least one implementer who is looking to transmit 1TB of data using STIX each day. XML is not a good transport mechanism for that volume of data. We need to ensure that the transmission of TAXII data is done as efficiently as possible. We need to make TAXII use the least amount of space on the wire as is physically possible, so that we fit the most amount of data in the least amount of space.
This naturally leads us towards a binary protocol implementation, as this is what all the major cloud based service providers who deal with voluminous amounts of data have moved to (Google, Microsoft, etc) - Tenet 3 - Be Easily Extensible
This alludes to the fact that as hard as we might try, we will get things wrong in the initial implementation. Also, over time, the needs of the community will morph and change. We need to ensure that any solutions we devise are easily extensible such that we are able to add new functionality onto the previously released implementations without too much impact.
Please note - This only applies within minor releases i.e. within 2.x. I expect major releases to break stuff as per the TAXII versioning policy. - Tenet 4 - Only Transmit Whats Necessary
In a way this is a by product of Tenet 2 - Minimise Size, but I thought it was important enough to describe separately. By enabling the ability to do things such as send partial STIX updates, keeping connections open (pipelining), defining 'hardcoded' locations to eliminate discovery phase, we can eliminate parts of the transmission, to help minimise the size of the data that needs to flow from point A to point B. - Tenet 5 - Minimise Resource Usage
This is also fairly similar to Tenet 2, but is focused on the processing that the producer and consumer need to do at the each end of the communication. We need to ensure that we also make the data as easy to consume/translate/serialize etc as possible. This will allows implementations to scale to much greater heights than they can at present.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com
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.