cti message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti] Intel note and opinion
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>
- Date: Tue, 11 Apr 2017 12:07:27 -0300
I do not see how these comments address either
of the points I raised in my original email.
At it's core, this is "two ways to
do the same thing". It is something we very explicitly said we were
going to try to avoid in STIX 2 because it results in implementation problems
and ambiguity for software creators. If we go in this direction, it is
invariably going to lead to incompatible products.
-
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:
"Reller, Nathan
S." <Nathan.Reller@jhuapl.edu>
To:
"cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Date:
04/11/2017 11:21 AM
Subject:
Re: [cti] Intel
note and opinion
Sent by:
<cti@lists.oasis-open.org>
Hello everyone. I’m new to the group.
I thought I would chime in to introduce myself and hopefully add to the
discussion without asking too many dumb questions.
I also wanted to comment on the statement,
“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.” I also disagree with that statement. The classes that we
create in code should represent ideas and concepts of the system and user.
I would totally expect to see users create new campaigns, threat actors,
etc. The GUI should be the glue to translate the low-level details of the
class into a human understandable format (i.e. Boolean should be True/False
or Yes/No, DateTime property is converted to and from a String).
> “If we have two different objects,
then you can immediately see how this presents a problem for the software
creators”
I’m not sure that I follow this. Especially
in the next paragraph where you state, “Consider the producer software
When someone wants to simply enter text - which object do I encode it as
in STIX?” Can I ask how you are getting to this point? I am picturing
a user looking at some piece of information on the screen and the user
then decides he wants to add a note or opinion. He would do that by clicking
a button to add a note or opinion, whichever he feels is the most appropriate,
and then he would enter the details for the note or opinion. How does the
user get to a point where they simply want to enter text? Can you provide
more context as to how I get into that state?
I’ll vote even if my vote doesn’t count
: ) I vote for option 1. They seem to represent different concepts to me.
-Nate
From: <cti@lists.oasis-open.org>
on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Tuesday, April 11, 2017 at 8:37 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Intel note and opinion
I vote 1 then 2.
I strongly disagree with merging these
two objects. I think they are distinct enough that most people creating
this human generated information would understand the difference, and I
believe they serve very different purposes.
If this is true: “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.”
Then I can see where the problem is coming
from. What I don’t understand is why would you ever want to abstract this
away from the analyst using the tool? At that point, you would be tying
their hands and limited what they can use. If you present the analyst with
both a note and an opinion, they would choose what they felt was appropriate.
The whole point of creating a standard with all these various objects,
fields and properties is so that an end user can actually use these fields
in a tool to create this data. If you don’t reveal all the features we’re
putting into the language to the end user, then what is the point of putting
them in the spec in the first place?
I also don’t understand the chronology
problem. To add one more likely scenario into the mix, I create a threat
actor. Then I revise the threat actor 5 times. Which creates 5 different
versions, with five different description fields containing different analysis.
You have to merge this in with any intel notes and with opinions (even
if you merge this into one object). So, you’re already going to have to
figure out a way to make a ‘timeline’ by looking at multiple objects.
What’s the difference?
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>
on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, April 11, 2017 at 7:38 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Intel note and opinion
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
...
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.
. . .
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]