Proposal: Clarify structures of ObjectType associated with object characterization

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Clarify structures of ObjectType associated with object characterization

Charles Schmidt (MITRE)
Administrator
Hello all,

This proposal deals with clarification of the structures of ObjectType
associated with the characterization of an object (i.e., the specification
of the object's attributes). Specifically:
- the language intent is that schema-defined and ad-hoc attributes not be
intermingled, but the schema doesn't prevent this
- the purpose of the @type attribute (namely, characterizing a collection of
ad-hoc attributes) is not clear from the attribute's name and its
restriction to an enumeration does not serve this intended purpose well
Proposals have been put forward to address these issues and bring the schema
into better alignment with the language intent.

A detailed proposal, including expected impacts, is attached. This
corresponds to item #6 in the CybOX Project/Schemas issue tracker on GitHub.
(https://github.com/CybOXProject) Please note that this is not describing an
accepted change but rather is a proposal being put forward for community
review and feedback. Comments and concerns with regard to this proposal are
welcome - please send comments in response to this message.

Thanks,
Charles (for the CybOX Team)

ClarifyObjectAttributeStructures.pdf (620K) Download Attachment
smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Clarify structures of ObjectType associated with object characterization

Charles Schmidt (MITRE)
Administrator
Hi Dave,

I believe you are mostly correct:

Currently the @type attribute exists within the ObjectType. Its intent is to
characterize ad-hoc sets of attributes for an object. Unfortunately, the value
of the @type attribute is set to a list of enumerated values. This is purely
an artifact of CybOX development. The result is that we are trying to
characterize ad-hoc attributes, but have restricted people to using a specific
set of terms to do so. Some feel this is both overly restrictive (ad-hoc
attributes could easily include things that are not covered by this list) and
also gives a false sense of uniformity (if two authors define ad-hoc
attributes and associate them with the same @type keyword, that doesn't
necessarily mean that the two authors are describing the same thing).

So as part of this proposal, we seek to have the @undefined_type (which
replaces @type) be a freeform string so that authors can characterize their
ad-hoc attributes in any way they want. You are correct - authors might still
have collisions in their values for this field even if they are not
necessarily talking about identical things. I would argue collisions are less
likely than they were when authors were restricted to the enumeration, but it
is definitely still a possibility and could lead to the same false sense of
uniformity. Do you feel that this is likely enough that we should take steps
to prevent it? I guess my initial thought is that commonly described objects
should have their own DefinedObjectType extension schema, so the
@undefined_type would only come into play in edge cases to begin with, making
accidental collisions even less likely. I might be overly optimistic on that.
What are your thoughts?

Thanks,
Charles

>-----Original Message-----
>From: Challener, David C. [mailto:[hidden email]]
>Sent: Tuesday, February 26, 2013 3:48 PM
>To: Schmidt, Charles M.
>Subject: RE: Proposal: Clarify structures of ObjectType associated with
>object
>characterization
>
>So if I understand correctly, @type would come out of a maintained list of
>things that it could be, whereas undefined_type would be freeform text that
>might have a collision with something someone else has defined?
>
>-----Original Message-----
>From: [hidden email] [mailto:owner-cybox-
>[hidden email]] On Behalf Of Schmidt, Charles M.
>Sent: Tuesday, February 26, 2013 10:38 AM
>To: cybox-discussion-list Cyber Observable Expression/CybOX Discussi
>Subject: Proposal: Clarify structures of ObjectType associated with object
>characterization
>
>Hello all,
>
>This proposal deals with clarification of the structures of ObjectType
>associated with the characterization of an object (i.e., the specification
>of the object's attributes). Specifically:
>- the language intent is that schema-defined and ad-hoc attributes not be
>intermingled, but the schema doesn't prevent this
>- the purpose of the @type attribute (namely, characterizing a collection of
>ad-hoc attributes) is not clear from the attribute's name and its
>restriction to an enumeration does not serve this intended purpose well
>Proposals have been put forward to address these issues and bring the
>schema
>into better alignment with the language intent.
>
>A detailed proposal, including expected impacts, is attached. This
>corresponds to item #6 in the CybOX Project/Schemas issue tracker on
>GitHub.
>(https://github.com/CybOXProject) Please note that this is not describing an
>accepted change but rather is a proposal being put forward for community
>review and feedback. Comments and concerns with regard to this proposal
>are
>welcome - please send comments in response to this message.
>
>Thanks,
>Charles (for the CybOX Team)

smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Clarify structures of ObjectType associated with object characterization

Charles Schmidt (MITRE)
Administrator
In reply to this post by Charles Schmidt (MITRE)
Hello all,

I received a correction with regard to the previous proposal: specifically,
the Domain-specific_Object_Attributes element is apparently intended for use
with all characterizations of an Object, be it through well-defined
attributes or ad-hoc attributes. As such, it is intended to align with the
needs of a community of practice that cross all Object boundaries, rather
than represent an extension of a particular Object type that is specific to
a community of practice. The revised proposal (attached) reflects this,
removing Domain-specific_Object_Attributes from the proposed choice block
and allowing it to be present regardless of whether Defined_Object or
Custom_Attributes is used.

In addition, it was suggested that the lack of clarity over the meaning of
the @type attribute is significantly reduced when it gets moved to the
Custom_Attributes element, so giving it the name @undefined_type is
unnecessarily wordy. As such, in the new proposal the @type attribute's name
does not change, although it does move from <Object> to <Custom_Attributes>.

Note that this revised proposal does not address Dave Challener's concern
about the possible accidental collision of @type values provided by
different parties as a way to characterize their custom attributes. At the
moment, our thought is that collisions are probably best avoided by best
practices where authors include a short identifying string (e.g., a DNS
name) at the beginning, but that this would not be schema enforced. Please
send us feedback if you have concerns about this or any other aspect of this
proposal.

Thanks,
Charles (for the CybOX Team)

>-----Original Message-----
>From: [hidden email] [mailto:owner-cybox-
>[hidden email]] On Behalf Of Schmidt, Charles M.
>Sent: Tuesday, February 26, 2013 9:38 AM
>To: cybox-discussion-list Cyber Observable Expression/CybOX Discussi
>Subject: Proposal: Clarify structures of ObjectType associated with object
>characterization
>
>Hello all,
>
>This proposal deals with clarification of the structures of ObjectType
>associated with the characterization of an object (i.e., the specification
>of the object's attributes). Specifically:
>- the language intent is that schema-defined and ad-hoc attributes not be
>intermingled, but the schema doesn't prevent this
>- the purpose of the @type attribute (namely, characterizing a collection
of

>ad-hoc attributes) is not clear from the attribute's name and its
>restriction to an enumeration does not serve this intended purpose well
>Proposals have been put forward to address these issues and bring the
>schema
>into better alignment with the language intent.
>
>A detailed proposal, including expected impacts, is attached. This
>corresponds to item #6 in the CybOX Project/Schemas issue tracker on
>GitHub.
>(https://github.com/CybOXProject) Please note that this is not describing
an
>accepted change but rather is a proposal being put forward for community
>review and feedback. Comments and concerns with regard to this proposal
>are
>welcome - please send comments in response to this message.
>
>Thanks,
>Charles (for the CybOX Team)

ClarifyObjectAttributeStructures2.pdf (455K) Download Attachment
smime.p7s (9K) Download Attachment