OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Database Subcommittee


I am all for that.  I just want to make sure the work gets done as I believe it will help adoption.  

Bret 

Sent from my Commodore 64

On Jun 19, 2015, at 11:55 AM, "alexcp@mlsecproject.org" <alexcp@mlsecproject.org> wrote:

Maybe we could tweak the name and description of the subcommittee then?

I am getting on a flight now. Will probably be able to send something later.



On Fri, Jun 19, 2015 at 7:22 PM, Guy Wertheim <guy@comilion.com> wrote:

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. 



On 19 June 2015 at 19:50, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
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>




--
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]