Tanium Integration Methods
When building an integrated solution with Tanium, one of the first decisions you need to make is how information will flow between Tanium and your system. Choosing the right method from among the available options requires evaluating your use case requirements, architecture, and the Tanium solutions involved.
Integration Methods Summary Table
This summary chart provides a quick summary to help you identify which method is the best for your needs. If you have any questions about the different integration methods or capabilities or need advice selecting the best option for your project, head over to the Forum where the community and Tanium Partner team are ready to help.
| Requirement | Connect Module | GraphQL API | Reporting 1 | Direct Connect 2 | Platform REST API | Asset API | Threat Response API | Other Module APIs | Custom Content |
|---|---|---|---|---|---|---|---|---|---|
| Push data to cloud service | |||||||||
| Pull live endpoint data into remote system | |||||||||
| Pull endpoint data into remote system | |||||||||
| Perform solution-specific functions, such as Comply scan | |||||||||
| Perform action on endpoints | |||||||||
| Push endpoint data into Tanium | |||||||||
| Gather evidence | |||||||||
| Manage Intel | 3 | ||||||||
| Get software utilization info | |||||||||
| Get SBOM data | |||||||||
| Read/Apply Discover Labels | |||||||||
| Get Discover Data | |||||||||
| Run a script on an endpoint |
Preferred Option For Specific Use Cases
Method 1: Connect Module
The Tanium Connect module can be configured to deliver data to downstream systems, based on a schedule or triggered by events. It is a flexible solution that can use a variety of delivery mechanisms and data formats. The Connect module is generally the easiest and most straightforward method of integration. The Connect Module Guide will help you get started.
Best For
The Connect module is the best integration method for use cases to regularly deliver specific data from Tanium to a file, syslog, webhook, or other common destination type. You can also trigger delivery on detected events, such as Thread Response alerts.
Not Suited For
The Connect Module is for scheduled outgoing data feeding an external system. It is not the best solution for externally triggered or ad-hoc data requests. When integrating with TaaS (Tanium as a Service), Connect destinations are limited to Cloud services and cannot be configured to deliver to on-prem destinations.
Method 2: GraphQL API Gateway
The Tanium API Gateway is a GraphQL interface for querying data and taking action in Tanium. It is the newest integration method, and going forward, it is the preferred option for integrating with Tanium over the various REST APIs.
The API Gateway Guide provides helpful details. If there are gaps or capabilities you would like to leverage that are not yet available through the Gateway, please let us know about them in the Suggestions Forum. Developer feedback is critical in planning out our API roadmap.
Best For
The API Gateway is best for querying data about online and offline systems, deploying actions, managing groups, and most other common integration scenarios. It is also the solution of choice for scheduling software deployments, establishing direct endpoint connections, and inserting or updating records in Asset. New capabilities are added and announced regularly.
Not Suited For
The API Gateway is new and does not yet cover all the capabilities seen in the Platform or Module REST APIs. It might not be able to fully support integration with specific solutions.
Method 3: Reporting
The Tanium Reporting module allows you to visually explore data and define custom reports. These reports can drive data visualization charts in the console and also be exported for external use.
Best For
Reporting is ideal for cases where you need a consistent set of data from a consistent set of endpoints. It offers a visual method of defining and previewing your data in the console. Reports have flexible delivery options via Connect module or API Gateway.
Not Suited For
Tanium Reporting sources its data from Tanium Data Service (TDS), so it is not suitable for getting data from sensors that are not configured for collection. Because report definitions cannot be modified via the API, it is not suitable for cases where the data requested or endpoints targeted are dynamic. Filtering capabilities are also simplified. If you need to read sensors directly from live endpoints or have complex filtering requirements, the 'endpoints' query in API Gateway is a better option.
Method 4: Direct Connect (DEC)
Direct Connect is used to establish a live connection to an endpoint to perform certain troubleshooting, evidence gathering, and remediation actions. You can visualize resource consumption, download files, kill processes, and other useful functionality.
Best For
DEC is used to retrieve Performance-related data from endpoints and perform various Threat Response capabilities. The DEC Performance module capabilities are accessed through API Gateway and the DEC Threat Response module capabilities are accessed through the Threat Response REST API.
Performance Module DEC Capabilities
Threat Response Module DEC Capabilities
Not Suited For
DEC is not suited for actions on a very large set of endpoints; it is meant for use on a limited number of endpoints at once. It is not a general-purpose integration method, but rather an underlying utility that enables certain specific Tanium functionality.
Method 5: Platform REST API
The Tanium Core Platform REST API can be used to gather information about managed endpoints, deploy actions to them, evaluate the health of the Tanium deployment, and much more. Many of the core functions that can be performed in the Tanium Interact module or administration screens can be done via the REST API. Its use for integrations is being phased out in favor of the GraphQL API Gateway. Note that some endpoint availability will be limited to either Cloud or On-Prem deployments.
Best For
The Platform REST API is the best choice when you need to access core platform functionality that isn't available in API Gateway, such as managing certificates, updating packages, or downloading audit logs.
Not Suited For
The Platform REST API should only be used when the capability you need has not yet been made available through the API Gateway. It is also not suited for performing unadvised or unsupported activities against the Tanium platform.
Warning: Tanium will NOT approve an integration that uses the REST API to do unscalable or dangerous activities, such as pushing unapproved sensor code to endpoints. Prior unadvised or unsupported Platform REST API activity against the Tanium platform has corrupted or deleted data, negatively impacted functionality and performance, and even crashed environments. It is best to ask questions on the Developer Form about your plan if you are unsure.
Methods 6-8: Module REST APIs
Some solutions in Tanium have their own REST API with unique capabilities. If you need to pull data from the sensors included with these modules, then you can simply query the data with API Gateway or create a connection with a saved question source in Connect. If you need to perform module-specific actions, such as quarantining an endpoint with Threat Response or pulling Asset report data, then you might need to leverage that module's REST API.
Best For
The various module REST APIs are best reserved for those cases that cannot be accomplished through any of the other methods available. The Asset API is a useful source for endpoints that have aged out of TDS. The Threat Response API is useful for many threat hunting or investigation scenarios. It is advised that you run your implementation plan by us before building out your solution if you plan to make use of a module API so that we can help you determine if that is the best option available.
Not Suited For
This method is generally not recommended when another method can meet your needs.
Method 9: Custom Content
Custom Sensors and Packages can be created if you need to retrieve specific information or make a change on an endpoint.
Sensors are scripts that are run on an endpoint to return information about the state of that endpoint. They should be fast executing and read-only in nature, meaning no changes are made to the endpoint.
Packages are used when you need to alter the state of the endpoint in any way, such as running a process or updating the Registry. Custom packages are deployed in Actions.
Best For
This method is recommended only for developers that have taken Tanium's Content Authoring course and understand the implications and risk that running scripts on an organization's endpoints entails. They are useful when you need to install or run another application, get status information from an installed application, or perform various types of information gathering or changes on an organization's endpoints at scale.
Not Suited For
This method is not recommended when there is an existing sensor or package that can accomplish the task or to run scripts that are contrary to the best practices outlined in the Content Authoring course and related guides.
Last Updated: