I started my response thinking that we should step back and determine which use cases require defanging and/or obfuscation. That caused me to look at the STIX use cases [1], of which there are between ~50-~200 (depending on which list you use to count).
In doing that, I may have (re)identified a non-obvious issue that is tripping up the group.
To start, I’ll show the breakdown of use case categories from the wiki page (using the first list only; emphasis mine):
Analyzing Cyber Threats - 24 Use Cases
Managing Cyber Threat Response Activities – 5 Use cases
Managing Situational Awareness – 1 Use Case
Management of Content Over Time – 3 Use Cases
Sharing Cyber Threat Information – 14 Use Cases
The two biggest groups are “Analyzing Cyber Threats” and “Sharing Cyber Threat Information”, which I expected to find. However, seeing them laid out this way caused me to think that perhaps these two classes of use cases might be incompatible. Analyzing
Cyber Threats would seem to require a very human and document-oriented solution; Sharing Cyber Threat Information would seem to require a very automated and processing-oriented solution. Note: I am not the first person to bring this up.
Many have noted this group’s tendency to spend lots of time on seemingly straightforward technical discussions, only to have them re-opened months later. I feel that the underlying cause is the unmediated tension between the Analysis perspective and the
Automation perspective. And let me be clear: both perspectives have value, and both perspectives belong in the CTI TC. We just have to figure it out together.
I feel that the recent defanging discussion is caught in the weeds because of this underlying dichotomy. I feel that I have seen (generally) two perspectives: those who want something with strict processing rules and those who favor a more flexible solution.
Further, pick any other beaten-to-death topic and you can find a similar tension of perspectives – automation, or flexibility?
If we do not sort out these different perspectives, they will continue to plague our discussions in non-obvious ways, leading to frustration, exhaustion, and design-by-committee. Let’s get together and figure out how these perspectives can coexist peacefully
so that we can make the progress we all want to make.
Thank you.
-Mark
[1] https://github.com/STIXProject/use-cases/wiki
From: <> on behalf of "Kirillov, Ivan A." <>
Date: Thursday, February 25, 2016 at 1:10 PM
To: "Barnum, Sean D." <>, "Wunder, John A." <>, ""
<>
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
If we were to use a flattened representation for this, it would mean that every field that has a string as its base type would also need a corresponding field for the capture of observed encoding. Accordingly, this would entail MANY extra fields in the Object
data models, which doesn’t seem ideal.
