Overview
This article is a workflow guide to accompany the CrowdStrike Falcon Next-Gen SIEM Intelligence Engine app in Agentic TIP.
There are two ways to feed the CrowdStrike Next-Gen SIEM detections.
- Route A uses the lookup file that the CrowdStrike Falcon Next-Gen SIEM Egress app builds for you from the indicators you already hold in Agentic TIP.
- Route B uses a lookup file you provide yourself.
Route A pushes indicators to Next-Gen SIEM as a lookup file, Falcon detects against it, and each hit comes back to Agentic TIP as an Event with the matched indicator attached.
Route B provides four sample detections running in Falcon Next-Gen SIEM. Each one creates an Event in Agentic TIP with the related IPs, domains, URLs, email addresses, and file hashes attached as associated indicators.
How it works
- Events flow into Falcon Next-Gen SIEM from any source.
- A correlation rule compares one field in each event against a lookup file you upload.
- When a value matches a row, the rule copies the indicators from that row onto the alert as ioc[N] fields.
- The CrowdStrike Falcon Next-Gen SIEM Intelligence Engine app pulls High and Critical alerts (as configured in the Agentic TIP integration), reads the ioc[N] fields, and creates the indicators.
The Agentic TIP app does not scan your logs for indicators. It reads one thing: fields named ioc[0].indicator, ioc[0].type, ioc[0].malicious_confidence and ioc[0].labels (and the same for ioc[1], ioc[2] and so on) on the match event Falcon writes when a rule fires.
The sample rules in this guide add the ioc[N] fields using a lookup file. CrowdStrike's own ioc:lookup() function can also add ioc[N] fields, but only for IP addresses, URLs and domains, and only from CrowdStrike's own intelligence.
The lookup file route in this guide works with your own intelligence and supports all seven indicator types.
Choose your route
| header | Route A: Egress app lookup file | Route B: your own lookup file |
|---|---|---|
| Indicators in Agentic TIP | A CSV you write or export | |
| Who builds the file | The Egress app, refreshed on a schedule | You, by hand or from another tool |
| Indicators per alert | One, the value that matched | As many as the row lists |
| Best for | Detecting on the intelligence you already curate | Alerts that need several related indicators, or intel that is not in Agentic TIP |
| Setup effort | Install and configure the Egress app | Paste a few CSV files |
Dependencies
Agentic TIP Dependencies
- The CrowdStrike Falcon Next-Gen SIEM Intelligence Engine app is installed and has been configured, as per documentation.
- A command line with curl to send the sample events.
CrowdStrike Dependencies
- Access to Falcon Next-Gen SIEM with permission to upload lookup files, create correlation rules, and create a data connection. Ask your Falcon administrator if you cannot see these menus.
- Permission to create an API client in the Falcon console.
- For Route A, the CrowdStrike Falcon Next-Gen SIEM Egress app.
Step 1. Create an API client for Agenetic TIP
The CrowdStrike Falcon Next-Gen SIEM Intelligence Engine app signs in to Falcon with an API client. Give it only what it needs.
- In the Falcon console go to Support and resources > API clients and keys.
- Select Create API client and name it something clear, for example Agentic TIP-ngsiem.
- Grant read access to Alerts and NGSIEM.
- Create the client and copy the Client ID and Secret straight away.
Step 2. What each indicator looks like
Each indicator is a group of four fields. The number N is unique on the alert, starting from 0.
| Field | What it goes into |
|---|---|
| ioc[N].indicator | The value: an IP address, domain, URL, email address or file hash |
| ioc[N].type | One of the type names in the table below |
| ioc[N].malicious_confidence | high, medium, low or unverified |
| ioc[N].labels | Comma-separated tags, optional |
| ioc[N].type | Agentic TIP indicator |
|---|---|
| ip_address | Address |
| domain | Host |
| url | URL |
| email_address | EmailAddress |
| hash_md5 | File |
| hash_sha | File |
| hash_sha256 | File |
Confidence converts to: high is confidence 75 and rating 4, medium is 50 and 3, low is 25 and 2, unverified is 10 and 1. Labels become tags on the indicator.
Step 3. Create a data connection for the sample events
Skip this step if you already have real events that match your lookup values.
- In the Falcon console open the data connectors area of Next-Gen SIEM and add a new connector for HEC / HTTP event collector.
- Name it ioc-sample-test and choose the generic JSON parser.
- Save it, then copy the API URL and the API key.
- In your terminal set them as variables:
export HEC_URL="paste the API URL here"
export HEC_TOKEN="paste the API key here"
Step 4. Route A Option. Use the lookup file from the Agentic TIP Egress app
A1. Set up the Egress app
The Egress app reads indicators from Agentic TIP and writes them to a CSV lookup file in Next-Gen SIEM. It is one-way. It does not create anything in Agentic TIP.
Install and configure it by following its user guide: https://knowledge.Agentic TIP.com/docs/crowdstrike-falcon-next-gen-siem-user-guide
The settings that matter for detections:
| Setting | Default | What to know |
|---|---|---|
| Next-Gen SIEM Lookup Table Filename | tc_ioc_lookup | This is the file your rules read. Use one service and one file name per intel set. |
| Next-Gen SIEM Repository | search-all | Case-sensitive. CrowdStrike has no way to list repositories, so a typo fails silently. |
| Time-to-live per indicator type | 24 hours | Rows expire after this time and are dropped from the file. Increase Time-To-Live configurations for each supported Indicator type. |
| CrowdStrike API Endpoint | none | Must match the cloud where the API client was created. |
Create an export configuration that selects only the indicators you want to alert on, for example, high-confidence indicators from one owner using TQL. Every indicator in the file can raise an alert, so a broad export means a noisy rule.
A2. Confirm the file exists in Falcon
Go to Next-Gen SIEM > Lookup files and look for the file name you set, usually tc_ioc_lookup.csv.
Open it. The columns are:
| Column | What it holds |
|---|---|
| value | The indicator, one row per value |
| type | The Agentic TIP indicator type |
| rating | Agentic TIP rating |
| confidence | Agentic TIP confidence |
| ThreatAssessScore | Agentic TIP score |
| expires_at | When the indicator expires (TTL) |
A3. Know what the rule has to do
The Ingress app reads ioc[N] fields. The Egress file has value, type, rating and confidence instead. So the rule does two jobs. It matches the event field against the value column, then it builds the ioc[N] fields itself.
Because the rule already knows which event field it matched, it can set the indicator type directly.
| Event field matched | Set ioc[0].type to |
|---|---|
| destination.ip | ip_address |
| dns.question.name | domain |
| url.full | url |
| email.from.address | email_address |
| file.hash.md5 | hash_md5 |
| file.hash.sha1 | hash_sha1 |
| file.hash.sha256 | hash_sha256 |
A row gives one indicator, so each alert from Route A carries one indicator. To attach several related indicators to one alert, use Route B.
A4. Create the rules
Create one correlation rule per event field, as a filter (streaming) rule with severity High. The app's default query ignores Medium and below.
Rule name: TC intel - destination IP
#event.dataset=ioc.sample labels.scenario="tc-egress-ip"
| match(file="tc_ioc_lookup.csv", field=destination.ip, column=value, strict=true, include=["confidence", "rating"])
| "ioc[0].indicator" := destination.ip
| "ioc[0].type" := "ip_address"
| "ioc[0].malicious_confidence" := "high"
| "ioc[0].labels" := "Agentic TIP"
Rule name: TC intel - file SHA256
#event.dataset=ioc.sample labels.scenario="tc-egress-sha256"
| match(file="tc_ioc_lookup.csv", field=file.hash.sha256, column=value, strict=true, include=["confidence", "rating"])
| "ioc[0].indicator" := file.hash.sha256
| "ioc[0].type" := "hash_sha256"
| "ioc[0].malicious_confidence" := "high"
| "ioc[0].labels" := "Agentic TIP"
For another field, copy a rule and change three things: the field= value, the field name on the ioc[0].indicator line, and the type on the ioc[0].type line, using the table in A3.
How the query works:
- The first line selects the events to look at. The test rules use a sample dataset and a scenario label. For real detections, replace it with a filter for your own data, for example the dataset of your proxy or endpoint logs.
- file is the lookup file name. If your file name differs, change it. Falcon file names end in .csv.
- column=value is the indicator column in the Egress file.
- strict=true means only events that match a row create an alert.
- include copies the matched row's confidence and rating onto the event, so you can see them in the alert.
- The four lines starting with a quoted ioc[0] name build the fields the Ingress app reads. Confidence is set to high for every hit.
Do not add aggregate functions such as groupBy() or count() to a filter rule. Falcon rejects them in streaming rules, and scheduled aggregate rules produce grouped rows that carry no ioc[N] fields.
A5. Send a test event
Use an indicator you noted from the file in A2.
export TEST_IP="paste an IP from the lookup file"
export TEST_SHA256="paste a SHA256 from the lookup file"
Destination IP test
curl -s -X POST "$HEC_URL" \
-H "Authorization: Bearer $HEC_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"event\":{\"event\":{\"dataset\":\"ioc.sample\",\"kind\":\"event\"},\"host\":{\"name\":\"SAMPLE-HOST-04\"},\"destination\":{\"ip\":\"$TEST_IP\"},\"labels\":{\"scenario\":\"tc-egress-ip\"}},\"sourcetype\":\"_json\"}"
File SHA256 test
curl -s -X POST "$HEC_URL" \
-H "Authorization: Bearer $HEC_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"event\":{\"event\":{\"dataset\":\"ioc.sample\",\"kind\":\"event\"},\"host\":{\"name\":\"SAMPLE-HOST-05\"},\"file\":{\"name\":\"update.exe\",\"hash\":{\"sha256\":\"$TEST_SHA256\"}},\"labels\":{\"scenario\":\"tc-egress-sha256\"}},\"sourcetype\":\"_json\"}"
Do not send a timestamp. Falcon uses the time it receives the event. Then go to Step 5 to check the result.
Step 4. Route B Option. Use your own lookup file
Use this route when you do not run the Egress app, when your intelligence is not in Agentic TIP, or when one alert should carry several related indicators.
B1. Create the four lookup files
A lookup file is a small CSV that Falcon compares event values against. Each sample has its own.
For each file below:
- Copy the text into a plain text editor.
- Save it with exactly the file name shown, ending in .csv. Choose UTF-8 if asked, and make sure the editor does not add .txt.
- In Falcon, go to Next-Gen SIEM > Lookup files, import the file, and keep the name.
Each file has a header line and one data row. Keep both lines. The column names must be written exactly as shown, brackets included.
ioc_sample_c2.csv
indicator,ioc[0].indicator,ioc[0].type,ioc[0].malicious_confidence,ioc[0].labels,ioc[1].indicator,ioc[1].type,ioc[1].malicious_confidence,ioc[1].labels,ioc[2].indicator,ioc[2].type,ioc[2].malicious_confidence,ioc[2].labels
147.43.181.134,147.43.181.134,ip_address,high,c2_server,sample-c2-gateway.com,domain,high,c2_domain,https://sample-c2-gateway.com/beacon/check,url,medium,c2_url
ioc_sample_phish.csv
indicator,ioc[0].indicator,ioc[0].type,ioc[0].malicious_confidence,ioc[0].labels,ioc[1].indicator,ioc[1].type,ioc[1].malicious_confidence,ioc[1].labels,ioc[2].indicator,ioc[2].type,ioc[2].malicious_confidence,ioc[2].labels,ioc[3].indicator,ioc[3].type,ioc[3].malicious_confidence,ioc[3].labels
billing@sample-invoice-portal.com,billing@sample-invoice-portal.com,email_address,high,phishing_sender,sample-invoice-portal.com,domain,high,phishing_domain,https://sample-invoice-portal.com/pay/invoice-4471,url,high,phishing_url,24a8974395e7686e9422728fea7b98b9f4d223715c1507906c6b5a9da420ad71,hash_sha256,high,malicious_attachment
ioc_sample_malware.csv
indicator,ioc[0].indicator,ioc[0].type,ioc[0].malicious_confidence,ioc[0].labels,ioc[1].indicator,ioc[1].type,ioc[1].malicious_confidence,ioc[1].labels,ioc[2].indicator,ioc[2].type,ioc[2].malicious_confidence,ioc[2].labels,ioc[3].indicator,ioc[3].type,ioc[3].malicious_confidence,ioc[3].labels,ioc[4].indicator,ioc[4].type,ioc[4].malicious_confidence,ioc[4].labels
18e7f5b2d25780351efca324c956226547428e7ef00507fa9328149f768632a9,18e7f5b2d25780351efca324c956226547428e7ef00507fa9328149f768632a9,hash_sha256,high,malware_sample,3805578e5e692bf2e52be43ac5968a2e,hash_md5,high,malware_sample,3870ff2d07abc8e38bbaed102245e85aa9e89601,hash_sha1,high,malware_sample,117.6.233.10,ip_address,medium,malware_c2,sample-payload-host.com,domain,medium,malware_staging
ioc_sample_dns.csv
indicator,ioc[0].indicator,ioc[0].type,ioc[0].malicious_confidence,ioc[0].labels,ioc[1].indicator,ioc[1].type,ioc[1].malicious_confidence,ioc[1].labels
xk3q9vlz7t.sample-dga-net.com,xk3q9vlz7t.sample-dga-net.com,domain,high,dga_domain,49.128.136.31,ip_address,medium,dga_resolved_ip
The first column, indicator, is the value the rule matches on. The ioc[N] columns hold what gets attached to the alert.
| Sample detection | Matches on | Indicators it attaches |
|---|---|---|
| C2 callout | destination.ip | IP, domain, URL |
| Phishing email | email.from.address | Email address, domain, URL, attachment hash |
| Malware execution | file.hash.sha256 | SHA256, MD5 and SHA1 hashes, IP, domain |
| Suspicious DNS lookup | dns.question.name | Domain, IP |
The values in these samples are made up for testing. The domains are invented and never contacted. The IP addresses are real public addresses used only as text. Do not use documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) or reserved test domains such as .example for anything you send to Agentic TIP. Owners usually exclude them, and one rejected value can fail the whole batch.
For production use, replace every value with indicators from your own intelligence.
:::
Email addresses are personal data. If your privacy policy requires it, hash or redact email values before they go into a lookup file.
B2. Create the four detection rules
- Go to Next-Gen SIEM > Detections and create a new correlation rule.
- Choose a filter (streaming) rule type so the alert fires as events arrive.
- Set the severity to High. The app's default query ignores Medium and below, so a Medium alert never reaches Agentic TIP.
- Paste the query, name the rule as shown and save it.
Rule name: Sample - C2 callout
#event.dataset=ioc.sample labels.scenario="sample-c2"
| match(file="ioc_sample_c2.csv", field=destination.ip, column=indicator, strict=true, include=["ioc[0].indicator", "ioc[0].type", "ioc[0].malicious_confidence", "ioc[0].labels", "ioc[1].indicator", "ioc[1].type", "ioc[1].malicious_confidence", "ioc[1].labels", "ioc[2].indicator", "ioc[2].type", "ioc[2].malicious_confidence", "ioc[2].labels"])
Rule name: Sample - Phishing email
#event.dataset=ioc.sample labels.scenario="sample-phish"
| match(file="ioc_sample_phish.csv", field=email.from.address, column=indicator, strict=true, include=["ioc[0].indicator", "ioc[0].type", "ioc[0].malicious_confidence", "ioc[0].labels", "ioc[1].indicator", "ioc[1].type", "ioc[1].malicious_confidence", "ioc[1].labels", "ioc[2].indicator", "ioc[2].type", "ioc[2].malicious_confidence", "ioc[2].labels", "ioc[3].indicator", "ioc[3].type", "ioc[3].malicious_confidence", "ioc[3].labels"])
Rule name: Sample - Malware execution
#event.dataset=ioc.sample labels.scenario="sample-malware"
| match(file="ioc_sample_malware.csv", field=file.hash.sha256, column=indicator, strict=true, include=["ioc[0].indicator", "ioc[0].type", "ioc[0].malicious_confidence", "ioc[0].labels", "ioc[1].indicator", "ioc[1].type", "ioc[1].malicious_confidence", "ioc[1].labels", "ioc[2].indicator", "ioc[2].type", "ioc[2].malicious_confidence", "ioc[2].labels", "ioc[3].indicator", "ioc[3].type", "ioc[3].malicious_confidence", "ioc[3].labels", "ioc[4].indicator", "ioc[4].type", "ioc[4].malicious_confidence", "ioc[4].labels"])
Rule name: Sample - Suspicious DNS lookup
#event.dataset=ioc.sample labels.scenario="sample-dns"
| match(file="ioc_sample_dns.csv", field=dns.question.name, column=indicator, strict=true, include=["ioc[0].indicator", "ioc[0].type", "ioc[0].malicious_confidence", "ioc[0].labels", "ioc[1].indicator", "ioc[1].type", "ioc[1].malicious_confidence", "ioc[1].labels"])
- The first line selects the events to look at. Each sample event carries a labels.scenario value, so each rule only sees its own sample.
- file is the lookup file name from Step 4.
- file is the lookup file name from Step 4 (Route A or B).
- field is the event field being compared. This is the one you change for a different use case.
- strict=true means only events that match a row create an alert. That keeps noise down and stops alerts with no indicators from reaching Agentic TIP.
- include lists every ioc[N] column to copy onto the event. Anything left out of this list is not delivered.
Do not add aggregate functions such as groupBy() or count() to a filter rule. Falcon rejects them in streaming rules, and scheduled aggregate rules produce grouped rows that carry no ioc[N] fields.
B3. Send the sample eventsmatches one sample. Run them one at a time.
C2 callout
curl -s -X POST "$HEC_URL" \
-H "Authorization: Bearer $HEC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"event":{"event":{"dataset":"ioc.sample","kind":"event"},"host":{"name":"SAMPLE-HOST-01"},"destination":{"ip":"147.43.181.134"},"labels":{"scenario":"sample-c2"}},"sourcetype":"_json"}'
Phishing email
curl -s -X POST "$HEC_URL" \
-H "Authorization: Bearer $HEC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"event":{"event":{"dataset":"ioc.sample","kind":"event"},"host":{"name":"SAMPLE-MAILGW-01"},"email":{"from":{"address":"billing@sample-invoice-portal.com"}},"url":{"full":"https://sample-invoice-portal.com/pay/invoice-4471"},"file":{"hash":{"sha256":"24a8974395e7686e9422728fea7b98b9f4d223715c1507906c6b5a9da420ad71"}},"labels":{"scenario":"sample-phish"}},"sourcetype":"_json"}'
Malware Execution
curl -s -X POST "$HEC_URL" \
-H "Authorization: Bearer $HEC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"event":{"event":{"dataset":"ioc.sample","kind":"event"},"host":{"name":"SAMPLE-HOST-02"},"file":{"name":"update.exe","hash":{"sha256":"18e7f5b2d25780351efca324c956226547428e7ef00507fa9328149f768632a9"}},"labels":{"scenario":"sample-malware"}},"sourcetype":"_json"}'
Suspicious DNS lookup
curl -s -X POST "$HEC_URL" \
-H "Authorization: Bearer $HEC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"event":{"event":{"dataset":"ioc.sample","kind":"event"},"host":{"name":"SAMPLE-HOST-03"},"dns":{"question":{"name":"xk3q9vlz7t.sample-dga-net.com"}},"labels":{"scenario":"sample-dns"}},"sourcetype":"_json"}'
Do not send a timestamp. Falcon uses the time it receives the event. Wait about a minute before you search for it.
Step 5. Check it in Falcon before involving Agentic TIP (Both Routes)
Do these checks in order. Each one proves a different link. Wait about a minute after sending an event.
5a. Confirm the event arrived. In Next-Gen SIEM > Advanced event search, last 15 minutes:
#event.dataset=ioc.sample
| table([@timestamp, labels.scenario, destination.ip, email.from.address, file.hash.sha256, dns.question.name])
You should see one row per command you ran.
5b. Confirm the alert fired.
le rule. The alert should show High severity. If nothing appears, the rule query found no match. The usual causes are a lookup file name that differs from the one in the query, or a value in the CSV that does not exactly match the event.
5c. Confirm the indicators were stored.
Search the stored match events. Do not put match() in this query, or the search adds the fields itself and hides a rule problem:atch() in this query, or the search adds the fields itself and hides a rule problem:
iem.event.type="ngsiem-rule-match-event" #event.dataset=ioc.sample
Ngsiem.event.type="ngsiem-rule-match-event" #event.dataset=ioc.sample
| table([@timestamp, Ngsiem.alert.id, labels.scenario, "ioc[0].indicator", "ioc[0].type", "ioc[1].indicator", "ioc[2].indicator", "ioc[3].indicator", "ioc[4].indicator"], limit=20)
newest alert for each sample should show every slot filled. The C2 sample fills three slots, phishing four, malware five, and DNS two. If a slot is blank, reopen the rule and read the saved query text.
The newest alert for each rule should show its indicators. Route A shows ioc[0] only. Route B shows every slot the sample row lists. If a field is blank, reopen the rule and read the saved query text.
Step 6. Configure the Agentic TIP Ingress app
CrowdStrike Falcon Next-Gen SIEM Intelligence Engine app guide: https://knowledge.threatconnect.com/docs/crowdstrike-falcon-next-gen-siem-ingress-user-guide
Agentic TIP
At the configuration screen, enter:
| Setting | Value |
|---|---|
| CrowdStrike API Endpoint | Your cloud region: US-1, US-2, EU-1 or US-Gov-1 |
| CrowdStrike API Client ID | From Step 1 |
| CrowdStrike API Client Secret | From Step 1 |
| Next-Gen SIEM Alert Query | Leave the default unless you need to narrow it |
The default query is:
product:'ngsiem'+type:'correlation-detection'+severity_name:['Critical', 'High'].
To bring in fewer alerts, add to it, for example, by rule name. Always keep the product:'ngsiem' and type:'correlation-detection' parts. Narrowing the query is the main way to control volume.
Step 7. Confirm Alerts appear in Agentic TIP
- Run the app job, or wait for its schedule. The alert has to fall inside the job's time window. The app pulls on a schedule and does not stream.
- Find the Event. Its name starts with the rule name, followed by the tail of the alert ID in square brackets. e.g. "R3: Known-malicious file hash executed [44b6bccbdb1741eeaf069e99104fa432]"
- Open the Event and select Associations.
What each sample should produce:
| Rule | Associations |
|---|---|
| Route A, destination IP | 1 Address |
| Route A, file SHA256 | 1 File |
| Route B, C2 callout | 1 Address, 1 Host, 1 URL |
| Route B, phishing email | 1 EmailAddress, 1 Host, 1 URL, 1 File |
| Route B, malware execution | File indicators for the SHA256, MD5 and SHA1 hashes, 1 Address, 1 Host |
| Route B, suspicious DNS lookup | 1 Host, 1 Address |
Build your own detection
- Pick the scenario and the field. Decide what should trigger the alert and which event field holds the value, for example file.hash.sha256 for a known-bad file. Confirm in Advanced event search that your logs fill that field.
- Build the lookup file. One row per known-bad value. The first column, indicator, is the value to match. Add ioc[N] columns for each indicator you want attached. Copy the header pattern from a sample and add or remove slots as needed.
- Pick the route. If the value is an indicator you hold in Agentic TIP, use Route A and copy a rule from A4. If you need several indicators on one alert, or the intel lives elsewhere, use Route B.
- For Route B, build the lookup file. One row per known-bad value. The first column, indicator, is the value to match. Add ioc[N] columns for each indicator you want attached, copying the header pattern from a sample.
- Replace the filter on the first line with one for your real events.
- Run checks 5a to 5c. Then confirm in Agentic TIP.
Exact matching matters. Values are compared exactly, so keep hashes in lowercase and write URLs and domains the way your logs record them.
Troubleshooting
| What you see | Likely cause | What to do |
|---|---|---|
| No Event in Agentic TIP | Alert is Medium or Low, or outside the job's time window | Raise the rule severity to High, check the alert time, run the job again |
| Event exists but has no Associations | The stored match event has no ioc[N] fields | Run check 5c. Fix the rule, then send a fresh event. The existing alert does not update |
| Route A, no alert fires | The Egress file is missing, still empty, or the file name in the rule differs | Open Lookup files, confirm the name and that the test value is in the value column |
| Route A, Egress file never appears | Wrong repository name or API client access | Check the Egress app settings. The repository name is case-sensitive, and the Egress job logs show the Falcon error |
| Route A, rule saves but ioc[0] fields are blank | The assignment lines were not saved with the rule | Reopen the rule and confirm all four ioc[0] lines are present |
| Route B, only one indicator, usually the first | The rule lists only ioc[0] in include, or chains several match() calls | Use one match() call with every slot in include |
| Some indicators missing, others present | Agentic TIP rejected those values, for example an excluded IP or an invalid domain | Open Batch Errors in the Ingress app. It names each rejected value and the reason |
| Two alerts per event, one with no indicators | A second rule matches the same events | Disable every rule except the one you are testing |
| TableDoesNotExist error | The lookup file is not uploaded, or the name differs | Upload the file and match the name exactly |
| Indicator type silently dropped | The type value is not one of the seven supported names | Correct the spelling, for example hash_sha256 and not sha256 |
Best practice
- Start with one rule and one lookup file, prove it end to end, then expand.
- Alert only on indicators you would act on.
- Keep the API client scoped to read access For Route A, narrow the Egress export configuration first, because every row in the file can raise an alert.and rotate its secret on a schedule.
- All traffic between the app and Falcon runs over HTTPS. The app records its actions in its job and task logs, which is where you look when something fails.
- Existing alerts never change. If you fix a rule, new alerts get the fix and old ones keep what they had.
- Disable or delete the sample rules and lookup files when you are done.