Add Cyble IOC workflow

[prasad-cyble]

Add Cyble IOC workflow (Universal Cloud REST API)

Summary

Adds a new community log source workflow that ingests Indicators of Compromise (IOCs) from Cyble Vision into QRadar via the Universal Cloud REST API protocol. This complements the existing Cyble Threat Intel (alerts) workflow.

New files under Community Developed/Cyble IOC/:

• Cyble-IOC-Workflow.xml — the workflow
• Cyble-IOC-Workflow-Parameter-Values.xml — parameter values template (no secrets)
• README.md — setup, parameters, filter discovery, and versioning notes

What it does

• Pulls IOCs from POST /engine/api/v4/y/iocs (JSON body, Bearer auth), one PostEvent per IOC into Universal DSM.
• Configurable filters via workflow parameters: ioc_type, risk_gte/risk_lte (risk rating range), and optional regions and industries.
• Multiple IOC types supported: the API accepts a single type per request, so the workflow Splits a comma-separated ioc_type and runs one paginated pass per type.
• Incremental fetching mirrors the Threat Intel workflow (first-fetch seeded by fetch_since, then fromDate = last toDate + 1), formatted to the date-only (yyyy-MM-dd) window the IOC API expects.
• De-duplication: because the API filters by date only (so the window overlaps on the current day), the workflow keeps a persistent per-type last_seen high-water mark and posts only newer IOCs, stopping pagination as soon as it reaches already-ingested ones.
• Pagination with a modest page size (limit=100) to avoid upstream 504: Gateway Timeout.

Design decisions validated against the live API

• Body must use string values for iocType/regions/industries (JSON arrays return 500); riskRating is a JSON object.
• Empty regions/industries are ignored by the API (equivalent to no filter), so they're always sent and safe to leave blank.
• README documents the GET /engine/api/v2/y/iocs/filters endpoint to discover valid filter values, with the current enumerations (IOC types, regions, industries, confidence ratings).

[prasad-cyble]

Hi @ChrisCollinsIBM please review this PR

[prasad-cyble]

Hi @ChrisCollinsIBM it would be very helpfull if you review and merge this PR.

[ChrisCollinsIBM]

Please review the namespace and possible source tag conflicts and comment on whether the concerns are valid.

Thanks!

[ChrisCollinsIBM]

This workflow is still using the V1 namespace which requires a source tag.

There is another Cyble workflow at https://github.com/IBM/IBM-QRadar-Universal-Cloud-REST-API/tree/master/Community%20Developed/Cyble%20Threat%20Intel also using the V1 namespace and using the API host as the source

IBM-QRadar-Universal-Cloud-REST-API/Community Developed/Cyble Threat Intel/Cyble-Threat-Intel-Workflow.xml

Line 98 in 58a6f89

<PostEvent path="/current_event" source="${/hostname}" />

Would that workflow and this workflow be using the same API endpoint for the same customer? If so there will be a conflict here with the customer trying to setup to Universal REST API log sources with the same identifier.

Give the API path in the CallEndpoint command in each I suspect that will be the case, but please confirm.

IBM-QRadar-Universal-Cloud-REST-API/Community Developed/Cyble Threat Intel/Cyble-Threat-Intel-Workflow.xml

Line 65 in 58a6f89

<CallEndpoint url="https://${/hostname}/engine/api/v1/y/tpi/qradar/alerts" method="POST" savePath="/get_events">

[ChrisCollinsIBM]

Any new workflows should really be using the V2_1 namespace to ensure access to the latest features, but especially the Postevent changes around not needing to specify a source attribute, more details below.