-
Notifications
You must be signed in to change notification settings - Fork 21
March 2015 Community Meeting
John Wunder edited this page Mar 12, 2015
·
5 revisions
- The MAEC community is currently working towards MAEC 5.0. See: http://maec.mitre.org
- Mark is putting together a document template that can be used to create TAXII Message Bindings. See: http://taxii.mitre.org
- Tools - See http://github.com/STIXProject for more info
- There was a discussion about whether the approach was digging STIX farther into the hole of XPath markings
- Aharon and others are concerned that it creates a defined usage for marking under the major object level which hasn’t really been expressed yet.
- Sean said that the use case has existed for awhile, we’re not creating it but rather addressing it.
- XPath data markings are also not doable in JSON, what’s the solution there?
- Bret will explore potential solutions and present at the next community meeting
- It was also suggested that language support would also be a use case for multiple descriptions. MITRE felt that this would be better addressed in a consolidated fashion in 2.0 and Pat agreed. Gary pointed out that it might even use the same “marking” approach as handling does now.
- Consensus: For the description field itself, consensus seemed to be that we should add the field per the proposal and address both data markings and language support more generally in 2.0.
- There was a fairly length discussion on versioning. Most people feel that it needs to be re-considered in the 2.0 release, potentially with the CRUD concept that Pat has outlined.
- Multiple people expressed that the simpler the vocabulary the better
- Sean pointed out that the verbs in the current proposal were derived from previous discussions.
- Consensus: The general tone of the conversation by the end of the discussion seemed to lean towards having just “updates” and “deletes” but there's probably still more discussion to have.
- There was no further discussion on the report object itself. Aharon agrees that there are use cases for nested packages so long it’s clear that there’s no context suggested by that, it’s just a convenience, and so there's good consensus on that proposal.
- Consensus: We'll confirm on the mailing list and if there are no objections close/reject the proposal to prohibit nested packages.
- There was a long discussion about embedding content within reports, however it didn't seem to move things in either direction:
- On the DISALLOW side
- Fewer options are better than more options
- We should be encouraging people to create good content (read: has IDs) and only allowing references does that
- Eventually the entire ability to inline content should be removed so this is a step in that direction
- On the ALLOW side
- It’s consistent with the way STIX does things now.
- It offers more flexibility to content producers
- IDs are already strongly suggested
- Aharon offered that he would strongly prefer to DISALLOW it but could live with either. He also suggested that we could ALLOW it but require IDs be included on all content within the Report.
- MITRE team pointed out that that might be hard to validate.
- Consensus: Because we did not reach consensus on the call we'll post these notes to the mailing list and continue the conversation there.
- On the DISALLOW side
Desiree Beck and Rich Piazza from the MITRE STIX team went over an example of the representation-independent specification and UML model that are being developed.
- They will be published to the Github specifications repository as they’re ready.
- At this point anything out there should be considered DRAFT.
- Bret and Pat were both very happy to see them.
Gitter.im service is now available off the schemas repository. Link.
- Pat pointed out that this is a third-party service that will receive details of your Github account so if you have sensitive data tied to your Github account you may want to create a new one to use with it. That said, we haven't had any issues (or we wouldn’t have set it up of course).
- MITRE team members will be on the chat and anyone in the community is encouraged to join. We welcome questions/discussions about the schemas, specs, releases, python-stix, other tools, etc.
- The link is available from the README of the schemas repository as well as directly here: https://gitter.im/STIXProject/schemas
The Github wiki is also available for the community to use. Link.
- We’ve started tracking ongoing discussion via wiki pages, starting with versioning. Everyone is encouraged to edit these to add your thoughts or to create new pages.
The STIX schemas issue tracker is used to track current and upcoming issues. Link.
- It’s also open for community members to add issues, add comments, etc.
- Marlon pointed out that often the discussions on the mailing list can take odd turns and we never get back. He suggested that people create an issue in Github Issues for the diversion and then send that back out to the list. That way it can be tracked separately.
- The team will be at RSA and will almost certainly be arranging some kind of meetup
- We'll be sure to announce that on the list when it happens. We'll also send out a news article with a listing of the talks that explicitly mention STIX/TAXII.
- Bret and others suggested actual working sessions, including an offer to hold one at Georgetown.
- The MITRE team could not commit to attending those.