OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] STIX 2.0 RC4 Open for Review & Document Conversion


Forgot to attach the changelog, sorry!

 

From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Tuesday, December 20, 2016 at 3:33 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] STIX 2.0 RC4 Open for Review & Document Conversion

 

All,

 

Now that the timestamp ballots have closed and the open issues are resolved, we’ve locked down the STIX 2.0 documents again and are releasing STIX 2.0 RC4 for comments. Given that this is the 4th release candidate, we’ll be doing an abbreviated comment period just through the end of this week (Dec 23). Please review the documents, paying particular attention to things that have changed since RC3. A changelog is attached to help with that. All comments should be sent to this mailing list.

 

In addition to the Word documents and PDFs in the attached .zip file, you can see the documents online by following the links from the cover page: https://docs.google.com/document/d/1yvqWaPPnPW-2NiVCLqzRszcx91ffMowfT5MmE9Nsy_w

 

After the close of the RC4 review period, assuming no further substantive comments are received, the editors will begin the process of converting the documents to the OASIS templates in preparation for a ballot to approve them as a Committee Specification Draft. Each part of the work product (5 documents) will be converted individually by following this process:

 

1.      The document text will be copied from Google Docs and pasted into the OASIS templates - Bret Jordan

2.      The normative and non-normative references will be added into the documents as tracked changes – Rich Piazza

3.      A style and consistency check will be performed as tracked changes – Trey Darley

4.      The documents will be reviewed by a series of TC co-chairs and members to ensure that no text has changed and that the conversion is complete/correct:

a.      John Wunder (initial review to accept tracked changes)

b.      Sarah Kelley

c.       Ivan Kirillov

d.      Greg Back

e.      Other TBD, any volunteers?

5.      The converted documents will be shared with the TC

6.      A ballot to approve the documents as a CSD will be opened. This will be CSD01, because our previous CSD ballot on RC2 didn’t have the complete documents as required by OASIS (notably, were missing the conformance sections). We expect the conversion to take roughly two weeks, so the ballot should be opening in early January.

 

The editors will maintain strict versioning practices and have the 5 review steps to ensure that no text is changed as a result of the conversion. This is merely a reformatting exercise. You can track the status of the conversion, once it starts, by looking at a table that we’ll add to the STIX 2.0 cover page (link above) that identifies where each work part is in the process at any given time and who owns it.

 

Please let any of the co-chairs or editors know if you have any questions or concerns.

 

Thanks,

John, Sarah, Trey, Ivan, Bret, and Rich P.

 

Parts 1 & 2: STIX Core and STIX Objects
=======================================

Substantive changes
-------------------
* Added a last_seen field to campaign and intrusion set. Added clarifications to first and last seen to specify how theyâ??re different from sightings.
* Updates to Bundle
    * Per Allanâ??s proposal, flattened list of objects from buckets by object type to just a single list
    * Per Allanâ??s suggestion and list consensus, removed normative statement and replaced it with a definitional one
* Updates to versioning to use modified time rather than version number, fairly significant re-writes to incorporate this change
* Removed timestamp precision and updated reserved properties to reserve them
* Added some clarification and expansion to the fact that markings cannot be updated
* Added normative statements to sighting_of_ref, observed_data_refs, and where_sighted_ref to limit what those fields can point to

Text clarifications / editorial updates
---------------------------------------
* Updated document numbering to conform to OASIS requirements (renaming parts 3a and 3b to parts 3 and 4).
* Clarified text in section 1.2.1 where it describes the graph-based model
* Used â??entitiesâ?? consistently to refer to systems, orgs, etc.
* Updated language around â??indicatorâ?? to use â??detectâ?? rather than â??indicateâ?? in section 1.2.3
* Updated definition of â??listâ?? to make it more clear that the order is specified by the object creator/producer
* Clarified language in â??identifierâ?? to make it clear that our style rules say that object names must be lowercase
* Added a clarification to our naming rules to state that when a vocabulary comes directly from a canonical source it may have capitals or otherwise not conform to our lowercase/dashes convention (used exclusively in parts 3-5).
* Added TTP to the definitions section
* Made definitions section consistent across parts 1-2 (TODO: what for 3-5?)
* Added some text to bundle clarifying the use of ID
* Corrected examples to align with spec changes
* Fixed incorrect part numbers in the introduction
* Other very minor grammar & style
* Added note that IDs in the versioning section are simplified
* Removed created_by_ref from the list of required fields in Custom Objects. It was erroneously listed as required when it isnâ??t on normal objects.
* Simplified an example in the Course of Action <=> Malware relationship to make it more understandable and readable
* Corrected â??Intrusionâ?? to â??Intrusion Setâ?? in the table in 2.5.2
* Corrected definition on threat actor labels to remove â??if known or suspected"

Part 3: Cyber Observable Core Concepts
======================================

* Rename document from "Part 3a" to "Part 3"
* Update table of contents
* Replace "§" with "Section" throughout entire document
* Replace "extended_properties" with "extensions" as Object property for Cyber Observable Object Extensions throughout entire document
* Replaced sample IP Addresses and Domain Names with those specified by RFC3849, RFC2606 and RFC5737 throughout the entire document
* Section 1. Introduction
    * Editorial polish, some wordsmithing, including the removal of historical discussion about CybOX 2.0.
* Section 1.1.1. Cyber Observable Objects
    * Change "forensics" to "digital forensics"
* Section 1.1.3. Cyber Observable Extensions
    * Textual changes to clarify the role of Cyber Observable Object Extensions
* Section 1.1.4. Vocabularies & Enumerations
    * Change "Objects" to "Cyber Observable Object" in sentence 1.
* Section 1.2.1. Naming Conventions
    * Textual clarification in sentence 1 about property case in instances where property names are taken from external registries (e.g., IANA)
* Section 1.2.2. Font Colors and Style
    * Formatting tweaks
* Section 2. Cyber Observable Specific Data Types
    * Formatting tweaks on table
* Section 2.2. Binary
    * Add text to clarify how type should be handled in STIX Patterning
* Section 2.3. Hexadecimal
    * Add text to clarify how type should be handled in STIX Patterning
* Section 3.1. Common Properties
    * Renamed extended_properties property to extensions for clarity
    * Formatting tweaks on table
* Section 3.3.1. String Encoding
    * Textual clarifications regarding how string encodings are to be handled in Cyber Observable Objects
    * Deprecated text around corresponding _bin properties for _enc; accordingly, the use of _bin is no longer permitted
* Section 3.4. Object Relationships
    * Textual clarifications regarding Cyber Observable Object property naming conventions for properties referring to one or more Cyber Observable relationships
* Section 3.5. Predefined Object Extensions
    * Textual clarifications regarding the predefined set of Cyber Observable Object Extensions (as opposed to Custom Extensions, discussed in Section 5.2)
* Section 4.1. Hashing Algorithm Vocabulary
    * Formatting tweaks on table
* Section 4.2. Encryption Algorithm Vocabulary
    * Formatting tweaks on table
* Section 5. Customizing Cyber Observables
    * Rename section title
    * Textual clarifications (paragraph 2 and 3) regarding the use of Custom Properties on Cyber Observable Objects
* Section 5.1.1. Requirements
    * Formatting tweaks
* Section 5.2. Custom Object Extensions
    * Textual clarifications (paragraph 1) regarding the use of Custom Object Extensions in Cyber Observable Objects
* Section 5.2.1. Requirements
    * Formatting tweaks
* Section 6. Custom Object Properties
    * Promoted Custom Object Properties into a top-level section of the document
* Section 6.1. Requirements
    * Formatting tweaks
* Section 7. Reserved Names
    * Formatting tweaks
* Section 8.1. Producers and Consumers
    * Formatting tweaks
* Section 9. Appendix A. Acknowledgments
    * Formatting tweaks


Part 4: Cyber Observable Objects
================================

* Rename document from "Part 3b" to "Part 4".
* Update table of contents
* Replace "§" with "Section" throughout entire document
* Replace extended_properties with extensions as Object property for Cyber Observable Object Extensions throughout entire document
* Replaced sample IP Addresses and Domain Names with those specified by RFC3849, RFC2606 and RFC5737 throughout the entire document
* Added normative text to various size-related properties to state that their values must not be negative.
* Section 2.1. Artifact Object
    * Formatting tweaks
* Section 2.2.1. Properties
    * Fix typo on type value from (old) "as" to (current) "autonomous-system"
* Section 2.3. Directory Object
    * Remove descriptive text about requirements around path and path_bin properties
* Section 2.3.1. Properties
    * Remove optional path_bin property
    * Make path property required
    * Formatting tweaks on table
    * Added normative text to contains_refs property to clarify the types of Objects that can be referenced from this property
* Section 2.4. Domain Name Object
    * Update normative text in resolves_to_refs property to properly restrict the types of Objects that can be referenced from this property
* Section 2.7. File Object
    * Remove optional name_bin property
* Section 2.12.1. Properties
    * Update normative text in src_ref and dst_ref properties to properly restrict the types of Objects that can be referenced from these properties
* Section 2.12.3. HTTP Request Extension
    * Rename extension from "HTTP Extension" to "HTTP Request Extension"
* Section 2.12.6. TCP Extension
    * Textual clarifications regarding handling dst_flags_hex extension property in cases where network traffic start/end times are unspecified.
* Section 2.13.4.3. Windows Service Type Enumeration
    * Fix typo
* Section 2.14. Software Object
    * Fix typos
* Section 2.14.1. Properties
    * Replace swid property with cpe for capturing a more standard software/platform identifier
* Section 2.16.4. UNIX Account Extension
    * Fix typos


Part 5: STIX Patterning
=======================

* Rename document from "Part 4" to "Part 5".
* Update table of contents
* Replace "§" with "Section" throughout entire document
* Replace "extended_properties" with "extensions" as Object property for Cyber Observable Object Extensions throughout entire document
* Replaced sample IP Addresses and Domain Names with those specified by RFC3849, RFC2606 and RFC5737 throughout the entire document
* Section 2. Definitions
    * Comparison Expression, correct reference to STIX 2.0, Part 3
    * Observation Expression, add clarifying text regarding recursive composition of Observation Expressions
* Section 2.1. Constants
    * Add clarifying text regarding valid type comparisons in STIX Patterning as applied to the Cyber Observable Object data model
    * Substantial additions to the accompanying table, specifically pertaining to comparisons between strings/binary/hex types and integer/float types
    * Updated syntax for hex, binary, and timestamp constants to make it easier to discern between them
* Section 4. Pattern Expressions
    * Add clarifying text regarding processing of invalid STIX patterns
* Section 4.1.1. Observation Expression Qualifiers
    * Change "REPEATED" qualified to "REPEATS" (change is reflected throughout the entire document)
    * Typo fixes
* Section 4.1.2. Observation Expression Operators
    * Renamed â??ALONGWITHâ?? operator to â??ANDâ?? for semantic consistency and accuracy
    * Added new â??ORâ?? operator to allow for OR compositions of Observation Expressions
* Section 4.2.1. Comparison Operators
    * Add clarifying text regarding valid type comparisons in STIX Patterning as applied to the Cyber Observable Object data model
    * Add clarifying text in accompanying table, under the "MATCHES" comparison operator, as to how regular expressions are to be evaluated against binary or hex constants
* Section 4.2.4. Native Format Comparison
    * Add clarifying text regarding how binary and hex are to be evaluated against string constants
    * Typo fixes
* Section 5. Object Path Syntax
    * Textual clarification regarding how object property names are to be delineated in STIX Patterning Object Paths
* Section 6. Examples
    * Typo fixes in a number of the provided examples
    * Updates to examples to account for other specification changes, such as delineation of Object property names
* Section 8. Conformance
    * Typo fixes
    * Substantial textual clarifications in paragraph 3


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]