A few updates on these items:
·
Hashes: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.odoabbtwuxyd
o
Added normative text around the corresponding specification/RFC that the hash value must conform to
·
NTFS File Extension: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.o6cweepfrsci
o
Updated size field to be a non-negative integer
·
PDF File Extension: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.fyl99becfz8j
o
Updated the document_information_dictionary field to be of type dictionary rather than a separate type
·
URL Object: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.ah3hict2dez0
o
Added normative text around value field conforming to a particular character set
o
Added embedded relationship (redirects_to_ref)
·
Domain Name Object: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.prhhksbxbg87
o
Added embedded relationships (resolves_to_ref, redirects_to_ref)
·
Registry Key Object:
https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.luvw8wjlfo3y
o
Refactored creator_username field to an embedded relationship (creator_ref) that points to a User Account Object
Please review the above changes if you get a chance, so that we can move these items out to DRAFT status.
Also, based on previous feedback (or lack thereof) the following Objects have been moved out to DRAFT status:
·
X509 Certificate Object
·
Mutex Object
Regards,
Ivan
From:
<cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Friday, May 13, 2016 at 10:59 AM
To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] Formalizing Consensus - CybOX
If there are any additional comments on these review items, please let us know ASAP. If not, we’ll assume that we have consensus and move these out to DRAFT status.
We’ve had a few comments on the Registry Key Object, including on last Thursday’s call, and consensus seemed to be that we should allow users to keep case in registry keys (via
the key field). Otherwise, not many comments so far; I think we could especially use review and comments on the following:
We’d like to close the comment period for these entities this Thursday, May 12th.
I just added basic examples to each of the “Review” items. I agree that the “Draft” items should have a requirement of having examples, so I’ll do that next.
Yes, if you could have a simple JSON example for each of the items under "Review" in preparation of them becoming Draft. That would be really helpful.
Further thinking, maybe we should add that to the requirements of something becoming draft status... It needs to have an example.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
Do you mean a JSON example? E.g., for the Image File extension:
{
"type":"file-object",
"id":"file-object--1",
"hashes":{"md5":"B4D33B0C7306351B9ED96578465C5579"},
"extended_properties":{"image-file-extension":{
"image_is_compressed":true,
"exif_tags":{
"make":"Nikon",
"model":"D7000",
"xresolution":4928,
"yresolution":3264
}
}}
}
It might help if each of these had a simple example following the properties table to show how this might be used. It is kind of hard to understand what each of these mean
in a bigger context.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
Following in the footsteps of STIX, we’d like to move towards a more formal process of gaining consensus on CybOX entities. Thus, we’ve used the STIX status concepts as a baseline
and came up with the following:
-
Content coming into the document starts as a
Concept
-
Once the community begins to work on the topic it will move to the
Development
phase. During this phase, the group will flesh out the design and come up with normative text.
-
As the group comes to general consensus it will move to a
Review phase. As co-chairs, we will send a note to the list stating that a topic is ready for formal review. Any comments
received during this phase will be discussed via email or during the Thursday CybOX working session.
-
A topic will move into its final
Draft phase, based on the views of the co-chairs on having formal consensus, to include receiving no comments/objections. If this cannot be established, a formal motion for a ballot will be made on the email list; however,
we’d like to avoid this if at all possible due to the large number of CybOX entities. Draft status doesn’t mean that the text cannot change. Editorial changes can be made throughout the process without going back to earlier phases, however, if material changes
are needed, the topic under review would move back to the Development phase and start again.
Based on this, we’ve gone through the CybOX 3.0 specification and marked each entity accordingly.
Accordingly, we welcome your feedback and comments on the items currently ready for Review :
|