Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

The reason we selected this wording is
because it is not possible to create formal definition of a "material
change" based on STIX itself. 

You can't base a material change based
on the number of properties. I may change all of the properties of an object
and the changes are so minor that it is not a material change at all. On
the other hand, I may change a single property and it completely changes
the meaning of the object, and would in fact represent a material change.

Since you can't create a formal definition
for a material change based on STIX itself, it makes little sense to have
a formal MUST or SHOULD around it's usage.

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

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




From:      
 "Piazza, Rich"
<rpiazza@mitre.org>
To:      
 Allan Thomson <athomson@lookingglasscyber.com>,
John-Mark Gurney <jmg@newcontext.com>
Cc:      
 Bret Jordan <Bret_Jordan@symantec.com>,
"Wunder, John A." <jwunder@mitre.org>, Patrick Maroney
<pmaroney@wapacklabs.com>, "Jason Mr. Keirstead" <Jason.Keirstead@ca.ibm.com>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,
"Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu"
<Nathan.Reller@jhuapl.edu>
Date:      
 06/19/2017 10:37 AM
Subject:    
   Re: [cti] Re:
[EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
Sent by:    
   <cti@lists.oasis-open.org>

---

Here is the text from the spec:
 
Any time a change indicates a material
change to the meaning of the object, a new object with a different
id should be used. A material change is any change that the object
creator believes substantively changes the meaning of the object
 
Notice, that the “should” in the first
sentence is not the normative SHOULD, so as you say, the specification
doesn’t prevent anyone from using versioning to make “material changes”.
 Further, the spec says:
 
The object creator should also think about
relationships to the object when deciding if a change is material. If the
change would invalidate the usefulness of relationships to the object,
then the change is considered material and a new object id should
be used.
 
Once again, the non-normative “should”.
 
I guess the point is – how much do we
add to the spec to allow object creators to do something we explicitly
warn them against doing??
 
 
 
From: <cti@lists.oasis-open.org>
on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, June 19, 2017 at 9:20 AM
To: Rich Piazza <rpiazza@mitre.org>, John-Mark Gurney <jmg@newcontext.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, John Wunder <jwunder@mitre.org>,
Patrick Maroney <pmaroney@wapacklabs.com>, "Jason Mr. Keirstead"
<Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>,
"Nathan.Reller@jhuapl.edu" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level
SDO
 
Hi Rich – I think your point on versioning
of a SDO materially is important to understand (by all implementers) and
it’s important to note that there is nothing in the standard that precludes
such changes.
 
Other than the object-id which remains
immutable after object creation all other attributes are mutable for SDOs
in the current specification.
 
I’m not sure we can change the specification
to enforce anything else. Therefore, it’s possible that intel changes
significantly from one version of an object to another.
 
 
Allan
Thomson
CTO
+1-408-331-6646
LookingGlass
Cyber Solutions
 
From: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org> on behalf of "Piazza, Rich"
<rpiazza@mitre.org>
Date: Friday, June 16, 2017 at 6:10 AM
To: John-Mark Gurney <jmg@newcontext.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "Wunder, John"
<jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>,
Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>,
"Nathan.Reller@jhuapl.edu" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level
SDO
 
John-Mark, you bring up an important point,
which I, and maybe others, often forget – material changes should not
be handled via versioning.
 
Therefore, no one should be changing their
SDO, that your SDO is related to, in a way that makes the relationship
invalid.  
 
Your work flow below is the way this should
he handled – revoke the SRO, and create a new one to the new SDO.
 
I’m not sure I understand your argument
about the final flag – but based on the rest of your email – I think
it is unnecessary (at least for this use case). 
 
On 6/15/17, 6:53 PM, "John-Mark Gurney"
<jmg@newcontext.com> wrote:
 
    Piazza, Rich wrote this message
on Wed, Jun 14, 2017 at 20:58 +0000:
    > I don't think we should
give up on the idea of reusing Locations so quickly.  Assuming we
go with Locations as SDOs, it certainly is a problem if you reuse someone's
Location and they change it from underneath you.   I was first thinking
that there should be immutable SDOs - in other words, the unique USA Location
SDO CAN'T be changed.   If we had a set of the common ones (defined
in some library/repo somewhere)  then we could just use their ids.
  Duplicates are allowed, but hopefully few people would need to create
their own USA Location SDO.   I was thinking of an extra property
(on all SDOs?)  - final.  If final is true for an SDO, then a
new version couldn’t be created.  
    
    I'd like to point out we
already have an "imutable" SDO.  The versioning
    spec specifically calls out
that if you make a material change to an
    SDO, that you need to create
a new one, and not reuse an existing one.
    
    We might want to extend the
text to say that if you created an SDO
    and link it, but that the
linked SDO was incorrect, say USA vs
    USA Major Islands, that you
need to create a new Location object,
    and revoke the original relationship,
and that changing the original
    object is NOT the correct
work flow.
    
    The idea of a final flag
is an interesting one, but what would the
    handling of when a new final
object is created?  Or a new one that
    had the modified date before
the other one?  This is just changing
    the problem slightly w/o
solving it.
    
    Other solution is to simply
say the Location objects cannot be versioned.
    
    I cannot really think of
a good reason/way to version/update a Location
    object w/o materially altering
it's meaning.
    
    > Adding immutable objects
to the spec might be a good idea in general, but I think a simpler way
to handle this is just to "trust" that the library/repo contains
objects that will not change.  In other words, locations created by
a certain (well-known) identity (SDO-Immutable-Library) could be reused
with little concern that they are going to change.  And if they DO
change - maybe that is a feature - after all, all those Soviet-Union Location
SDOs are no longer too useful...
    
    -- 
    John-Mark