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] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs


Well said Jason, and I completely agree.  


Thanks,

Bret



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." 

On Mar 14, 2016, at 10:04, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

IDs should be immutable and not based on hashing, as having IDs flux based on the content (hash) creates more problems than it solves. I don't want the ID of a threat actor to change because I am correcting a spelling mistake. I also don't want to have to re-author or append to all of my relationships because someone adds a host to a watch list and have that change it's ID.

IE, changing an object should not change all of the relationships people have with that object, it should just increment a version.

Terry McDonald posted a good discourse on why this is important on slack.. I will copy / paste here.


    "With Explicit Updates: each ID specifies a particular object, and that updates to that object are actually brand new completely new objects with completly new object IDs, and then they are related to each other as 'updates' using a relationship object.

    The problem is when people connect other relationships to earlier versions of the object. How do we handle that? Are all relationships transitive across all versions of the object? In that case the consumers al need to keep all versions of the object and then walk the graph to the latest version every time they want to find all the relationships.

    Or we say that relationships aren't transitive, and then when a new update comes out all the realationahips that point to it need to be updated top point to the latest version of that object.

    It seems much simpler to go with an implicit versioning scheme, where the object always maintains its Object ID, and we just version control the update through updates to that one object. It makes relationships much easier to handle (they link to the Object ID), it makes it easier for consumers (keep only the latest version of the object if you want) and easier for them to walk the relationships (there are no versioning relationships).

    Its also conceptually easier for new users to understand, which is a big plus in my view
...
    There should only be one way to version the one object. It should always keep the same ID during it's lifecycle, and should have a version field (or some other field that changes per version) that tracks which version the object is.

    There should be no way to version major changes. New objects should be considered to be completely different and should have a completely new ID. There should be ONLY one way to version an object. We had two ways to version in STIX v1.x (i.e. major updates or incremental) and it didn't work."

-
Jason Keirstead
STSM, 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


<graycol.gif>"Mates, Jeffrey CIV DC3---03/14/2016 12:53:13 PM---My understanding is that in general versioning should be handled using the CTI Core "created_at" att

From: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "marlon.taylor@us-cert.gov" <marlon.taylor@us-cert.gov>
Date: 03/14/2016 12:53 PM
Subject: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs
Sent by: <cti@lists.oasis-open.org>




My understanding is that in general versioning should be handled using the
CTI Core "created_at" attribute which exists on both objects and
relationships.  If this changes any object with a deterministic hash would
also have its GUID change.  As such different versions of an object would
respect each other's unique GUIDs thus protecting referential integrity.

Even without a deterministic hash this would still be possible by simply
generating a new GUID every time a new version of an object or relationship
is produced.

Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335


-----Original Message-----
From: cti@lists.oasis-open.org [
mailto:cti@lists.oasis-open.org] On Behalf
Of Jason Keirstead
Sent: Monday, March 14, 2016 11:27 AM
To: Taylor, Marlon
Cc: cti@lists.oasis-open.org; Mates, Jeffrey CIV DC3/DCCI;
marlon.taylor@us-cert.gov
Subject: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs

Are you saying that versions will only exist on relationship objects? How
will that help me figure out if a given threat actor's description is the
most recent.


-
Jason Keirstead
STSM, 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


Inactive hide details for "Taylor, Marlon" ---03/14/2016 12:07:46
PM---Correct. Hashing won't provide that capability. Relation"Taylor,
Marlon" ---03/14/2016 12:07:46 PM---Correct. Hashing won't provide that
capability. Relationships will provide what you're looking for.

From: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,
"marlon.taylor@us-cert.gov" <marlon.taylor@us-cert.gov>
Date: 03/14/2016 12:07 PM
Subject: RE: [cti] RE: Versioning Background Docs

________________________________




Correct. Hashing won't provide that capability.

Relationships will provide what you're looking for.

-Marlon



________________________________

From: Jason Keirstead
Sent: Monday, March 14, 2016 10:56:04 AM
To: Taylor, Marlon
Cc: Mates, Jeffrey CIV DC3/DCCI; cti@lists.oasis-open.org;
marlon.taylor@us-cert.gov
Subject: RE: [cti] RE: Versioning Background Docs


Apologize for my confusion but I don't really understand what is being
discussed in this thread.

Are people talking about IDs or Versions? What does hashing have to do with
versioning?

I (hope?) people are not advocating to simply hash the contents of the
object and use that as a version? That is not workable. A version has to be
continually incrementing. I need to be able to look at a version and know if
it is the latest version or if it is stale. You can't do that with hashes.

-
Jason Keirstead
STSM, 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


Inactive hide details for "Taylor, Marlon" ---03/14/2016 11:42:28 AM---Hi
All, Jeff and I spoke offline and we are in agreement"Taylor, Marlon"
---03/14/2016 11:42:28 AM---Hi All, Jeff and I spoke offline and we are in
agreement with the hash based approach. Some takeaway

From: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>
To: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "marlon.taylor@us-cert.gov" <marlon.taylor@us-cert.gov>
Date: 03/14/2016 11:42 AM
Subject: RE: [cti] RE: Versioning Background Docs Sent by:
<cti@lists.oasis-open.org>

________________________________




Hi All,

Jeff and I spoke offline and we are in agreement with the hash based
approach. Some takeaways:
- cleared up "shallowness" of shallow objects
- conveyed the idea of relationships which contain arrays of ids (he calls
them link aggregators)

As we finalize objects across the TC we can go into object-specific required
fields. Ex: should every Indicator have an observable?

Keep up the feedback.

-Marlon



________________________________
















Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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