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

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

Yes but you don't want to revoke the string
"http://http://<domain>"
- you want to revoke the object that contains that string, so you can correct
it. This is the difference.

-
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:      
 Sarah Kelley <Sarah.Kelley@cisecurity.org>
To:      
 Terry MacDonald <terry.macdonald@cosive.com>,
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:      
 CTI TC Discussion List
<cti@lists.oasis-open.org>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>,
Andras Iklody <andras.iklody@circl.lu>, "Sean Barnum" <sean.barnum@fireeye.com>
Date:      
 10/03/2017 04:51 PM
Subject:    
   Re: [cti] Re:
[EXT] Re: [cti] type changing from "object" to "array"
for cyber observable objects
Sent by:    
   <cti@lists.oasis-open.org>

---

The only thing I would comment on is the
ability to revoke an observable. We often throw around “an observable
is a fact”, and it causes me angst. The reason for this is that people
and tools make mistakes. For example, in my tool at the moment, I have
a bunch of URLs that are in the database as “http://http://<domain>”.
This is CLEARLY wrong. That isn’t’ the format of a URL. I don’t care
how or why this happened (at the moment), but the issue is that if I can’t
revoke an object that’s wrong, I can never correct it. 
 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information
Sharing and Analysis Center (MS-ISAC)          
        
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations
Center
SOC@cisecurity.org- 1-866-787-4722

From: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org> on behalf of "terry.macdonald@cosive.com"
<terry.macdonald@cosive.com>
Date: Tuesday, October 3, 2017 at 3:21 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,
"Bret Jordan (CS)" <Bret_Jordan@symantec.com>, Andras Iklody
<andras.iklody@circl.lu>, Sean Barnum <sean.barnum@fireeye.com>
Subject: Re: [cti] Re: [EXT] Re: [cti] type changing from "object"
to "array" for cyber observable objects
 


I would agree with Jason here. By tying
an identifier to each observable, we effectively make each observable unique.
A consumer doesn't want unique observables, but instead wants to use the
observables as pivot points that they can use to relate other parts of
Intel to.  
 
For example if org A sends out a malware
object describing that a domain name is used by malware, and org B sends
out a domain name of a C2 server as being part of an incident, then a consumer
TIP will extract the domain name and use that domain name as a node to
relate those the malware and incident together.
 
If we then add an additional layer of object
above that (observables as SDOs), then what do we actually gain? The TIP
has identified a relationship between the malware and incident objects
in my example, do what is the benefit of sending observables as SDOs? Versioning
But what use is versioning to a domain name? It's just a domain name. It
is what it is. Revoking? Why would I revoke a thing that is a fact? I would
revoke an ObservedData object because it is an assertion - but an observable
is just a piece of piece of data.
 
AFAICT adding Observables as top level
objects just creates more objects and more work for the end customers TIP
with no noticeable gain in functionality.
 
Cheers
Terry MacDonald
Cosive
 
On 4/10/2017 07:11, "Jason Keirstead"
<Jason.Keirstead@ca.ibm.com>
wrote:
The problem is you are confusing the
notion of an observable piece of data, and an observation of that data.

Anyone who is storing the contents of observed_data as nodes in a graph,
is not properly modeling the data because they are treating the observable
as the observation, when they shouldn't be.

Having UUIDs for every single piece of content in observed_data would serve
no purpose at all. The IP address "8.8.8.8" is already unique.
It therefore needs no UUID because it is a key in and of itself. This is
the big problem I always had with the concept, the idea that every single
number, string, IP, host, and URL in existence turns into its own SDO is
beyond ridiculous 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:      
 Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:        Andras
Iklody <andras.iklody@circl.lu>,
"cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>,
Sean Barnum <sean.barnum@FireEye.com>
Date:        10/03/2017
02:05 PM 

Subject:        Re:
[cti] Re: [EXT] Re: [cti] type changing from "object" to "array"
for cyber observable objects
Sent by:    
   <cti@lists.oasis-open.org>

---

All of the implementations that I have seen so far, treat these as first
order citizens and link them in the graph directly.  The way we have
it now is a bit weird.  We basically have a two layered graph that
does not allow you to cross link things together.   Further, we have
two radically different ways of structuring the content.  The STIX
object way with a type and ID field and the Observable way of a dictionary.
 

My other problem is with the complexity of the Observed Data object.  If
you question that, please look at the length of text we as editors had
to write to try and explain it.  It would be SO much easier if the
cyber observables were just first order citizens. 

Bret

---

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Tuesday, October 3, 2017 6:15:52 AM
To: Bret Jordan
Cc: Andras Iklody; cti@lists.oasis-open.org;
Sean Barnum
Subject: Re: [cti] Re: [EXT] Re: [cti] type changing from "object"
to "array" for cyber observable objects
 
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.



 

.....

This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .