12.2 Case Connectors & External Incident Escalation
Key Takeaways
Case connectors push Elastic Security cases to external ticketing, ITSM and SOAR platforms; they need Platinum or higher and the Actions and Connectors privilege.
Cases can be pushed to ServiceNow ITSM, ServiceNow SecOps, Jira (including Jira Service Desk), IBM Resilient, Swimlane, and any REST system through Webhook - Case Management.
Automation platforms such as Tines or Torq are usually reached through webhooks: Webhook - Case Management for cases, or a Webhook connector used as a rule action.
Pushing is one-way: Elastic sends the case and later updates, but changes made in the external system (including closing the ticket) do not flow back; a case setting can close Elastic cases automatically when they are pushed.
Connector security relies on least-privilege service credentials (API tokens, API keys, or OAuth for ServiceNow), TLS verification, Kibana's xpack.actions proxy and allowed-hosts settings, and the Actions and Connectors privilege.
The Enterprise Requirement for External Ecosystem Integration
While Elastic Security provides a robust, native Case Management platform for security analysts, enterprise IT and security organizations rarely operate in a technological silo. Large enterprises typically maintain centralized IT Service Management (ITSM) platforms to govern organizational change control, configuration management databases (CMDB), and cross-departmental Service Level Agreements (SLAs).
Furthermore, dedicated Security Operations Centers frequently utilize dedicated Security Orchestration, Automation, and Response (SOAR) platforms or hyperautomation engines (such as ServiceNow SIR, IBM Resilient, Tines, or Torq) to execute complex, multi-system playbooks—such as querying external threat intelligence APIs, revoking active directory tokens, blocking IP addresses on perimeter firewalls, and orchestrating forensics triage.
To bridge the gap between high-speed SIEM detection and enterprise-wide orchestration, Elastic Security leverages Kibana Action Connectors. These connectors allow security teams to seamlessly escalate Elastic Security Cases to external platforms, push updates as the investigation progresses, and keep IT and SecOps teams aligned.
Supported External Connectors for Cases
In Elastic Security 8.15 you can push cases to these external incident management systems: ServiceNow ITSM, ServiceNow SecOps, Jira (including Jira Service Desk), IBM Resilient, Swimlane, and Webhook - Case Management, a generic REST connector. Pushing cases needs the appropriate subscription (Platinum or higher) and All privileges for the Actions and Connectors feature.
+--------------------------------------------------------------------------+
| Elastic Security Case Connectors |
+--------------------------------------------------------------------------+
| [ Elastic Security Case ] |
| | push (one way) |
| v |
| +-------------+-----------+------------+----------+-----------------+ |
| | ServiceNow | ServiceNow| Jira / Jira| IBM | Swimlane | |
| | ITSM | SecOps | Service | Resilient| Webhook - Case | |
| | (incident) | (security | Desk | | Management | |
| | | incident) | | | (any REST API) | |
| +-------------+-----------+------------+----------+-----------------+ |
+--------------------------------------------------------------------------+
1. ServiceNow ITSM vs. ServiceNow SecOps
Elastic Security provides two ServiceNow connectors for different teams:
- ServiceNow ITSM Connector: Creates records in the standard ServiceNow incident table, with IT fields such as urgency, severity, impact, category and subcategory. It suits escalations to IT operations, such as re-imaging a compromised laptop or patching a server.
- ServiceNow SecOps Connector: Creates security incidents (
sn_si_incident) in ServiceNow Security Incident Response, with fields such as category, subcategory and priority. It suits handing incidents to a security team that works in ServiceNow SIR.
2. Jira
The Jira connector works with Jira Cloud and Jira Server or Data Center, including Jira Service Desk. You choose the issue type, priority, labels and, where relevant, a parent issue. Authentication uses an account email or username plus an API token or password.
3. IBM Resilient
Pushes Elastic cases into IBM Resilient (now IBM Security QRadar SOAR) as incidents. You set the incident types and severity code, and authenticate with an API key ID and secret.
4. Swimlane and Webhook - Case Management
- Swimlane: Sends cases to a Swimlane application, with Elastic case fields mapped to Swimlane fields.
- Webhook - Case Management: A generic connector for any ticketing system with a REST API. You define the HTTP calls to create an incident, get it, update it and add comments, using mustache variables such as
{{{case.title}}},{{{case.description}}},{{{case.tags}}}and{{{case.comment}}}. It stores the external ID and URL that the create call returns.
Automation platforms such as Tines or Torq usually connect through a webhook: the Webhook - Case Management connector for cases, or a Webhook connector used as a rule action that sends alert details whenever a rule fires.
Pushing Cases: One-Way Synchronization
+--------------------------------------------------------------------------+
| Case Push Workflow |
+--------------------------------------------------------------------------+
| 1. Analyst selects a connector for the case (or a default connector) |
| and pushes -------------------------------> external incident created |
| 2. Elastic stores the external ID and URL and shows a link in the case |
| 3. New comments or field changes in Elastic -> analyst pushes again |
| ("Push as ... update") -------------------> external record updated |
| 4. Changes made in the external system are NOT pulled back into Elastic |
| (closing the ticket there leaves the Elastic case open) |
+--------------------------------------------------------------------------+
1. External Incident Linkage and Field Mapping
The first push creates the external record and returns its identifier, such as a ServiceNow incident number or a Jira issue key. Elastic Security saves it and shows a link in the case, so analysts can jump to the external ticket. Title and description are pushed with the case, and connector-specific fields are chosen in the case's external incident management settings. Examples are ServiceNow urgency, impact and category, Jira issue type, priority and labels, or Resilient incident types and severity code. Case comments are added to the external record when you push, for example as ServiceNow work notes or Jira comments.
2. Updates and Case Closure
Synchronization is one-way. After the first push, the case shows when it has updates that have not been pushed, and the analyst pushes again to send them. Updates made directly in ServiceNow, Jira or the other systems do not flow back into the Elastic case. For the same reason, closing the ticket in the external system leaves the Elastic case open until someone closes it in Elastic. To keep the two aligned, Cases → Settings offers a closure option: Automatically close cases when pushing new incident to external system.
Security Hardening of Connectors
Connectors carry sensitive incident details across network boundaries, so configure them carefully.
1. Authentication and Least Privilege
- Jira: Account email or username plus an API token (Jira Cloud) or password.
- IBM Resilient: API key ID and API key secret.
- ServiceNow ITSM and SecOps: Basic authentication, or OAuth, which uses a client ID and client secret together with a user identifier and a private key that signs a JWT. OAuth avoids storing a user's password in the connector.
- Use a dedicated integration account with only the permissions needed to create and update records.
- In Kibana, restrict who can create or edit connectors with the Actions and Connectors feature privilege. Connector secrets are encrypted in Kibana saved objects and require the
xpack.encryptedSavedObjects.encryptionKeysetting on self-managed deployments.
2. TLS Verification
Connector traffic should use HTTPS with certificate verification. Kibana's xpack.actions.ssl.* settings control verification and trusted certificate authorities for connectors. Setting xpack.actions.ssl.verificationMode: none disables verification and exposes incident data to man-in-the-middle attacks, so avoid it in production.
3. Corporate Proxy Traversal and Egress Control
If Kibana cannot reach SaaS endpoints such as atlassian.net or service-now.com directly, route connector traffic through a forward proxy with xpack.actions.proxyUrl (with optional proxy headers and bypass lists). xpack.actions.allowedHosts restricts which hosts connectors may contact at all.
4. Failure Handling
Pushes can fail because of timeouts, expired credentials, rate limiting (HTTP 429) or outages. Kibana reports the error on the case. Once the external system recovers, the analyst simply pushes again.
Comparison Matrix: Case Connectors
| Connector | External Record | Synchronization | Typical Fields Set | Authentication | Primary Use |
|---|---|---|---|---|---|
| ServiceNow ITSM | incident table | One-way push (create and update) | Urgency, severity, impact, category, subcategory | Basic auth or OAuth (JWT) | IT escalation: re-imaging, patching, infrastructure work |
| ServiceNow SecOps | Security incident (sn_si_incident) | One-way push (create and update) | Category, subcategory, priority | Basic auth or OAuth (JWT) | Security team escalation in ServiceNow SIR |
| Jira | Issue | One-way push (create and update) | Issue type, priority, labels, parent | Email/username + API token or password | Remediation tracking with engineering teams |
| IBM Resilient | Incident | One-way push (create and update) | Incident types, severity code | API key ID + secret | SOAR playbooks in IBM Resilient / QRadar SOAR |
| Swimlane | Swimlane record | One-way push (create and update) | Mapped Swimlane application fields | API token | Swimlane-based SOAR workflows |
| Webhook - Case Management | Any REST ticketing system | One-way push using the configured REST calls | Anything you template with mustache variables | Basic auth, custom headers, or none | Custom or unsupported ticketing systems |
A security engineering team wants to configure a Kibana Action Connector that automatically routes high-severity Elastic Security Cases into their enterprise security orchestration system. The organization uses ServiceNow's dedicated Security Incident Response module, which includes specialized security categories, threat intelligence fields, and attack vector attributes. Which connector should the team configure?
The ServiceNow SecOps (SIR) connector, because it targets the dedicated 'sn_si_incident' table and supports security-specific fields and workflows.
The standard ServiceNow ITSM connector, because it disables all encryption to maximize transmission throughput.
A local Bash script that executes raw cURL commands against the Elasticsearch primary data node.
The Jira Software connector configured with an anonymous guest access profile.
An enterprise SOC pushes Elastic Security cases to Jira Service Desk. During an active incident, an engineer adds forensic notes to the Jira issue and moves it to Done. What happens to the Elastic Security case?
Nothing flows back: pushing is one-way, so the Elastic case keeps its own comments and stays open until someone updates or closes it in Elastic Security.
The Elastic case is deleted automatically to prevent conflicting records across systems.
The Jira updates are written to a temporary file on the Fleet Server host for later import.
The Jira comments are mirrored into the case activity log and the case status is reconciled to Closed.
A security architect is configuring a ServiceNow SecOps connector to push cases from an on-premises Kibana deployment to a ServiceNow cloud instance. Security policy requires all outbound SaaS traffic to pass through an inspected corporate proxy and forbids storing a person's password in the connector. Which configuration meets these requirements?
Disable TLS certificate verification and hardcode the administrative root password into the connector payload.
Use the connector's OAuth option (client ID and secret with a JWT signed by a private key) for a dedicated integration identity, set xpack.actions.proxyUrl so connector traffic goes through the corporate proxy, and keep TLS verification enabled.
Route traffic through an unencrypted Telnet tunnel directly to the external SaaS IP address.
Deploy a custom eBPF kernel module on all endpoint agents to bypass the corporate perimeter firewall.
Sections you finish are checked off in the contents.