Re: [cti] Re: [EXT] Re: [cti] type changing from "object" to "array" for cyber observable objects

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

I still can not see the value in having
an immutable fact have a UUID. It makes no logical sense to me.

-
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:      
 Bret Jordan <Bret_Jordan@symantec.com>
To:      
 Sean Barnum <sean.barnum@FireEye.com>
Cc:      
 Andras Iklody <andras.iklody@circl.lu>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:      
 10/02/2017 08:08 PM
Subject:    
   [cti] Re: [EXT]
Re: [cti] type changing from "object" to "array" for
cyber observable objects
Sent by:    
   <cti@lists.oasis-open.org>

---

I was one of the ones that pushed against this. At the
time I could not see the value of having observable objects be first order
citizens.  I admit that.  But I am really beginning to question
it.  So much so, that I think we may have gotten it wrong. 

Bret

Sent from my iPhone

On Sep 29, 2017, at 9:42 AM, Sean Barnum <sean.barnum@FireEye.com>
wrote:

I will take this opportunity to restate our strong assertion
that observables should stand on their own as full objects with UUID-based
identifiers and all the other metadata of SDOs.
This opinion was very strongly held by many at the time of the debate but
was overruled by a majority of others.
The decision to fold observables into the arglebargle and to get rid of
CybOX thus losing their context independence was what led players in the
digital forensic community to leave the CTI TC and begin work on CASE/UCO
separately as they did not believe it possible to support the needs of
cyber investigation without observables as independent objects.
We at FireEye understand that this is the way that voting memberships work
and we accepted the decision and have continued to work within the CTI
TC to make the most we can of the situation.
This acceptance does not mean we agree with the decision then or now, only
that we accept it as the consensus will of the TC members who voted at
the time.
FireEye’s own model that integrates across CTI, DFIR, security operations,
vulnerability management, malware analysis, threat detection, threat prevention,
orchestration, etc treats observables as full objects as we believe that
it is absolutely necessary to do so for many reasons, some obvious and
some less obvious. Our desire to support STIX for partners/customers who
request it means that conversion from our model to STIX will require extensive
custom extensions and will also likely be lossy and/or inefficient for
real world iterative sharing due to observable objects not being full objects.
We believe that eventually the CTI TC will recognize the need for observables
to be full objects but we have carefully avoided any attempts to press
the issue prematurely and cause unnecessary drama.
I hope that this message does not cause unnecessary drama but figured this
was a good time to simply restate our position given the comments from
Cheolho and Andras combined with several recent Slack comments from Bret
questioning whether we should reconsider our decision regarding observables
as full objects.

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com

On 9/29/17, 4:06 AM, "cti@lists.oasis-open.orgon behalf of Andras Iklody" <cti@lists.oasis-open.orgon behalf of andras.iklody@circl.lu>
wrote:

   Is the reasoning behind it explained anywhere? Whoever we've discussed
   STIX 2.x so far with had their faces buried deeply in their palms
   whenever they got to the part of the documentation that explained
this
   very concept.

   Also, revising bad decisions, even if they were reached via concensus
/
   a previous debate can be healthy for a standard. Especially when
the
   only explanation we get each time we ask about this is "as
thus has been
   decideth" without any reasoning given.

   Best regards,
   Andras


   On 29. sep. 2017 09:53, Trey Darley wrote:
On 29.09.2017 09:43:26, Andras Iklody wrote:
100% agreed! {"0":{}, "1":{}} is just
ridiculous.


All -

Referring to STIX 2.0, Part 3, §2.5 "Observable Objects":

"Each key in the dictionary SHOULD be a non-negative
monotonically
increasing integer, incrementing by 1 from a starting
value of 0, and
represented as a string within the JSON MTI serialization.
However,
implementers MAY elect to use an alternate key format
if necessary."

As anyone participating in standards development work
knows,
compromises are often necessary. The choice to standardize
on a
monotonically increasing integer was a compromise following
a lengthy
debate. Note, however, that this is a SHOULD. You're free
to use
whatever you like as a key provided it's a valid JSON
string.


   ---------------------------------------------------------------------
   To unsubscribe from this mail list, you must leave the OASIS TC
that
   generates this mail.  Follow this link to all your TCs in
OASIS at:
   https://clicktime.symantec.com/a/1/_a1HRn3Ks5mnBIdMQdg49Boz24ieDy4g-A_aSoSb1RE=?d=afesj0rpxoEcEKpscK4aDSOZVZ2lbQP0nzYQ88zZq320t6Zl-q45e4cZ9PP5KBIvZTo4jG9Rlw5ui-Z-HEB_BrFoaKV0xxdWofRdKPzYoatjPem5wqdVCbCy0QGMpn0BN9RX8TW7Y7K9GxoeBCwtTI1lNK8hBwAnEfEF505bXLc0cniNx7fjRR6QCHTHCDhfGaopo1PUPr5NtWKdOEsL39EEHq74WqUOMEtAOqS1OoCKAGcEPMRsaVbRNu-Z7kRQ-jmk_fpeIjPbYlWGt1RFXMzw4XXMQYN_Uup2pMZdRloEFr9-hednZPEK7nzmBybDAcNniDOag0RLyTBN8f1LVpN66XgVR1EC7PIDG-GXupPEM-_FvBKTu3pGFTAIRgtCRT4rfen7muaghV3pQ2EX-EaiYnETVDJNSimokmK-j17SBuSAqOWxdzwfHhh_Ogd9JeDGE2gP9L-vpxV2Ew_9E4L1G40eqmTolBwOPAXRuL3i2G0%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php






This email and any attachments thereto may contain private, confidential,
and/or privileged material for the sole use of the intended recipient.
Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended
recipient, please contact the sender immediately and permanently delete
the original and any copies of this email and any attachments thereto.