.png)
Securonix Integration Guide
Securonix integrates with enterprise systems through tenant-specific REST APIs and selected notification or HTTP callback mechanisms for security data and response workflows.
Securonix integration options at a glance
Securonix provides REST APIs for selected platform operations, including querying incidents, alerts, cases, entities, and indicators, retrieving investigation details, and performing supported updates or response actions. Selected events or workflows may also support notification or HTTP callback mechanisms, although coverage and payload behavior depend on the tenant and product version. Bulk, asynchronous, batch, file, and export capabilities must be confirmed for the specific module. Martini can consume documented Securonix APIs, receive confirmed callbacks, authenticate with tenant-approved credentials, and orchestrate pagination, time windows, mapping, deduplication, retries, and downstream updates in reusable workflows.
| Integration point | Supported by Securonix? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Limited | Securonix exposes REST APIs for selected platform functions, including querying Incidents, Alerts, Cases, Entities, and Indicators, retrieving investigation details, and performing supported updates or actions. | Martini can consume documented Securonix REST endpoints from workflows, map JSON responses, paginate searches, and route results to enterprise applications. |
| Webhooks and outbound callbacks | Limited | Selected security events or workflows may produce notifications or HTTP callbacks. Coverage, payload completeness, authentication, and retry behavior vary by tenant. | Martini can expose an API or receive a webhook-triggered workflow, validate the notification, deduplicate it, and retrieve the authoritative Securonix object when the payload contains only an identifier. |
| Bulk, asynchronous, and batch APIs | Limited | High-volume telemetry processing is central to Securonix, but a single general-purpose bulk API for all management and investigation objects was not confirmed. | Martini can implement bounded time windows, pagination, checkpoints, controlled concurrency, and scheduled batch workflows where the tenant exposes suitable search or export operations. |
| Authentication | Limited | Authentication is deployment- and product-version-dependent and may use bearer tokens, OAuth-style flows, API credentials, API keys, or service-account credentials. | Martini can store tenant URLs, tokens, client secrets, and other credentials in secure environment configuration and apply the authentication method documented for the selected API. |
| File and attachment APIs | Not confirmed | File ingestion, export, incident evidence, reports, or threat-intelligence files may be available for selected modules, but a universal file or attachment API was not verified. | Martini can process files when Securonix exposes a documented file or export endpoint, but the workflow should be designed against the customer-specific interface rather than assuming one. |
| GraphQL APIs | Not confirmed | No official Securonix GraphQL API was confirmed for new integrations. | Martini supports GraphQL generally, but Securonix integrations should use documented REST or other confirmed interfaces instead. |
| SOAP APIs | Not confirmed | No current official Securonix SOAP integration was confirmed. | Martini supports SOAP generally, but no SOAP-based Securonix design should be assumed without tenant documentation. |
| Database and analytics access | No | Direct access to internal Securonix databases was not confirmed and is not the recommended integration approach. | Martini should use supported Securonix APIs, callbacks, ingestion interfaces, or documented exports rather than connecting directly to an internal database. |
How Securonix exposes data and business events
Securonix REST APIs
Securonix REST APIs are the primary standards-based mechanism for selected platform operations. Depending on the product version and tenant configuration, they can support queries for Incidents, Alerts, Cases, Entities, and Indicators, investigation retrieval, selected updates, event submission, or response actions.
Martini implementation pattern
Martini implementation pattern: Martini authenticates against the tenant-specific endpoint, invokes the documented resource, validates the response, maps Securonix JSON into a canonical model, and routes it to a target system or subsequent workflow step. The workflow records source identifiers and checkpoints and applies controlled retries for transient failures.
Implementation sequence
Securonix notifications and callbacks
Securonix may provide notifications or outbound callbacks for selected security events and workflows. Broad webhook coverage, payload completeness, delivery retries, signatures, and replay protection must be verified for the customer tenant.
Martini implementation pattern
Martini implementation pattern: a Martini API or webhook-triggered workflow receives the callback, authenticates and validates it where supported, persists the event identifier, and retrieves the authoritative Securonix object through REST when the notification is only a summary. Polling can provide a fallback when the required event is not available as a callback.
Implementation sequence
Securonix batch and scheduled synchronization
Securonix processes high volumes of security telemetry, while general-purpose bulk access for every management object was not confirmed. Scheduled searches, exports, or asynchronous operations must be verified for the relevant module.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow retrieves a bounded time range, follows pagination, normalizes the results, and writes them to a reporting or analytics destination. Martini stores a durable watermark based on timestamp and object identifier and uses rate control to avoid repeatedly querying historical data.
Implementation sequence
Common Securonix integration patterns
Pattern 1: Sync incidents to ServiceNow
When to use this pattern
Use this pattern when security operations need Securonix Incidents represented in ServiceNow for assignment, response coordination, and auditability. A callback can reduce latency when the tenant supports the required event; otherwise Martini can poll for new or changed Incidents.
Integration direction
Example Mapping
| Securonix Field | Canonical Field | Target Field |
|---|---|---|
| incident ID | sourceIncidentId | correlation_id |
| severity | severity | priority |
| status | incidentStatus | state |
| Entities | relatedEntities | affected_ci_or_user |
Martini implementation pattern
Martini receives a notification or retrieves changed Incidents, calls Securonix for complete details, maps severity and status through explicit business rules, and creates or updates the ServiceNow record. It stores both identifiers, handles transient failures with backoff, and routes validation or permission errors for review.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- retry and idempotency
Pattern 2: Route detections to Jira remediation
When to use this pattern
Use this pattern when qualifying Securonix Alerts or detections need engineering or application-owner remediation in Jira. Severity thresholds, ownership rules, and links back to the Securonix investigation should be defined before enabling automated issue creation.
Integration direction
Example Mapping
| Securonix Field | Canonical Field | Target Field |
|---|---|---|
| detection title | findingTitle | summary |
| description | findingDescription | description |
| severity | severity | priority |
| Indicator values | observables | issue description or labels |
Martini implementation pattern
A Martini workflow queries or receives qualifying detections, enriches them with related Entities and Indicators, applies severity and assignment rules, and creates Jira issues with a Securonix investigation reference. A source detection identifier prevents duplicates, while retry and dead-letter handling separates transient API errors from mapping failures.
Martini capabilities used
- scheduled or event-driven workflows
- API consumption
- data mapping
- conditional routing
- business rules
- error handling
Pattern 3: Enrich Securonix investigations
When to use this pattern
Use this pattern when analysts need additional endpoint, identity, or threat-intelligence context for Securonix Indicators, Alerts, or Cases. Write-back must be limited to resources and permissions explicitly exposed by the Securonix tenant.
Integration direction
Example Mapping
| Securonix Field | Canonical Field | Target Field |
|---|---|---|
| Indicator value | observable | indicator or query value |
| Entity type | entityType | resource type |
| enrichment result | enrichmentSummary | case note or analyst context |
| confidence | enrichmentConfidence | confidence |
Martini implementation pattern
Martini retrieves Indicators and related Entities, calls an approved enrichment API, validates and normalizes the response, and writes supported results to a Securonix Case or forwards them to an analyst workflow. The process applies timeout and retry policies, records correlation IDs, and avoids logging sensitive payloads.
Martini capabilities used
- API orchestration
- data transformation
- validation
- business rules
- secure configuration
- audit logging
Pattern 4: Export incidents for scheduled reporting
When to use this pattern
Use this pattern when reporting or analytics teams need a controlled feed of Securonix Incidents, detections, or related objects. It is appropriate when a callback is unavailable or when a periodic reporting extract is preferred.
Integration direction
Example Mapping
| Securonix Field | Canonical Field | Target Field |
|---|---|---|
| incident ID | sourceObjectId | incident_id |
| created or updated timestamp | sourceUpdatedAt | updated_at |
| severity | severity | severity |
| status | status | status |
Martini implementation pattern
A scheduled Martini workflow loads a durable watermark, queries a bounded interval, follows pagination, normalizes objects, and writes them to the approved destination. It accounts for late updates by using an overlap window, deduplicates on source ID and revision information, and advances the watermark only after successful writes.
Martini capabilities used
- scheduling
- workflow orchestration
- pagination handling
- data mapping
- checkpointing
- error handling
Applications commonly integrated with Securonix
Securonix commonly participates in security-operations architectures alongside the following named products. Exact API support, permissions, and event coverage should be confirmed in each customer environment; Martini can orchestrate the relevant APIs, callbacks, and transformations where those interfaces are available.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create and update security incidents, tasks, and response workflows from Securonix detections. | Securonix → Martini → ServiceNow | Receive a confirmed notification or poll for new Incidents, retrieve authoritative details, map severity and Entities, then create or update a ServiceNow security incident while storing both source and target identifiers for idempotency. |
| Jira | Assign remediation work to engineering and application teams based on qualifying security findings. | Securonix → Martini → Jira | Filter Alerts or detections by severity and ownership, enrich them with related Entities and Indicators, and create Jira issues with correlation links, assignment rules, retry handling, and duplicate checks. |
| Splunk | Exchange security telemetry, search results, or investigation data where both platforms are present. | Securonix → Martini → Splunk | Use documented APIs or export and ingestion interfaces to move selected Events or investigation data, normalize schemas in Martini, apply time-window and checkpoint logic, and record processing outcomes. |
| Microsoft Sentinel | Coordinate detections, incidents, and investigation context across security analytics platforms. | Securonix → Martini → Microsoft Sentinel | Retrieve qualifying Securonix Incidents or Alerts, map severity, status, and entity context to Sentinel objects, and optionally route supported updates back through approved APIs with audit identifiers. |
| CrowdStrike Falcon | Enrich investigations with endpoint, detection, host, or permitted response information. | Securonix → Martini → CrowdStrike Falcon | Read Securonix Indicators or Entities, call approved CrowdStrike APIs for enrichment, validate returned evidence, and write supported results to a Securonix Case or downstream analyst workflow. |
| Microsoft Defender | Enrich Securonix incidents with identity, endpoint, email, or cloud-security findings. | Securonix → Martini → Microsoft Defender | Orchestrate calls to both platforms, correlate stable identifiers, transform security metadata, and restrict any write-back or response action to explicitly permitted API operations. |
| Okta | Correlate identity events, users, authentication activity, and access-related findings. | Okta → Martini → Securonix | Consume approved Okta events or API results, map identity and authentication context into Securonix-supported ingestion or event interfaces, and apply validation, batching, and retry controls. |
| Slack | Send selected incident notifications and analyst updates to controlled security channels. | Securonix → Martini → Slack | Select Incidents or Alerts using severity and routing rules, retrieve only necessary details, transform the message for an approved Slack endpoint, and prevent duplicate notifications with source identifiers. |
How to build a Securonix integration in Martini
Objective
Establish the Securonix tenant endpoint and authentication method documented for the customer’s product version and deployment.
Instructions in Martini
- Configure the tenant URL and regional or private-network endpoint as environment values.
- Store bearer tokens, OAuth credentials, API keys, or service-account secrets in Martini secure configuration.
- Grant only the permissions required for the selected Incidents, Cases, Alerts, Entities, Indicators, Events, or response operations.
Objective
Select an event-driven or scheduled initiation method based on the Securonix capabilities confirmed for the tenant.
Instructions in Martini
- Use a Martini API or webhook-triggered workflow for a confirmed HTTP callback.
- Use a scheduler when the required event type is unavailable or callback coverage is incomplete.
- Define polling windows, overlap periods, and checkpoints for scheduled synchronization.
Objective
Receive the notification or call the authoritative Securonix REST resource to obtain complete data.
Instructions in Martini
- Validate incoming callback structure and authentication before processing.
- Retrieve the full Incident, Case, Alert, Entity, Indicator, or Event when a notification contains only an identifier.
- Implement pagination, bounded time ranges, rate control, and transient retry handling.
Objective
Coordinate enrichment, validation, routing, and target-system operations in a maintainable Martini workflow.
Instructions in Martini
- Assign correlation IDs and preserve source object identifiers.
- Separate transient API failures from validation, permission, and business-rule failures.
- Use conditional routing for severity, status, object type, ownership, and target destination.
Objective
Convert Securonix-specific JSON and security metadata into a canonical model and target-specific payload.
Instructions in Martini
- Map severity, confidence, risk, status, timestamps, Entities, and Indicators explicitly.
- Preserve investigation links and essential source metadata for auditability.
- Use tolerant handling for nonessential fields while validating required identifiers and values.
Objective
Create, update, enrich, or export data only through confirmed Securonix and target-system operations.
Instructions in Martini
- Check the source identifier and existing correlation record before creating a downstream object.
- Restrict Securonix write-back and response actions to documented resources and approved permissions.
- Commit checkpoints only after the target write or export completes successfully.
Common Securonix data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Incidents | Security incidents generated or managed by Securonix and synchronized to response or service-management processes. | ServiceNow, Microsoft Sentinel, reporting platforms | Martini retrieves complete details after polling or notification, maps severity and status, applies idempotency, and creates or updates downstream objects where supported. |
| Cases | Investigation or response containers grouping related findings, activities, and analyst context. | ServiceNow, Jira, analyst workflows, reporting platforms | Martini correlates Cases with Incidents, Alerts, Entities, and Indicators, preserves source identifiers, and writes only to documented Securonix resources or approved downstream APIs. |
| Alerts or detections | Analytics results identifying suspicious activity and initiating triage or remediation. | Jira, ServiceNow, Microsoft Sentinel, Slack | Martini filters by severity or business rules, enriches related data, transforms fields, and routes qualifying detections with duplicate protection. |
| Entities | Users, hosts, IP addresses, applications, and other objects associated with security activity. | CrowdStrike Falcon, Microsoft Defender, Okta, ServiceNow | Martini normalizes entity types and identifiers, calls approved enrichment services, and preserves relationships needed for investigation context. |
| Indicators | Threat observables such as IP addresses, domains, hashes, and other intelligence values. | CrowdStrike Falcon, Microsoft Defender, threat-intelligence services, Cases | Martini validates indicator types, queries approved enrichment APIs, applies confidence and relevance rules, and writes supported enrichment results or forwards them to analysts. |
| Events | Normalized or raw security telemetry processed by Securonix. | Splunk, Microsoft Sentinel, reporting platforms, Securonix ingestion interfaces | Martini can transform and submit Events where the tenant exposes a supported interface, using batching, time windows, checkpoints, and sensitive-data controls. |
Authentication and security considerations
Tenant-specific authentication
Securonix authentication varies by deployment, product version, and API. Confirm whether the selected endpoint requires a bearer token, OAuth 2.0 flow, API key, or service-account credentials, including token endpoints, scopes, and permissions.
Secrets and access control
Store tenant URLs, tokens, client secrets, and API credentials in Martini secure environment configuration. Use separate credentials for development, testing, and production, and grant only the permissions required by the workflow.
Sensitive security data
Incidents and Events may contain usernames, IP addresses, hostnames, command lines, URLs, and other sensitive content. Restrict workflow and log access, minimize copied data, use TLS, and avoid writing credentials or sensitive payloads to debug logs.
Operational considerations for Securonix integrations
Rate limits and pagination
Confirm tenant-specific throttling and implement pagination, bounded time windows, controlled concurrency, and backoff for HTTP 429 and transient 5xx responses.
Idempotency and delivery
Use stable Incident, Case, Alert, Event, or other object identifiers as idempotency keys. For callbacks, authenticate and validate the payload, persist the identifier, handle duplicate delivery, and retrieve the full object when necessary.
Schema and status changes
Security platforms can add detection metadata and fields. Validate required values, tolerate nonessential fields, preserve important unmapped data, and define explicit mappings for severity, confidence, risk, status, closure, suppression, and reopening.
Testing and auditability
Test against the customer’s Securonix API version and enabled modules. Retain correlation IDs, source and target identifiers, timestamps, and processing outcomes without exposing sensitive payloads in operational logs.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini centralizes Securonix API calls, callback handling, enrichment, target writes, business rules, and error paths in maintainable workflows rather than scattering logic across scripts.
Controlled transformation
Mappings can normalize Securonix Incidents, Cases, Alerts, Entities, Indicators, and Events for different target systems while preserving source identifiers and investigation context.
Operational resilience
Martini supports scheduled and event-driven execution, pagination, checkpoints, retries, validation, deduplication, secure configuration, and monitoring patterns needed for security-operations integrations.
API-led reuse
Martini can expose a controlled API façade for normalized Securonix data, allowing multiple applications to consume consistent integration behavior without creating separate point-to-point implementations.
Frequently asked questions
Securonix can be integrated primarily through tenant-specific REST APIs for querying Incidents, Alerts, Cases, Entities, Indicators, and selected Events or actions. Selected security events or workflows may also support notifications or HTTP callbacks. The exact resources, authentication, and notification coverage depend on the Securonix product version and tenant configuration.
Yes. Martini can consume documented Securonix REST APIs, receive confirmed HTTP callbacks, store tenant-specific credentials securely, transform Securonix JSON, and orchestrate downstream systems such as ServiceNow or Jira. The integration should be designed against the customer’s enabled Securonix API specification.
No. A dedicated Securonix connector is not required. Martini can integrate using Securonix’s confirmed native mechanisms, including documented REST APIs, supported notification or callback interfaces, tenant-approved authentication methods, and any documented export or ingestion endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Securonix. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Securonix, infrastructure providers, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs should be treated as the primary standards-based method for new integrations, subject to tenant and product-version availability. Notifications or HTTP callbacks can be used for selected events when confirmed. Bulk, asynchronous, batch, file, and export capabilities must be verified for the specific Securonix module.
Securonix may support notifications or outbound callbacks for selected security events and workflows, but broad webhook coverage should not be assumed. Confirm whether the tenant provides an HTTP callback, the event types covered, payload completeness, authentication, retries, and replay protection. Martini can receive a callback and retrieve the authoritative object through REST.
Synchronization can be event-driven when a suitable callback is available, or scheduled through REST polling. Martini can use pagination, bounded time windows, durable watermarks, overlap windows for late updates, stable source identifiers, and explicit severity or status mappings to synchronize Incidents, Cases, Alerts, Entities, Indicators, or Events.
Martini workflows can distinguish validation and permission failures from transient HTTP errors, apply controlled retries and backoff, and route unresolved failures for review. Stable Securonix object identifiers, target identifiers, and update timestamps can support idempotency and prevent duplicate incidents, issues, or notifications.
Related Martini documentation
Integrate Securonix with Martini
Use Martini to connect Securonix REST APIs and confirmed notification mechanisms with enterprise applications through secure, observable, and maintainable workflows.