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] 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:
 

  1. First of all, some of these Observed Data Objects in the examples arenât valid per the current spec
    1. Itâs not permissible to have multiple unrelated Cyber Observables in a single Observed Data object
    1. Related to the above, number_observedisnâ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
  1. 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]









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