[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
+!
I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading.
sean
From: <Kirillov>, Steve Cell <ikirillov@mitre.org>
Date: Wednesday, July 8, 2015 at 8:35 AM To: Terry MacDonald <terry.macdonald@threatloop.com>, "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: David Eilken <deilken@fsisac.us>, "Struse, Richard" <Richard.Struse@HQ.DHS.GOV>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold
with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object?
Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).
Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or
CybOX as appropriate ). I could envision this as a taxonomy, e.g.,
Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go down this road of per-use case based maturity levels, I’d recommend limiting
the number of levels to 3 to keep things sane:
Regards,
Ivan
From: Terry MacDonald <terry.macdonald@threatloop.com>
Date: Tuesday, July 7, 2015 at 7:26 PM To: Bret Jordan <bret.jordan@bluecoat.com> Cc: David Eilken <deilken@fsisac.us>, Richard Struse <Richard.Struse@HQ.DHS.GOV>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] CTI TC Adoption and Interoperability SCs I agree. I like the way this is headed.
I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible
with the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support
all CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant 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.
On 7 July 2015 at 06:55, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]