Overview

This document provides information on how to package and deliver an in-platform integration for the ThreatConnect Platform.

In-Platform Packaging

This section applies to any in-platform integration and relates to integration packaging. A package for the integration must be produced using ThreatConnect-provided tools based on the integration type:

• Playbooks and/or Components: Exported into a PBX file from the Playbooks editor.

• Playbook Apps (one of the methods below):

  • Published using Release within the ThreatConnect Sandbox environment. The released package can be downloaded from the App Builder interface as a TCX file.

  • Packaged using the ‘tcpackage’ command from your development environment if you’ve elected to develop outside of the platform.

• Runtime Apps: Packaged using the ‘tcpackage’ command from your development environment.

Integration Naming

Integrations should use the following naming standard as a display name:

An explanation of these fields is below:

• <Company> should represent the brief name of your company. For example, if your business name is “Awesome Security Services”, you might choose “Awesome”.

• <Product> should represent the brief name of the specific product or product category where this integration is applicable. For example, if your product is named “ThreatMonitor Endpoint Security”, you might use “ThreatMonitor ES”. If you do not employ a name for your product at this time (such as using the same name as your company), please use “Platform” as the product name.

• [<Description>] is an optional field to clarify your integration if your product or product category doesn’t provide sufficient specification. This field should be kept brief.

Integration Versioning

Integrations should use the versioning scheme below:

• Each release must be versioned regardless of the changes.

• Versioning is expressed as “<Major>.<Minor>.<Release>”.

A summarized version of your display name without spaces (use _ as a substitute if necessary) should be used in package naming (internal name, file name). The major version of your integration should be included in your package name at the end (such as v2). For example, if your display name is “Awesome ThreatMonitor ES”, you might use “awesome_threatmonitor_es_v2” as your technical package name.

The version of your integration is stored within the install.json file as the programVersion field. When using the in-platform App Builder, the install.json is managed for you behind the scenes based on the values you specify within the UI. When packaging using ‘tcpackage’ outside of the platform, your package name will be automatically generated for you based on the value of programVersion.

Version Changes

When changing the version of your integration, this should be done with the following guidelines and consequences in mind:

• Major Versions

  • Changes to the Major version indicates that a breaking change has been made that will break existing implementations.

  • When updating a major version within a package outside of the platform, you must update the following fields:

    • programVersion in install.json

    • app_version in tcex.json (with the major version only)

• Minor Versions

  • Changes to the Minor version indicates that significant changes have been made but nothing that breaks existing implementations.

  • When updating a minor version within a package outside of the platform, you must update the following fields:

    • programVersion in install.json

• Release Version

  • Changes to the Release version indicates that minor bug fixes or small enhancements have been made.

  • When updating a release version within a package outside of the platform, you must update the following fields:

    • programVersion in install.json

Package Delivery

The following guidelines should be used when delivering an integration for the ThreatConnect Platform:

• For integrations that reside outside of the ThreatConnect Platform:

  • We request that you provide us with general instructions on how your customers should access the integration and associated documentation.

  • This could be made available via a marketplace, private portal, or public-facing website, for example.

• For integrations that reside within the ThreatConnect Platform:

  • We request that you make the required deliverables available first on your GitHub repository.

  • You then create a Pull Request to the appropriate ThreatConnect GitHub repository and this request is reviewed and approved by your ThreatConnect Solutions Engineer.

  • Customers and others will be directed to retrieve this integration from the ThreatConnect GitHub repository.

Solution Delivery

The following guidelines should be used when working with a prospect or customer interested in making use of your integration with the ThreatConnect Platform:

• For integrations that reside outside of the ThreatConnect Platform:

  • Either ThreatConnect or the Developer Partner may be engaged to provide assistance with the integration.

  • We ask that you contact us to coordinate support within ThreatConnect if necessary.

• For integrations that reside within the ThreatConnect Platform:

  • We ask that you direct your customers to the appropriate Customer Success contacts at ThreatConnect. The ThreatConnect team will take the lead on guiding the customer.

  • We welcome your participation in this process.