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]