As in code streams, it's typically optimal to maintain the integrity of particular specification bases. In Oasis fashion ,a particular element (STIX, CYBOX, TAXII) may be treated as distinct work streams. Within each, merge (STIX/CYBOX), bindings (XML, JSON, .or ..), or versions (1.3, 2.0, ++) can be addressed, managed, and completed.
In practice, multiple/parallel efforts within the element categories has not proven to be particularly effective. While we're all motivated to 'get on with it,' history suggests linearization of streams (STIX, TAXII, CYBOX) to be an effective means to advance each. Bindings (JSON, Xmas, ?) can be addressed in parallel.
| stsm | chief architect, infrastructure protection | division idt lead | ibm security systems | mobile +1.512.633.7711 | ofc +1.512.286.9254
"It is much less dangerous to think like a man of action, than to act like a man of thought." - Nicholas Nassim Taleb
I was trying to just spell out exact what I read from Sean. That we have one top level STIX working group, but then have sub-working groups (I think he called them "work product efforts") underneath. And each (using his terminology) "work product efforts" would have their own leadership to drive it and make sure it gets done.
I just do not see the STIX 1.x work going away anytime in the next few years. It will slow down, yes, but it is not going away. And we need a group of people that are committed to its success and making sure the investments made by people hold true.
The problem we have had over and over again on the old MITRE lists is discussions of future work and current work getting cross mixed and people getting all in a dither about the sky falling and the sun exploding. I feel like if we keep them on separate lists, then it will be easy for people to discern what is being proposed and talked about.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"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. Bret – I think your email below is the opposite of what Sean proposed, unless I’m reading it wrong.
If we have one big STIX committee then I would want the structure underneath it to represents separate sub-working groups with their own leaders, deliverables. and own working spaces. Can OASIS setup that kind of structure? I want the working groups to be focused on what they are trying to do. For example I could see a structure like:
STIX - Sean and ????? (maybe Joep or?? )
STIX 1.x - Someone from MITRE and Aharon
Given the community that Aharon already supports and needs to support, it is really important that he be involved in the STIX 1.x work. That is not to say that he is not also highly involved or a co-chair of STIX 2.x, but I feel he really needs to make sure that STIX 1.x does what it should.
In my mind it is also very important that chairs of working groups and sub-working groups have the time to actually spend on it. We have way too much work to do to have partially committed leadership. Director of Security Architecture and Standards | Office of the CTO PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." So, the typical way of doing this would be to have a single STIX SC with multiple work product efforts (e.g. STIX 1.x & STIX 2.0) underway with different editors and contributors. This provides the coordination and communication Aharon describes as well as the separate focus that Bret, et al, describe. This is true of almost all SDOs and I think still meets the objectives you are all conveying here. I can also see some advantage with regards to focus. Separate work stream with separate cadence, leadership expertise, etc might be helpful. J- The same people may be on both subcommittees. By breaking them up this allows each subcommittee to focus on different things. There are some people that will not care about STIX 1.3 and some that will not care about STIX 2.0 Director of Security Architecture and Standards | Office of the CTO PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I think a single STIX committee will ensure good communication between the folks working STIX 1.x and STIX 2.x. This may also improve interoperability between the two major releases. SOLTRA | An FS-ISAC & DTCC Company I am against the idea of creating a single STIX working group. STIX 1.3 and STIX 2.0 are two totally different animals and we do not want to bog one down to work on the other. I could see Aharon and Sean co-Chairing the STIX 1.3 sub committee. I would be good with that. Director of Security Architecture and Standards | Office of the CTO PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Yaana seconds the proposal
I am submitting a proposal to create a STIX subcommittee and nominate Aharon Chernin & Sean Barnum as co-chairs
The STIX subcommittee will maintain and steer the future direction of the Structured Threat Information _expression_ language.
- Create a roadmap for STIX 1.x
- Maintain and enhance STIX 1.x as necessary
- Create a roadmap for STIX 2.x
- Design and create STIX 2.x
- STIX Documentation
Information Security Services
U.S. BANCORP made the following annotations
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.
________________________________ Anthony Michael Rutkowski EVP, Industry Standards & Regulatory Affairs ________________________________