| 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.
Then include: 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 ð Rich P. -- Rich Piazza Lead Cyber Security Engineer The MITRE Corporation 781-271-3760 <image001.png> <image002.png>
|