[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
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>:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]