RE: [EXT] Re: [cti] Possible Changes to Observed Data

Since the whole reason weâre contemplating changing how observed data works is so that it fits for new use cases like malware and infrastructure, Iâd like to suggest that we should hold off on making a decision on how to change observed data until we know that it will actually work with these new proposed objects. Since we pushed malware from CSD01, and infrastructure was never in it, I think we should hold off on making any changes to the observed data object until we can work through these objects at the same time. Otherwise we could wind up making changes now that ultimately will need to be changed again if they donât work for malware/infrastructure, etc.

Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation

703-983-6242

skelley@mitre.org

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan
Sent: Wednesday, August 15, 2018 3:31 PM
To: John-Mark Gurney <jmg@newcontext.com>
Cc: Kirillov, Ivan A. <ikirillov@mitre.org>; cti@lists.oasis-open.org
Subject: [cti] Re: [EXT] Re: [cti] Possible Changes to Observed Data

John-Mark,

I think the idea is that Malware and other things like it will use embedded relationships to observed data or something like observed data.

Bret

Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050

On Aug 15, 2018, at 10:55 AM, John-Mark Gurney <jmg@newcontext.com> wrote:

Kirillov, Ivan A. wrote this message on Wed, Aug 15, 2018 at 13:29 +0000:

Iâm OK with #1 as long as we understand the implications of doing this and that weâre changing the definition of Observed Data that weâve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances without specifying the time window during which the data was observed and how many times it as observed during that window?

The changes made had no requirement that first/last_observed be present
when number_observed is present.

We also still havenât changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.

Only if we use the observed data object, the related definition is only
in observed-data, not in observable-objects.

Current malware uses observable-objects directly, and so no related
requirement.

From: <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org>

Date: Wednesday, August 15, 2018 at 6:19 AM

To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com>

Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>

Subject: Re: [cti] Possible Changes to Observed Data

Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.

However, I feel #3 is ultimately (2.2?) the right answer. Remember in STIX 1.x when we conflated observed data and patterns because they âkindaâ looked the same?

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>

Date: Wednesday, August 15, 2018 at 8:02 AM

To: Allan Thomson <athomson@lookingglasscyber.com>

Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>

Subject: Re: [cti] Possible Changes to Observed Data

I support #1.

I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily consumed by humans.

-

Jason Keirstead

Lead Architect - IBM.Security

www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown

From:        Allan Thomson <athomson@lookingglasscyber.com>

To:        "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>

Date:        08/14/2018 06:42 PM

Subject:        Re: [cti] Possible Changes to Observed Data

Sent by:        <cti@lists.oasis-open.org>

I support #1 -> #2 in that order.

Although I donât really see a need for #2 and therefore am primarily supportive on #1.

I agree with Johnâs perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new ârelaxedâ observed data object.

That is why I think #1 is also the best course of action.

Regards

allan

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>

Date: Tuesday, August 14, 2018 at 2:38 PM

To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>

Subject: Re: [cti] Possible Changes to Observed Data

I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that itâs usable and complete (note that I didnât say âperfectâ). Weâre waiting on 2.1 in order to do internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we canât share in a standardized way right now, and thatâs preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think we risk losing support and getting the perception that we wonât finish things.

To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer it should address the comments from JMG and others (see working call notes from today) to ensure we donât lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review period for WD02 letâs include it in CSD01, otherwise letâs defer to CSD02.

John

From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>

Date: Tuesday, August 14, 2018 at 5:04 PM

To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>

Subject: [cti] Possible Changes to Observed Data

All,

There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc). We have talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.

Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific use case.

Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container or solution so cyber observables can be documented, captured, and shared. This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not an "observation" it is just cyber observable data.

I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:

1) Relax Observed Data and some of the properties to make it useable by more use cases

2) Same as 1, but rename Observed Data to be something more appropriate

3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)

4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)

5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard to avoid.

## Personal Opinion ##

From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more in CSD02 and CSD03. But it would be nice to at least get the major changes done for CSD01.

## END ##

Please comment here on the email list and help us understand what you as a TC member would like to have happen here.

--
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://clicktime.symantec.com/a/1/WjL0BNNLSSfy48DNxI0gjOfA4xqAbzvwVTe-wFkRu1U=?d=GQOtyPk8refrgLooup2jjGxGm9jyOBV-FzaYgj5azJQZyFNQLM73p0UuCAVhP9dvEYnvjM-zcivptBS_-vfTDVUActM95HivtxYXWlLlZ61YaEkgtTwQL1TzYR-Gc0zziWHIwTf7R9MMUGHYTTByV81suBTYj4FFeOBiyqHPEPFkfPNBbRbkSMZTqG7906OBMndRvVio79DM6CJwD5D0R723OoUQGbJq55dcnjBj9mqx6HTwkUJJSqgyB7LVCoe9OljG2MNZ0EzZsorDEfdIFUnc62X06uvuzG6xgCYOeHLuOyk3st3_iS3n4wbnWfv8WonjdbmEWWXxOkXI7iFPSvQX3Q367ZoVAg5cYKvsBASMOme3GqRpTlFLM6pOuszgSHIZ_wUvkRWl17XC0e-fzqWEgpuQ4zqsenEJrGVLUu-HIE9ydd-wwjd_3A%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php

cti message