HI Allan,
Iâve been involved in other things, so Iâm sorry I havenât responded until now.
I think use cases should be a large part of a best practice guide, but I donât think it should be its only focus. Itâs no coincidence that the outline I suggested resembles the specification. My point of
view is that whomever (developer, designer, content producer, etc.) has a question about best practices might not have a particular use case in mind, but just wants advice on how to create labels, give a confidence score, or how an opinion is different than
a note, etc. When I take on one of the roles mentioned above â one of the first places I look is the specification. Having a best practice guide, at least partially organized around the specification layout, seems to lend itself to further understanding
and clarification.
Additionally, it is difficult to get coverage by organizing only around use cases.
However, I also see the use cases as an outgrowth of the structure Iâm suggesting.
To summarize, I agree with your suggestions, but for me at least, the creation of use cases comes after we have an initial draft of the document.
Rich P.
From: <cti@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Date: Monday, November 30, 2020 at 6:25 PM
To: Rich Piazza <rpiazza@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] Re: [cti] STIX Best Practice Guide
Rich - Hereâs my input.
The current suggested structure looks like the current STIX specification layout and not necessarily how developers or product engineering design/refinement occurs.
Suggestion: Consider structuring the best practice content based on
use cases, where you explain a high-level use case and what are the key requirements attempting to be met by the use case.
This helps identify to the reader whether they care about that particular use case or they can skip.
It helps map to their particular issues more easily if they can identify with a use case description.
a) design choices when modeling; mapping and implementing STIX or TAXII
b) functionality choices (what features you get from choosing a particular design choice vs other)
c) what set of features across STIX/TAXII are included in the use case
d) scalability considerations (how to scale a solution for the particular use case and whatâs important to keep in mind)
e) interoperability trade-offsâ.etc.
For example. Currently the proposed content suggests a section on timestamps. Time is a broad topic but incredibly important when it comes to distributed systems. But there are different aspects of time that matter to different use
cases. It is also the fundamental aspect of how versioning takes place in STIX; its how TAXII tells other systems whether there is new data on the server to pull downâ.etc.
*But* a reader not knowing STIX or TAXII would probably not know that. Therefore they wouldnât know to look at the timestamp best practices.
Use Case:
Determining new or updated intelligence records on a TAXII server since a particular time
Related Interop Persona:
TIP (â.list other interoperability persona)
Category Labels:
Scalability, Performance, Data Modeling, STIX, TAXII
Best Practice Key Benefits:
Avoid having to read all records in a collection repeatedly and efficiently return only the delta set of records since last checked by the client.
Description:
<describe the general scenario of what a client does to read records from TAXII and then how time can be used to improve efficiency of that use case>â.
If you structure this way then you can still label/tag use cases based on the terms from the specification as an additional indexing mechanism so that people who know more specifically what theyâre looking for can search the content that
way also.
DHS has asked MITRE to organize the writing of a best practice guide for STIX. We have some basic ideas, but were hoping for some input from the community. In many calls, emails and in Slack â members of
the TC would often say something like â âthatâs a data quality issueâ, or âproducers should follow certain guidelines when creating this content (e.g., naming labels)â. Those are among the kind of things this document would capture.
DHS sees this document as a possible OASIS CTI TC note, so all content would be intellectual property of OASIS and the TC. As a google document, anyone on the TC can contribute.
Here is an outline MITRE put together. It is just a âstrawmanâ. The way to organize the document is open to discussion.
The subsections are possible topics for best practices that we thought of.
Any suggestions would be welcome 😊
Lead Cyber Security Engineer