Re: [cti] Database Subcommittee

[Jerome Athias <athiasjerome@gmail.com>]

We will need to provide Guidance documents. Luckily, efforts put into
the documentation (like the idioms <- perfect simple basic use cases
examples), Specifications and UML model will definitely be helpful.
And make this thing as much unambiguous as possible.
A relational approach (performed years ago) just helped me removing
ambiguity and redundancy, and visualize the hierarchy and
relationships between the numerous concepts/entities/objects.

Regarding extension points, I get your point, but it is likely that
some STIX Reports would be used like "a newspaper where you would read
just the financial articles and ignore sport results"; depending on
interest, needs, context or capabilities/maturity.




2015-06-20 23:55 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>:
> Just to be clear  I believe the languages should be very expressive and when
> I say simple, that does not mean lack of expressiveness.  What I want is:
>
> 1) Ease of use "simple".  Meaning, there should be only one way of doing
> things and it should be super intuitive to do so.  We should not have to
> figure out and have discussions about how to map this basic thing  or how to
> do that basic thing.  It should just make sense.  And there should be only
> one way of doing it.
>
> 2) Common things should be super easy and clean, we should not have a lot of
> extra markup to support them.  Take my +1 example from the past.  The fact
> that I have 2000% markup for just a "+1 I have seen this too" is problematic
> when we need to scale.
>
> 3) I want a solution that is performant and super efficient.  I am not
> worried about the design for today, 10,000 indicators a day is not what I am
> thinking about.  I am thinking more of the 100 million -1 billion a day
> situation when STIX and TAXII is running on everyone's handhelds.  This is
> also going to impact the backend database systems and how we correlate and
> merge data.
>
> 4) The language should work very well in code. The goal of this project is
> for Machine-2-Machine learning, so therefore it needs to work well without
> any human interaction and it should be implementable in all forms of
> languages and delivery platforms.
>
> 5) We need to standardize on extension points and things we bring in to the
> language so that we all do the same thing. Infinite extensibility is bad and
> very problematic. People worry about introducing some other binding language
> and that we will be fracturing the market. Well I have bad news, we already
> have this problem today with extension points.  If you go though and
> implement a series of extension points (even OASIS CIQ) that I do not
> support, guess what.  I can not use any of your data.  Lets figure out what
> we are going to do and standardize on it.
>
> I want solution that is easy and simple to use.  This is the only way we get
> out of early adopter phase and move across the chasm in to mainstream
> adoption.
>
> 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 16:03, Patrick Maroney <Pmaroney@Specere.org> wrote:
>
> Don't disagree with the objectives in terms of identifying and addressing
> "Impediments to Adoption".  (e.g., "I've got 10 Billion Indicators on my
> Soltra-Edge Gateway, with 10,000s more arriving daily,, now what do I do
> with it?).
>
> However, I do want to emphasize what I think is a key point (and we circle
> around this point often when we engage in discourse on the merits (pro/con)
> of the inherent complexity/flexibility of expression in CTI*
>
> Some of the  foundational objectives of CTI were the definition and common
> adoption of a rich, highly expressive, flexible, and extensible [Language]
> for the [<== Inter-Exchange ==>] of Cyber Intelligence.  This approach
> provides the framework that we need to transform Cyber Intelligence from
> "My" Data Model to "Your" Data Model, while maintaing as much fidelity and
> context as is practical for a given Use Case.
>
> Now as a natural (and intentional outcome) as more CTI producers, consumers,
> "processors" (e.g. Vendor Products, Shared Community Tools and Frameworks)
> increasingly adopt common schematic representations, and/or common
> Taxonomies, the once ephemeral Inter-exchange vehicle/package becomes
> increasingly persistent as more and more producers, consumers, and
> "processors" can reliably process CTI in this (currently two-dimensional)
> "STIX" form.  This is a powerful outcome.
>
> However, this should not distract from the core objectives of expressiveness
> of any "thing" in the Cyber-Domain.  Whether it's the sharing of a single
> Indicator or the potential for new concepts like real-time dynamically
> evolving shared Analytics Models and Training Data Sets  (i.e., expressed in
> PMML and conveyed through STIX/TAXII).  These concepts require
> multi-dimensional semantic and temporal data models that need to be
> expressed with the same precision as XML.
>
> So [+1] for community developed shared tooling,  reference implementations,
> etc. using any available data format (Relational, NOSQL, Property Graphs,
> RDF...I still chew up a lot of raw CSV/TSV Table Data), but argue for focus
> on expressiveness in the language vs. focus and perhaps constraint of the
> language as some have argued for as a means to reduce complexity for their
> current Use Cases and/or World Views.
>
> Everyone is "right" including the "Less Filling" camp, So I'm just voting
> for the "Tastes Great" side.
>
> BTW: That's probably my third use of what may be American Colloquialisms to
> express underlying concepts in less than 24 Hours, so I'm self-declaring a
> "foul" on myself
>
>
>
> Patrick Maroney
> Office:  (856)983-0001
> Cell::     (609)841-5104
> Email:   pmaroney@specere.org
>
>
> * CTI:   (...it's really nice to be able stop typing STIX/CybOX/TAXII  ;-).
>
> From: <cti@lists.oasis-open.org> on behalf of "Jordan, Bret"
> <bret.jordan@bluecoat.com>
> Date: Friday, June 19, 2015 at 2:58 PM
> To: Jerome Athias <athiasjerome@gmail.com>
> Cc: Alex Pinto <alexcp@mlsecproject.org>, "cti@lists.oasis-open.org"
> <cti@lists.oasis-open.org>
> Subject: Re: [cti] Database Subcommittee
>
> And this is case in point of why I think you would be a great Co-Chair or
> Chair if Eric can not do it, for this work.
>
>
> 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 12:42, 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>
>
>
>
>