CTI STIX Subcommittee

 View Only

Re: [cti-stix] "Assertion" object and Working Call

  • 1.  Re: [cti-stix] "Assertion" object and Working Call

    Posted 12-13-2017 13:39
    Hi Sean; To date we have had significant
    consensus on several consecutive working calls (4) leading to the current
    approach in the working concepts document. I would put out a call to the TC - if
    there are any others in the TC who agree with Sean's point of view, *please*
    make your voice heard. In addition, as an update to the TC
    - The non-unanimous consensus on the working call yesterday (notes taken
    here - https://www.oasis-open.org/apps/org/workgroup/cti/document.php?document_id=62220 )
    was to move the current proposal from Working Concepts into the main 2.1
    document for finalization, with the only remaining work item to be to update
    and expand upon the examples. Discussions on this call were as follows: - We discussed renaming the object.
    Given no strong opinions, we took a vote of those attending the all. No
    one voted to change the name, so the concensus was to leave it as "assertion" - We discussed valid_from and valid_to
    with respect to STIX versioning. Brett gave strong use cases for them.
    Concensus was to keep them. - We discussed re-naming valid_from
    and valid_to. Exampes were given by Sarah about how we already have many
    examples throughout STIX spec of valid_from and valid_to (as well as other
    ways to describe time ranges). Concensus was to leave as-is - We discussed Brett's rationales addition.
    Concensus was that although we agree we need the concept, this is not well
    understood at this time and is likely going to have to be tied to categories,
    and we will not include in the 2.1 proposal. - We discussed how some of these things
    needed to be added to the Github issues tracker for post-2.1 work on this
    object. - We discussed how we need more verbose
    examples, especially on how this object works WRT STIX versioning. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security "Things may come to those who wait, but only the things left by those
    who hustle." - Unknown From:      
      Sean Barnum <sean.barnum@FireEye.com> To:      
      Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
    "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:      
      12/12/2017 04:02 PM Subject:    
        Re: [cti-stix]
    "Assertion" object and Working Call Sent by:    
        <cti-stix@lists.oasis-open.org> I will not be able to make the working
    call as I continue to be buried.   I would like to restate that while I agree
    with the importance of supporting the use cases that Jason has raised for
    this object, I strongly disagree with the structural approach currently
    being taken.   Making this a specific property (on specific
    SDOs) with a specific type that lists specific sorts of asserted categorizations
    we are painting ourselves into a corner that will be very difficult to
    back out of. While some might characterize this as the
    simple approach for now I would disagree. I think it is a much more complex
    approach.   Making Assertion an SDO and making all
    of the different kinds of categorization assertions extension types that
    can be hung from an Assertion we make this far more flexible and future-proof
    and far more efficient.   I know that my cries are falling on deaf
    ears and will likely be ignored but I felt it important to once more make
    this opinion explicit. I have high confidence that this will require
    significant work arounds for real-world users in real-world scenarios as
    things get more complex. I believe this will require revisiting
    and revision in the future.   </my_two_cents>   Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com   From: <cti-stix@lists.oasis-open.org>
    on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Monday, December 11, 2017 at 11:03 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] "Assertion" object and Working Call   Hello all. On the working call this
    week, we are going to be attempting to bring the discussion around "Assertion"
    to a close. As a reminder here is a link to the current up-to-date proposal: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.qxvz3vox3ksj There were two remaining points of concern after the last working call - There was a request by some participants to rename the object, but there
    were few proposed alternatives. The only suggestion I have seen thus far
    is re-naming the object itself to threat_level. The reason we went with
    a neutral term from the beginning, is because in the future you will probably
    want to assert *other* things that do not have to do with threat - for
    example, categories for URLs etc. So myself I would not like a name with
    the word “threat” in it. Keeping that in mind, if you are a stakeholder
    who wants this object to be renamed, please bring some suggestions to the
    working call. - There is a suggestion about valid_from and valid_to. Neither of these
    are in the document currently.        - There was a discussion around if these fields
    are needed when STIX versioning is taken into account... IE shouldn't assertions
    in the past have been expressed via previous versions of the object.  
                 - If kept there was a request to rename valid_from
    and valid_until to align with start_time and end_time to align with some
    other STIX objects.         - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security "Things may come to those who wait, but only the things left by those
    who hustle." - Unknown This email and any attachments thereto may contain private,
    confidential, and/or privileged material for the sole use of the intended
    recipient. Any review, copying, or distribution of this email (or any attachments
    thereto) by others is strictly prohibited. If you are not the intended
    recipient, please contact the sender immediately and permanently delete
    the original and any copies of this email and any attachments thereto.