Re: [cti] Database Subcommittee / conceptual/logical model subcommittee

[Patrick Maroney <Pmaroney@Specere.org>]

Level-Set questions:

I've presumed the recent "legacy" community discourse on, and consensus
for, the priority focus on development of the STIX/CybOX UML Models was a
given in the transition to OASIS.  This in turn implies consensus that
these UML Models are key deliverables (as OASIS Standards) to the CTI TC
by the STIX and CybOX SCs.

Do we need to re-visit importance of the UML Models as near term
deliverables or is there consensus on this point?

Procedurally, I don't know if I should direct this to the Chair, make a
motion, or use some other method to establish/confirm consensus.  However,
in my view this is a critical aspect of the work we are beginning which
requires broad consensus in terms of specific deliverables for the CTI SCs
(and the sequencing/prioritization of same).

Patrick Maroney
Office:  (856)983-0001
Cell::     (609)841-5104
Email:   pmaroney@specere.org




On 6/24/15, 11:39 AM, "cti@lists.oasis-open.org on behalf of Jerome
Athias" <cti@lists.oasis-open.org on behalf of athiasjerome@gmail.com>
wrote:

>I'm a great fan of conceptual models!
>
>I skipped this step while reading the specifications to go directly to
>a data relational model, but I can see a lot of benefits producing a
>CMap, especially for new adopters (just because one picture can tell
>thousands of words). It's easy to share also (e.g. CmapTools)
>
>The issue that I think we would encounter, is not so much about the
>level of abstraction (multiple CMaps could resolve that), while there
>is not so much concepts there (in CTI). (I used to do CMap for complex
>systems)
>It is mainly, AGAIN, related to the taxonomy.
>You could see that when dealing with the extensions points, figuring
>out what would be the most appropriate standard/specification to map
>CTI to. Things that are around CTI and that you have to deal with,
>such like Assets, Vulnerabilities, Exploits, Shellcodes, etc.
>But I assure you that it's fascinating ;)
>And while all these things are somehow linked together, it makes quite
>difficult to make choice to -split- this into multiple models.
>(you could look at it in many ways, like asset-centric, risk-based,
>vulnerability-based, etc.)
>
>My 2c
>
>
>2015-06-24 18:18 GMT+03:00 Cory Casanave <cory-c@modeldriven.com>:
>> There is certainly a value in a DBMS capability, perhaps one that can
>>be implemented across multiple technologies. This may then also relate
>>to the "conceptual model" initiatives which have already started. A
>>conceptual model can bridge the exchange and repository viewpoints and
>>also allow for greater flexibility in implementation technologies. We
>>have had great success in generating schema as well as transformations
>>between them from models.
>>
>> With this in mind perhaps a conceptual and/or logical model
>>subcommittee should be considered. Depending on the approach this could
>>provide some of the value that is being sought for the database. A
>>separation of concerns would allow for the definition of the database in
>>models with implementation in one or more chosen technologies. Such
>>implementation would probably be another activity.
>>
>> There is some grey area in what people call conceptual and logical
>>models and the levels of abstraction each represents. For me (and many
>>others), a conceptual model is a model of how the world is understood -
>>it is then a model of the terms and concepts of the world, not a data
>>model. An "instance" of a person in a conceptual model is a real person
>>- not data. A logical model is then a technology independent data model
>>about the world where choices are made as to structure and
>>representation. An "instance" of a person in a logical model is data. An
>>initial activity of a conceptual/logical model subcommittee could be to
>>define the purpose, scope and appropriate level of abstraction.
>>
>> Of course the model activity is just as relevant to the exchange schema
>>and can help make them more understandable as well as provide a basis
>>for support of other technologies (essentially a model driven
>>architecture approach).  This works best when the models are the
>>normative definition and technology schema are generated from them.
>>Since this tends to introduce more change (as well as more consistency),
>>it would best be coupled with the second phase.
>>
>> There has already been work on conceptual models this direction seems
>>consistent with the communities direction. With the above in mind we may
>>want to consider a conceptual and/or logical model subcommittee.
>>
>> Regards,
>> Cory Casanave
>> Representing OMG
>>
>>
>> -----Original Message-----
>> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On
>>Behalf Of Jerome Athias
>> Sent: Wednesday, June 24, 2015 7:06 AM
>> To: Eric Burger
>> Cc: cti@lists.oasis-open.org
>> Subject: Re: [cti] Database Subcommittee
>>
>> I wonder if providing consumer-oriented XQuery examples (maybe with the
>>STIX idioms) would help providing guidance and test/validation cases
>>
>>
>> 2015-06-22 14:20 GMT+03:00 Eric Burger <Eric.Burger@georgetown.edu>:
>>> 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.
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
>---------------------------------------------------------------------
>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
>