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


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


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