-
Notifications
You must be signed in to change notification settings - Fork 21
August 2014 Community Meeting
Around 35 community members joined the call for some portion.
The STIX team gave a quick status update into the new documentation site, python-stix, other tools, and new Java bindings.
There was a question about the performance issue exporting XML, the team is working on a resolution.
The STIX team talked about changing the language used in profiles from the current set of "Prohibited", "Optional", "Suggested", and "Required" to that defined by RFC2119: "MUST NOT", "MAY", "SHOULD", and "MUST". Several options were presented:
- Do not change anything, continue to use the old language
- Continue to use the old language in the profile rows, but define them in the legend per RFC2119
- Use RFC2119 directly in the profile rows
There was not a strong consensus, but general opinion seemed to lean towards including RFC2119 directly in the profile rows despite the impact on clarity. Fixing the headings and understanding what the profile describes make it obvious; though at initial glance it is not as intuitive.
Action: The STIX team will send an e-mail to the discussion list with the options and an explanation
The team and community walked through the overview document that was sent out ahead of time. In cases where there was decent consensus for a change an action will be taken to update the profile before it is sent out again. In cases where someone commented but there was not strong consensus, a note will be made in the overview document indicating the comment but the profile itself will not be changed.
About halfway through the document it was brought up that we didn't really know what the scope of this profile was. Is it describing a producer sharing content out to subscribing consumers or is it describing a sharing community sharing information with each other? It was noted that these require very different things: versioning, sightings, and other features may be required in the latter but not the former.
Action: The team will send an e-mail asking the community which use case (or cases) they think we need profiles for. Individual profiles/overviews will be created for each version (ideally 2 at most, of which one should be a subset of the other).
No objections to what was presented.
Action: No changes made, but noted in the document the consensus on the call
One note that it may be useful on individual indicators.
Action: No changes to the profile for now, but noted that we may need to add information source to individual indicators (and potentially TTPs/Courses of Action)
No comments other than that @timestamp inclusion will be dictated by the versioning approach.
There was fairly strong consensus towards only allowing referenced relationships.
Action: No changes made, but noted in the document the consensus on the call
FS-ISAC requested that handling be allowed in individual components in addition to the top level. MISP project noted that they may need to mark things at more discrete levels and will look into it.
It was also noted that if handling be allowed in individual components that would create a duplicate capability: marking a component could be done either in the head of the document via the existing XPath or in the individual component via the Handling element in that component. The exception is observables, which can't be marked themselves and so must be marked from the head of the document.
Action: Updated the document and profile to indicate that marking is also allowed in individual components. Added a question about the (somewhat) duplicate capability and some options to resolve it.
There was a suggestion and one assent to prohibit Short_Description.
Action: Updated the document and profile to indicate that Short_Description is prohibited.
No strong consensus either way.
Earlier in the call FS-ISAC (Aharon) noted that @apply_condition means fields can appear in one or more list or by themselves. Prohibiting @apply_condition would prevent that and would also mean only Observable_Composition can be used to perform logical composition. There was one assent to this proposal later during this section.
Action: Marked @apply_condition as prohibited and included a note about the bandwidth/size downsides of this
There was a discussion of whether "Contains" was really necessary, including the MISP project indicating that they don't support it. The discussion, however, included with everyone agreeing that "Contains" is necessary. No other patterning conditions were suggested.
Actions: indicated consensus for status quo
Some confusion about how the information is presented and what it means.
Actions: did not change the suggested, some re-wording to make it clearer what is being suggested
No dissent.
Actions: removed separate question
Lots of discussion, where it was realized that the decision really depends on the use case that the profile intends to address. Sharing by an ISAC requires full versioning, simple sharing by producers/consumers may not.
Actions: will depend on which use case this is addressing. The answer is really fully dependent on that. After getting consensus on which ones need to be developed, this section will be updated w/ the appropriate answer.
Covered in the other section, no additional discussion.
Actions: Remove section as duplicative
MISP project noted that they used embedded packages, so that capability may be required. It was noted that if they do that, they will need to reference them (assuming we add it to this profile).
Actions: Noted the use of embedded packages in the overview
No real discussion, depends on the use case as versioning does
Some discussion, may also end up depending on the use case
Not enough time to discuss the remaining sections.
Actions: Will ensure the write-ups are sufficient to stand on their own