[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Database Subcommittee
Jerome (as he often does) gets this right in one (how about that - use a British colloquialism instead of a US one!). We just submitted a paper for publication at MILCOM looking at STIX/TAXII/CybOX versus IODEF/RID from the perspective of humans versus machines doing the processing. My guess is you can guess the end of the story: STIX/TAXII/CybOX is much better for machines. IODEF/RID is much better for people. Since the goal is for inter-machine communication, you get the point. It does mean there is a lot riding on VERY clear, implementable, interoperable specifications. Debugging this stuff is going to be a nightmare, more especially if the language is so nuanced there are dozens of ways of saying the same thing. > On Jun 19, 2015, at 2:42 PM, Jerome Athias <athiasjerome@gmail.com> wrote: > > The users have basically an issue managing and sharing information > because this information is stored in various ways and > representations. (because of different and non-interoperable > softwares) > A common language was needed. (just like we use English there, because > we don't all speak Chinese, Spanish, French or Russian, etc.) > > While we want humans to share information between each other, by using > machines, these humans (users) need a way* to talk to machines > (computers). > If this language is seen/perceived as too complex (complicated, large > or 'grammatically' difficult to learn before being able to make "valid > sentences with the available words and rules of the language") by the > users; we need to assist them*. > (Computer programming is there to assist.) > More than just a "database subcommittee", this subcommittee could > support Software engineering. > https://en.wikipedia.org/wiki/Software_engineering > > Relational databases represent, IMHO, a significantly interesting idea > to be explored to support and potentially enhance-extend the current > specifications, and facilitate understanding and Software development > around and using the STIX family of domain-specific languages (DSL). > > I think that relational database schemas based and designed on the > data format specifications -could- facilitate the use of 4GLs tools in > order to build or generate easily (faster) Graphical User Interfaces* > intended to greatly simplify the 'complexity' of the OASIS-CTI > languages. > Being a mature development approach (explored for decades) this could > provide benefits such like a larger pool of skilled and available > resources (developers). > > PS: Furthermore, the possible resultant application programming > interfaces (APIs), could be used for M2M communications too. > > > 2015-06-19 19:50 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>: >> Great points.. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> On Jun 19, 2015, at 10:43, Alex Pinto <alexcp@mlsecproject.org> wrote: >> >> 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. >> >> Cheers, >> Alex >> -- >> Alex Pinto >> Niddel >> http://niddel.com >> https://mlsecproject.org >> >> On Jun 19, 2015, at 6:26 PM, Jordan, Bret <bret.jordan@bluecoat.com> wrote: >> >> 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. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> On Jun 19, 2015, at 08:55, alexcp@mlsecproject.org wrote: >> >> 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? >> >> >> >> On Fri, Jun 19, 2015 at 4:28 PM, Jordan, Bret <bret.jordan@bluecoat.com> >> wrote: >> >> And I would nominate Jerome to Co-Chair this with Eric Burger. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> On Jun 19, 2015, at 02:14, Jerome Athias <athiasjerome@GMAIL.COM> wrote: >> >> +1 >> >> 2015-06-19 6:11 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>: >> >> 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. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> >> <signature.asc> >> >> >> >> 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> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]