You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need a field set to express information about signatures, and in particular code signatures. Already, the word signature has multiple meanings in security, so we'll need to pick a good word that's clear, and doesn't collide with "signature based detections". Maybe digsig or codesig or code_signature?
For code signatures, I'm most familiar with signing Windows PE files, and lightly familiar with code signing for macOS. I think a new field set could belong in a few places, depending on what feels the most natural.
I'm leaning towards nesting it under process.signature, lib.signature (#675) and file.signature to be more generic. We could also nest it under tls. Even if this happens later, we should at least choose fields to maximize compatibility.
Without diving into the internals of code signatures and trust relationships that I won't pretend to understand, here are some obvious high value fields that are common between different implementations:
subject_name: "Microsoft Corporation" (I believe this was called "signer_name" within Endgame)
valid: bool - maintains integrity,
timestamp: date - timestamp for when it was signed
trusted: bool
expired: bool
exists: bool - check if the signature exists. useful to disambiguate between if a signature explicitly doesn't exist vs that information is not available
A few things that may be useful for other non-binary use cases:
certificate authority information?
The text was updated successfully, but these errors were encountered:
So, since exists is only really informative if it's set to false wonder if it makes sense to invert things, like call it missing or something of the sort? Probably just a preference thing, but just seems kind of odd to me if the only feasible query to use this field seems to be something like signature.exists == false
I think the most common use case will be checking if it's set to false, but I can conceive of other use cases. In general, I try to avoid fields named for the inverted case. And I think it does have value in aggregations, for instance. Maybe you want to know if the signature is there regardless of its signer or validity. For those cases, you could do digsig.signer_name:*, but if we need the field anyway to check if its explicitly missing, then it would make more sense to just do digsig.exists:true
We need a field set to express information about signatures, and in particular code signatures. Already, the word signature has multiple meanings in security, so we'll need to pick a good word that's clear, and doesn't collide with "signature based detections". Maybe
digsig
orcodesig
orcode_signature
?For code signatures, I'm most familiar with signing Windows PE files, and lightly familiar with code signing for macOS. I think a new field set could belong in a few places, depending on what feels the most natural.
I'm leaning towards nesting it under
process.signature
,lib.signature
(#675) andfile.signature
to be more generic. We could also nest it undertls
. Even if this happens later, we should at least choose fields to maximize compatibility.Without diving into the internals of code signatures and trust relationships that I won't pretend to understand, here are some obvious high value fields that are common between different implementations:
subject_name
: "Microsoft Corporation" (I believe this was called "signer_name" within Endgame)valid
: bool - maintains integrity,timestamp
: date - timestamp for when it was signedtrusted
: boolexpired
: boolexists
: bool - check if the signature exists. useful to disambiguate between if a signature explicitly doesn't exist vs that information is not availableA few things that may be useful for other non-binary use cases:
The text was updated successfully, but these errors were encountered: