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] Asset TLO discussion


We had to discuss this in twigs and ended up with the solution Bret is suggesting (using relationships to indicate how the infrastructure is being used). We also at one point had discussed whether malicious infrastructure and asset were separate but infrastructure could be made up of many assets.

 

That said, over the past few months, one thing I’ve started to realize is that just because two things might be “the same” in some cases if we’re saying very different things about them it’s OK for them to be different TLOs. Just because you can have an IP address in an observation and an indicator doesn’t mean we should merge those objects.

 

For asset and malicious infrastructure, I wonder if we really represent the same things for both of those concepts. For example, do we need the capability to represent DGA algorithms for malicious infrastructure? Or a list of a crapton of AWS IPs? If so, does that mean we add that capability to asset? And if we want to represent business value for an asset, does that mean it’s now a field you can use when representing malicious infrastructure?

 

My other concern with the relationship approach is that it means you need a relationship on the TLO for it to make any sense. This, to me, gets away from the concept of building blocks. You need to either:

-          You have an indicator pointing to an “asset” and that means you assume it’s malicious infrastructure…which means indicators must always indicate malicious things, which I thought we didn’t want to do

-          Or, you relate the asset to a campaign and at that point you say it’s being used by that campaign. But, this means that in order to share information about malicious infrastructure you also need to share campaign information. This seems bad to me.

 

So I do think it’s workable to have asset and malicious tool merged, but at this point my preference would be for them to be separate. Yes, there will be some overlap and maybe in some cases you’ll have the exact same computer as both an asset and malicious infrastructure…in that case, just use a relationship to say that.

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, June 14, 2016 at 7:05 PM
To: Jerome Athias <athiasjerome@gmail.com>, Rich Piazza <rpiazza@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Asset TLO discussion

 

I do not think we should use a boolean flag to say an Asset is malicious.  As that means that Asset is always malicious.  What we talked about today on the call was collapsing down Asset and Malicious-Infrastructure in to a single Asset object... Then using the relationships to tie an Asset to a Campaign or Threat Actor with a verb link "used maliciously".  This would enable us to tie the relationship to a point in time and assign a confidence score to it.

 

Bret

 

 


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias <athiasjerome@gmail.com>
Sent: Tuesday, June 14, 2016 1:53 PM
To: Piazza, Rich
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Asset TLO discussion

 

Asset is a top level concept (note the difference with object (or subject wich is potentially better term semantically for what is currently called object...))

 

I tried to highlight that as a concept, an infrastructure could be a target/victim asset in one context (i.e. For one Organization) or/and a TTP asset in another context (or Organization)

The point being that it should be avoided to have the same concept/object called differently in various places/objects when the concept is the same, and the only difference is the 'boolean' malicious or not

Org A could use a laptop to target a laptop of Org B

Is laptop A a TTP and laptop B a Target? 

(Laptop A is an asset of Org A. Laptop B is an asset of Org B)

(Replace laptop by infrastructure...)

 

IMHO they would have the same properties

(Eg IP address)

 


On Tuesday, 14 June 2016, Piazza, Rich <rpiazza@mitre.org> wrote:

On today’s working call the topic of the Asset TLO came up.  Currently, the Asset TLO  is described in the “Potential TLO” google doc (https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4 ), because that is where the text is located concerning TLOs that aren’t definitely in 2.0.  As Bret mentioned, much of that text is boilerplate…

 

Last week, I sent out some email discussing Incident, another TLO that is in the same state, which also included discussions of the Asset TLO.  It is thought that those two TLOs are connected such that both or neither should be in STIX 2.0.  The point of that email was to level-set everyone, summarizing what these two concepts were in STIX 1.2 and making comments and posing questions concerning what we need to discuss in order to include these TLOs into STIX 2.0.

 

Gary Katz brought up an aspect of discussion that I hadn’t thought of – how does Asset relate to Malicious Infrastructure, another potential TLO.  The consensus on the call, at least, was that these two potential TLOs concepts are too similar, therefore either could be used to represent some object – violating a 2.0 design goal.

 

I think that is more due to their colloquial definitions.  Returning to STIX 1.2, these were very different concepts, as Malicious Infrastructure was a type of TTP, and Asset was some object that was compromised by an Incident.  In other words, some object to be used in an attack as opposed to some object that WAS attacked (although they may be the same underlying object).  Put another way, Malicious Infrastructure was concerned more with HOW some infrastructure was used (e.g., as a botnet, C2 server, etc).  Asset was more about WHAT the object was, e.g., a laptop owned by a customer. ).  It is important to note that each of these had a field to describe characteristics of the object (e.g., IP_Address) using CybOX.

 

Do we need to maintain this distinction in STIX 2.0?  Can we collapse both of these concepts into one?

 

Let the conversation begin J

 



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