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
