OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] Event proposal updated


I agree with Gary.

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Katz, Gary CTR DC3\DCCI" <Gary.Katz.ctr@dc3.mil>
Date: Monday, August 28, 2017 at 1:30 PM
To: "Wunder, John A." <jwunder@mitre.org>, 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>
Subject: RE: [cti-stix] Event proposal updated

 

IMO If we are going to include Aliases I would suggest making it a dictionary.  For example, when individuals submit an event to us, we assign a name to the event.  They may have also placed the information into some other sharing platform or organization that would also name the event differently.  Aliases can be useful, but if the dictionary doesn’t say what platform the alias name should be used in, it becomes difficult for a piece of software to do anything with it.  I have also seen event names used for very well-known events, such as Aurora, the Sony hack, OPM, etc.

 

Just my 2 cents.

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Monday, August 28, 2017 12:56 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc: cti-stix@lists.oasis-open.org; Trey Darley <trey@newcontext.com>
Subject: [Non-DoD Source] Re: [cti-stix] Event proposal updated

 

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.


. . . . .




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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]