This article will provide an overview of Cydarm webhooks.
Webhooks overview
Webhooks are intended as a way to send data to Cydarm for external systems that do not have any authorisation to access the API. The webhook URL is a configuration option, but it is a static configuration, ie. not an address per case.
The format of the URL is as follows: /webhook/base64-encoded-webhook-secret/topic/topic-name
The base64 encoded secret is comprised of a user:user-secret string, base64 encoded. The user part of the secret does not have to be a real username, just some kind of identifying label to distinguish different webhook URLs, while the user-secret part should be randomly generated. Multiple webhooks can be configured, with different secrets to receive data from multiple sources. Within each webhook, multiple topics can be configured, to deliver data in different formats, eg. Elastic, Splunk, GuardDuty.
Behind the scenes, data sent to a topic is delivered to a translator that tries to confirm the format of the data (using cascading rules) and then convert it to STIX2.1, augmented with some customer Cydarm fields. The STIX2.1 data is delivered to a case loader, that creates a new case from each payload and attaches the data payload to the case
If the data payload was successfully processed by the translation engine, then it will show up as STIX2.1 and appear rendered on the graph, per the examples on the stack.
If the data payload was not recognised by the translation engine, it gets attached as a file. Note that data which parses as JSON will be attached as a JSON file, subject to syntax highlighted formatting, and we have an option to do this as pretty-printed colourful JSON, or as a table (based on system property JSON_SYNTAX_STYLE).
For more detailed technical information please refer to our Cydarm API documentation.
