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 ;-).
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."
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>
|