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


Can’t an asset become malicious infrastructure at some point and then stop when its cleaned up?

For me, there are all network connected systems that perform different functions over time and may become infected or used to attack others. But they’re really all just network connected systems.

How they are referred to and what context determines whether they are malicious or not.

I would prefer a single object class that represents ‘networked systems’ and that can be referenced by relationships to campaigns, threat actors, indicators….etc.

It’s the relationship to the other objects that defines the context of malicious or asset.

allan

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Monday, June 20, 2016 at 5:09 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Asset TLO discussion

Hm, that’s what I was meaning to describe…maybe I’m missing something? I see it like this:


1.      Malicious Infrastructure (used to be Infrastructure part of TTP): describes a particular adversary infrastructure and is the central object which has relationships to/from it when describing infrastructure. As an example, the delivery infrastructure used by a particular Locky campaign would be represented as this object.

a.       Campaign => Uses Infrastructure

b.      Threat Actor / Intrusion Set => Uses Infrastructure

c.       Indicator => Indicates Infrastructure

d.      Observation => Evidence Of Infrastructure (??)

e.       Asset => Part of Infrastructure

2.      Asset: I would focus this on IT assets, so describes a particular system (VM or physical) owned by an organization. As an example, my MITRE laptop would be an asset.

a.       Asset => Affected By Incident

b.      Asset => Part of Infrastructure

So, my broader point is that I think we need both TLOs (we should not merge them as discussed in Rich P’s original e-mail) and that they serve these separate purposes.

John

From: Paul Patrick <ppatrick@isightpartners.com>
Date: Friday, June 17, 2016 at 12:41 PM
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Asset TLO discussion

John,

Be very careful as it sounds like your describing what the Infrastructure TTP is intended to represent.


Paul Patrick


From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Thursday, June 16, 2016 at 9:45 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Asset TLO discussion
Resent-From: <Paul.Patrick@FireEye.com>

I agree with this. It also lets you express confidence that an asset is actually part of that infrastructure.

I think for 2.0 and in general near-term most usage of infrastructure will be relatively abstract…we track infrastructure not by literally listing every domain that’s a part of it but rather by generally describing the DGA or IP blocks that particular attacks use. Then, people use indicators to point to the infrastructure and, in some cases, say that an asset owned in an incident was a part of the infrastructure for an attack.

I’m curious what Gary thinks about this.

John

From: Terry MacDonald <terry.macdonald@cosive.com>
Date: Thursday, June 16, 2016 at 5:46 PM
To: Bret Jordan <bret.jordan@bluecoat.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
Subject: Re: [cti-stix] Asset TLO discussion


Nope. A malicious infrastructure object with many assets related via separate relationships. We would need to use relationships as third parties would need to be able to associate assets as part of the malicious infrastructure if they believe it is.

Cheers
Terry MacDonald
Cosive
On 16/06/2016 7:02 PM, "Jordan, Bret" <bret.jordan@bluecoat.com<mailto:bret.jordan@bluecoat.com>> wrote:

Are you talking about Asset with a bunch of fields and a Malicious-Infrastructure that has an array of Asset_refs?



Bret

________________________________
From: cti-stix@lists.oasis-open.org<mailto:cti-stix@lists.oasis-open.org> <cti-stix@lists.oasis-open.org<mailto:cti-stix@lists.oasis-open.org>> on behalf of Terry MacDonald <terry.macdonald@cosive.com<mailto:terry.macdonald@cosive.com>>
Sent: Wednesday, June 15, 2016 4:00 PM
To: John A. Wunder
Cc: cti-stix@lists.oasis-open.org<mailto:cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Asset TLO discussion


I am fine with using a relationship of 'used maliciously' along with an asset, or also with a malicious infrastructure, asset and used maliciously relationship.

The asset and relationship combo seems more correct, but the malicious infrastructure, asset and relationship could be more pragmatic.

One option is to use the malicious infrastructure object as a summary (grouping) object, allowing multiple individual assets to be associated with it CX and the malicious infrastructure object acting as a group of infrastructure. This would allow a threat actor to have one or more groups of malicious infrastructure they use, and the list of assets to change within that group. It would also allow for multiple threat groups sharing malicious infrastructure, and would allow for assets to be part of multiple malicious infrastructure groups.

Does that sound useful?

Cheers
Terry MacDonald
Cosive
On 15/06/2016 10:37, "Wunder, John A." <jwunder@mitre.org<mailto:jwunder@mitre.org>> wrote:
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<mailto:cti-stix@lists.oasis-open.org>> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com<mailto:bret.jordan@bluecoat.com>>
Date: Tuesday, June 14, 2016 at 7:05 PM
To: Jerome Athias <athiasjerome@gmail.com<mailto:athiasjerome@gmail.com>>, Rich Piazza <rpiazza@mitre.org<mailto:rpiazza@mitre.org>>
Cc: "cti-stix@lists.oasis-open.org<mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org<mailto: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<mailto:cti-stix@lists.oasis-open.org> <cti-stix@lists.oasis-open.org<mailto:cti-stix@lists.oasis-open.org>> on behalf of Jerome Athias <athiasjerome@gmail.com<mailto:athiasjerome@gmail.com>>
Sent: Tuesday, June 14, 2016 1:53 PM
To: Piazza, Rich
Cc: cti-stix@lists.oasis-open.org<mailto: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<mailto: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 ☺

<<attachment: winmail.dat>>



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