|As a reminder the docs are also located here:|
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
<STIX2.0-draft3-core.docx><STIX2.0-draft3-objects.docx>---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Thanks everyone for the great comments, feedback, and (especially) suggestions on STIX 2.0 drafts 1 and 2! As Rich Struse mentioned in his e-mail last week, we’ve had a TON of activity and the specification is significantly better as a result. Now that comments have tapered off, the editors have decided to release STIX 2.0 Draft 3. Given the amount of feedback this will be a decent change from Draft 2: - Significant refactoring of the introduction - Update to marking definitions to remove versioning - Added the FIRST IEP marking definition as an option - Cleaned up Threat Actor, Intrusion Set, and Campaign - Cleaned up Sighting and Observed Data - Added Infrastructure object - Improved Malware object (some minor work remains) - Tightened fields/relationships on Incident object to a small stub - Improved vocabulary descriptions - Relationships tweaked and cleaned up - Miscellaneous editorial changes - Removed version_comment Given our timeline, Draft 3 will be the final draft of STIX 2.0! To focus on the finish line, here’s a few guidelines for review: 1. At this point we will not be considering any new additions to the specification. There’s just not enough time to discuss anything new. 2. Focus your review on objects, properties, and relationships, rather than the text. We appreciate all of the text suggestions, but at this point we need a final review of the structured format itself to make sure it will work. 3. Finally, please provide suggestions rather than simply comments. If something is broken, don’t just say it’s broken. Tell us how you want to fix it. This will make sure we keep moving forward. Looking ahead, we hope to have received all comments on draft 3 by Friday, August 12 so that we can issue a release candidate on Monday, August 15. After the release candidate is issued we’ll remove suggestion access to Google Docs and require that all comments be made on the e-mail list. This will ensure that everyone has full awareness of what we’re changing. Again, thanks everyone for all of your hard work on this. As I read through the specification and imagine using it I’m feeling very, very good about where we ended up. A couple other people I’ve talked to who have been less involved have said the same. We’ve done some great work already, so let’s keep that up next week and make a final push to finish this off.