OASIS Cyber Threat Intelligence (CTI) TC

Folks, I'm sorry to have missed the presentation and discussion around Cisco's XMPP-Grid. As some of you already know, I've spent the past decade or so working with XMPP within the XMPP Standards Foundation, and I'm currently serving on their XMPP Council, the technical council for the standards. I'm happy to make myself available to people wanting further information on how XMPP works, and what facilities is has in various spaces. At Surevine, we're already using XMPP within the CTI space, and are moving to exposing STIX data stores over XMPP. It's useful as it provides a clear mechanism for publish/subscribe operations across multiple domains (both in terms of the DNS and autonomous organisations), and since we're largely focussed on people rather than simply the raw data, the inclusion of discussion and chat capability is extremely convenient. We are using a combination of the base specifications (RFC 6120 and RFC 6121), and selected XMPP Extension Protocols (XEP-0060, XEP-0258, XEP-0369 being the primary ones of interest). It's never been clear to me precisely what XMPP-Grid offers over and above these - for example it appears to provide its own subscription syntax (which offers nothing beyond the XEP-0060 syntax it replaces), but does not provide any guidance on topic layout. To put it another way, we're already achieving much of XMPP-Grid's stated aims, but without having had to write new protocol extensions. So while I do like the idea of using XMPP for CTI data exchange, I'm not interested in XMPP-Grid. I've raised this on the IETF MAIL WG list, but never actually had an answer as to what XMPP-Grid is doing that cannot be done using pre-existing protocol. As a final note, I would exhort people to continue with TAXII (or at least, some form of classical Web API), since developers often find XMPP quite a steep learning curve. But for higher volumes and higher complexity, XMPP will save a vast amount of engineering design. Dave. -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Hi Dave, In the alternative proposal I presented last call we suggested to split TAXII 2.0 into 2 specs: JSON API and Channels. Do you think XMPP spec/extensions can be used as an inspiration for Channels spec? and maybe as an engine for a prototype implementation? Thanks, Sergey Polzunov EclecticIQ > On 10 Mar 2017, at 17:17, Dave Cridland <dave.cridland@surevine.com> wrote: > > Folks, > > I'm sorry to have missed the presentation and discussion around Cisco's XMPP-Grid. As some of you already know, I've spent the past decade or so working with XMPP within the XMPP Standards Foundation, and I'm currently serving on their XMPP Council, the technical council for the standards. I'm happy to make myself available to people wanting further information on how XMPP works, and what facilities is has in various spaces. > > At Surevine, we're already using XMPP within the CTI space, and are moving to exposing STIX data stores over XMPP. It's useful as it provides a clear mechanism for publish/subscribe operations across multiple domains (both in terms of the DNS and autonomous organisations), and since we're largely focussed on people rather than simply the raw data, the inclusion of discussion and chat capability is extremely convenient. > > We are using a combination of the base specifications (RFC 6120 and RFC 6121), and selected XMPP Extension Protocols (XEP-0060, XEP-0258, XEP-0369 being the primary ones of interest). > > It's never been clear to me precisely what XMPP-Grid offers over and above these - for example it appears to provide its own subscription syntax (which offers nothing beyond the XEP-0060 syntax it replaces), but does not provide any guidance on topic layout. > > To put it another way, we're already achieving much of XMPP-Grid's stated aims, but without having had to write new protocol extensions. So while I do like the idea of using XMPP for CTI data exchange, I'm not interested in XMPP-Grid. > > I've raised this on the IETF MAIL WG list, but never actually had an answer as to what XMPP-Grid is doing that cannot be done using pre-existing protocol. > > As a final note, I would exhort people to continue with TAXII (or at least, some form of classical Web API), since developers often find XMPP quite a steep learning curve. But for higher volumes and higher complexity, XMPP will save a vast amount of engineering design. > > Dave. > -- > Dave Cridland > > phone +448454681066 > email dave.cridland@surevine.com > skype dave.cridland.surevine > > > Participate Collaborate Innovate > > Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND > If you think you have received this message in error, please notify us.

Going through these one at a time: On 10 Mar 2017 22:41, "Sergey Polzunov" < sergey@eclecticiq.com > wrote: Hi Dave,     In the alternative proposal I presented last call we suggested to split TAXII 2.0 into 2 specs: JSON API and Channels. I've not examined JSON-API in great detail, and I would have expected a major shift in underlying technology to be capable of a wider range of use-cases, but in general a split between basic functionality and more complex use-cases seems to make sense.     Do you think XMPP spec/extensions can be used as an inspiration for Channels spec? Inspiration? You could build it directly. Taking a "Channel" to be an asynchronous-capable publish-subscribe topic, you could build a simple "Channel" directly in existing XMPP protocols. Off the top of my head, using MAM (XEP-0313) on top of PubSub (XEP-0060), and combined with the usual base specs, would be pretty much all you need. There are existing implementations of this. You could skip XEP-0313 for simple cases; in which case there are a large number of existing implementations. This would give discovery (XEP-0030), polling (XEP-0313/XEP-0060), and push notifications (XEP-0060). A limitation here is that fine-grained access control hasn't been completed in a PubSub setting - while XMPP does have a label concept (XEP-0258) which is compatible with SDN.801(c) models (and therefore STANAG 4774, GENSER, IC-IHM, et al) the work on its companion for PubSub, XEP-0314, stalled some time back - I'm hoping to revive this soon, since Surevine's work relies on it. Right now, only basic ACL systems (IBAC), and approval-required subscriptions, are available in XEP-0060 (roughly equivalent to that in XMPP-Grid). This far, everything required for a CTI distribution service is available using existing services - hence my confusion with XMPP-Grid. A more advanced service might make a break between the "pub" and "sub" aspects; therefore the XMPP PubSub "nodes" become more like AMQP topics with some bespoke (and CTI-aware) code to choose which XMPP nodes nominally contain which STIX objects. This also allows topics/nodes representing particular IP addresses, networks, and other items of interest not directly represented in STIX SDOs. How this latter might work is what I'd expect to see in XMPP-Grid, but it's not there - XMPP-grid seems to be a content-neutral publish-subscribe service, but XMPP has one of those already. and maybe as an engine for a prototype implementation? This is somewhat easier. There are a number of open-source servers built in a number of different languages which implement part or all of this. Thanks, Sergey Polzunov EclecticIQ > On 10 Mar 2017, at 17:17, Dave Cridland < dave.cridland@surevine.com > wrote: > > Folks, > > I'm sorry to have missed the presentation and discussion around Cisco's XMPP-Grid. As some of you already know, I've spent the past decade or so working with XMPP within the XMPP Standards Foundation, and I'm currently serving on their XMPP Council, the technical council for the standards. I'm happy to make myself available to people wanting further information on how XMPP works, and what facilities is has in various spaces. > > At Surevine, we're already using XMPP within the CTI space, and are moving to exposing STIX data stores over XMPP. It's useful as it provides a clear mechanism for publish/subscribe operations across multiple domains (both in terms of the DNS and autonomous organisations), and since we're largely focussed on people rather than simply the raw data, the inclusion of discussion and chat capability is extremely convenient. > > We are using a combination of the base specifications (RFC 6120 and RFC 6121), and selected XMPP Extension Protocols (XEP-0060, XEP-0258, XEP-0369 being the primary ones of interest). > > It's never been clear to me precisely what XMPP-Grid offers over and above these - for example it appears to provide its own subscription syntax (which offers nothing beyond the XEP-0060 syntax it replaces), but does not provide any guidance on topic layout. > > To put it another way, we're already achieving much of XMPP-Grid's stated aims, but without having had to write new protocol extensions. So while I do like the idea of using XMPP for CTI data exchange, I'm not interested in XMPP-Grid. > > I've raised this on the IETF MAIL WG list, but never actually had an answer as to what XMPP-Grid is doing that cannot be done using pre-existing protocol. > > As a final note, I would exhort people to continue with TAXII (or at least, some form of classical Web API), since developers often find XMPP quite a steep learning curve. But for higher volumes and higher complexity, XMPP will save a vast amount of engineering design. > > Dave. > -- > Dave Cridland > > phone  +448454681066 > email  dave.cridland@surevine.com > skype  dave.cridland.surevine > > > Participate Collaborate Innovate > > Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND > If you think you have received this message in error, please notify us.

Thanks Dave for your perspective. For the broader forum’s education here’s some pointers and background why this technology is important -

XMPP Grid IETF draft -  https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid /.
The draft discussions where we extend XMPP and some of the core components that XMPP Grid messaging framework offers over and above XMPP. Platform Exchange Grid (pxGrid) is a commercial version of XMPP Grid which is adopted by 50+ industry vendors across 10+ technology areas and the eco-system is growing. Please review  https://developer.cisco.com/site/pxgrid/discover/overview /
and  http://www.cisco.com/c/en/us/products/security/pxgrid.html We have Web Sockets and REST extensions with STOMP defined for XMPP Grid, alleviating the need for clients to be XMPP aware and have a client installed on them to exchange on XMPP Grid.

We believe that an integration between STIX/TAXII and XMPP-Grid is important as you state Dave so look forward to working on a community based approach to solving that
problem.






Thanks

Syam









From: < cti@lists.oasis-open.org > on behalf of Dave Cridland < dave.cridland@surevine.com >
Date: Friday, March 10, 2017 at 8:17 AM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Use of XMPP in CTI





Folks,


I'm sorry to have missed the presentation and discussion around Cisco's XMPP-Grid. As some of you already know, I've spent the past decade or so working with XMPP within the XMPP Standards Foundation, and I'm currently serving on their XMPP Council, the
technical council for the standards. I'm happy to make myself available to people wanting further information on how XMPP works, and what facilities is has in various spaces.


At Surevine, we're already using XMPP within the CTI space, and are moving to exposing STIX data stores over XMPP. It's useful as it provides a clear mechanism for publish/subscribe operations across multiple domains (both in terms of the DNS and autonomous
organisations), and since we're largely focussed on people rather than simply the raw data, the inclusion of discussion and chat capability is extremely convenient.


We are using a combination of the base specifications (RFC 6120 and RFC 6121), and selected XMPP Extension Protocols (XEP-0060, XEP-0258, XEP-0369 being the primary ones of interest).


It's never been clear to me precisely what XMPP-Grid offers over and above these - for example it appears to provide its own subscription syntax (which offers nothing beyond the XEP-0060 syntax it replaces), but does not provide any guidance on topic layout.


To put it another way, we're already achieving much of XMPP-Grid's stated aims, but without having had to write new protocol extensions. So while I do like the idea of using XMPP for CTI data exchange, I'm not interested in XMPP-Grid.


I've raised this on the IETF MAIL WG list, but never actually had an answer as to what XMPP-Grid is doing that cannot be done using pre-existing protocol.


As a final note, I would exhort people to continue with TAXII (or at least, some form of classical Web API), since developers often find XMPP quite a steep learning curve. But for higher volumes and higher complexity, XMPP will save a vast amount of engineering
design.


Dave.
--



Dave Cridland

phone   +448454681066
email   dave.cridland@surevine.com
skype   dave.cridland.surevine




Participate Collaborate Innovate

Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
If you think you have received this message in error, please notify us.

+1 to Dave’s comments about continuing with TAXII as it exists in draft form.   I think that XMPP and related technologies can play an important role in the transportation of STIX data within certain communities and I would definitely like to help those communities support STIX interchange.  Having said that, as the Mandatory-to-Implement transport for STIX data, TAXII must be based on technologies and concepts with as close to universal appeal as possible – hence the HTTP-based approach taken by the TAXII SC over the past year.   From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Syam Appala (syam1) Sent: Friday, March 10, 2017 7:03 PM To: Dave Cridland; cti@lists.oasis-open.org Subject: Re: [cti] Use of XMPP in CTI   Thanks Dave for your perspective. For the broader forum’s education here’s some pointers and background why this technology is important - XMPP Grid IETF draft -  https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid /. The draft discussions where we extend XMPP and some of the core components that XMPP Grid messaging framework offers over and above XMPP. Platform Exchange Grid (pxGrid) is a commercial version of XMPP Grid which is adopted by 50+ industry vendors across 10+ technology areas and the eco-system is growing. Please review  https://developer.cisco.com/site/pxgrid/discover/overview / and  http://www.cisco.com/c/en/us/products/security/pxgrid.html We have Web Sockets and REST extensions with STOMP defined for XMPP Grid, alleviating the need for clients to be XMPP aware and have a client installed on them to exchange on XMPP Grid. We believe that an integration between STIX/TAXII and XMPP-Grid is important as you state Dave so look forward to working on a community based approach to solving that problem.     Thanks Syam   From: < cti@lists.oasis-open.org > on behalf of Dave Cridland < dave.cridland@surevine.com > Date: Friday, March 10, 2017 at 8:17 AM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Use of XMPP in CTI   Folks,   I'm sorry to have missed the presentation and discussion around Cisco's XMPP-Grid. As some of you already know, I've spent the past decade or so working with XMPP within the XMPP Standards Foundation, and I'm currently serving on their XMPP Council, the technical council for the standards. I'm happy to make myself available to people wanting further information on how XMPP works, and what facilities is has in various spaces.   At Surevine, we're already using XMPP within the CTI space, and are moving to exposing STIX data stores over XMPP. It's useful as it provides a clear mechanism for publish/subscribe operations across multiple domains (both in terms of the DNS and autonomous organisations), and since we're largely focussed on people rather than simply the raw data, the inclusion of discussion and chat capability is extremely convenient.   We are using a combination of the base specifications (RFC 6120 and RFC 6121), and selected XMPP Extension Protocols (XEP-0060, XEP-0258, XEP-0369 being the primary ones of interest).   It's never been clear to me precisely what XMPP-Grid offers over and above these - for example it appears to provide its own subscription syntax (which offers nothing beyond the XEP-0060 syntax it replaces), but does not provide any guidance on topic layout.   To put it another way, we're already achieving much of XMPP-Grid's stated aims, but without having had to write new protocol extensions. So while I do like the idea of using XMPP for CTI data exchange, I'm not interested in XMPP-Grid.   I've raised this on the IETF MAIL WG list, but never actually had an answer as to what XMPP-Grid is doing that cannot be done using pre-existing protocol.   As a final note, I would exhort people to continue with TAXII (or at least, some form of classical Web API), since developers often find XMPP quite a steep learning curve. But for higher volumes and higher complexity, XMPP will save a vast amount of engineering design.   Dave. -- Dave Cridland phone  +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us. Attachment: smime.p7s Description: S/MIME cryptographic signature