Re: [cti] Re: [EXT] Re: [cti] Intel note and opinion

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

There's a difference though between these
arguments.

"if we model the data this way,
it forces you down this UI path", vs "if we model the data this
way then analysts won't like the experience". 

Those are very different things being
argued.

-
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:      
 "Wunder, John
A." <jwunder@mitre.org>
To:      
 Jason Keirstead/CanEast/IBM@IBMCA,
Paul Patrick <Paul.Patrick@FireEye.com>
Cc:      
 Bret Jordan <Bret_Jordan@symantec.com>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,
Dave Cridland <dave.cridland@surevine.com>, Nicholas Hayden <nhayden@anomali.com>
Date:      
 04/13/2017 10:37 AM
Subject:    
   Re: [cti] Re:
[EXT] Re: [cti] Intel note and opinion
Sent by:    
   <cti@lists.oasis-open.org>

---

So I hesitate to keep talking about this,
but I did want to point out that one of the arguments given for merging
the objects is that people can’t imagine a UI that distinguishes opinions
from notes. People have said that you’ll always need to display them in
the same way, so therefore they should be merged. So given those arguments
are specifically about UI, I do think Paul’s comment is worth considering…his
analysts apparently would like a UI that distinguishes them.
 
Again I think with the one-object approach
this is possible. Just wanted to point out that many of these arguments
have been explicitly about UI.
 
John
 
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, April 13, 2017 at 9:18 AM
To: Paul Patrick <Paul.Patrick@FireEye.com>
Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>,
Dave Cridland <dave.cridland@surevine.com>, John Wunder <jwunder@mitre.org>,
Nicholas Hayden <nhayden@anomali.com>
Subject: Re: [cti] Re: [EXT] Re: [cti] Intel note and opinion
 
STIX is not a UI, it is a machine-to-machine
communications mechanism. We are not modeling a UI, we are modeling data.

The way that anything represented in STIX ends up being shown to the user
is totally up to the software vendor.  

I do not believe most software vendors in the TC are planning to expose
STIX SDOs directly to analysts.. in my opinion it would be a very non-typical
use case if someone is envisioning this. So I am unsure why it is relevant
to this data modeling problem.

-
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:        Paul
Patrick <Paul.Patrick@FireEye.com>
To:        "Wunder,
John A." <jwunder@mitre.org>, Dave Cridland <dave.cridland@surevine.com>,
Bret Jordan <Bret_Jordan@symantec.com>
Cc:        Nicholas
Hayden <nhayden@anomali.com>, Jason Keirstead/CanEast/IBM@IBMCA,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        04/13/2017
09:55 AM
Subject:        Re:
[cti] Re: [EXT] Re: [cti] Intel note and opinion

---

I’m in agreement with what both Jane and Sarah has stated.  When
I speak with my analysts, they think of these as different things and find
both concepts useful.
 
So I’m definitely in favor of keeping them separate.
 
 
Paul Patrick
 
From: <cti@lists.oasis-open.org> on behalf of "Wunder, John
A." <jwunder@mitre.org>
Date: Thursday, April 13, 2017 at 8:27 AM
To: Dave Cridland <dave.cridland@surevine.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc: Nicholas Hayden <nhayden@anomali.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Intel note and opinion
 
Hey Dave,
 
I agree w/ you that the same capabilities are possible in both approaches.
The question is less the functionality and more a combination of what we
want to encourage (treating intel notes and comments separately, or treating
them the same) and which is easier to describe and understand. The two-object
proposal requires you to develop support for two objects that each have
a distinct set of required and optional fields. The one-object proposal
uses normative text to achieve the same thing. Apparently, there are different
opinions about which is easier and more natural.
 
The two ways we can resolve this are either a simple ballot to approve
whichever approach has the most informal votes or the people who back the
one with fewer informal votes (*looks at self*) can agree that we’re close
to consensus and let us approve it by unanimous consent on a TC call. Although
it didn’t go the way I wanted, I’m OK saying that a single object is
doable and won’t object to unanimous consent.
 
John
 
From: <cti@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com>
Date: Thursday, April 13, 2017 at 4:05 AM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Cc: Nicholas Hayden <nhayden@anomali.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
John Wunder <jwunder@mitre.org>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Intel note and opinion
 
FWIW, I'm still utterly bewildered why this makes a difference.
 
Consider:
 
1) [Object] <-- [Opinion + Note]    // Obviously nice and
clear; the note is an explanation of the opinion.
2) [Object] <-- [Opinion]    // Opinion without explanation.
3) [Object] <-- [Opinion] <-- [Note]    // Same as (1)
4) [Note] --> [Object] <-- [Opinion]    // Independent
note and opinion.
5) [Object] <-- [Note] <-- [Opinion]    // Opinion about
a note.
6) [Object] <-- [Note] <-- [Opinion + Note]    // Messaging
over STIX, giant can of worms.
 
Which pattern is ruled out by which option, and which patterns are problematic?
Are there patterns which are missing that are important?
 
On 12 April 2017 at 19:40, Bret Jordan <Bret_Jordan@symantec.com>
wrote:
As of right now, I hope I have captured people's views correctly, here
is the summary that I seen from email (the current majority is 6 to 4 for
"Against 2 objects":

 
Against 2 objects
Jason Keirstead - IBM
Bret Jordan - Symantec
Rich Shok - US Bank
Nicholas Hayden - Anomali
Pat Maroney - Wapack Labs
Stefan Hagen


In the Middle
Allan Thompson - Looking Class
Dave Cridland - Survive


For 2 objects
John Wunder - MITRE
Sarah Kelley - CIS
Nathan Reller - JH APL
Terry MacDonald

If you have not spoken up, please do so.

Bret

---

From: cti@lists.oasis-open.org<cti@lists.oasis-open.org>
on behalf of Nicholas Hayden <nhayden@anomali.com>
Sent: Wednesday, April 12, 2017 11:28:21 AM
To: Jason Keirstead
Cc: Wunder, John A.; cti@lists.oasis-open.org
Subject: [EXT] Re: [cti] Intel note and opinion
 
I also agree with Jason, having two separate objects will muddy the water
for implementation.
 
 
Best Regards, 
Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+ 
Director of Engineering Anomali | anomali.com
808 Winslow St Redwood City, CA 94063
Phone: (650)
257-0867 | Twitter: @anomali



 
On Apr 11, 2017, at 7:38 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
wrote:
 
I have a very strong opinion either #2 or #3 must  be done, and that
#1 is not workable.

In order to fully understand why, you have to consider the entire life-cycle
of the objects - from production in one piece of software, to consumption
and storage/display in another. You also have to understand that, at their
core, both of these objects are objects are things that originate from
humans, and carry human-entered facts about an object (either as human-entered
text, or as "opinion", or other). Finally, you have to understand
that the folks writing STIX software do not normally expose the data model
to the operators/analysts.... operators and analysts should not be seeing
"note", or "opinion", or any other names of objects
in most software that deals with STIX, it should be totally abstracted
away. The analysts should not know or care about this.

In any piece of software dealing with creating CTI by humans, one can imagine
you will have to have some UI where one would enter these "things",
and in any piece of software dealing with displaying CTI to humans, one
can imagine you will have to have some UI where one will display these
"things". If we have two different objects, then you can immediately
see how this presents a problem for the software creators

- Consider the producer software When someone wants to simply enter text
- which object do I encode it as in STIX? Since both can convey the information,
it is totally ambiguous which to use - out of the gate, we are now at "two
ways to do one thing", something we said we are trying to get away
from in STIX 2. What if they enter text, it gets encoded as a "note",
and then later on the same user goes in and and add an "opinion"
flag? Should I revoke the "note" object and add an "opinion"
object? Leave it and issue an "opinion" and duplicate all the
text? Again, totally ambiguous. This points to the fact that these two
things are different ideas - voting and commenting - and should be kept
fully separate (#2)

- Consider now the consumer software. Any piece of consumer software who
is going to  display notes and opinions to a user is going to want
to have some kind of comment-trail.. some type of timeline. It will simply
not be possible to construct this comment trail without unionizing these
two objects and treating them as one... as viewing a timeline of "note"
without including "opinion", or vice-versa, will have the potential
to leave a large number of human-created comments dropped on the floor.
 I can't reasonably see any valid use case to have software where
one shows a set of "opinion" without including "note",
or vice-versa. This again points to the fact that you need a single source
of truth for a comment timeline... either option #2, or option #3 alternatively.

-
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




From:        "Wunder,
John A." <jwunder@mitre.org>
To:        "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Date:        04/10/2017
05:30 PM
Subject:        [cti]
Intel note and opinion
Sent by:        <cti@lists.oasis-open.org>

---

Hey everyone,

After a lot of conversation on intel note and opinion, we’ve narrowed
down a lot of the questions on these two objects but have one big one remaining.
Specifically, with both intel note and opinion existing as separate objects
a few people (notably Jason and Bret) have noted that there may be overlap
and in fact the objects should be merged into one. The thinking is that
giving an opinion is essentially the same as giving extra analysis about
something (or is at least handled the same way most of the time) and having
two separate objects will be confusing for people. So, here’s how I would
outline the questions:

1.       Should opinion and intel note remain separate objects?
a.       Merging them would provide a single object to provide
a simple opinion on a scale (agree/disagree), an opinion on a scale with
a text explanation (agree and here’s why), and added analysis w/ no opinion
scale (here’s extra info about this object).
b.       Separating them would distinguish providing an
opinion (agree/disagree) from providing extra analysis
2.       If we go with option b and we have two separate
objects, should opinion have an optional description field?
a.       Having a description on opinion keeps all information
about the opinion in a single object.
b.       Not having a description on opinion would mean
that opinions are just the agree/disagree statements. People would use
the intel note object to capture their explanation and therefore all text
commentary would be provided by intel note.

It seems like the key thing people are wrestling with is whether there’s
a distinction between giving extra analysis or context to something and
giving an opinion about something. I.e., when people are doing shared analysis
is it important to distinguish me providing an opinion on your object (agree/disagree/neutral)
from me adding extra context (human-readable notes) to your data?

So, combining those questions, we have three options:

1.       Opinion and intel note are separate objects, and
opinion has a description. To have a text explanation of an opinion, you
would use the description field on the opinion object.
2.       Opinion and intel note are separate objects, and
opinion does not have a description. To have a text explanation of an opinion,
you would use an intel note and link it to the opinion.
3.       Opinion and intel note are merged (likely calling
it intel note, since not all of them would be opinions) and you would use
that object to describe opinions, opinions w/ descriptions, and added analysis

People can reply with their reasoning and pros/cons, but I’m particularly
interested in hearing people who have not chimed in yet. What is your preferred
option? Any thoughts on the reasoning?

FYI, here are the latest working versions of intel note and opinion, in
Google Docs. These are roughly option #1, based on the recent working call
and a poll in Slack.

-          Intel note: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.74spnst8naxc
-          Opinion: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.haeazu2sh3sq

My own opinion (sorry I know this pun is getting old) is that giving an
opinion is distinct from adding analyst notes or extra context and therefore
I prefer #1. My second choice would be #2, because I think #3 results in
an ambiguous object that does too many things and can have completely orthogonal
sets of fields, which to me is an indication that it really should be two
objects.

Thanks,
John


 


 
--

Dave Cridland
phone  +448454681066
email  dave.cridland@surevine.com
skype  dave.cridland.surevine

Participate | Collaborate | Innovate
Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
If you think you have received this message in error, please notify us.

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.