OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion

Apologies for not responding sooner to various posts. I've been on a family vacation behind the Great Firewall since the TC was established.

Regarding a Maturity Model, I agree quantitative and qualitative measurements would be appropriate. I also think there is an opportunity with the Outreach SC to bring together the work that has been done up to date and coordinate the various people involved moving forward.

You may have seen the list attached of STIX & TAXII implementations that we have actually reviewed and tested. I think with some additional level of object granularity (or an associated STIX profile) and a combination of the more qualitative aspects that Mitre has put forth, we could have a Maturity Model that is quite robust. And with a labeled "maturity level", it could be relatively straight forward.

I'm happy to contribute the many hours that I and others at Soltra have put behind this effort and combine with other sources for the SC to carry on. More broadly, I feel the Outeach SC should be about all TC members contributing to encourage standards adoption and help drive maturity versus just a small group of appointed evangelists.

Dave Eilken

Soltra/ FS-ISAC

VP Strategy

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jane Ginn - jg@ctin.us <jg@ctin.us>
Sent: Thursday, July 2, 2015 6:09 AM
To: Joep Grommers; mclancy@soltra.com; Jerome Athias
Cc: pallor@us.ibm.com; richard.struse@dhs.gov; cti@lists.oasis-open.org
Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion


A Maturity Model for the STIX/TAXII/CYBOX ecosystem is something I would support, too. It seems like it would be most suitable for Producers of STIX....

How many levels would you envision? What kind of certifying/auditing body would confirm achievement of certain levels? How would the Producers demonstrate features of maturity?

I envision a Maturity Model along two dimensions for this ecosystem: qualitative and quantitative.

Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.

-------- Original Message --------
From: Joep Gommers <joep@intelworks.com>
Sent: Tuesday, June 30, 2015 05:29 AM
To: Mark Clancy <mclancy@soltra.com>,Jerome Athias <athiasjerome@gmail.com>
Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
CC: Peter Allor <pallor@us.ibm.com>,Rich Struse <richard.struse@dhs.gov>," cti@lists.oasis-open.org" <cti@lists.oasis-open.org>

Hi Mark,

Love the MMO angle here!


From: Mark Clancy <mclancy@soltra.com>
Date: Friday, June 26, 2015 at 2:25 PM
To: Jerome Athias <athiasjerome@gmail.com>, Joep Gommers <joep@intelworks.com>
Cc: Peter Allor <pallor@us.ibm.com>, Rich Struse <richard.struse@dhs.gov>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion

The adoption chart is part of the need and the OVAL example is a good one. 

Another side of this is the STIX profile  (https://stix.mitre.org/about/documents/STIX_Profiles_Overview_White_Paper_v0.1.pdf). This is important as different parts of the ecosystem have and need different levels of ‘completeness’ in how they handled Cybox/STIX.  So if I am trying to consume STIX data for say a Snort based IDS system there are a lot of Cybox objects (like Win Reg key), STIX object types (like say Campaigns) that don’t make any sense for a Snort based sensor to consume or produce.  Where as we also have STIX implementations for devices/sensors like say a SIEM that can/should handle mode Cybox/STIX object types, but don’t do so at present.  It is kind of hard to describe the difference between those two levels of implementation.  I could have everything implemented for a Snort type IDS that the device is able to do and have the same number of STIX/Cybox objects supports in same a SEIM tool which should be able to handle a lot more of these the STIX profiles would be the same, but the maximum possible maturity of the implementations IMHO are quite different.


I would really like to see the concept of an implementation maturity model worked into the ‘adoption’ notions here. We see quite a difference between “like” products in the same categories as to their level of implementation.  Today you could say you support STIX if you support say IPv4 address Cybox objects and only STIX Observables. Technically that is STIX ‘support’ and if that is what is in your STIX profile you are legit. The reality is the STIX profile is the way to ‘transact’ the objects supports vs. not when being shared, but we need a simpler summary of this so when customers of these products make choices informed of what “we support STIX/TAXII” actually means.  If consumers experience “STIX support” at this level of maturity/completeness and they expected much more it is going to reflect poorly on our standards.  So say supporting one Cybox object and one Stix object is Level 1 maturity in a single direction , but supporting all Cybox and STIX objects, bi-directionally, linked to each other is a much higher level.

I suggest we add this to the outreach workstream as a way of keeping track of what "adoption" really means.


Mark Clancy
Chief Executive Officer
SOLTRA | An FS-ISAC and DTCC Company
+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535  UK mobile
mclancy@soltra.com| soltra.com
One organization's incident becomes everyone's defense.

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jerome Athias <athiasjerome@gmail.com>
Sent: Friday, June 26, 2015 2:00 AM
To: Joep Gommers
Cc: Peter Allor; Rich Struse; cti@lists.oasis-open.org
Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
Adoption Program?

2015-06-26 8:46 GMT+03:00 Joep Gommers <joep@intelworks.com>:
Hi Peter,

Let me put some context around my proposal for certification, which perhaps means rewording.

First, I am completely aligned with you on the “voluntary” part and on the fact that mandatory certification would severely hinder adoption. Yet, what I think it hindering adoption more is – and perhaps this speaks to your concerns about STIX/TAXII too – that it is ensure for producers how their intelligence value is retained when received by other consumers. In a world where I send you a PDF, I know how you will consume the PDF. It is predictable and the value I bring as an intelligence producer is surely retained. Additionally, I as a producer am in full control.

Now in STIX this isn’t necessarily the case. Since STIX is transport, it does not guarantee to any extent that the intelligence value is retained all the way to its human consumer – not as that the intent. STIX 1.1.1 compliancy usually means, for both CSIRT communities and vendors (and many other communities I might add that this is relevant for), a partial implementation of parts of the standard – that are processed by a machine and/or readable by a human in different ways.

For TAXII, a similar challenge exists where there is no easy automated way of determining for machines what the TAXII implementors supports. Think; authentication, authorization, different services (depending on discovery service on/off, hooked on/off), polling subscription models, etc.

For me, certification and compliancy effort would be to ensure that it is publicly known and easily measurable what implementors actually support from the standard and where value is retained and where it isn’t. For TAXII, this means simple tools that make transparant the pattern of functionality implemented by a CSIRT community, vendor, etc. so they can say “guys I’m level A TAXII” - which will mean I support features A, B and C. For STIX similarly, a certain level of certification might mean that an producer/consumer implements the indicator/observable idioms, but does not retain much of the intelligence value of threat actor or exploit target information. This is relevant for the public to know, for producers to understand and to make transparant as to drive the community towards the right priorities and compatibility efforts. Right now, the conversational line of “STIX/TAXII compatible” has no value and requires significant effort to undercover what REALLY is implemented and what intelligence value is REALLY retained.

So perhaps, certification is a bad word. Thoughts?

Best regards,

From: Peter Allor <pallor@us.ibm.com>
Date: Wednesday, June 24, 2015 at 7:11 PM
To: Joep Gommers <joep@intelworks.com>
Cc: Rich Struse <richard.struse@dhs.gov>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>

Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion

I think I will push back a bit here, especially on your 'certification' and 'compliance' aspects.


We need to be "voluntarily" adopting this 'standard'.

While I can see Tony's comments about talking with EC bodies, the real adoption and use for CTI is in two communities, which by their nature are international.

They are the CSIRT Community, specifically National CSIRTs but also Critical Infrastructure CSIRTs and Enterprise CSIRTs (I will not delve into the Big, Medium, Small discussion).   There is a whole lot going on in CSIRT Services Framework and Education Development where this can be included and is updating materials from CERT/CC-SEI that are now 20 years old.

Then there is the 'vendor' community, which has not been really engaged here.   I know some will say they are part of that community, but then also tout how they are international.   So we need the large IT Vendors and we need the broad IT Security Vendors as part of this process.   That would be for all FOUR Sub-Committee's.    Much of the indicators and expressions will need their input and adoption to actually gain traction for many and to enable the CSIRT Community (yes, the vendors are part of that community as well).     Just to be clear, I am talking about Intel/McAfee, Symantec, Microsoft, IBM, Cisco/SourceFire, FireEye/Mandiant, and a slew of others.

Pushing mandatory compliance and certification does not work globally (think Common Criteria / NIAP, I could go on on that alone) and in security venues globally it is a check box with little use.    Now I know that vendors are looking to be part of this, but the sentiment here in the discussions does not reflect that.    I say that from a vendor and incident response community perspective.

So lets focus on how we get their perspectives to be included, as I know as vendors, we see that STIX/TAXII in their current incarnation do NOT work very well and that exchanging threat data today is severely challenged.   The goal for CTI is to make that easier and simple for users and that means we as designers need to have the implementers involved and participating, not corralled and shamed.   If you take CVRF as an example, you can see that vendors do want a system and are willing to put it into operations and such, but the customer and the vendor need to have value out of it, not just another checkbox.



Peter Allor  
Senior Security Strategist, Project Manager, Disclosures
Product Management and Strategy
IBM Security
6303 Barfield Rd NE
Atlanta, GA 30328-4233
Mobile: +1-404-643-9638    
Fax:       +1-845-491-4204  

Inactive hide details for Joep Gommers ---06/24/2015 11:15:54 AM---Hi Patrick, Great point. I think part would be an effort of Joep Gommers ---06/24/2015 11:15:54 AM---Hi Patrick, Great point. I think part would be an effort of mapping the landscape on

From: Joep Gommers <joep@intelworks.com>
To: Patrick Maroney <Pmaroney@Specere.org>, Mark Clancy <mclancy@soltra.com>, Peter F Brown <peter@peterfbrown.com>, "tony@yaanatech.com" <tony@yaanatech.com>, Rich Struse <richard.struse@dhs.gov>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 06/24/2015 11:15 AM
Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
Sent by: <cti@lists.oasis-open.org>

Hi Patrick,

Great point. I think part would be an effort of mapping the landscape on
the one side, ensuring the tooling required to enable people to be
compatible (in addition to the standards and corresponding libraries) and
part certification to solidify and ensure compliancy. Especially the
latter option combined with hall of fame/shame (in a nice way :)) could
drive some tangible KPIs.. ?

Best regards,

On 6/24/15, 4:29 PM, "Patrick Maroney" <Pmaroney@Specere.org> wrote:

>I would agree with the position that Engagement subsumes Outreach.
>One open question is where Interoperability (as a tangible deliverable)
>fits into our stratgegy.
>Patrick Maroney
>Office: (856)983-0001
>Cell: (609)841-5104
>From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of
>Mark Clancy <mclancy@soltra.com>
>Sent: Wednesday, June 24, 2015 10:17:23 AM
>To: Peter F Brown; tony@yaanatech.com; Rich Struse
>Cc: cti@lists.oasis-open.org
>Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
>I agree with need this SC and am happy to help. I have been doing a lot
>this as part of my role as  DTCC's CISO in addition to my Soltra role.  I
>have been presenting/meeting in the US, Europe and Asia. I spend a lot of
>time with legislators, policy makers, and global financial regulators on
>information sharing and why automation is a key part of capablity needs.
>By the same token most of the challenges in the global context are not
>purely technical but national and regualtory impediments.  Not to say the
>technical things we are doing in CTI commitee in Oasis isn't also
>critical as it certianly is, but that if we only address the technical
>side of this problem we won't achieve the risk mitigation benefits we all
>So at some level what do we think "engagement" means vs. "outreach"?
>Mark Clancy
>Chief Executive Officer
>SOLTRA | An FS-ISAC and DTCC Company
>+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535
>UK mobile
>mclancy@soltra.com | soltra.com
>One organization's incident becomes everyone's defense.
>From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of
>Peter F Brown <peter@peterfbrown.com>
>Sent: Tuesday, June 23, 2015 6:37 PM
>To: tony@yaanatech.com; Rich Struse
>Cc: cti@lists.oasis-open.org
>Subject: RE: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
>Also agree with comment in an earlier thread that this SC ought to have
>engagement as a core focus rather than outreach - and that ought to be
>reflected in the name of any proposed SC.
>-----Original Message-----
>From: cti@lists.oasis-open.org [
mailto:cti@lists.oasis-open.org] On
>Behalf Of Tony Rutkowski
>Sent: 22 June, 2015 13:08
>To: Rich Struse
>Cc: cti@lists.oasis-open.org
>Subject: Re: [cti] CTI-Outreach Sub-Committee Nominations/Discussion
>Hi Rich,
>There is a great symmetry occurring here on a global scale.
>The first day of the annual cybersecurity workshop was held this
>afternoon here in Sophia Antipolis in France's approximation of Silicon
>Valley in the hills of Valbonne, France.  There are people here from
>around the world, but this afternoon was somewhat Euro centric with key
>officials describing what was essential to regional and national
>cybersecurity.  Perhaps not by coincidence, cyber threat intelligence
>sharing was at the top of their lists - along with security assurance.
>The four people who were engaged at this session were:
>o Florent Frederix who heads the key Network Information Security
>(NIS) initiative of the the European Commission and has some
>responsibilities at the Directorate level similar to Rich Struse's as the
>execution arm of the EU cybersecurity strategy - the analog of the White
>House's framework initiatives.
>o Chris Ensor who heads up cybersecurity work in the UK's CESG
>organization - also similar to Rich's responsibilities.
>o Marc Henauer of Switzerland's MELANI organization that is similar the
>principal Swiss threat intelligence sharing body.
>o Edri an Belmonte, who plays the lead role in this area in ENISA
>All of the presentations except Cris Ensor's are available at:
>In the discussion session following the presentations, speaking at the
>ETSI TC CYBER threat intelligence sharing rapporteur, I had the
>opportunity to explain the creation of the new TC CTI committee and how
>the platforms being pursued in CTI were proven best-of-breed models and
>structured information sharing specifications that provided an ideal
>match to each of their objectives.
>It was quite amazing how each of the parties - even in Europe - was
>rather independently pursuing similar objectives.
>We also discussed how the work of TC CYBER was to survey the global
>cybersecurity ecosystem and make use of the most successful existing
>standards and not pursue duplicative work.  Everyone seemed in agreement,
>and going forward, there seems like an excellent basis for convergence
>with the CTI work now getting underway.
>There will be further discussion at the workshop over the next two days
>as well as definitive actions at the TC CYBER meeting on Thursday and
>Friday.  It was a good beginning that was continued usefully over local
>provence wine and hors d'oeuves this evening (and setting a useful
>precedent for future TC CTI physical gatherings).
>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:
>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:

[attachment "CTI Standards Adoption.docx" deleted by Peter Allor/Atlanta/IBM]
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:

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:

Attachment: STIX TAXII Integration 2015-May22.pdf
Description: STIX TAXII Integration 2015-May22.pdf

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