|I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your products will seamlessly fit into the ecosystem, which makes the product more attractive to customers.|
We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build.
So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite a product needs to have to meaningfully address the use case.
+1 Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues.
Patrick Maroney <Pmaroney@Specere.org
Wednesday, July 8, 2015 at 12:45 PM
"Barnum, Sean D." <firstname.lastname@example.org
>, Steve Cell <email@example.com
>, Terry MacDonald <firstname.lastname@example.org
"Jordan, Bret" <email@example.com
David Eilken <firstname.lastname@example.org
>, "Struse, Richard" <Richard.Struse@HQ.DHS.GOV
>, Eric Burger <Eric.Burger@georgetown.edu
Re: [cti] CTI TC Adoption and Interoperability SCs
I may be missing something here and have been hesitating throwing in my usual advocacy for STIX Profiles [Plus]
as a method to help manage complexity, interoperability, different world views, use cases, etc.,
We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex. The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these
and iterate over them to revise or create new Community "Standard" STIX Profiles.
Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase:
(1) The CTI language should be precise both in terms of how one expresses any given "thing" and similarly precise in how one interprets "things" expressed in this manner.
(2) The language should (must?) limit the ability to represent a given "thing" in multiple ways.
I have always agreed with these objectives.
However, I still see extended STIX Profiles (Human and Machine readable)
as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex), and to describe methods and any assumptions (e.g. Tokenization,
TLP Mapping Transforms, COA).
Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains. Many variations of these CTIX Communities/Operational Domains
will be established. So from these perspectives there is never any intent to forge "One Ring to Rule Them All". Understand there are also those quite legitimately seeking a unified "STIX" package (although I might quip that Einstein was quite legitimately
seeking similar unification ;-).
Also note that I've argued for the addition of a very explicit form of STIX Profile: I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand. this proposed form of STIX Profile can be extremely simple and only needs to enumerate
what I can (1) Convey and (2) Consume. This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e., My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing,
(4) Reject Entire Package, (5) Hold and Contact Source. However, Key take-away here is:
You only describe what you need and nothing more.
Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration :
Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels. As she explores, try's new things, makes mistakes, learns, and continue to expand her horizons, we can eventually remove
the Training Wheels.
I was planning to wait for the CTI TC re-organization dust to settle before re-engaging the community in discourse on extending STIX Profiles. However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability,
maturity levels, impediments, to adoption, etc.
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.
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.,
- Indicator Characterization/Sharing
- Host-based Indicator Sharing
- Level 1: Basic Context
- Level 2: Level 1 + Supports Sightings
- Level 1: Supports File Object
- File_Path field
- Hashes field
- Level 2: Level 1 + Supports Windows Registry Key Object
- Network Indicator Sharing
- TTP/Malware Characterization Sharing
- Basic TTP/Malware Characterization
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:
- Level 1: minimal support – very basic, incomplete support
- Level 2: partial support – typical/average support (with what is commonly expected with regards to the use case)
- Level 3: full support – fully supports the use case, in all facets
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.