cti-cybox message

Subject: Re: [cti-cybox] Re: CybOX 3.0: HashType Refactoring

From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
To: "Kirillov, Ivan A." <ikirillov@mitre.org>
Date: Tue, 3 Nov 2015 11:38:24 -0400

Agree. +1 :)

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

"Kirillov, Ivan A." ---2015/11/03 11:32:28 AM---Yes, I absolutely agree on the utility of enumerations, and I probably should have clarified my poin

From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Davidson II, Mark S" <mdavidson@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "John Anderson" <janderson@soltra.com>
Date: 2015/11/03 11:32 AM
Subject: Re: [cti-cybox] Re: CybOX 3.0: HashType Refactoring
Sent by: <cti-cybox@lists.oasis-open.org>

Yes, I absolutely agree on the utility of enumerations, and I probably should have clarified my point accordingly. Anyhow, my thought is that the “type” field in HashType should NOT be implemented through a controlled vocabulary but should instead yse a fixed enumeration that is defined as part of the CybOX 3.0 specification:

“type": {
"enum": [ “md5", “md5", “sha1”, “sha256”, etc. ]}
Regards,
Ivan

From: Jason Keirstead
Date: Tuesday, November 3, 2015 at 8:12 AM
To: Mark Davidson
Cc: "cti-cybox@lists.oasis-open.org", Ivan Kirillov, John Anderson
Subject: RE: [cti-cybox] Re: CybOX 3.0: HashType Refactoring

I think the hashing algorithms should be either a controlled vocabulary or a type enum like Jerome suggested, that is part of the specification. Anything that a coder would implement as an Enumeration, should be a controlled vocabulary or an enumeration.

RE:

1. No. Controlled vocabularies make the most sense when there is no expectation that what they’re capturing is complete and/or there is a large need for it to be customized by content producers. I don’t think this is the case with cryptographic hashing algorithms; they’re largely stable and standardized for the most part.

The reason you need this is not because you see it being extended, it is so that everyone agrees on how it should be entered into the document so that it can be parsed properly and efficiently. "MD5" vs "md5", "sha" vs "SHA-1" vs "sha256" vs "SHA-256"

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

"Davidson II, Mark S" ---2015/11/03 08:43:46 AM---My comment is really about controlled vocabularies in general. I tend to have a gut reaction of want

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: "Kirillov, Ivan A." <ikirillov@mitre.org>, Jason Keirstead/CanEast/IBM@IBMCA, John Anderson <janderson@soltra.com>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 2015/11/03 08:43 AM
Subject: RE: [cti-cybox] Re: CybOX 3.0: HashType Refactoring

My comment is really about controlled vocabularies in general. I tend to have a gut reaction of wanting to do away with controlled vocabularies wherever we have them because they are hard for me to implement. That said, I think changing two key factors about controlled vocabularies would change the way I feel about them.

I think we should consider improving controlled vocabularies in these two areas:

REQUIRE a specific controlled vocabulary, allow other controlled vocabularies. Right now any vocabulary is just as valid as any other vocabulary, and this makes things more difficult. STIX/CybOX do have the notion of default vocabularies, but this seems like more of a starting point than a definition. If we made a single vocabulary required and all other vocabularies optional (perhaps calling them “third party vocabularies”) I think that would go a long way toward making controlled vocabularies easier to implement.

As a sub-point, I think MTI vocabularies should be specified in the overall spec, as this reduces the number of overall moving parts for people to track.

DEFINE the semantics for each value. In many places the meaning of certain controlled vocabularies is unspecified. When I get an indicator with an IndicatorType of “URL Watchlist”, what does that mean exactly? The XSD annotation has some descriptive text (in this case, “Indicator describes a set of suspected malicious URLS”), but it doesn’t tell me how the value of this field changes how I process (or not) the indicator. I can make an inference based on experience, but we should seek to improve these definitions so that implementers have an easier time. If this is just a label and not meant for processing, we should call it out as such.

If controlled vocabularies were to meet the requirements I lay out above, I would have no opinion on whether hashes use a default vocabulary or not. As controlled vocabularies currently stand, my preference is for not using them.

Thank you.
-Mark

From: