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

[Crowdstrike FDR]: Pipeline sets fields wrongly based on bad assumption #12476

Open
monkeyonbranch opened this issue Jan 27, 2025 · 5 comments · May be fixed by #12508
Open

[Crowdstrike FDR]: Pipeline sets fields wrongly based on bad assumption #12476

monkeyonbranch opened this issue Jan 27, 2025 · 5 comments · May be fixed by #12508
Assignees
Labels
Integration:crowdstrike CrowdStrike needs:triage Team:Security-Service Integrations Security Service Integrations Team [elastic/security-service-integrations]

Comments

@monkeyonbranch
Copy link
Contributor

Integration Name

CrowdStrike [crowdstrike]

Dataset Name

crowdstrike.fdr

Integration Version

1.49.0

Agent Version

8.17.3

Agent Output Type

elasticsearch

Elasticsearch Version

8.17.3

OS Version and Architecture

Not relevant

Software/API Version

Not relevant

Error Message

The pipeline renames "remote" fields into destination fields. Which is wrong because it is done based on the assumption that all connections are outbound. For inbound connections this renaming is wrong. There needs to be if statements that bases the renaming on the network direction.

It looks to be sourced from this commit 512db6f#diff-9b8e65a89b684b4faab3770dbf228c2d81ba7dcb4836169d221c73ef3e70d8d2 which is 4(!!!) years old. Anyone who has been using this pipeline of-the-shelf has had their data wrongly renamed for the past four years.

Event Original

No response

What did you do?

Ingest data via the official integration

What did you see?

Fields are being renamed wrongly.

What did you expect to see?

I would expect the destination address to correlate to the direction of the network session.

Anything else?

No response

@andrewkroh andrewkroh added Integration:crowdstrike CrowdStrike Team:Security-Service Integrations Security Service Integrations Team [elastic/security-service-integrations] labels Jan 27, 2025
@elasticmachine
Copy link

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

@efd6
Copy link
Contributor

efd6 commented Jan 28, 2025

@monkeyonbranch Do you have example event.original events that you can share for the inbound case? Also, what would you propose be the behaviour in the case that the direction is unknown (an event for this would also be helpful)?

@efd6 efd6 linked a pull request Jan 28, 2025 that will close this issue
5 tasks
@efd6
Copy link
Contributor

efd6 commented Jan 28, 2025

@monkeyonbranch Please take a look at #12508 which is an attempt at a fix. There are subtleties that make it more difficult to have a definitive fix than it would seem at the surface (there is an impedance mismatch between ECS and the convention used by Crowdstrike for network direction, and there are test cases where we have no data in the ConnectionDirection and so we don't know how to handle to the directionality). I'd be grateful if you would take a look and add any input that you have that would be useful.

@efd6 efd6 self-assigned this Jan 28, 2025
@monkeyonbranch
Copy link
Contributor Author

In the case that the direction is unknown it is very hard to guess. Best guess, that would have the highest hit rate would be to assume direction based on port number. Ports 10000 and below are usually services and therefore usually destination. It is not 100% correct but based on how things "normally" work it is more correct than it is wrong.

@monkeyonbranch
Copy link
Contributor Author

I'll grab a look at #12508, asap. Thank you for helping out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Integration:crowdstrike CrowdStrike needs:triage Team:Security-Service Integrations Security Service Integrations Team [elastic/security-service-integrations]
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants