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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: RE: [Non-DoD Source] RE: [cti] Definitions for Campaigns, Intrusion Sets and Threat Actors


Jason, 
  It seems to me that that would do the opposite.  We'd now make things ambiguous to the tool creators which would then lead to them making things ambiguous to the users who would then enter things into the tools (and thereby share) incorrectly.  We'd also have this one object out there which looks different from all other objects and needs to be used differently than all other objects.  It would have an extra layer of abstraction that would need to be accounted for in every tool built.  I'm sorry but I don't see this approach working well in practice.

-Gary

-----Original Message-----
From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com] 
Sent: Tuesday, May 24, 2016 11:19 AM
To: Katz, Gary CTR DC3/DCCI
Cc: 'Back, Greg'; 'cti@lists.oasis-open.org'; Mark Davidson
Subject: [Non-DoD Source] RE: [cti] Definitions for Campaigns, Intrusion Sets and Threat Actors

What if we had an object with a different name - lets call it fooferah for now.

Then that object had a "fooferah-type" that pointed at a closed vocab - which had entries "campaign", "intrusion set", other "fooferah" objects, and possible other in the future. 

This object is allowed to have all of the required relationship types to TTPs, indicators, threat actors, etc. And can have optional life-cycle type of attributes.

This makes it not ambiguous at all to an analyst - it's one or the other. But, it eliminates a superfluous TLO from the model.

We would just need to name this TLO.

-
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 


Inactive hide details for "Katz, Gary CTR DC3---05/24/2016 11:51:48 AM---Greg, It's an interesting point and I had original"Katz, Gary CTR DC3---05/24/2016 11:51:48 AM---Greg, It's an interesting point and I had originally considered it. The information captured wi

From: "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil>
To: "'Back, Greg'" <gback@mitre.org>, "'cti@lists.oasis-open.org'" <cti@lists.oasis-open.org>
Cc: Mark Davidson <mdavidson@soltra.com>
Date: 05/24/2016 11:51 AM
Subject: RE: [cti] Definitions for Campaigns, Intrusion Sets and Threat Actors Sent by: <cti@lists.oasis-open.org>

________________________________




Greg,
   It's an interesting point and I had originally considered it.  The information captured within a Campaign object and what is captured within an Intrusion Set object are very similar.  The issue is that the constructs mean two different things.  At the end of the day, what we are representing in a STIX format needs to be displayed to analysts in a user interface.  I apologize for the large amount of text below, but at the end of it I do have a compromise.

  Anyone who has worked with intel analysts (and I realize most of you have) know that they are extremely literal.  Their job is to make sure that they fully understand the facts and what something means.  If they write something in a document, they do their best to make sure that what they have written has the correct caveats and will be interpreted by all readers correctly.  I remind everyone of this, because I have made the mistake in the past of asking analysts to respond to requests where any other person would understand what I meant, but an analyst analyzes the request and comes back with questions or caveats to consider.

  The issues arises that while we might be able to represent Campaigns and Intrusion Sets in a single object, we would not be able to easily digest STIX from an external source and distinguish to the analyst what is a Campaign and what is an Intrusion Set.  To the analyst, they are not the same thing.  If they need to look through a list of Intrusion Sets and apply attribution to an Incident, they don't want to see Campaign names coming up.  That is a separate distinction.  

  Campaigns are identified fairly quickly.  Hey, I just had 5 spear phishing emails sent to me by partner organizations that all look very similar.  There's a campaign going on.  Identifying a new Intrusion Set is much more meticulous.  There is a process.  They need to prove to the community that it really is a new Intrusion Set and that the activity is not really attributed to something already known.  The analyst typically needs to identify at least 3 of the 4 points in the diamond model.   Most organizations track how many new Intrusion Sets they have identified to the community and named as a source of pride.  There are naming boards to come to a consensus on the names.  

  All of this is to say that the analyst community views these as different things with different controls attached to the creation and usage of these objects.  Which makes me believe combining them would result in a negative reaction from the analysts.  With that being said, I could see us having one object definition in the documentation that under the 'type' field has the option of 'campaign' or 'intrusion-set' and in the description of the object we provide definitions for both and when to use which object.

Thoughts?

-----Original Message-----
From: Back, Greg [mailto:gback@mitre.org]
Sent: Tuesday, May 24, 2016 10:12 AM
To: 'cti@lists.oasis-open.org'
Cc: Mark Davidson; Katz, Gary CTR DC3/DCCI
Subject: [Non-DoD Source] RE: [cti] Definitions for Campaigns, Intrusion Sets and Threat Actors

I'm still trying to wrap my head around how these concepts relate, based on my limited experience in operational government environments. 

I (believe I) understand the difference, particularly in (U.S.) government circles, between one or more "campaigns" and the encompassing intrusion set(s). From a data modeling perspective, though, I wonder if it makes sense to consider intrusion sets to just be a "meta-campaign", and allow a STIX Campaign to be made up of "subcampaigns". From my perspective, both campaigns and intrusion sets can be loosely defined as "collections of activity determined by an analyst to be related based on shared TTPs (tools, infrastructure, targets, themes, etc.)". The exact method of that determination can vary wildly based on the source (and we can and probably should support the representation of those assertions in STIX), but I'm hesitant to encode the distinction between the more general term "campaign" and the more specific term "intrusion set" directly into the STIX data model. As a concrete example, if one STIX producer considers a set of activity to be a "campaign" and another (likely US gov't) producer considers it to be an "intrusion set", it's simpler and easier to reconcile in STIX if you can assert a relationship between the two campaigns than saying "campaign X is the same as intrusion set Y".

On top of that is the idea that some organizations consider "Threat Actors" to be individuals who can move between groups/campaigns/intrusion sets, while others consider the group itself to be the Threat Actor. It's likely that STIX will need to support both models. In some ways, it's similar to Intrusion Set/Campaign in that you can have "meta threat actors" (groups) which are made up of "sub threat actors" (individuals).  

Gary, do you think it would be possible for government users to use the existing "Campaign" construct (perhaps with modifications) to handle intrusion sets (where an Intrusion Set is just a special type of Campaign)? I realize the terminology itself may cause confusion, but if you get past that, are the data types at least compatible?

Just my 2 cents.

Greg






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