CrowdStrike Falcon

What Hal reads

Falcon alerts: the detections your sensors raise, read from Falcon’s own Alerts feed with no product filter. Prevent and Insight detections and CrowdStrike Signal leads arrive today; Identity, Cloud and Mobile alerts arrive the same way where you have them. Each one lands in Hal’s triage with its severity, tactic and technique, the host and user involved, and the file or command line behind it, so a Falcon detection is judged alongside the same user’s sign-ins and mailbox activity rather than in a console of its own. The first pull reaches back 30 days; after that Hal reads the feed on every cycle.

Falcon Spotlight, if your subscription includes it: ask Hal in chat what is exploitable at a client right now, which machines carry a CVE, or what is open on a host, and he reads it from Spotlight at that moment. He leads with what matters, the vulnerabilities on CISA’s known-exploited list or rated critical or high for exploitability by CrowdStrike, with the machines carrying each and the remediation Falcon recommends, and can put the full list in a PDF or CSV. Nothing of it is stored in Hal: exposure is a picture of now, and he asks Falcon for it when you ask him.

Access is read-only, and that is enforced by the credential you create, not by a promise: the API client gets Alerts → Read and Sensor Download → Read, and optionally Hosts → Read and Vulnerabilities → Read, none of which can change anything. Hal cannot change an alert’s status, assign it, or touch a host.

This page is the one thing on your side: creating the API client Hal reads with. It takes about five minutes in your own Falcon console. There is no partner account to apply for and nothing to install.

Before you start

• You need the Falcon Administrator role, or someone who has it.
• Note the hostname you sign in at. It names your cloud region, and Hal needs it: a credential only works against its own region.

• Hal connects one API client per CID. If each customer has a standalone CID, you create one API client in each customer’s console. If you manage customers as member CIDs under a parent CID (Flight Control), you still create the client in each member CID you want Hal to watch and hand him each one; a parent-CID credential that covers members is planned, and we will build it with the first design partner who runs that way.

Create the API client

1. Sign in to the Falcon console.
2. In the left navigation, open Support and resources → API clients and keys.
3. Under OAuth2 API clients, click Add new API client (some console versions label it Create API client).
4. Client name: Hal. Add a short description, so it’s obvious in a year what it is for.
5. API scopes: tick Alerts → Read and Sensor Download → Read. Sensor Download lets Hal read your CID before the first detection arrives; without it he learns the CID from the first alert instead. If you want him to answer questions about the sensors themselves in chat, add Hosts → Read; without it he still reads every alert, he just cannot list hosts. If you have Falcon Spotlight and want Hal to answer exposure questions, add Vulnerabilities → Read; questions about a named host also need Hosts → Read, which is how Hal finds the sensor. Leave everything else unticked. Scopes can be changed later on this same page, and a scope you tick later applies to Hal’s next request. If Vulnerabilities → Read is ticked and Hal reports Falcon still refuses, your subscription has no Spotlight module.
6. Click Add.

The confirmation shows two values: the Client ID (32 hex characters) and the Secret (40 characters). Copy the secret now. It is not shown again; if it’s lost, reset it from the same page, which invalidates the old one.

Hand it to Hal

In the Hal portal chat, as a Hal admin, tell Hal which client this Falcon tenant belongs to: “Connect CrowdStrike for Acme.” He opens a paste box for that client under Settings → CrowdStrike Falcon (it stays open for a day; asking again re-opens it) and relays the steps above. Paste the Client ID and the Secret into that box, pick the cloud region from the table, Save, and tell him you’re done. The secret never passes through chat.

When you say done, Hal reads the paste and checks it against Falcon: he signs in with it, confirms Alerts → Read is granted, reads the tenant’s CID (from Sensor Download → Read, or from the newest alert if that scope is missing), and asks the Hosts API whether Hosts → Read is granted. He then tells you what he found, the CID, the cloud, the scopes present, whether Hosts → Read is granted, how many alerts are on record and the newest one, and asks you to confirm. Nothing is stored until you do. Say yes and he stores the tenant and the credential, creates the client’s Falcon log source and connects it to the detection pipeline; the first pull runs in his next cycle, 30 days back. Say no and he closes the box and writes nothing.

If the credential is rejected, the Alerts scope is missing, or the CID cannot be read, Hal says so and tells you what to change in the console. To replace the API client later, after a reset secret or a rejected credential, ask Hal to rotate Acme’s CrowdStrike credentials: he opens the box again, checks that the new paste belongs to the same tenant, and swaps it in.

Related: the other integrations Hal reads, and how detections move through triage.