CrowdStrike bidirectional response actions (isolate & release)

[joepeeples]

Contributes to #5446 and https://github.com/elastic/security-docs-internal/issues/21 (internal).

Previews

The format is a little different between serverless and stateful docs, due to each system's limitations. The serverless version uses a neat tabbed format to display one EDR system at a time, while stateful docs use separate sections or collapsible sections. The goal in both approaches is to avoid overwhelming the reader by limiting the amount of text displayed (one EDR system at at time).

Serverless docs:

• Click the link below, then in the Security card click View serverless docs.
• Navigate to Endpoint response actions, then:
  • Third-party response actions
  • Configure third-party response actions

Stateful/ESS docs:

• Third-party response actions
• Configure third-party response actions

[github-actions]

A documentation preview will be available soon.

• 🔨 Buildkite builds
• 📚 HTML diff
• 📙 Preview page

Request a new doc build by commenting

• Rebuild this PR: run docs-build
• Rebuild this PR and all Elastic docs: run docs-build rebuild

_{run docs-build is much faster than run docs-build rebuild. A rebuild should only be needed in rare situations.}

_{If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here.}

[elasticdocs]

🚀 Built elastic-dot-co-docs-preview-docs successfully!

• https://elastic-dot-co-docs-production-58zjin3es-elastic-dev.vercel.app

• Built with commit e6d7288

Issues? Visit #next-docs in Slack

[nastasha-solomon]

Just left a handful of optional edits and some questions. Looks great overall though, and good use of the tabbed and collapse/expand components to organize information!

[paul-tavares]

Hi @joepeeples ,
I took a pass at these docs, but really I'm hopping that you can wait until sometime next week to get @tomsonpl 's review since he's the most knowledgeable with CrowdStrike.

[paul-tavares]

Lets double check this step is correct, because this currently states that the 1 API key with full privileges to read and also execute response actions. This provides the integration policy with a token that IMO has too many unnecessary privileges.

[joepeeples]

Makes sense. The demo video and other materials I was able to find for CrowdStrike didn't specify multiple API clients, but we recommend 2 API keys for SentinelOne and could do something similar for CrowdStrike.

[tomsonpl]

Unfortunately I cannot confirm this - but you both may be right. Ingesting data might use a different clientId/secret than response actions - but it's rather Crowdstrike specific that I do not have information of ;/

[joepeeples]

OK, I can try to reword this to be a little less prescriptive about exact number of API clients, give more general guidelines and leave it up to the user's discretion.

[paul-tavares]

NOTE: there are two crowdstrike integrations. Lets confirm that the only needed one is this one you documented here (the other one is called 'CrowdStrike Falcon Intelligence')

[paul-tavares]

This, IMO, is not a good suggestion for the index name - it essentially says "create alerts for any type of crowdstrike data". I think (but you would need to confirm with @tomsonpl ) that there are specific indicates for crowdstrike alerts and other malware data, so perhaps using a more specific example would be best.

The other alternative would be to refer the customer tot he Integration overview page which describes the different types of data collected by the integration - that should give the user a good starting point on how to setup their Rule to only promote valid threats to SIEM alerts in kibana.

---

@caitlinbetz - it would be great if we could get an example rule from one of our customers that run CrowdStrike just to see how they have setup their rule

[joepeeples]

A sample index pattern or query would be preferable, I think — linking to the integration's docs could be overwhelming since it just lists every possible fields ingested, but doesn't recommend any particular pattern.

Is there an alert-specific pattern we could suggest, similar to how for SentinelOne we suggest logs-sentinel_one.alert*? That way the query only targets alerts, not all CrowdStrike data.

[tomsonpl]

I would agree with @paul-tavares here, it's really up to user what query they want to use and most of the times they are pretty specific. For the docs I would suggest using something like this: 'use a query or index pattern that could find Crowdstrike data' - of course in better English ;p

WDYT @joepeeples ?

[joepeeples]

Similar to above, I'll reword this to be more general guidance, and probably link to our CrowdStrike integration docs page since it lists all the available fields. Even if it's up to the user to write queries however they see fit, it'd be ideal if we could at least give some example queries to illustrate how to detect specific things, but maybe we can add that in a later revision once we know more about the data.

[tomsonpl]

Added my 2 cents to Paul's great comments, but other than that - LGTM 👍 thank you!

[joepeeples]

@paul-tavares @tomsonpl I pushed some revisions to address your feedback above (API client privs, rule query suggestions). Please check out the updated preview page and let me know if this works. We can always add more details later to fine-tune our guidance for customers. Thanks!

[joepeeples]

Wondering if the API client used to perform actions also needs privs to read CrowdStrike data?

[tomsonpl]

🤷 no idea, but I would assume it's nicely explained in CrowdStrike when creating credentials, so imho the users shouldn't be confused by this 👍

[tomsonpl]

LGTM 👍 thank you !