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: [cti] Re: [EXT] Re: [cti] Working Call Recap and action items


If we go down this path, it is going to break a lot of things and assumptions about how we report observations.

It will require a re-think of a lot of other things including Indicators and Sightings and a lot of our existing relationships.

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

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson




From:        Bret Jordan <Bret_Jordan@symantec.com>
To:        Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Piazza, Rich" <rpiazza@mitre.org>
Cc:        "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        04/24/2019 01:35 PM
Subject:        Re: [cti] Re: [EXT] Re: [cti] Working Call Recap and action items
Sent by:        <cti@lists.oasis-open.org>




I think one of the use cases that Sarah brought up and that started this, is that SCOs could exist out side of an Observed Data.  Like:

Threat Actors -> Owns -> Email Address Object (SCO)
Malware -> Creates -> Mutex (SCO)

Bret



From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent:
Wednesday, April 24, 2019 10:07:31 AM
To:
Piazza, Rich
Cc:
Bret Jordan; cti@lists.oasis-open.org
Subject:
Re: [cti] Re: [EXT] Re: [cti] Working Call Recap and action items

 
That is correct Rich - what I am saying is those SCOs, "live" inside that observed-data (as well as perhaps some others).

SCO's don't exist by themselves, they always have at least one container - because that container is where all higher level context and relationships exist, not to the SCOs themselves.


Lets say I "version" that SCO, but I DO NOT version the SDO observed-data. What does that even mean? Does the version cascade up? Should it cascade "down" (if I version the observed-data SDO does it take effect on all related SCOs?) What if the created and modified dates collide (ie the SCOs created date is before the observed-datas), is that valid?


I don't understand how this is supposed to work, and I have not seen anyone write it up. I don't grock the workflow for versioning these and what it achieves that can't be achieved by versioning the SCO.


-
Jason Keirstead
Lead Architect - IBM Security Connect

www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson




From:        
"Piazza, Rich" <rpiazza@mitre.org>
To:        
Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc:        
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        
04/24/2019 12:53 PM
Subject:        
[cti] Re: [EXT] Re: [cti] Working Call Recap and action items
Sent by:        
<cti@lists.oasis-open.org>




Jason wrote:


Another aspect I don't see fully thought-through here is that SCOs do not exist in isolation, they still "live" inside one or more observed-data SDOs. Those SDOs *themselves* have full versioning capabilities.


Is this the general understanding?  This is not the way the editors (Bret and I) have been changing the examples in the specâ

Here is an example:

{
"type": "observed-data",
"spec_version": "2.1",
"id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf",
"created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
"created": "2016-04-06T19:58:16.000Z",
"modified": "2016-04-06T19:58:16.000Z",
"first_observed": "2015-12-21T19:00:00Z",
"last_observed": "2015-12-21T19:00:00Z",
"number_observed": 50,
"object_refs": [
  "ipv4-address--efcd5e80-570d-4131-b213-62cb18eaa6a8",
  "domain-name--ecb120bf-2694-4902-a737-62b74539a41b"
]
}


{
"id": "domain-name--ecb120bf-2694-4902-a737-62b74539a41b",
"type": "domain-name",
"value": "example.com"
}


{
"id": "ipv4-addr--efcd5e80-570d-4131-b213-62cb18eaa6a8",
"type": "ipv4-addr",
"value": "198.51.100.3"
}


{
"type": "relationship",
"id:" "relationship--58b912ad-cbb0-41e4-9c6b-d0824fed0d3e",
"spec_version": "2.1",
"created": "2015-12-21T19:00:00Z",
"modified": "2015-12-21T19:00:00Z",
"relationship_type": "resolves-to",
"created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
"source_ref": "domain-name--ecb120bf-2694-4902-a737-62b74539a41b"
"target_ref": "ipv4-address--efcd5e80-570d-4131-b213-62cb18eaa6a8"
}









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