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] Re: [EXT] Re: [cti-stix] Event proposal updated


>I think there is a very distinct difference, semantically, between recording a COA that was taken and its outcome, and a suggestion for taking a COA to resolve an incident. 

 

[sdb] Strongly agree.

 

>I think we need to be super careful about just assuming that STIX is and will only be an exchange format.  There will probably be a lot of small start-ups that will use the STIX data model as their data model.  

 

[sdb] Strongly agree. It is also important to note that “exchange format” itself is a bit ambiguous as exchange between tools, systems, groups or people within an organization is not necessarily the same thing as exchange between orgs. Both are extremely important use cases for STIX.

 

 

You should be seeing the FireEye input I promised VERY soon. Just tweaking a diagram a bit. We hope that it will be useful input for many of the issues being discussed lately.

 

 

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Monday, August 28, 2017 at 3:53 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, Trey Darley <trey@newcontext.com>
Subject: [cti-stix] Re: [EXT] Re: [cti-stix] Event proposal updated

 

I think there is a very distinct difference, semantically, between recording a COA that was taken and its outcome, and a suggestion for taking a COA to resolve an incident. 

 

I think we need to be super careful about just assuming that STIX is and will only be an exchange format.  There will probably be a lot of small start-ups that will use the STIX data model as their data model.  

 

With this said, than if you believe that the STIX Event is for transport and exchange of information, then it will by populated post event.  Which means, even if other groups in the organization did stuff, all of that information could be recorded by a single entity. 

 

Observed Data is another sticky point.  Do you really want some third party adding observed data blobs to your incident ?  Do you really want confidence scores on it? 

 

Bret


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Monday, August 28, 2017 11:27:13 AM
To: Wunder, John A.
Cc: cti-stix@lists.oasis-open.org; Sarah Kelley; Trey Darley
Subject: [EXT] Re: [cti-stix] Event proposal updated

 

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.


. . . . .





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]