Correcting telemetry for LimaCharlie.

[maximelb]

Pull Request Template

Description

Hopefully I interpreted the questions below correctly, this is a simple update to LimaCharlie supported telemetry. I will put screenshots at the end of this description as proof. Hopefully it makes sense but let me know if something's not clear or I misinterpreted.

Full disclosure: I'm the co-founder of LimaCharlie :)

Please provide the below information so we can validate before merging:

1. Does the proposed EDR feature align with our definition of telemetry?(definition here)
2. Could you please provide documentation to support the telemetry you are proposing?(If it is held privately, please reach out to me or @inodee)
3. If no documentation is available for all the categories you are proposing, could you provide screenshots or sanitized logs?

1: Yes 2: Yes 3: Doc and screenshots

Type of change

Please delete options that are not relevant.

• [x] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.

Just used a LimaCharlie sensor on Windows, did a history_dump command to get all telemetry in one dump, and then selected the relevant events missing.

Test Configuration:

• EDR version: Latest
• Operating System version: Windows 2016

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have made corresponding changes to the documentation
• [x] I have added tests that prove my corrections or additions are accurate
• [x] I have checked my code and corrected any misspellings

Don't stress yourself out, just answer the above to the best of your ability and we can discuss in the comments 🙂

The screenshots: File Open: partial as in we do Reads

File Rename: partial as they're reported as a delete+write https://docs.limacharlie.io/docs/reference-events-system-files

All the new "Via EventLogs" answers. Wasn't 100% sure how to interpre (via EventLogs, or Yes) because in LC all Windows Event Logs (and Mac Unified Logs) are first-class telemetry, so it's not a case where they get polled for on demand or something like that, it's just telemetry.

Driver Load: yes in 2 ways, as MODULE_LOAD and as CODE_IDENTITY (deduped unique binaries loading)

Device Mounts/Unmounts: partially, we do not do "device", but anything mounting / unmounting a Volume will get reported. So I figured partial because it's not found connecting a mouse, but connecting a USB Drive will be recorded: https://docs.limacharlie.io/docs/reference-events-system-volumes

[tsale]

Thank you for the PR, @maximelb! Everything looks good as far as I can see. However, I would hold off on including the Via EventLogs events for now. This refers to the EDR’s ability to independently collect Windows Event Logs. As far as I know, LimaCharlie does not collect these logs directly but allows users to enable the forwarding of Windows Event Logs through the agent.

Customers are responsible for enabling this option and the logs on each host. Therefore, it doesn’t qualify under the current criteria. For it to qualify, LimaCharlie would need to collect events from Windows logs to address a telemetry capability gap, and this would need to be documented.

We are specifically looking for the capability of an EDR to provide telemetry to the user via the end agent’s independent log collection capabilities. We are not looking for a forwarder, as some users might choose to use the agent in that capacity.

[tsale]

@maximelb, if there are no further comments regarding this, I will go ahead with the modifications regarding the Via EventLogs fields and merge.

[maximelb]

Oh my bad for some reason I did not get the notification on your reply. Giving more details in a sec.

[maximelb]

Thanks @tsale for the reply, didn't expect it that fast. :)

Hmmm I'm not sure I understand the distinction. LimaCharlie supports 2 ways of ingestion Windows Event Logs: https://docs.limacharlie.io/docs/tutorials-telemetry-ingesting-windows-event-logs 1- Through raw evtx files ingested and parsed. 2- Through real-time feed of the Windows Event Logs.

Pretty sure 1- is not what you're looking for. But number 2 is (AFAIK), with it the agent registers directly within the OS to receive the WELs in real-time (at the API level). It then fires them off to the cloud as first-class telemetry, so not as an altternate stream of data, but the same way as for example a new process execution. Because they're first class, users can alert and automate directly from them, there's no secondary step.

In terms of the "enabling" side of things, the way LC works isn't like a traditional EDR that's just an out-of-the-box thing. LC is designed for professionals doing Services or Products, so we do nothing at all out-of-the-box on purpose. We're unlike an AV in that way.

That being said, 99% of people using it for Services like MDR or IR will enable all kinds of collections, including WELs, on LC using infra-as-code to replicate across their tenants.

From my perspective it would match what you're looking for, but maybe I'm missing some nuance somewhere?

[tsale]

Thank you for the clarification @maximelb. I understand more about the process now, and it does make sense to categorize it as telemetry via Windows Event Logs. However, we want to ensure that we include EDR telemetry collection capabilities without delving into features that don't conform to the purpose of this project. While it is a fine line to draw, in this case, I think it would be reasonable to include it as Windows Event Log telemetry.