OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti-stix] Proposal - Top Level Relationship Object

Exactly my point...  The way I see it, there is nothing for the community to do in regards to STIX 1.2.1, that work is purely administrative for the Chairs.  They copy-n-paste and fix some basic formatting.  Once they finish that, then they will submit to the community to review and make sure they did not miss something.  But these documents should not really be any different from what we have today.  

So to keep the community engaged, the community should be working on STIX 2.0..  That means take an topic of concern and bounce ideas and solutions around, one at a time, until we come to some sort of steady state. Some times this will happen rapidly, especially when we can get key interested parties on all at the same time.  Once we get 80+% there, and things little down, we should document it as a proposal/potential proposal for the next version, add it to the wiki, and let others read over it and digest it.  I understand that it may take time for some to fully digest and understand what it is we are talking about.  That is fine.  And they may have great ideas or radical ideas to change said proposal, which is also fine.  The point is to get the major players to some sort of alignment, and then document it.  

The problem I have with the way things have been run in the past is we discuss things over and over and over and then they fizzle out and are left on the side of the road to die.  If we do not fix that problem in the community then the community might just give up on us.  There have been many that have said, we have already talked about this 4-5 times before and nothing has ever been done.  That needs to be fixed.  We need to prove to the community that we listen and we are wiling to push things forward...  And one of the outcomes of a proposal, in the end, might be community rejection of it.  But at least it went the paces. 



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Aug 1, 2015, at 06:33, Bush, Jonathan <jbush@dtcc.com> wrote:

I would agree, it sounds like the group has gotten off to a good start on this topic, but we sorely need to get this documented and distributed.  It has been very difficult to keep up with all of the email traffic on the topic, and would beneficial to I’m sure many to be able to see it all detailed in writing so we can take our time and digest it.  My guess is that some additional opinions would surface once we do that.
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Davidson II, Mark S
Sent: Friday, July 31, 2015 8:30 AM
To: cti-stix@lists.oasis-open.org; cti@lists.oasis-open.org
Subject: RE: [cti-stix] Proposal - Top Level Relationship Object
From my observational perspective, this group quickly came to a rough consensus on a form (fields, optionality, and meaning) for a top level relationship object. Hopefully we can all agree that this rough consensus exists, even if there remain some individual nits to pick (there may not – just saying).
I believe there are some fundamental truths about this topic, as well as pretty much any other future-revision topic on all the lists (CybOX, STIX, TAXII). I’ll list them for the sake of being explicit:

-          This rough consensus on this one topic does not yet take into account all factors that may impact it. As John Wunder noted, versioning, producers, IDs, and serialization are all interrelated. Future discussions can, and probably will, change today’s discussion.

-          We need to document our current line of thinking, or else it will be lost. This group’s current line of thinking may see substantial changes in the future, or it might eventually get discarded altogether. That is OK and it is a natural part of the creative process. The prospect of change should not prevent us from writing down where we are now, because capturing the substance of this discussion is an important step.

-          Right now, process is premature. This group is brand new, and we are still learning how to work together. Process exists to improve repeatability and defend against change. I see all three subcommittees as being in a brainstorming phase, and as such I think we want change and we do not yet care for repeatability. If we are successful we will reach a point where process will be desired and necessary, but I do not think process benefits us now, at least for these discussions.

-          Trust your committee members to be thoughtful, collaborative, and open minded. The corollary here is: be thoughtful, collaborative, and open minded! If we cannot achieve this, we will fall into argumentative, defensive positions; we will build political coalitions; and we will become our own worst enemy.
Coming back to something concrete: We do need substantive discourse (part of which has occurred, part of which is yet to occur); we do need Conceptual Models expressed in a broadly accessible manner (I have seen one UML diagram so far); and forward progress will certainly modify and enhance these conceptual models. We just need to make sure the maintenance of conceptual models is not overly heavy, so that they can evolve with reasonable quickness.
I’ll close with this thought. If somebody makes a suggestion, first attempt to frame it as “something additional to get right”, even if it sounds a little bit like “a reason to not proceed”. I have personally been practicing this over the past few weeks, and it has helped me become more open minded and collaborative. Trust that the members of this group all have the same goal and want to succeed; it is this trust that forms the bedrock of this community.
Thank you.
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, July 30, 2015 7:51 PM
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
The screen shot is from a UML model, with some extra data for context.  Further we are having substantive discourse about this topic, if there are things that are missing in the diagram, then please bring them up and fill in the gaps. I for one would love your feedback about how to make it better.
I think it is also important to note how this process should probably work, given the problems we have had in the past.
1) We should discuss things on the list and bounce ideas back and forth until we come to some sort of stead state.
2) At that point I can see the current ideas being captured and archived on the wiki as a proposal to be included in the next major release
3) Until such a time that the next release is done, people can continue adding to or making suggestions about a said proposal on the wiki.   But at least we will have captured it.  

In the past we would discuss things over and over and they would never get captured, and then they would get blackholed to die. What I am trying to do here, is get us to a point where it can resemble a proposal that can make it to the wiki.  From there we can continue discussing as people come up with ideas and requests, but at least we will have something down on paper.

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
On Jul 30, 2015, at 17:21, Patrick Maroney <Pmaroney@Specere.org> wrote:
I appreciate and support the desire to move forward, however I need to push back on this.  The Relationships Model is a critical gap that requires, in my view, substantive discourse and conceptual modeling. 
I suggest to the CTI TC that:
(1) We should be driving towards completion of the Conceptual Models expressed in:
  (1.1) UML
  (1.2) Some form of diagrammatic representation (form TBD).
  (1.3) Narrative Specifications in OASIS Standards document format.
(2) Progress forward should modify and enhance these Conceptual Models and supportive documents.
Patrick Maroney
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org
From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Thursday, July 30, 2015 6:17 PM
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
To: <cti-stix@lists.oasis-open.org>

Lets try and finish this up tomorrow, Friday.  I would like to see us start work on the Sighting Object the week after BH/DC.  
Outstanding Items: 
1) How do we handle an unknown start / end time?  Do we just leave it blank or do we actually put in "unknown" or a zeroed out date/time?
2) Are these values good for the Confidence Vocab?
3) What should the Type Vocab be, is this really needed?
4) How do we handle a more elaborate object marking?  Do we add a Marking_Detail as an object like I said earlier? 
5) Do we really need multiple targets?  Just trying to make sure John's question gets enough focus.
<Screen Shot 2015-07-30 at 16.15.55.png>
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 




DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]