[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Asset TLO discussion
Going to the Triples direction makes things easier (it's a RDFa/JSON-LD orientation) where your relationship is a predicate with clear meaning*. Use of top level concept/class (abstraction, or ontology hierarchy) helps to quickly represents use cases, before going to the details of subclasses. Considering Asset as potentially Organization, Person, IT-Assets Then IT-Assets as Hardware, Software... Software as Tools, Websites... Website as Forums... Again, this, represented as an Ontology, or UML diagrams, or others, simplifies greatly the human reasoning before focusing on the low level format representation of the concept/objects/properties... Again, before reinventing the wheel, and waisting time discussing things that other people already spent a lot of time on, I suggest leveraging existing work for the various pieces of our puzzle. (especially when it already comes with a data representation format) Here, again, this should be reused: https://scap.nist.gov/specifications/ai/ So I hope than using the Asset concept will help prototyping quickly use cases, and we could benefit of using/dispatching our resources (members), to focus on the use cases/objects where they are SMEs (we are not experts in anything/everything). IMHO that would be more efficient To go further on Assets (without arguing against all reasoning and conceptualization errors I've read); - Yes it's useful to know the business value (for the Threat_Actor/OPFOR) of an asset/infrastructure used maliciously - "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 is inexact. * Context is important. Because, i.e. in the context of a Red Team exercise, an Organization would use its own Assets to target its own Assets (so Red and Blue Assets will definitely share common properties) Furthermore, the Asset concept, will help (if designed properly, with categorization, grouping or tagging...) for the automated actions (ref. COAs) e.g. https://github.com/phantomcyber/playbooks/tree/2.0 2016-06-17 0:46 GMT+03:00 Terry MacDonald <terry.macdonald@cosive.com>: > 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> 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 <cti-stix@lists.oasis-open.org> on >> behalf of Terry MacDonald <terry.macdonald@cosive.com> >> Sent: Wednesday, June 15, 2016 4:00 PM >> To: John A. Wunder >> Cc: 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> 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> 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]