[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Extension Process vs New Incident Object vs insanity
Folks â the multiple email threads on this email list on incident vs extension process vs 2.1 is insane.
There appears to be 5 conversations at once and I have to believe that most in the TC are confused on what is actually happening. This is not a good thing. The reason why *we* as a TC took the time to come up with a list of priorities was to help get everyone on the same page on the set of steps we collectively are trying to achieve.
Whether this is the right incident object or not or its following the âprocessâ I would suggest that
at this very moment it is only introducing further confusion and delay to what *most* of the TC agreed was the next step. We should focus on the agreed plan. Regarding the specific proposal from Gary. Many in the TC were discussing the need and desire to adopt an incident/event/group object and after many months of discussion a limited version of that
was the outcome for now and that was tabled in the queue for future work. If Garyâs org and the other organization (whats the name of that org?) have developed something they would like to adopt into the standard that overlaps with those previous proposals/discussions
then this new object needs to be reviewed in the context of previous proposals *not* in isolation. One of the items in the new extension process was exactly this issue on how to handle competing or different proposals. Until we have a new extension
proposal actually defined then just accepting the new proposal is ignoring all of the prior work trying to achieve an agreed data model that worked for more than just 2 orgs.
Allan From: Bret Jordan <Bret_Jordan@symantec.com> Gary, Thanks for all of your work on this object. Thank you for taking the time with your team to work on Malware and verify the changes that needed to be made for it to be useable. Your work has shown how valuable it
is to have implementations written before text is finalized. Further, you are absolutely right that the voted on ballot text does leave this open and does suggest that the process you have done is correct. The fact that you already have two different organizations working on this and writing code for it says a lot. I wish all proposals were this far along. So I guess it comes down to a question for the TC on scope.
Given that this proposed object is going to meet the definition of "DONE", should it be added in to 2.1 in the next CSD? Per the voted on the ballot text, you just need a simple majority for it to be included. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil> Sarah, Thank you for breaking down these points for everyone (including myself), and I do truly appreciate the hard work that leadership is putting in to get out the current CDS. I feel I should clarify the driving
forces behind this proposal. First, in CDS 1, we are not including a complete Malware object. This is partially because my team (as requested by the TC) implemented the Malware proposal object as part of the TCâs process. During this
implementation we uncovered what we believed to be a couple of issues with the design (which is the main purpose of doing an implementation). We also developed solutions to those issues, namely that the samples and results must use cyber observables to represent
the data and we proposed that the Malware object reference Observed Data objects that would hold this cyber observable data to have a consistent design pattern for including observed data. There was a request for additional work to be done to show that this
design pattern would hold for Infrastructure and Incident (Suspicious-Activity) objects. The proposal I put forth, shows how this design pattern would hold for a Suspicious-Activity object and therefore gets us one step closer to getting a Malware Object
included in the standard. The second reason is more selfish. One of the key missions of my organization is to receive and share Incident information with our partners. My leadership would like to move towards using STIX to share this
information, but we need an Incident object to do so. Understanding that this may not be the most important object for the rest of the community, we are attempting to do this work mostly on our own, but it would be nice if we can send out drafts of our work
and receive inputs from the community. We do need to understand what the correct path is to closure. I currently see 3 options. I am fine with whichever, but someone needs to inform us which path should be taken. 1.
Work on the Incident (suspicious-activity) object with any other interested CTI members, meeting the requirements for when an object is considered âDONEâ and work with the TC to have it included in the standard. 2.
Work on the Incident (suspicious-activity) object with any other interested CTI members, and use it as a custom object. 3.
Work on the Incident (suspicious-activity) object without any knowledge or inputs from other CTI members, and use it as a custom object. Please let us know what the correct path is.
In your last paragraph you stated that organizations that wish to add new objects or features should take one of three options, including âcomment on the email listâ. This whole discussion started because I
attempted to âcomment on the email listâ and was shut down. I understand that there are specific objects that the TC is focusing on, but my organization has a near-term need to represent this data and right now I am not sure what the correct method is to
receive feedback when the group is told we canât focus on this. Thanks, -Gary From: Kelley, Sarah E. <skelley@mitre.org>
There has been a lot of confusion around this situation, so let me try to clarify a few things.
The goal here isnât to stop innovation or to shut down the creation of new objects. We are trying to push very hard to get the enhancements process finalized so
that things like this proposal have a consistent process they can follow thatâs repeatable and works for everyone. We also need to keep in mind that the more objects we attempt to finish and push into 2.1, the further out it will push our eventual release
of a full committee specification (CS). For anyone/organization that would like to add new objects or features, I would urge you to join the #enhancements channel in Slack, join the mini-group calls (which
will hopefully be set up soon), and comment on the email list so we can get this process nailed down and everyone can moved forward together. Thanks,
Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 From: Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>
Rich, The decision to push an Incident object to an unknown date in the future was prior to having a process for introducing new objects. We now have a STIX enhancement
process. It was voted on by the TC. I am planning to follow that process and my expectation is that the TC should follow the process that was agreed upon as well and not unilaterally shut down the creation of new objects.
The following was decided at the face-to-face and had a ballot. A new object is considered Done when: Done - A new feature is considered done when it: 1: has at least 2 independent organizations using at least 2 separate code bases running at least POC code with real or semi-real data that can interoperate. 2: has all normative specification text is complete 3: is covered by one or more interoperability tests and at least the 2 POC implementations pass those tests. Posting for comments on the Suspicious-Activity object was to work towards completing task 2.
I have 2 independent organizations building 2 separate code bases to begin sharing these objects using real or semi-real data. We are currently working towards interoperability tests.
If you are now suggesting that the TC will not be following the processes decided upon, please let us know. This is not to detract from the hard work that the chairs
are doing to get out current CSD or the work that we are doing to complete other objects, but TC members should be able to work (and encouraged to work!) on the objects that are important to their organizations and should have a known path for getting their
work added to the standard as long as it meets the agreed upon process and fits a known gap.
If I have misunderstood your comments, please let me know and I apologize in advance if that is the case. Thanks, Gary From: Struse, Richard J. <rjs@mitre.org>
Gary, Thanks for taking the time to put this together but you may recall that the TC decided to defer a full-blown Incident-like object after STIX 2.1. We discussed Incident
for months and it was clear that we were just going round-and-round. Right now we have a lot of work to do in getting the objects and features that the TC agreed to deliver in STIX 2.1 defined, implemented and reviewed. I would therefore
ask that we focus on that. As we define the STIX enhancement process, we could use that to experiment with the object you have proposed. Thanks, Rich From:
<cti-stix@lists.oasis-open.org> on behalf of "Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil> Apologize for any confusion, To clarify, this is another attempt at getting an Incident/Event object through. I am really starting to feel that we should just go with the name âIncidentâ because
it is confusing everyone having âEventâ or âSuspicious-Activityâ as the object. We had originally stayed away from âIncidentâ because we were worried about the bad connotations with the word, but it seems like alternative names are just confusing everyone. Please let me know if people would rather that this be renamed âIncidentâ for clarity. Thanks, -Gary Ps. Document should now be updatable.
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Agree Sarah, somewhat.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]