We’re excited to announce connectors in QRadar SOAR v51.0.5.0. Connectors are intended to provide a low-code capability to playbook design requiring REST API call execution. Connectors overcome many challenges companies experience with apps:
· How to fill the gap between existing and missing apps found on the AppExchange,
· How to resource personnel to develop or extend existing apps with additional functions, and
· How to manage additional system resources, such as private registries for private apps.
This solution meets several design goals:
· Utilize the industry standard, OpenAPI, for REST API specification,
· Speed SOAR playbook development,
· Minimize the skills necessary to develop integrations, and
· Use existing product resources, such as App Host.
Connectors are exposed through the same App Host run-time environment used for SOAR apps. But unlike apps, no additional deployments are required.
For companies moving to v51.0.5.0, I encourage you to explore the changes to the Playbook Designer with connectors. Connector specifications can be imported, configured, and functions incorporated into playbooks, all from the same playbook designer view.
Refer to the QRadar SOAR documentation for detailed information about connectors and how to incorporate them into playbooks. The remainder of this blog is focused on the OpenAPI specification file required to import connectors.
OpenAPI
In brief, OpenAPI is an industry specification for describing REST API endpoints including:
· What URL to use for service access,
· What authentication to use for API calls,
· What endpoints are exposed for API calls, their input parameters and expected results
All this information is in either specified as JSON or YAML format files intended for machine-readable use.
Many vendors expose OpenAPI documents for their product’s public APIs. These documents can be used with tools to code-generate client software, or like IBM QRadar SOAR, import the specification file in order to make API calls and incorporate the data returned.
There are three options for acquiring an OpenAPI spec for a given vendor product:
· From the vendor,
· From external sources, or
From the Vendor
Some vendors publish OpenAPI documents. However, not all do. A few examples are:
· Tenable
· Github
In most cases, if you search the Internet with: <vendor> openapi download, the results will identify if OpenAPI documents are available for download. Contacting a vendor directly would also help.
From External Sources
In lieu of vendor produced OpenAPI documents, enterprising individuals have produced their own OpenAPI documents of vendor APIs. A useful resource is https://apis.guru, documenting OpenAPI solutions across a wide set of categories. These solutions should be vetted to ensure:
· They represent the version of the product you need access to,
· They are complete, defining the REST API endpoints you require, and
· They are accurate
Develop your own
More times than not, a vendor publishes their public APIs for reference, but do not specify an OpenAPI document for download. This is not a lost cause. There are a number of online tools for crafting the specification document, such as https://editor-next.swagger.io and https://www.apibldr.com. In both cases, knowledge of the OpenAPI taxonomy is required and, in my opinion, a little confusing to navigate until you become familiar with its terminology and syntax. Beyond that, these tools can help produce the specification document you need.
Another solution is OpenAPIBuilder which can be found at IBM's GitHub. It’s a command line tool, written in Python, introducing the user to the different OpenAPI data sections, explaining the meaning of the data required, and prompting with examples.
As an example, let’s say you’d like to write a connector for PagerDuty to create an incident. Start by referencing the PagerDuty documentation here and here.
Data from the PagerDuty REST API reference pages, such as the ‘create incident’ endpoint, would be transcribed into OpenAPIBuilder, as prompted. The completed document is saved as a file, and that file imported into SOAR as a connector. The ‘create incident’ connector function would be ready for configuration within a playbook.
IBM Connector Futures
The SOAR v51.0.5.0 release represents the start of capabilities for connectors. For example, the next release in Spring of 2025, connectors will include OAuth authentication along with the ability to produce ad-hoc connectors directly in the playbook workspace. This last feature will reduce the need for these external tools for OpenAPI spec document creation.
Conclusion
Whether you have a ready-made OpenAPI spec document or one you craft using the different tools available, using SOAR’s connector feature will add value to your playbook development experience through increased development speed and reduced skills needed.