Yes, describing how to store STIX in a database is not what standards are all about, but this might be the most efficient way to make this standard thrives.

This database doesn't need to be obligatory rather than a suggestion so potential implementers would have a better starting point.

There are many "standards" for threat sharing, we should do whatever we can to make this the last one.

BTW, couldn't agree more about the "...if there is more than one way to generate the the same piece of information on the STIX format, we would have failed to describe an actual interoperable standard." since I've encountered it myself.

Ok, I think I get it now. By focusing on the “database” part of it, I became a bit confused. Since the standards describe a data definition format, the trivial and obvious solution would be to translate that to a relational database verbatim. I am glad
I am not an investor on these startups that are struggling to do something like that. ;)

However, the larger implementation problem is a good one to address, in my opinion. What I have seen people struggling with is how to efficiently translate the data they have INTO the STIX data format. Say I have an IP address indicator from the “Tap-dancing
Penguin” threat actor. what is the correct, unambiguous path, to translate that to the equivalent STIX object. Do I need to create an Observable? Only an Indicator? Can Threat Actors be linked directly to Indicators or do you need to have a Observable to do
that?

However, I STILL think that having something along the lines of these “suggested recipes” of normal use-cases should be a part of each subcommittee. Because if there is more than one way to generate the the same piece of information on the STIX format, we would
have failed to describe an actual interoperable standard.

Don’t get me wrong. I LOVE this idea of making it more developer-friendly, but I want to make sure we are focusing on the right things here.

The subcommittee would create work products, documentation, and best practices for using STIX, TAXII and CYBOX. As I talk with start-ups and other implementors / integrators, I hear a common theme. "How do we actually store this data and what is the best
practices for doing so?". This working group, in my mind, would address those issues and report back to the TC with recommend best practices, examples, and documentation on how to build the databases to actually make use of STIX, TAXII, and CYBOX.

You could even put in scope the query functions that should exist for each language and how best to do those. It would be nice to have a working group focused on this effort. And IMHO, I think this would help get a lot of new people to STIX and TAXII up
and running more quickly.

I need some more time to structure a more complete response right now (trying to catch flights out of Berlin) but I am really struggling to understand how can this possible be on the scope of the standard.

Could you please elaborate how the actual database format would be relevant for the standard discussion?

About 9 months ago or so we tossed around the idea of setting up a
Subcommittee / Working group to look in to database requirements and build
photo-type examples for storying STIX and or TAXII data. I would like to
propose that we do that here at OASIS and I would nominate Eric Burger to
Chair this committee. He is after all a professor of computer science that
teaches database theory... I think we would be very lucky to have him run
this group.

This e-mail message and any files transmitted with it contain legally privileged, proprietary information, and/or confidential information, therefore, the recipient is hereby notified that any unauthorized dissemination, distribution or copying
is strictly prohibited. If you have received this e-mail message inappropriately or accidentally, please notify the sender and delete it from your computer immediately.

--

------------------------------

This e-mail message and any files transmitted with it contain legally
privileged, proprietary information, and/or confidential information,
therefore, the recipient is hereby notified that any unauthorized
dissemination, distribution or copying is strictly prohibited. If you have
received this e-mail message inappropriately or accidentally, please notify
the sender and delete it from your computer immediately.<signature.asc>

--

Guy Wertheim, CTO
Comilion Ltd.

This e-mail message and any files transmitted with it contain legally privileged, proprietary information, and/or confidential information, therefore, the recipient is hereby notified that any
unauthorized dissemination, distribution or copying is strictly prohibited. If you have received this e-mail message inappropriately or accidentally, please notify the sender and delete it from your computer immediately.