cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-stix] Event proposal updated
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Wunder, John A." <jwunder@mitre.org>
- Date: Mon, 28 Aug 2017 14:27:13 -0300
COA should be an external reference.
The person creating the event is not
always the same identity as the one auctioning the event. In fact in most
organizations these are "two separate yet equally important groups",
which may have unique identities in STIX.
-
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 <Jason.Keirstead@ca.ibm.com>,
Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc:
"cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>, "Trey Darley" <trey@newcontext.com>
Date:
08/28/2017 01:56 PM
Subject:
Re: [cti-stix]
Event proposal updated
Sent by:
<cti-stix@lists.oasis-open.org>
I agree on aliases, I couldn’t think of
any aliases that weren’t just IDs into other incident tracking systems.
Bret, could you provide some examples of that being used?
To explain a bit about activity type and
why it was added:
- A lot of ticketing systems have the concept
of an activity stream, where responders can talk about what they’ve done
or discovered related to the incident. So it started out just capturing
that.
- Then, we had this concept of COA taken…which,
when you come down to it, is that same type of activity. We also had a
comment from someone (I believe Sarah) saying that a regular relationship
doesn’t give you the ability to specify whether a COA was successful,
failed, worked but didn’t completely resolve it, etc. So it was just moved
to activity type.
- Collected data was basically the same story…it’s
still a reference (so you wouldn’t need to duplicate it) but the idea
was that a lot of time the activity that you take in response to an event
is to collect more data. As with COA, this also gives us a place to put
contextual data so you can describe what hosts it was collected from, etc.
All that said, I’ve never really loved
that we ended up down this road and would be happy to get rid of it. It
does feel too much like event record syncing vs. exchange between tools/orgs.
It seems like we could replace it with:
- Either just text in the description or
intel notes for the textual activity (probably uncommonly used, anyway,
unless you’re literally talking about just dumping an entire incident
record)
- An embedded or external relationship to
observed data (triggered is probably not the right word, since the data
might be collected after the event is being investigated). You would lose
the ability to describe how the data was collected if you did an embedded
relationship, but with an external relationship you again get into the
fact that it’ll have a confidence and external parties can technically
add it. Maybe that’s fine though.
- The tougher one is COA…if we use an embedded
reference, you can’t represent the result of applying the COA. If we use
an external relationship, it implies that the COA taken had some confidence
associated with it, allows others to add it, etc. We could define some
structure, but that structure would look essentially like activity anyway.
Alternatively, we just say we’re not going to support that now and if
people want it they can put it in the description.
I’d be happy either way, just wanted to
explain why it was there.
John
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, August 28, 2017 at 12:34 PM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>,
John Wunder <jwunder@mitre.org>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Event proposal updated
I am also unsure what would be meant
by an "alias" of an event. I understand what it would mean applied
to malware, campaign, intrusion set... but not event...?
I also added a comment, why would we have collected_data... I always thought
this was relationship to observed_data (currently called 'triggered').
This is important because I don't want to have to write the same observed
data twice to have an indicator point at it.
I am actually unsure why this 'activity' construct even needs to exist
as it seems to me it is duplicating the purpose of STIX versioning and
external relationships.
-
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: Trey
Darley <trey@newcontext.com>, "John Wunder (*CONTRACTOR)"
<jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date: 08/28/2017
01:26 PM
Subject: Re:
[cti-stix] Event proposal updated
Sent by: <cti-stix@lists.oasis-open.org>
I was also a detractor on the “alias” property. I don’t really grasp
how it’s used, but as Trey said, if someone can explain it to me, I’ll
happily change my mind.
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
<https://msisac.cisecurity.org/>
<https://www.facebook.com/CenterforIntSec>
<https://twitter.com/CISecurity>
<https://www.youtube.com/user/TheCISecurity>
<https://www.linkedin.com/company/the-center-for-internet-security>
On 8/28/17, 12:09 PM, "Trey Darley" <cti-stix@lists.oasis-open.org
on behalf of trey@newcontext.com> wrote:
On 25.08.2017 20:39:44, Wunder, John A. wrote:
>
> 2. We have three sets of properties that people have suggested we
> might want to exclude for Event in 2.1. Please review these and
> let us know whether they should be included or removed.
> * coa_taken and collected_data (observed data)
> * Financial impact
> * Aliases
>
I was the one questioning the usefulness of the `aliases` property.
Bret says that it's used all the time to characterize Event data. I'd
happily withdraw my objection if someone could give me a concrete real
world example. (Newsflash: I don't know everything. ^_^)
>
> 4. There were two sets of relationships that had a lot of semantic
> overlap and we had trouble writing up separate descriptions:
> * Event had “exploits”, “targets”, and “impacts” relationships
> to Location and Identity. We consolidated that list to
> “targets”, but if people feel we need all three (or two of
> the three) they can be added back…the request though is that
> if you want them added back, you need to provide a good
> description for each one that lets us distinguish them.
>
The `impacts` property is semantically distinct from `targets` insofar
as (at least in my mind) it allows characterization of collateral
(i.e., probably unintended) effects.
--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"The newest computer can merely compound, at speed, the oldest problem
in the relations between human beings, and in the end the communicator
will be confronted with the old problem, of what to say and how to say
it." --Edward R. Murrow
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]