-
Notifications
You must be signed in to change notification settings - Fork 21
December 2014 Community Meeting
Around 40 community members joined the call for some portion.
The STIX team gave a quick status update on:
- Tooling, including python-stix. Ivan Kirillov introduced maec-to-stix, a utility to convert MAEC content into STIX content.
- Documentation, where there were no major updates
Rich Struse (STIX lead at DHS) announced the beginning of work on STIX 1.2, the upcoming minor release of STIX. John Wunder then presented the issues currently targeted for inclusion. The release is focused on implementing the report object as quickly as possible and as such the list of issues is minimal and includes only the report object and a few very minor non-functional changes.
The STIX team asked if anyone in the community thought other issues should be added to the release. At that time nothing was suggested, though later in the call it was suggested that the versioning vocabulary be added.
** Followup: The STIX team will formally announce the release on the STIX discussion list. At that time the community can review the list of issues targeted for inclusion and make suggestions. The release announcement will detail a timeline for when proposals will be issued and when the release will be finalized.**
Release progress can be tracked on the STIX 1.2 Milestone page on Github and the schema changes can be tracked in the STIX 1.2 branch.
Michael Walsh and Jasen Jacobsen presented a demo of java-stix and java-taxii. java-taxii is currently at the 1.0.0 release and can be downloaded from the releases page. java-stix has not been released, an announcement will be made when it is.
Sean Barnum led a discussion of IDs and versioning. The portion was intended to also cover de-duplication and revocation but there was not time. Sean will schedule a follow-up meeting to continue the ID/versioning discussion and to start the de-duplication/revocation discussion.
The primary discussion topics on IDs were:
-
Mandatory IDs: Several members suggested that IDs should be mandatory for most or all STIX constructs. There was somewhat more support for requiring them than for not requiring them but it was not unanimous. This discussion will be continued on the mailing list with a proposal from Soltra.
-
ID format: currently the GUID format is not required and the use of a prefix is not required. There was some discussion of whether either of those non-requirements should change but no strong consensus.
-
example.com ID namespace: the python-stix and python-cybox bindings default to use the example/example.com namespace prefix for generated IDs. Soltra feels that too many people don't change this ID namespace and therefore create poor content and would like to see the behavior changed. There was some discussion but no consensus on whether the bindings should simply issue a warning if it isn't changed or, alternatively, simply require the namespace to be set. Another option would be to use no namespace if none is set. The discussion will be continued with the community.
-
Use of IDs: several community members felt that it wasn't clear how STIX IDs were meant to be used. To help coalesce thought around this the STIX team will write something up and send it to the list for discussion.
Major topics were:
-
Whether both forms of versioning are truly required. Simplifying to either
@id/@timestampversioning or relationship versioning would mean less implementation burden. There was some concern about the complexity of requiring relationship versioning and the loss of capability from requiring id/timestamp versioning. -
The lack of a versioning vocabulary. This was brought up and noted as a potential work item for STIX 1.2. It will be discussed as part of the STIX 1.2 release process and as part of this conversation going forward.