OASIS OpenEoX TC

 View Only
  • 1.  Motion to merge pull request #10

    Posted 05-12-2024 00:15

    Dear OpenEoX TC members,

    I hereby submit the following motion and request that if seconded and no objection received per this list before one week has passed on 2024-05-18 23:00 UTC to automatically carry. We will state the result via an mail to this list when the period has passed.

    I, Omar Santos, move to approve the pull request #10 ( https://github.com/oasis-tcs/openeox/pull/10) which contains our initial core schema draft. By merging this pull request, we will facilitate the schema review during our monthly calls and working meetings.



    ------------------------------
    Best regards,

    Omar Santos
    ------------------------------


  • 2.  RE: Motion to merge pull request #10

    Posted 05-12-2024 03:14
    Dear members,

    On Sun, May 12, 2024, at 06:14, Omar Santos via OASIS wrote:
    > [...] Dear OpenEoX TC members,
    >
    > I hereby submit the following motion and request that if seconded and no objection received per this list before one week has passed on 2024-05-18 23:00 UTC to automatically carry. We will state the result via an mail to this list when the period has passed.
    >
    > I, Omar Santos, move to approve the pull request #10 ( https://github.com/oasis-tcs/openeox/pull/10 ) which contains our initial core schema draft. By merging this pull request, we will facilitate the schema review during our monthly calls and working meetings. [...]
    >
    > Best regards,
    >
    > Omar Santos [...]

    I second this motion and like to amend this motion to take care to discuss and
    seek consensus on my comments on that schema draft at:

    - <https: github.com/oasis-tcs/openeox/pull/10#issuecomment-2046164162=""> and
    - <https: github.com/oasis-tcs/openeox/pull/10#discussion_r1562439747="">

    Cheers,
    Stefan.




  • 3.  RE: Motion to merge pull request #10

    Posted 05-12-2024 11:50

    Hi all,

    Apologies that I haven't been following this that closely and double apologies if you have already considered this. 

    Would you consider using JADN to specify your schema? JADN is the OASIS Specification for JSON Abstract Data Notation (https://www.oasis-open.org/standard/specification-for-json-abstract-data-notation-jadn-version-1-0-committee-specification-01/). 

    I believe there are some advantages to defining EoX at the information model level and then automagically deriving the data models from the information model rather than the other way round.

    Duncan



    ------------------------------
    Duncan Sparrell
    Chief Cyber Curmudgeion
    sFractal Consulting LLC
    Oakton VA
    703-828-8646
    ------------------------------



  • 4.  RE: Motion to merge pull request #10

    Posted 05-12-2024 11:52

    PS if you aren't familiar with JADN or information modeling, you may want to read https://docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.html which is a Committee Note on using JADN.



    ------------------------------
    Duncan Sparrell
    Chief Cyber Curmudgeion
    sFractal Consulting LLC
    Oakton VA
    703-828-8646
    ------------------------------



  • 5.  RE: Motion to merge pull request #10

    Posted 05-12-2024 12:40
    Dear members,

    On Sun, May 12, 2024, at 17:52, Duncan Sparrell via OASIS wrote:

    > PS if you aren't familiar with JADN or information modeling, you may want to read docs.oasis-open.org/openc2/imjadn/v1.0/imjadn-v1.0.html which is a Committee Note on using JADN.
    > [...]
    >> Hi all,
    >>
    >> Apologies that I haven't been following this that closely and double apologies if you have already considered this.
    >>
    >> Would you consider using JADN to specify your schema? JADN is the OASIS Specification for JSON Abstract Data Notation (www.oasis-open.org/standard/... <https: www.oasis-open.org/standard/specification-for-json-abstract-data-notation-jadn-version-1-0-committee-specification-01/).="">
    >>
    >> I believe there are some advantages to defining EoX at the information model level and then automagically deriving the data models from the information model rather than the other way round.
    >>
    >> Duncan [...]

    I have considered JADN already, but do not see real advantages for the actionable specification of EOX
    in the contexts of time-to-market, automation, and clarity and at this point in time.

    But, I see risk, adding another layer using another formalism based on
    Committee Specification level since 2021.
    (I know, that this may well be a good final evolution level for spreading an
    IPR guarded good idea - not always a need for an OASIS Standard).

    My assumption is, that the market will use JSON anyways or trivial mappings to
    YAML or XML.

    Thoughts in random order:

    After the initial TC meetings and by my personal experiences with "tools a supplier
    likes to stop supporting" I am sure, we have thousands of information models
    already floating around.
    I see as our magic trick we want to perform (successfully) that
    a simple and specific definition is agreed by the diverse membership and
    accepted later by the public and everyone agrees to the prose
    we write around it.

    Most standards in managing actionable security information tend to
    have abandoned XML in favor of JSON. I only know of DSS v2 which
    is still at CS level, that took the effort to describe the information
    model as well as data models for XML and JSON ... there will be others,
    but a) JSON is dominant, and b) most transforms between simple
    data models in one "format" to another are trivial.

    Given that we plan to only add mappings to a few terms there should
    be no extra effort in formulating the information model as part of the
    specification prose based on JSON Schema.

    We will get fast feedback from the members based on validatable
    examples that - as the discussions already showed - the members
    can relate to and that invoke use and abuse cases from the field.

    The CSAF and the SARIF TCs did that to my knowledge already nicely
    (defining the conceptual models in an actionable way as prose)
    explaining the use of the data model that the market asks for and uses.

    Cheers,
    Stefan.




  • 6.  RE: Motion to merge pull request #10

    Posted 05-12-2024 14:57

    We can agree to disagree. 

    I am not sure where the XML comment comes from as I couldn't agree more. I was the one advocating JSON in all these standards back when everyone else was advocating still XML. It's CBOR (and other efficient bit-level protocols which I'm now thinking are more the future as IoT takes over) where the main advantage comes in for multiple data layers on one information model - because I don't believe it's possible to do bit-level protocols without an information model. But the bigger advantage is 'upward' to the knowledge layer and priming for eventual AI feeds. Recall the info model is the layer between the data model and the knowledge model.

    I'm also not sure what is meant by the 'IPR guarded good idea'. There aren't any of those involved to my knowledge. All the work has come from the US DoD with no restrictions I am aware of, and there are certainly none in the OASIS spec. DoD created JADN because they have applications that need the bit-efficiency with protocols like CBOR, protbuf, etc. so want specs to have the option to be bit efficient. Efficiency is probably not as important a requirement for EoX.

    Could you elaborate on "my personal experiences with "tools a supplier likes to stop supporting" and what the implication is wrt JADN? It's a specification language. All it is effectively doing is agreeing how to specify schemas using JSON (as opposed to using ASN.1 or UML). Yes OASIS happens to have open source tools for things like converting the spec to property tables (which in our experience has made it much easier and less error prone for the specification/prose part of the process), but those are gravy not required and could go away.

    I'm fine if you think it's more work than it's worth so you don't want to use it. I'm not as fine with trashing it.



    ------------------------------
    Duncan Sparrell
    Chief Cyber Curmudgeion
    sFractal Consulting LLC
    Oakton VA
    703-828-8646
    ------------------------------



  • 7.  RE: Motion to merge pull request #10

    Posted 05-13-2024 14:14

    Assuming that a pull request will result in the schema serving as the basis of modifications moving forward, I would suggest that perhaps the terminology needs to be finalized, and also ask that all schemas be thoroughly reviewed before this happens.

     

    Langley Rock

    Product and Application Security

    Dell Technologies | Security & Resiliency Organization

    Langley.Rock@Dell.com

     

     

     

     


    Internal Use - Confidential






  • 8.  RE: Motion to merge pull request #10

    Posted 05-13-2024 14:22
    Yes indeed. It will serve as the starting point for the next step on getting the schema ready for a committee specification draft.

    Thank you �� 

    Regards,

    Omar Santos
    Security and Trust
    Cisco Systems
    PGP: 3AF27EDC






  • 9.  RE: Motion to merge pull request #10

    Posted 05-13-2024 14:24

    Thanks for the clarification.  As noted, I think it might be premature, but welcome (and may defer to) others' thoughts as well.

     

    Langley Rock

    Product and Application Security

    Dell Technologies | Security & Resiliency Organization

    Langley.Rock@Dell.com

     

     

     

     


    Internal Use - Confidential