|I understand what you are saying, but that is way too complex... Think about this from a Product Manager standpoint, not an academic stand point, further the whole point of doing this is for product managers and consumers. |
Product Managers are going to ask "how much of this do I need to implement to be compliant and do what my customers are asking for". Customers want some level of assurance that a vendor has actually implemented some level of support so they can make buying decisions and interoperability decisions.
Just like Common Criteria, vendors will start using their level of support as a stick to say they are better than some other vendor, which is good for us. This means, that more and more vendors will support more and more of STIX.
Yes I know we are also talking about CyboX and that CybOX can stand on its own and can be used by other things. However, in the real world when we get across the chasm and gain of mass adoption, people will not care, and it will referred to as just STIX. Because from the outside, assuming you did not know anything about it or its development, you would ask yourself WHY is it called two different things when it is just the same thing.
We need a very simple set of "line in the sand" markers of support. When you look at the list of products that claim they support STIX, right now we have NO idea what that means. Nor does any consumer or user have any idea what that means. Linksys for example, could add the ability in their interface for their home router to see the configuration of the admin page in STIX XML and they could then claim, legally, on all of their documentation that they are STIX compliant.
Building a simple set of "line in the sand" markers will also drive adoption, especially if the first level is relatively easy to get to. This will be something that a product manager can safely commit to his/her board of directors.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
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.