CTI STIX Subcommittee

Hey All, Apologize for the Friday release of data. Last week, I had the opportunity to present on some proposed changes to the malware object. As promised, I wanted to provide sample STIX documents for everyone's review. This is some redacted processing based upon some VirusTotal samples, but it is live results. As a reminder, the main things we are changing is: samples -> samples_ref where it points to an observed-data object that contains the samples that were submitted for processing results in the analysis_type changes to results_ref where it points to an observed-data object containing the cyber observables that came out of the processing. The reason we are proposing these changes is to make it easier for implementations to reuse the work they already performed to correctly parse observed-data rather than having to learn a separate way to use cyber observables in a malware object. Next, because results changed from a dictionary to a reference to an observed-data object, that data is captured in a common STIX format rather than being arbitrary to each implementation. We did have to use some custom extensions for our data, as we expect others will as well. As part of the STIX process, this will help identify new cyber-observables or updates to the standard, but because we are using extensions rather than a dictionary, it is putting us down the correct path toward conformity. During this upcoming Tuesday's call, we will review these changes. Hopefully we can get a consensus one way or another, if we cannot, I would suggest that we turn this into a ballot so we can quickly get approval to move forward on this object and get towards a 2.1 release. Btw: Big Thank you to Sagar Singh and Jeff Mates for helping put this all together. Thanks everyone! -Gary Attachment: STIX_AMR-2018-0000299_AutomatedResponse.json Description: Binary data Attachment: STIX_AMR-2018-0000302_AutomatedResponse.json Description: Binary data Attachment: STIX Malware Object Presentation 2.pptx Description: application/vnd.openxmlformats-officedocument.presentationml.presentation Attachment: smime.p7s Description: S/MIME cryptographic signature

On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote: > > The reason we are proposing these changes is to make it easier for > implementations to reuse the work they already performed to > correctly parse observed-data rather than having to learn a separate > way to use cyber observables in a malware object. > Gary et al - If I understand you correctly, the primary benefit of this approach is to avoid an implementer having to write a parser for the lite variant of observed-data currently defined for the malware object. But having examined your sample data, the way you're using observed-data is a definitely a variant of how observed-data is used everywhere else. If we make this change, you're still going to have to write code to handle parsing observed-data (proper) versus this variant. Maybe you shave off 50 lines of code with this approach but it seems like a negligible trade-off for all the additional normative text we're going to have to write to clarify this additional (proposed) use case for observed-data. This is certainly not the hill I'd choose to die on but the pro/con vis-a-vis the current malware definition is far from clear to me. > > During this upcoming Tuesday's call, we will review these changes. > Hopefully we can get a consensus one way or another, if we cannot, I > would suggest that we turn this into a ballot so we can quickly get > approval to move forward on this object and get towards a 2.1 > release. > Apologies for missing today's working call, unfortunately I have another pressing commitment. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Don t internet angry. If you re angry, internet later." --Quinn Norton Attachment: signature.asc Description: PGP signature

Trey, these appear to be standard observed_data
objects to me, from my naked eye at least - can you go into more details
as to the discrepancies / what would make them "lite" ? I know the original point is, as Gary
says, they are 100% native observed_data objects. The other benefit of this that Gary
didn't mention, is it would often reduce data duplication as indicator
sightings can be tied directly to these objects, vs. having duplicate information
inside malware. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:      
  Trey Darley <trey@newcontext.com> To:      
  "Katz, Gary CTR
DC3/TSD" <Gary.Katz.ctr@dc3.mil> Cc:      
  "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org> Date:      
  07/10/2018 01:41 PM Subject:    
    Re: [cti-stix]
Sample Malware STIX Documents Sent by:    
    <cti-stix@lists.oasis-open.org> On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote: > > The reason we are proposing these changes is to make it easier for > implementations to reuse the work they already performed to > correctly parse observed-data rather than having to learn a separate > way to use cyber observables in a malware object. > Gary et al - If I understand you correctly, the primary benefit of this approach is to avoid an implementer having to write a parser for the lite variant of observed-data currently defined for the malware object. But having examined your sample data, the way you're using observed-data is a definitely a variant of how observed-data is used everywhere else. If we make this change, you're still going to have to write code to handle parsing observed-data (proper) versus this variant. Maybe you shave off 50 lines of code with this approach but it seems like a negligible trade-off for all the additional normative text we're going to have to write to clarify this additional (proposed) use case for observed-data. This is certainly not the hill I'd choose to die on but the pro/con vis-a-vis the current malware definition is far from clear to me. > > During this upcoming Tuesday's call, we will review these changes. > Hopefully we can get a consensus one way or another, if we cannot,
I > would suggest that we turn this into a ballot so we can quickly get > approval to move forward on this object and get towards a 2.1 > release. > Apologies for missing today's working call, unfortunately I have another pressing commitment. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Don t internet angry. If you re angry, internet later." --Quinn Norton [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

There are a few key issues at play here:
 

First of all, some of these Observed Data Objects in the examples aren t valid per the current spec

It s not permissible to have multiple unrelated Cyber Observables in a single Observed Data object Related to the above,
number_observed isn t used correctly here it s meant to refer to the number of times the sole Cyber Observable was observed, not the number of Cyber Observable Objects in the container
More importantly, and I think this is what Trey was really getting at, the second example s (000302) use of Observed Data is ambiguous in many instances. For example, one of the larger
Observed Data instances (observed-data--61c378be-9aa1-48fc-bc27-af10eda14ec3) is referenced in both
static_analysis_results and sample_refs. However, it contains multiple Objects (including several Files), so how are you supposed to know which Cyber Observables correspond to static analysis results and which objects are the actual malware samples?
 
We can discuss further on today s call, but to me this points to Observed Data not working as we had hoped here.
 
Regards,
Ivan
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, July 10, 2018 at 10:57 AM
To: Trey Darley <trey@newcontext.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil>
Subject: Re: [cti-stix] Sample Malware STIX Documents


 

Trey, these appear to be standard observed_data objects to me, from my naked eye at least - can you go into more details as to the discrepancies / what would make them "lite"
?

I know the original point is, as Gary says, they are 100% native observed_data objects.

The other benefit of this that Gary didn't mention, is it would often reduce data duplication as indicator sightings can be tied directly to these objects, vs. having duplicate information inside
malware.

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

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





From:         Trey Darley <trey@newcontext.com>
To:         "Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil>
Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:         07/10/2018 01:41 PM
Subject:         Re: [cti-stix] Sample Malware STIX Documents
Sent by:         <cti-stix@lists.oasis-open.org>






On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote:
>
> The reason we are proposing these changes is to make it easier for
> implementations to reuse the work they already performed to
> correctly parse observed-data rather than having to learn a separate
> way to use cyber observables in a malware object.
>

Gary et al -

If I understand you correctly, the primary benefit of this approach is
to avoid an implementer having to write a parser for the lite variant
of observed-data currently defined for the malware object. But having
examined your sample data, the way you're using observed-data is a
definitely a variant of how observed-data is used everywhere else.

If we make this change, you're still going to have to write code to
handle parsing observed-data (proper) versus this variant. Maybe you
shave off 50 lines of code with this approach but it seems like a
negligible trade-off for all the additional normative text we're going
to have to write to clarify this additional (proposed) use case for
observed-data.

This is certainly not the hill I'd choose to die on but the pro/con
vis-a-vis the current malware definition is far from clear to me.

>
> During this upcoming Tuesday's call, we will review these changes.
> Hopefully we can get a consensus one way or another, if we cannot, I
> would suggest that we turn this into a ballot so we can quickly get
> approval to move forward on this object and get towards a 2.1
> release.
>

Apologies for missing today's working call, unfortunately I have
another pressing commitment.

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"Don t internet angry. If you re angry, internet later." --Quinn
Norton
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

- Where is (1)(a) stated in the spec? I
can't find this in the spec.... if it exists I would say it wouldn't actually
change much about Gary's concept, it would just change a bit and make these
fields lists in the malware object itself. - Agree on (1)(b) but I consider it
more a bug in the example than a fundamental problem with the concept. - I am not sure I agree (2) is a problem.
It could be a bug in the example. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:      
  "Kirillov, Ivan
A." <ikirillov@mitre.org> To:      
  Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
Trey Darley <trey@newcontext.com> Cc:      
  "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil> Date:      
  07/10/2018 02:15 PM Subject:    
    Re: [cti-stix]
Sample Malware STIX Documents There are a few key issues at play here:   First of all, some of these Observed
Data Objects in the examples aren t valid per the current spec It s not permissible to have multiple
unrelated Cyber Observables in a single Observed Data object Related to the above, number_observed isn t used correctly here it s meant to refer to the number of times
the sole Cyber Observable was observed, not the number of Cyber Observable
Objects in the container More importantly, and I think this
is what Trey was really getting at, the second example s (000302) use
of Observed Data is ambiguous in many instances. For example, one of the
larger Observed Data instances (observed-data--61c378be-9aa1-48fc-bc27-af10eda14ec3)
is referenced in both static_analysis_results and sample_refs.
However, it contains multiple Objects (including several Files), so
how are you supposed to know which Cyber Observables correspond to static
analysis results and which objects are the actual malware samples?   We can discuss further on today s call,
but to me this points to Observed Data not working as we had hoped here.   Regards, Ivan   From: <cti-stix@lists.oasis-open.org>
on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Tuesday, July 10, 2018 at 10:57 AM To: Trey Darley <trey@newcontext.com> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>,
"Katz, Gary" <gary.katz.ctr@dc3.mil> Subject: Re: [cti-stix] Sample Malware STIX Documents   Trey, these appear to be standard observed_data
objects to me, from my naked eye at least - can you go into more details
as to the discrepancies / what would make them "lite" ? I know the original point is, as Gary says, they are 100% native observed_data
objects. The other benefit of this that Gary didn't mention, is it would often reduce
data duplication as indicator sightings can be tied directly to these objects,
vs. having duplicate information inside malware. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:         Trey
Darley <trey@newcontext.com> To:         "Katz,
Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil> Cc:         "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org> Date:         07/10/2018
01:41 PM Subject:         Re:
[cti-stix] Sample Malware STIX Documents Sent by:         <cti-stix@lists.oasis-open.org> On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote: > > The reason we are proposing these changes is to make it easier for > implementations to reuse the work they already performed to > correctly parse observed-data rather than having to learn a separate > way to use cyber observables in a malware object. > Gary et al - If I understand you correctly, the primary benefit of this approach is to avoid an implementer having to write a parser for the lite variant of observed-data currently defined for the malware object. But having examined your sample data, the way you're using observed-data is a definitely a variant of how observed-data is used everywhere else. If we make this change, you're still going to have to write code to handle parsing observed-data (proper) versus this variant. Maybe you shave off 50 lines of code with this approach but it seems like a negligible trade-off for all the additional normative text we're going to have to write to clarify this additional (proposed) use case for observed-data. This is certainly not the hill I'd choose to die on but the pro/con vis-a-vis the current malware definition is far from clear to me. > > During this upcoming Tuesday's call, we will review these changes. > Hopefully we can get a consensus one way or another, if we cannot,
I > would suggest that we turn this into a ballot so we can quickly get > approval to move forward on this object and get towards a 2.1 > release. > Apologies for missing today's working call, unfortunately I have another pressing commitment. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Don t internet angry. If you re angry, internet later." --Quinn Norton [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

As far as 1.a, this is the text for the objects property in Observed Data that spells this out (especially the second sentence):
 
The Cyber Observable content
MAY include multiple objects if those objects are related as part of a single observation. Multiple objects not related to each other via Cyber Observable Relationships
MUST NOT be contained within the same Observed Data instance.
 
Regards,
Ivan
 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, July 10, 2018 at 12:11 PM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Sample Malware STIX Documents


 

- Where is (1)(a) stated in the spec? I can't find this in the spec.... if it exists I would say it wouldn't actually change much about Gary's concept, it would just change a
bit and make these fields lists in the malware object itself.

- Agree on (1)(b) but I consider it more a bug in the example than a fundamental problem with the concept.

- I am not sure I agree (2) is a problem. It could be a bug in the example.


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

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





From:         "Kirillov, Ivan A." <ikirillov@mitre.org>
To:         Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Trey Darley <trey@newcontext.com>
Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil>
Date:         07/10/2018 02:15 PM
Subject:         Re: [cti-stix] Sample Malware STIX Documents






There are a few key issues at play here:
 


First of all, some of these Observed Data Objects in the examples aren t valid per the current spec




It s not permissible to have multiple unrelated Cyber Observables in a single Observed Data object




Related to the above, number_observed isn t used correctly here it s meant to refer to the number of times the sole Cyber Observable was observed, not the number of Cyber Observable Objects in the container



More importantly, and I think this is what Trey was really getting at, the second example s (000302) use of Observed Data is ambiguous in many instances. For example, one of the larger Observed Data instances (observed-data--61c378be-9aa1-48fc-bc27-af10eda14ec3)
is referenced in both static_analysis_results and sample_refs. However, it contains multiple Objects (including several Files), so how are you supposed to know which Cyber Observables correspond to static analysis results and which objects are
the actual malware samples?
 
We can discuss further on today s call, but to me this points to Observed Data not working as we had hoped here.
 
Regards,
Ivan
 
From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, July 10, 2018 at 10:57 AM
To: Trey Darley <trey@newcontext.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil>
Subject: Re: [cti-stix] Sample Malware STIX Documents
 
Trey, these appear to be standard observed_data objects to me, from my naked eye at least - can you go into more details as to the discrepancies / what would make them "lite" ?

I know the original point is, as Gary says, they are 100% native observed_data objects.

The other benefit of this that Gary didn't mention, is it would often reduce data duplication as indicator sightings can be tied directly to these objects, vs. having duplicate information inside malware.

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

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





From:         Trey Darley <trey@newcontext.com>
To:         "Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil>
Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:         07/10/2018 01:41 PM
Subject:         Re: [cti-stix] Sample Malware STIX Documents
Sent by:         <cti-stix@lists.oasis-open.org>







On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote:
>
> The reason we are proposing these changes is to make it easier for
> implementations to reuse the work they already performed to
> correctly parse observed-data rather than having to learn a separate
> way to use cyber observables in a malware object.
>

Gary et al -

If I understand you correctly, the primary benefit of this approach is
to avoid an implementer having to write a parser for the lite variant
of observed-data currently defined for the malware object. But having
examined your sample data, the way you're using observed-data is a
definitely a variant of how observed-data is used everywhere else.

If we make this change, you're still going to have to write code to
handle parsing observed-data (proper) versus this variant. Maybe you
shave off 50 lines of code with this approach but it seems like a
negligible trade-off for all the additional normative text we're going
to have to write to clarify this additional (proposed) use case for
observed-data.

This is certainly not the hill I'd choose to die on but the pro/con
vis-a-vis the current malware definition is far from clear to me.

>
> During this upcoming Tuesday's call, we will review these changes.
> Hopefully we can get a consensus one way or another, if we cannot, I
> would suggest that we turn this into a ballot so we can quickly get
> approval to move forward on this object and get towards a 2.1
> release.
>

Apologies for missing today's working call, unfortunately I have
another pressing commitment.

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"Don t internet angry. If you re angry, internet later." --Quinn
Norton
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

I really like what Gary and company has done, I like their proposal. I think this is probably the way we should go.  The only thing I question is, is Observed-Data the right Cyber Observable container for this?  Or should there be a different one.  It seems like we made Observed-Data with a certain set of requirements. Now we need to open that back up or relax some of this restrictions, so maybe we just need a different container for Cyber Observable data.   I will remind everyone that we will need this same sort of thing for Infrastructure. So three approaches I see (keeping in mind that  Observed-Data the way we built it, it was really designed to be used with Indicators and Sightings) : 1) Try and use Observed-Data as is, even if painful or less than ideal  2) Relax some of the restrictions with Observed-Data / some of the assumption we had about it and maybe remove or change the properties that are on it 3) Create another more generic container that can be used for Cyber Observable data.  Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org> Sent: Tuesday, July 10, 2018 12:39:53 PM To: Jason Keirstead Cc: cti-stix@lists.oasis-open.org; Katz, Gary; Trey Darley Subject: [EXT] Re: [cti-stix] Sample Malware STIX Documents   As far as 1.a, this is the text for the objects property in Observed Data that spells this out (especially the second sentence):   “ The Cyber Observable content MAY include multiple objects if those objects are related as part of a single observation. Multiple objects not related to each other via Cyber Observable Relationships MUST NOT be contained within the same Observed Data instance. ”   Regards, Ivan   From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Tuesday, July 10, 2018 at 12:11 PM To: Ivan Kirillov <ikirillov@mitre.org> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil>, Trey Darley <trey@newcontext.com> Subject: Re: [cti-stix] Sample Malware STIX Documents   - Where is (1)(a) stated in the spec? I can't find this in the spec.... if it exists I would say it wouldn't actually change much about Gary's concept, it would just change a bit and make these fields lists in the malware object itself. - Agree on (1)(b) but I consider it more a bug in the example than a fundamental problem with the concept. - I am not sure I agree (2) is a problem. It could be a bug in the example. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         "Kirillov, Ivan A." <ikirillov@mitre.org> To:         Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Trey Darley <trey@newcontext.com> Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil> Date:         07/10/2018 02:15 PM Subject:         Re: [cti-stix] Sample Malware STIX Documents There are a few key issues at play here:   First of all, some of these Observed Data Objects in the examples aren’t valid per the current spec It’s not permissible to have multiple unrelated Cyber Observables in a single Observed Data object Related to the above, number_observed isn’t used correctly here – it’s meant to refer to the number of times the sole Cyber Observable was observed, not the number of Cyber Observable Objects in the container More importantly, and I think this is what Trey was really getting at, the second example’s (000302) use of Observed Data is ambiguous in many instances. For example, one of the larger Observed Data instances (observed-data--61c378be-9aa1-48fc-bc27-af10eda14ec3) is referenced in both static_analysis_results and sample_refs. However, it contains multiple Objects (including several Files), so how are you supposed to know which Cyber Observables correspond to static analysis results and which objects are the actual malware samples?   We can discuss further on today’s call, but to me this points to Observed Data not working as we had hoped here.   Regards, Ivan   From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Tuesday, July 10, 2018 at 10:57 AM To: Trey Darley <trey@newcontext.com> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil> Subject: Re: [cti-stix] Sample Malware STIX Documents   Trey, these appear to be standard observed_data objects to me, from my naked eye at least - can you go into more details as to the discrepancies / what would make them "lite" ? I know the original point is, as Gary says, they are 100% native observed_data objects. The other benefit of this that Gary didn't mention, is it would often reduce data duplication as indicator sightings can be tied directly to these objects, vs. having duplicate information inside malware. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Trey Darley <trey@newcontext.com> To:         "Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil> Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:         07/10/2018 01:41 PM Subject:         Re: [cti-stix] Sample Malware STIX Documents Sent by:         <cti-stix@lists.oasis-open.org> On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote: > > The reason we are proposing these changes is to make it easier for > implementations to reuse the work they already performed to > correctly parse observed-data rather than having to learn a separate > way to use cyber observables in a malware object. > Gary et al - If I understand you correctly, the primary benefit of this approach is to avoid an implementer having to write a parser for the lite variant of observed-data currently defined for the malware object. But having examined your sample data, the way you're using observed-data is a definitely a variant of how observed-data is used everywhere else. If we make this change, you're still going to have to write code to handle parsing observed-data (proper) versus this variant. Maybe you shave off 50 lines of code with this approach but it seems like a negligible trade-off for all the additional normative text we're going to have to write to clarify this additional (proposed) use case for observed-data. This is certainly not the hill I'd choose to die on but the pro/con vis-a-vis the current malware definition is far from clear to me. > > During this upcoming Tuesday's call, we will review these changes. > Hopefully we can get a consensus one way or another, if we cannot, I > would suggest that we turn this into a ballot so we can quickly get > approval to move forward on this object and get towards a 2.1 > release. > Apologies for missing today's working call, unfortunately I have another pressing commitment. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Don’t internet angry. If you’re angry, internet later." --Quinn Norton [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

Yes, to Jason s point, 1b is a bug and so is issue 2. I believe the actual sample_ref should be observed-data--78baac3e-9611-48fc-2ba1-04eedf11aac3. Jeff and I tried to proof read the samples prior to sending them out, but obviously we missed a couple of things.   My apologizes for the confusion. -Gary   From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Tuesday, July 10, 2018 2:12 PM To: Kirillov, Ivan A. <ikirillov@mitre.org> Cc: cti-stix@lists.oasis-open.org; Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil>; Trey Darley <trey@newcontext.com> Subject: [Non-DoD Source] Re: [cti-stix] Sample Malware STIX Documents   - Where is (1)(a) stated in the spec? I can't find this in the spec.... if it exists I would say it wouldn't actually change much about Gary's concept, it would just change a bit and make these fields lists in the malware object itself. - Agree on (1)(b) but I consider it more a bug in the example than a fundamental problem with the concept. - I am not sure I agree (2) is a problem. It could be a bug in the example. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         "Kirillov, Ivan A." <ikirillov@mitre.org> To:         Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Trey Darley <trey@newcontext.com> Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil> Date:         07/10/2018 02:15 PM Subject:         Re: [cti-stix] Sample Malware STIX Documents There are a few key issues at play here:   First of all, some of these Observed Data Objects in the examples aren t valid per the current spec It s not permissible to have multiple unrelated Cyber Observables in a single Observed Data object Related to the above, number_observed isn t used correctly here it s meant to refer to the number of times the sole Cyber Observable was observed, not the number of Cyber Observable Objects in the container More importantly, and I think this is what Trey was really getting at, the second example s (000302) use of Observed Data is ambiguous in many instances. For example, one of the larger Observed Data instances (observed-data--61c378be-9aa1-48fc-bc27-af10eda14ec3) is referenced in both static_analysis_results and sample_refs. However, it contains multiple Objects (including several Files), so how are you supposed to know which Cyber Observables correspond to static analysis results and which objects are the actual malware samples?   We can discuss further on today s call, but to me this points to Observed Data not working as we had hoped here.   Regards, Ivan   From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Tuesday, July 10, 2018 at 10:57 AM To: Trey Darley <trey@newcontext.com> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Katz, Gary" <gary.katz.ctr@dc3.mil> Subject: Re: [cti-stix] Sample Malware STIX Documents   Trey, these appear to be standard observed_data objects to me, from my naked eye at least - can you go into more details as to the discrepancies / what would make them "lite" ? I know the original point is, as Gary says, they are 100% native observed_data objects. The other benefit of this that Gary didn't mention, is it would often reduce data duplication as indicator sightings can be tied directly to these objects, vs. having duplicate information inside malware. - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Trey Darley <trey@newcontext.com> To:         "Katz, Gary CTR DC3/TSD" <Gary.Katz.ctr@dc3.mil> Cc:         "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:         07/10/2018 01:41 PM Subject:         Re: [cti-stix] Sample Malware STIX Documents Sent by:         <cti-stix@lists.oasis-open.org> On 06.07.2018 21:37:07, Katz, Gary CTR DC3/TSD wrote: > > The reason we are proposing these changes is to make it easier for > implementations to reuse the work they already performed to > correctly parse observed-data rather than having to learn a separate > way to use cyber observables in a malware object. > Gary et al - If I understand you correctly, the primary benefit of this approach is to avoid an implementer having to write a parser for the lite variant of observed-data currently defined for the malware object. But having examined your sample data, the way you're using observed-data is a definitely a variant of how observed-data is used everywhere else. If we make this change, you're still going to have to write code to handle parsing observed-data (proper) versus this variant. Maybe you shave off 50 lines of code with this approach but it seems like a negligible trade-off for all the additional normative text we're going to have to write to clarify this additional (proposed) use case for observed-data. This is certainly not the hill I'd choose to die on but the pro/con vis-a-vis the current malware definition is far from clear to me. > > During this upcoming Tuesday's call, we will review these changes. > Hopefully we can get a consensus one way or another, if we cannot, I > would suggest that we turn this into a ballot so we can quickly get > approval to move forward on this object and get towards a 2.1 > release. > Apologies for missing today's working call, unfortunately I have another pressing commitment. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Don t internet angry. If you re angry, internet later." --Quinn Norton [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] Attachment: smime.p7s Description: S/MIME cryptographic signature

On 10.07.2018 18:53:51, Katz, Gary CTR DC3/TSD wrote: > Yes, to Jason s point, 1b is a bug and so is issue 2. I believe the > actual sample_ref should be > observed-data--78baac3e-9611-48fc-2ba1-04eedf11aac3. Jeff and I > tried to proof read the samples prior to sending them out, but > obviously we missed a couple of things. > Hey, Gary - The UUID typos threw me off. Could you please share corrected samples as well as your POC code so we can all get on the same page? Thanks! -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "There are only two hard things in Computer Science: cache invalidation and naming things." --Phil Karlton Attachment: signature.asc Description: PGP signature