Purpose
This guide explains how to configure Logsign USO to pull attack and threat detection logs from a TINA appliance through its CTM (Central Threat Management) portal API, for security analytics and forensic purposes.
A note on the vendor name before you continue: "TINA" in this guide refers to TINA Threat Protection Systems (tinasecurity.com), a Turkish-developed appliance whose full name is "Threat Intercepting Network Appliance." It combines deception (attack trap), sandboxing and threat intelligence to detect attacks at the network perimeter. TINA's own marketing pages describe an optional "CTM SIEM" capability that lets an account "share logs to a SIEM," which is what this integration uses. This identification is based on the field names and behavior found in the Logsign poller, matched against TINA's public product pages and a real portal address (ctm.tinasecurity.com) referenced in Logsign's own test fixtures for this integration. No public developer documentation or API reference for the CTM portal was found on TINA's website. Every technical detail in this guide (request format, parameters, error behavior) is derived directly from Logsign's poller source code, not from a TINA-published API document, and has not been verified against a live TINA appliance. Confirm the exact request/response contract with TINA or its distributor (Mevertech) before relying on this guide for a production rollout.
TINA exposes its attack/threat records through a CSV-style export over HTTP on the CTM portal rather than syslog. This poller is the only supported way Logsign currently pulls TINA data; it is a pull-based (polling) integration, not a push or webhook feed.
Prerequisites
Your TINA account needs the CTM SIEM log-sharing capability enabled. Based on TINA's public product pages, this is described as a distinct feature of the CTM portal rather than something every account has by default, so confirm with your TINA account manager or Mevertech (TINA's technology partner) that log sharing to a third-party SIEM is active for your tenant before starting.
You need an API key issued from your CTM portal and the exact API URL for your account. TINA does not publish a self-service developer portal or API key generation walkthrough, so request both directly from TINA support or your Mevertech contact. Ask specifically for the endpoint that returns attack/threat log records in CSV form for SIEM integration, since the portal may expose other endpoints for device management that are not the ones this integration uses.
TINA's public documentation does not name a specific administrative role required to request or view the API key. Treat the key as a sensitive credential regardless: request it from whoever administers your CTM account, and avoid using a shared/general admin login purely to look it up if a scoped option exists in your version of the portal.
Step 1: Obtain Your CTM API URL and API Key
Contact TINA support or your Mevertech representative and request the CTM SIEM API URL and API key for your account. The URL is tenant- or appliance-specific; a URL of the form https://ctm.tinasecurity.com/en/portal/api is known to be used by at least one TINA deployment, but you should not assume this is universal. Confirm your own account's exact address with TINA before configuring Logsign.
Important: unlike some Logsign integrations, the Api Url field for this connector expects the complete URL, including the https:// prefix and full path (for example https://ctm.tinasecurity.com/en/portal/api), not a bare hostname. Do not strip the scheme when entering it.
The API key is sent as a static credential on every request; it does not expire on a schedule or get exchanged for a temporary token. Store it as you would any long-lived secret, and ask TINA/Mevertech how to rotate it if it is ever exposed.
Step 2: Configure the Integration in Logsign USO
In Logsign USO, add a new TINA API data source. You will be asked for:
| Field | Value |
|---|---|
| Api Url | The full CTM API URL from Step 1, including the https:// prefix, for example https://ctm.tinasecurity.com/en/portal/api |
| Token | The API key from Step 1 (entered as a masked/password field) |
| Device Name / Description | A label to identify this source in Logsign |
| Poll Interval | How often Logsign starts a new poll cycle. See Notes below: each cycle takes at least 60 seconds regardless of this setting. |
| Log Start Date | Present in the form, but see Notes below: this poller does not currently use it. The first poll for a new source always starts from the beginning of TINA's event sequence rather than the selected lookback window. |
Once saved, Logsign sends an HTTP POST request to the Api Url with your API key and the last processed record's numeric event ID in the request body, and TINA's CTM portal returns any newer attack/threat records as a semicolon-delimited, quote-aware CSV export (an extended log format similar to W3C logging). Logsign parses each row, normalizes the relevant fields into its event schema, and advances the cursor to the highest event ID it has processed, so the next poll only requests records after that point. There is no OAuth flow and no separate login step; authentication is the single static API key sent on every request.
Troubleshooting
TINA does not publish a list of API error codes for the CTM portal, and the current Logsign poller does not distinguish between different HTTP failure responses: any response other than HTTP 200 (this includes 401, 403, 429, and 5xx responses) is treated exactly the same way internally, as "no data returned," and only a generic "no new events" message is logged in Logsign. This means an authentication or permission problem can look identical, from the Logsign side, to genuinely having no new attacks to report. The table below gives the general REST meaning of the most likely codes and what to check on the TINA side, based on standard HTTP semantics rather than TINA's own published documentation, which does not exist publicly for this endpoint.
| Symptom / likely code | Likely cause | What to check |
|---|---|---|
| 401 Unauthorized | The API key is wrong, was revoked, or was never activated for CTM SIEM log sharing on this account. | Re-confirm the key and Api Url with TINA/Mevertech support. Since the poller reports this the same as "no new events," do not assume a quiet source means everything is fine; verify the key independently if you suspect it may be stale. |
| 403 Forbidden | The key authenticates but the account does not have CTM SIEM log-sharing enabled, or the key is scoped to a different function of the portal. | Ask TINA/Mevertech to confirm that log-sharing/SIEM export is licensed and enabled for your tenant, not just general CTM portal access. |
| 429 Too Many Requests | TINA's CTM portal is rate-limiting the polling account. No published rate limit figure was found; the poller currently waits 60 seconds after each successful cycle (see Notes), which may or may not be sufficient to avoid this depending on TINA's actual limit. | If you suspect rate limiting, increase the Poll Interval in Logsign and confirm with TINA/Mevertech whether a documented limit exists for your account tier. |
| Persistent "no new events" with a source you know has traffic | Any of the above, or a cursor mismatch: the stored last-processed event ID may no longer exist on TINA's side (for example after a portal-side data retention rollover). | Confirm with TINA/Mevertech that the event ID Logsign last recorded is still within their retained log window. If it has aged out, the position may need to be reset on the Logsign side; contact Logsign support before doing this on a production source. |
| 5xx server error | Issue on TINA's CTM portal side. | Usually transient. The poller does not retry within the same cycle; it will simply try again on the next scheduled poll. |
Notes and Limits
- Every poll cycle waits a fixed 60 seconds after retrieving data before it completes, regardless of the Poll Interval configured in Logsign USO. This is a hard-coded wait in the current poller, described in the code as required by TINA's API. If you set Poll Interval below roughly a minute expecting a faster cadence, you will not see any improvement.
- The "Log Start Date" field appears in the standard Logsign API source form, but the current TINA poller does not read or apply it. The very first poll for a new source always requests from the start of TINA's internal event sequence rather than the lookback window you select. What TINA's API returns for a brand-new key with no prior position (potentially a large volume of historical records) has not been verified live; discuss expected initial volume with TINA/Mevertech before onboarding a source with a long attack history.
- The connector only covers a single log type: TINA's attack/threat detection export from the CTM portal. Other CTM capabilities mentioned on TINA's site, such as multi-device dashboards or general device management, are not known to be exposed through this same API and are out of scope for this integration.
- Every record ingested through this connector is classified in Logsign's Event Mapping as Security / Attack / Info, regardless of the specific threat description or action reported by the appliance for that record. Per-record classification based on TINA's own threat description field is not implemented in the current connector.
- Some of TINA's raw field names do not map to Logsign's Source/Destination fields the way their names suggest. In particular, the field TINA calls the attack source IP is normalized into Logsign's Destination IP field, and the appliance's own geo-location is normalized into Destination Country, while the domain-related IP is normalized into Source IP. If you build correlation rules on Source/Destination for this source, confirm the mapping against a real event first rather than assuming the field names describe the Logsign-side direction.
- Authentication is a single static API key with no expiry or refresh cycle known to Logsign. If the key is rotated on the TINA side, the Logsign data source must be updated manually with the new value.