CTI-TC Working Session

Size: px

Start display at page:

Download "CTI-TC Working Session"

Noel Sherman
5 years ago
Views:

1 CTI-TC Working Session Meeting Date: March 13, 2018 Time: 3:00 p.m. EDT Purpose: Weekly CTI-TC Weekly Working Call Attendees: Sarah Kelley Wunder Davidson Moderator ard Struse Piazza Thomson Drew Varner McDonald Ivan Kirillov Darley Emmanuelle Vargas-Gonzalez Keirstead Jordan Jane Ginn Recorder Agenda: Articulate options for upcoming Ballot on way forward Meeting Notes: Davidson I ll stand in for to outline the various options Key Question: How do we enable rapid implementation of features that are already text complete without committing ourselves to untested text? Members of TC have access of these drafts Difference between can implement and will implement Work that this just Committee work companies don t feel comfortable Implementing until document is voted on Made a point on where in process we designate a CSD I d like to make a point about the notion of a shared client We have to be careful If we build it, they will come - We should respond to market pressure Here is a Use Case others can use it as well We want to enable exactly that Let s take that as a given We had a PlugFest and many of the participants focused on simple Indicator sharing We need to get beyond that - CSD would help us get implementations There are two different scenarios et issues are one thing the Spec is different et forces do drive us forward We do start to develop when in draft if core

2 [Driving towards Ballot language] Include in STIX 2.1 CSD 01 ASAP with all text-complete Confidence I18n Location Malware Intel Note Opinion Course of Action IEP Assertion Grouping All new items MUST have two or more independent software implementations to be Part of STIX 2.1 CS Any new item that does not meet the definition of done within 187 (or longer if Agreed to by the TC) days of issuing the CSD, they will be automatically Pulled from the next 2.1 CSD [ & noted that the above was the Face-to-Face consensus] Would anyone on this call oppose to this I put out the cut bait and run proposal without these implementations What we are debating is move from a CSD to a CS in 6 months [Clarified his example] I could get behind the option above, if there were implementations I would strongly disagree with releasing without implementations We ve been working on 2.1 for over a year Let s get something out there I don t think we have unanimity Almost the same as the F2F Can someone send me a copy so I can put it on the screen A agree with I would not be in favor of issuing without out code When we go to CSD we will have breaking changes Is there anybody on call opposed to the idea that before we issue a CS, every Object included needs to meet the definition of done On this call we have consensus Yes, we put out a CS with the current stuff then, moving forward, implement new process Page 2

3 The list in my head is the different from yours What we discussed at the F2F was removing the ambiguity with clear criteria There is stuff that is in the middle in a grey area That is why the F2F approach was defined I think, going forward, that is the way to go but for now, let s have a vote on each Another way to word Option 2 is to say let s go out with a CSD for 2.1 and move on I d like some clarification on two independent or a reference implementation Have we defined that? We need two with just one, it may not highlight some issues Having two code bases shows that it can interoperate That greatly ups the bar as long as we have a process that encourages future features Showed the original text from the F2F Worked through an Option #2 adding the longer language Talked through some alternative scenarios with new timers Simple process It is quite pragmatic for this first start Why have people spend more time on this? This process has a number of goals: Minimize backward breaking changes Verify market need Have running code Also need a process where minority voices can present If we say 185 days [gave example of Opinion ] Argued for having a longer time period on ad hoc basis Purpose of this process is to describe a general work flow but we can make changes I would merge the two First Options you have now (optional longer time) Then, make s proposal Option 2 I would disagree with voting on all and not separate on Object-by-object I got the impression from earlier that there was a grey area We could vote on all We had this as a F2F consensus then, it broke down. Now we need to talk through the issue of how to reference the draft version My gut reaction we should leave out of scope for the Ballot that is a separate issue I was the person that started that discussion we had a lot of people comment on it You are going to have phases people are going to implement You have clients that have to be written a lot of different ones Page 3

4 When new changes there will be a difference between times when implemented Does that need to be in the Ballot I m at a stage where I just don t care any more For simplicity s sake we leave it as CDS 2.1 not include here We ve already run into these problems with 2.0 Sarah We need to have some answer, even if it is to do nothing If we leave it off coding to a CSD, pick up the phone Talked about his TAXII implementation and thousands of calls Sarah Then it is not production code I think they are separate issues leave them separate What we could do to address s concern Proposed an optional property To avoid interoperability problems Do that for 2.1 I think our valid move is to amend one or the other proposals to do this I would like some kind of text on the Ballot explaining the recommendation NOT To write production-level code to the CSDs There was another Option to include Extensions Do a separate Ballot on that If we combine it will conflate the two and people will Get confused What if we add some text to Option 1 The risk any organization takes by implementing a CSD implementation We can pull that text out of the IETF This sounds great to me The Extension proposal should be part of something else. I will post. ******************************************************************** Meeting Terminated Page 4

5 Appendix A Final Wording Agreed Upon by Call Participants for the Ballot Proposal #1 F2F Consensus + slight modifications (bolded) For STIX 2.1 and TAXII We will release a series of TC approved CSDs, where each CSD has a 2 week ballot period. 2. Each CSD may have some fixes that require breaking changes to previous CSDs as required 3. A feature has 185 days (6 months) post CSD ballot approval to show that it meets the definition of done; If it does not meet the definition of done it will be scoped out of the next CSD. 4. Before we do a CS we will ensure that all changes and new features meet the definition of "done". 5. At least 2 organizations will have running POC code with real data that can interoperate 6. We will have fully defined specification text 7. The feature is covered by one or more interop tests, either new or existing 8. A CS will be submitted for TC approval no later than 185 days (6 months) 187 (or longer if agreed to by the TC) after the last CSD that the TC approved. However, if something has to be removed we will reissue a CSD with only components that were approved and shown to be done in a previous CSD. 9. STIX 2.1 CSD 01 shall include: a. 2.0 Breaking Changes b. Confidence c. i18n d. Location e. Malware f. Intel Note g. Opinion 10. CSD-02 a. IEP b. Grouping c. COA d. Assertion e. Pattern Extension 11. CSD-03 a. Infrastructure 12. Informationally note the risk that organizations take when implementing draft specifications Proposal #2: Cut Bait Proposal 1. Declare STIX 2.1 to be "done", and start the process for it to be released as the 2.1 CS. 2. Each currently "text-complete" feature will be voted on, and only ones approved by the TC will be included. Development of dropped features and others will continue with STIX 2.2 using the new approved process as discussed in the January F2F. Page 5

CTI-TC Weekly Working Sessions

CTI-TC Weekly Working Sessions Meeting Date: Thursday, May 12 2016 Time: UTC 14:00:00 Purpose: CTI-TC CybOX Subcommittee Working Session Attendees: Agenda: Kirillov - Moderator Darley Wunder Rich Piazza