Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code signature field set #681

Closed
rw-access opened this issue Dec 6, 2019 · 2 comments · Fixed by #733
Closed

Code signature field set #681

rw-access opened this issue Dec 6, 2019 · 2 comments · Fixed by #733
Assignees
Labels
endpoint Relevant to elastic endpoint security

Comments

@rw-access
Copy link
Contributor

rw-access commented Dec 6, 2019

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?
@rw-access rw-access self-assigned this Dec 6, 2019
@andrewstucki
Copy link
Contributor

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

@rw-access
Copy link
Contributor Author

rw-access commented Dec 9, 2019

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

@rw-access rw-access changed the title Digital signature field set Code signature field set Jan 24, 2020
@rw-access rw-access added the endpoint Relevant to elastic endpoint security label Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
endpoint Relevant to elastic endpoint security
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants