elastic / integrations

Elastic Integrations
https://www.elastic.co/integrations
Other
196 stars 424 forks source link

crowdstrike.alert: Integration does not map CrowdStrike tactics & techniques properly #10196

Closed NateUT99 closed 2 months ago

NateUT99 commented 3 months ago

While reviewing the crowdstrike.alert dataset, I noticed that there seems to be an issue with the threat.tactic.id and threat.technique.id values when the alert references what CrowdStrike calls the "MITRE-Based Falcon Detections Framework". I've highlighted the issue in the attached screenshot; as you can see the tactic_id and technique_id from the original alert is "CSTA0004" and "CST0007/CST0008" respectively. The value for threat.tactic.name and threat.technique.name are correct; however it appears that the threat.tactic.id and threat.technique.id have dropped the "CS" prefixes completely.

My recommnedation would be either 1) do not write values to threat.tactic. and threat.technique. when the alert ids are prefixed with "CS", or 2) write an appropriate name to threat.framework for the "Falcon Detections Framework", and ensure that the prefixes remain as expected.

I do have some additional documentation on the Falcon Detections Framework if that would be useful. As it requires authentication to download, I would prefer to not attach it to a public GitHub issue. Please feel free to contact me if this would be beneficial.

crowdstrike_alert_threats
elasticmachine commented 3 months ago

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

jamiehynds commented 3 months ago

Thanks for reporting @NateUT99

@piyush-elastic could someone from the team look into this one please, as it related to the alert pipeline added recently. https://github.com/elastic/integrations/blob/main/packages/crowdstrike/data_stream/alert/elasticsearch/ingest_pipeline/default.yml

piyushw-crest commented 3 months ago

sure @jamiehynds , will check and keep posted on issue in case if any need help.

efd6 commented 3 months ago

This appears to be intentional:

piyushw-crest commented 3 months ago

Yes @efd6 and @NateUT99 it's intentional, ideally tactic values won't have CS as a prefix reference link and while doing ECS mapping with threat.tactic as it expect the generic value so we have removed "CS" prefix there. We have provided/preserve original value in respective custom field crowdstrike.alert.tactic_id.

NateUT99 commented 3 months ago

The problem is that by intentionally doing this, you are putting incorrect values into the ECS fields. Dropping the "CS" turns the tactic.id into TA0004. However, the name isn't correct because TA0004 is "Privilege Escalation", not "Machine Learning". By just dropping the prefix, you are making it difficult to use this data for framework mapping/dashboarding, and the values do not represent what actually happened in the detection.

That is why I suggested either not writing ANY values to threat.tactic.id and threat.technique.id when the prefix "CS" is present, or adding support for the CrowdStrike Falcon Detections Framework (I can provide this documentation).

kcreddy commented 3 months ago

Hey @NateUT99

the name isn't correct because TA0004 is "Privilege Escalation", not "Machine Learning".

This was a miss and seems like a bug on the integration. I agree with the second approach of adding threat.framework as ECS doesn't restrict adding another framework.

The fix is also applicable to Falcon dataset as I see sample logs with tacticId prefixed with CS.

or adding support for the CrowdStrike Falcon Detections Framework (I can provide this documentation).

https://github.com/elastic/integrations/pull/10256 adds threat.framework as CrowdStrike Falcon Detections Framework if the prefix CS exists in both tactic and technique. It would be nice to get the documentation to validate and add any missing ECS fields. I will reach out to you.