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

[Elastic Defend] Align Integration docs with Elastic Defend Policy #522

Open
nicpenning opened this issue Oct 13, 2023 · 3 comments
Open

Comments

@nicpenning
Copy link

I noticed that in the Integration Documentation for Elastic Defend, there appears to be a discrepancy between the events that can be enabled by the policy versus what is provided in the integration.

For example, I would expect to see where does Driver and DLL Load events exist in the integration field docs. Another is the DNS events, even though I can assume they live in Network

https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html#event-collection
image

https://docs.elastic.co/en/integrations/endpoint#logs
image

Current:

Defend Policy Event Collection:
DLL and Driver Load Not in integration docs
DNS Not in integration docs
File
Network
Process
Registry
Security

Defend Integration Field Docs:
Alerts* Assumed from detect/prevent capabilities
File
Library Maybe DLL and Driver Load but unclear
Network
Process
Registry
Security

Expectation:

Defend Integration Field Docs:
Alerts
DLL and Driver Load*
DNS*
File
Library*** Remove? Or rename to DLL and Driver Load / sync with terminology from Elastic Defend?
Network
Process
Registry
Security

@intxgo
Copy link
Contributor

intxgo commented Apr 18, 2024

Good catch. It's interesting to see Library and DLL and Driver Load in the GUI/doc. There must be some history behind this I've never heard of, but internally we call it ImageLoad in Endpoint code as it could be any binary image, dll, exe, sys, etc.

@andrewkroh andrewkroh transferred this issue from elastic/integrations Jul 22, 2024
@ferullo
Copy link
Contributor

ferullo commented Jul 29, 2024

The integrations docs you're referencing document the indices that Endpoint data lives in, so they aren't directly documentation for what appears in the UX. I am not sure why there isn't a 1:1 mapping between the two, that decision was made years ago 😄 .

Changing which indices each event type streams to or renaming the indices would be a very big breaking change. Also trying to align the UX labels to the indices would not work well (e.g. both DNS and Network events flow into the logs-endpoint.events.network-* index and we wouldn't want to take away the UX separation.

In this repo there is custom documentation1 which aims to document which fields can appear in each event type (things like "Process Exec", "Process Fork", "Process Exit", etc). It's not directly something you're asking for but I want to make sure you're aware of it since it is tangentially related.

Would updating the documentation you referenced so each section states what UX toggles flow into that index meet what you're looking for given the limitations I mentioned above? (For instance, adding text between "library" and "Exported fields" in the flow screenshot)

image

Footnotes

  1. Linked to from here "For detailed information about which ECS fields can appear in documents generated by Elastic Endpoint, refer to the Endpoint event documentation"

@nicpenning
Copy link
Author

It might, I would need to see how that looks.

The frustrating part is that I want to see what fields DNS events have specifically in the integration so when I go to look at the integration I see Network, and it is a combination, so I won't know what fields exist for DNS and which fields exist for "network" telemetry.

Same of DLL Drive Load - What fields exists for that? It is not intuitive to know that Library == DLL Driver Load.

It is great you can gather that info from custom documentation1, but I would have never suspected to go find for this info here, since as an end user I use Fleet to install and deploy integrations. Maybe this needs to be surfaced as the true reference guide for understanding what Elastic Defend telem fields exist per type. Good info! Does that help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants