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: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object


+1.

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Kelley, Sarah E." <skelley@mitre.org>
Date: Tuesday, July 24, 2018 at 2:11 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

Gary,

 

As to the path forward, I have a few suggestions.

 

The proposal youâre bringing to the community right now is the perfect use case for the enhancements process weâre trying to get ironed out. If we already had enhancements done (as in formally voted on and in the specification), I would tell you to absolutely go use that, because this situation is exactly what enhancements are designed for. Since the enhancements process isnât yet done (in the specification), I would like to nudge you (and any other org/individual in a similar situation) to please help us iron that process out. The faster we finalize the enhancements process, the sooner we can stop having these types of conversations.

 

As a second suggestion, I would propose that you start a mini-group to work on your proposal for suspicious-activity/Incident/event (whatever you want to call it). That way, while weâre finalizing the enhancements process, you can still be making forward progress on your contribution.

 

I realize that the responses today might have seemed like you were being âshut downâ, and I apologize if thatâs the case. The motivation behind that was simply because of the importance of getting the STIX CSD approved so we have something we can point the external community to so we can show weâre on the path to releasing a new version. Given the difficulty we had getting people to review and vote on the interop documents, we felt it was important to draw peopleâs attention to the CSD Process so they realize how vital it is.

 

I hope this helps.

 

Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation

703-983-6242

skelley@mitre.org

cid:image006.png@01D0A90C.2B5B2680

 

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> On Behalf Of Katz, Gary CTR DC3/TSD
Sent: Tuesday, July 24, 2018 12:49 PM
To: Kelley, Sarah E. <skelley@mitre.org>; Struse, Richard J. <rjs@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

Sarah,

   Thank you for breaking down these points for everyone (including myself), and I do truly appreciate the hard work that leadership is putting in to get out the current CDS.  I feel I should clarify the driving forces behind this proposal.

 

First, in CDS 1, we are not including a complete Malware object.  This is partially because my team (as requested by the TC) implemented the Malware proposal object as part of the TCâs process.  During this implementation we uncovered what we believed to be a couple of issues with the design (which is the main purpose of doing an implementation).  We also developed solutions to those issues, namely that the samples and results must use cyber observables to represent the data and we proposed that the Malware object reference Observed Data objects that would hold this cyber observable data to have a consistent design pattern for including observed data.  There was a request for additional work to be done to show that this design pattern would hold for Infrastructure and Incident (Suspicious-Activity) objects.  The proposal I put forth, shows how this design pattern would hold for a Suspicious-Activity object and therefore gets us one step closer to getting a Malware Object included in the standard.

 

The second reason is more selfish.  One of the key missions of my organization is to receive and share Incident information with our partners.  My leadership would like to move towards using STIX to share this information, but we need an Incident object to do so.  Understanding that this may not be the most important object for the rest of the community, we are attempting to do this work mostly on our own, but it would be nice if we can send out drafts of our work and receive inputs from the community. 

 

We do need to understand what the correct path is to closure.  I currently see 3 options. I am fine with whichever, but someone needs to inform us which path should be taken.

  1. Work on the Incident (suspicious-activity) object with any other interested CTI members, meeting the requirements for when an object is considered âDONEâ and work with the TC to have it included in the standard.
  2. Work on the Incident (suspicious-activity) object with any other interested CTI members, and use it as a custom object.
  3. Work on the Incident (suspicious-activity) object without any knowledge or inputs from other CTI members, and use it as a custom object.

Please let us know what the correct path is. 

 

In your last paragraph you stated that organizations that wish to add new objects or features should take one of three options, including âcomment on the email listâ.  This whole discussion started because I attempted to âcomment on the email listâ and was shut down.  I understand that there are specific objects that the TC is focusing on, but my organization has a near-term need to represent this data and right now I am not sure what the correct method is to receive feedback when the group is told we canât focus on this.

 

Thanks,

    -Gary

 

From: Kelley, Sarah E. <skelley@mitre.org>
Sent: Tuesday, July 24, 2018 10:30 AM
To: Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>; Struse, Richard J. <rjs@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

There has been a lot of confusion around this situation, so let me try to clarify a few things.

 

  1. We did have a vote on a document in Utah at the F2F. You can find it here (https://docs.google.com/document/d/1pFL8gZpoU_iSRE4vCcZmmd0RG0I-hhUxGGzzoQlYMk8/edit) What was agreed in that document was a process for getting 2.1 out of the door, including the process Gary describes in his email AND a list of objects to which that process applied, which were the objects we had slated for release in 2.1. (CSD01: Breaking changes, confidence, i18n, location, malware, note, opinion, CSD02: IEP, Grouping, COA, Assertion, Pattering extensions, CSD03: infrastructure)
  2. We also had a ballot. You can find it here (https://www.oasis-open.org/apps/org/workgroup/cti/download.php/62810/Proposal%20%231.pdf) The major change from the agreement in Utah to the one in the ballot was just to combine the list for CSD02 and CSD03 into âSTIX 2.1 CSD 0X-TBDââ so as not to get bogged down based on when the remaining objects were completed.
  3. We are attempting to document and then finalize a full Enhancements proposal for going forward, specifically to be included in version 2.1 so it can be used for 2.2+. This new process has not yet been agreed to or voted on, though it will likely contain much of what was voted on for the 2.1 path forward. The rest of what is involved (will there be a public registry? Can people outside the TC use it? Etc..) is still under discussion.

 

The goal here isnât to stop innovation or to shut down the creation of new objects. We are trying to push very hard to get the enhancements process finalized so that things like this proposal have a consistent process they can follow thatâs repeatable and works for everyone. We also need to keep in mind that the more objects we attempt to finish and push into 2.1, the further out it will push our eventual release of a full committee specification (CS).

 

For anyone/organization that would like to add new objects or features, I would urge you to join the #enhancements channel in Slack, join the mini-group calls (which will hopefully be set up soon), and comment on the email list so we can get this process nailed down and everyone can moved forward together.

 

Thanks,

 

 

Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation

703-983-6242

skelley@mitre.org

cid:image006.png@01D0A90C.2B5B2680

 

From: Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>
Sent: Tuesday, July 24, 2018 9:25 AM
To: Struse, Richard J. <rjs@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Kelley, Sarah E. <skelley@mitre.org>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

Rich,

  The decision to push an Incident object to an unknown date in the future was prior to having a process for introducing new objects.  We now have a STIX enhancement process.  It was voted on by the TC.  I am planning to follow that process and my expectation is that the TC should follow the process that was agreed upon as well and not unilaterally shut down the creation of new objects. 

 

The following was decided at the face-to-face and had a ballot.  A new object is considered Done when:

 

Doneâ - A new feature is considered done when it:

1: has at least 2 independent organizations using at least 2 separate code bases running at

least POC code with real or semi-real data that can interoperate.

2: has all normative specification text is complete

3: is covered by one or more interoperability tests and at least the 2 POC implementations

pass those tests.

 

 

Posting for comments on the Suspicious-Activity object was to work towards completing task 2. 

I have 2 independent organizations building 2 separate code bases to begin sharing these objects using real or semi-real data.

We are currently working towards interoperability tests. 

 

If you are now suggesting that the TC will not be following the processes decided upon, please let us know.  This is not to detract from the hard work that the chairs are doing to get out current CSD or the work that we are doing to complete other objects, but TC members should be able to work (and encouraged to work!) on the objects that are important to their organizations and should have a known path for getting their work added to the standard as long as it meets the agreed upon process and fits a known gap. 

 

If I have misunderstood your comments, please let me know and I apologize in advance if that is the case.

 

Thanks,

    Gary

 

 

From: Struse, Richard J. <rjs@mitre.org>
Sent: Tuesday, July 24, 2018 8:57 AM
To: Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Kelley, Sarah E. <skelley@mitre.org>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

Gary,

 

Thanks for taking the time to put this together but you may recall that the TC decided to defer a full-blown Incident-like object after STIX 2.1.  We discussed Incident for months and it was clear that we were just going round-and-round.

 

Right now we have a lot of work to do in getting the objects and features that the TC agreed to deliver in STIX 2.1 defined, implemented and reviewed. I would therefore ask that we focus on that.  As we define the STIX enhancement process, we could use that to experiment with the object you have proposed.

 

Thanks,

Rich

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil>
Date: Tuesday, July 24, 2018 at 8:43 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kelley, Sarah E." <skelley@mitre.org>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Richard Struse <rjs@mitre.org>
Subject: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

Apologize for any confusion,

      To clarify, this is another attempt at getting an Incident/Event object through.  I am really starting to feel that we should just go with the name âIncidentâ because it is confusing everyone having âEventâ or âSuspicious-Activityâ as the object.  We had originally stayed away from âIncidentâ because we were worried about the bad connotations with the word, but it seems like alternative names are just confusing everyone.

 

    Please let me know if people would rather that this be renamed âIncidentâ for clarity.

 

Thanks,

    -Gary

 

Ps. Document should now be updatable. 

 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Tuesday, July 24, 2018 8:17 AM
To: Kelley, Sarah E. <skelley@mitre.org>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; cti-stix@lists.oasis-open.org; Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>; Struse, Richard J. <rjs@mitre.org>
Subject: [Non-DoD Source] RE: [cti-stix] FW: Suspicious Activity Object

 

Agree Sarah, somewhat.

The object seems like a hybrid of Incident/Event, "Group", and Intrusion Set. This is the challenge i have, it seems like it is trying to do 3 jobs.

If the object is just trying to describe an Incident, then I would argue a lot of these fields should not be there, or at the very least should be aligned with Intrusion Set, because right now there is confusing overlap.

-
Jason Keirstead
Lead Architect - IBM Security Cloud
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown




From:        "Kelley, Sarah E." <skelley@mitre.org>
To:        Allan Thomson <athomson@lookingglasscyber.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Katz, Gary" <gary.katz.ctr@dc3.mil>
Cc:        "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Struse, Richard J." <rjs@mitre.org>
Date:        07/24/2018 08:41 AM
Subject:        RE: [cti-stix] FW: Suspicious Activity Object
Sent by:        <cti-stix@lists.oasis-open.org>





To me this object seems a lot closer to Incident/Event than it does to an intrusion set. It looks like itâs trying to describe a specific instance of suspicious activity, rather than an ongoing, long-term grouping of activity/SDOs. That being said, we worked on Incident/Event for a long time without being able to drive the conversation to a successful conclusion, at which point we agreed to punt it until after 2.1.
 
This seems like it could be a good candidate for the STIX enhancement process, which I realize is still ill defined. Perhaps the focus should be on finalizing the enhancement process so that suggestions like this can be run through that process to see how they might work.
 
Thanks,
 
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
skelley@mitre.org

 
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> On Behalf Of Allan Thomson
Sent:
Monday, July 23, 2018 10:31 PM
To:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Katz, Gary <gary.katz.ctr@dc3.mil>
Cc:
cti-stix@lists.oasis-open.org; Struse, Richard J. <rjs@mitre.org>
Subject:
Re: [cti-stix] FW: Suspicious Activity Object

 
I generally agree with Jasonâs questions and concerns.
 
Maybe a different way to put the concerns/questions is this.
 

  • What motivated this object to be defined where an intrusion set did not already support the content?

 
If the differences are minimal, then justifying a new object weighting pros/cons vs just adding to existing object needs to be done.
 
Allan Thomson
CTO (+1-408-331-6646)
LookingGlass Cyber Solutions
 
From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date:
Tuesday, July 24, 2018 at 2:03 AM
To:
"
Gary.Katz.ctr@dc3.mil" <Gary.Katz.ctr@dc3.mil>
Cc:
"
cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Struse, Richard J." <rjs@mitre.org>
Subject:
RE: [cti-stix] FW: Suspicious Activity Object

 
I got in - commenting seems disabled so I will post them here

In general - having a hard time with the borderline between this object, and an intrusion set?

The difference seems to be that, for Intrusion Set, we know who they are. For this one, we don't. If that is the main difference, why are there so many distinct top level properties?

A Suspicious activity object allows individuals to group information together related to malicious activity, such as an incident, attempted incident or suspicious activity observed outside of their network.

An Intrusion Set is a grouped set of adversarial behaviors and resources with common properties that is believed to be orchestrated by a single organization. An Intrusion Set may capture multiple Campaigns or other activities that are all tied together by shared attributes indicating a common known or unknown Threat Actor.


REoutcome / suspicious-activity-outcome-ov-

- Suggest the names just be "successful" and "unsuccessful", as "successful-compromise" assumes already the objective was compromise, which perhaps it was not.

- Should "in progress" be an option? Or is that "unknown"?

RE compromise-type/ suspicious-activity-compromise-type-ov-

       - Shouldn't this same type of data be able to be used in Intrusion Set? Whats the difference between this and "goals" of intrusion set... seems fuzzy?  I know we wanted to encode "destrictive" on Intrusion Set in the past somehow...

RE observation-refs- Shouldn't these be sightings? This object is the epitome of a sighting is it not?

-
Jason Keirstead
Lead Architect - IBM Security Cloud
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown




From:        
"Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil>
To:        
"Struse, Richard J." <
rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:        
"
cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:        
07/23/2018 12:40 PM
Subject:        
RE: [cti-stix] FW: Suspicious Activity Object






Thanks Rich

From:
Struse, Richard J. <
rjs@mitre.org>
Sent:
Monday, July 23, 2018 11:11 AM
To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com>; Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>
Cc:
cti-stix@lists.oasis-open.org
Subject:
[Non-DoD Source] Re: [cti-stix] FW: Suspicious Activity Object

The link was messed up:
https://docs.google.com/document/d/1I5Cgqfk1Krt9EnYJZcyTLS3c5BtZ5uqvTDXI_i7OJrU/edit

From:
<cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date:
Monday, July 23, 2018 at 10:46 AM
To:
"Katz, Gary" <
gary.katz.ctr@dc3.mil>
Cc:
"
cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject:
Re: [cti-stix] FW: Suspicious Activity Object


I can't access the document; are the permissions open to the public?

-
Jason Keirstead
Lead Architect - IBM Security Cloud
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown




From:        
"Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil>
To:        
"
cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:        
07/23/2018 11:10 AM
Subject:        
[cti-stix] FW: Suspicious Activity Object
Sent by:        
<
cti-stix@lists.oasis-open.org>







It seems I was sending these emails to the wrong distro, hopefully this
works this time.  Interested in everyone's thoughts


Below is a link to the Suspicious Activity Object proposal.  As requested I
updated the object to use the embedded reference, similar to the Malware
proposal rather than using a relationship.  Comments welcome.  


https://docs.google.com/document/d/1I5Cgqfk1Krt9EnYJZcyTLS3c5BtZ5uqvTDXI_i7O
JrU/edit?usp=sharing





[attachment "image001.jpg" deleted by Jason Keirstead/CanEast/IBM]

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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