Jira & ServiceNow Integration

RhythmX integrates with Jira and ServiceNow to push incidents as tickets into your existing IT service management workflow. Tickets can be created manually by analysts or automatically when incidents exceed severity thresholds — ensuring critical threats are tracked in your organization's ticketing system without manual copy-paste.

How It Works

flowchart TD
    A["Incident Created<br><i>Auto or Manual</i>"] --> B{"Severity<br>Check"}

    B -->|"Above Threshold"| C["Auto-Push<br><i>If enabled</i>"]
    B -->|"Any Severity"| D["Manual Push<br><i>Analyst clicks Create Ticket</i>"]

    C --> E{"Target<br>System"}
    D --> E

    E -->|"Jira"| F["Jira Cloud / Server<br><i>REST API v3</i>"]
    E -->|"ServiceNow"| G["ServiceNow<br><i>Table API</i>"]

    F --> H["Ticket Created<br><i>ID + URL stored on incident</i>"]
    G --> H

    H --> I{"Success?"}
    I -->|"Yes"| J["Incident Updated<br><i>Ticket reference linked</i>"]
    I -->|"No"| K["Retry Queue<br><i>Exponential backoff</i>"]
    K -->|"Up to 5 retries"| E

    style A fill:#4a148c,stroke:#9c27b0,color:#fff
    style B fill:#1a237e,stroke:#534bae,color:#fff
    style C fill:#e65100,stroke:#ff9d3f,color:#fff
    style D fill:#0d47a1,stroke:#42a5f5,color:#fff
    style E fill:#00695c,stroke:#4db6ac,color:#fff
    style F fill:#1a237e,stroke:#534bae,color:#fff
    style G fill:#1a237e,stroke:#534bae,color:#fff
    style H fill:#1b5e20,stroke:#4c8c4a,color:#fff
    style I fill:#00695c,stroke:#4db6ac,color:#fff
    style J fill:#1b5e20,stroke:#4c8c4a,color:#fff
    style K fill:#b71c1c,stroke:#f05545,color:#fff

Configuration

Jira

Setting	Description
URL	Your Jira instance URL (e.g., `https://yourcompany.atlassian.net`)
Email	Jira account email for API authentication
API Token	Jira API token (generated from Atlassian account settings)
Project Key	The Jira project where tickets will be created (e.g., `SEC`)
Issue Type	Ticket type to create (default: `Task`)
Enabled	Toggle the Jira integration on or off

ServiceNow

Setting	Description
Instance	Your ServiceNow instance name (e.g., `yourcompany.service-now.com`)
Username	ServiceNow account username
Password	ServiceNow account password
Assignment Group	Default group for ticket assignment
Enabled	Toggle the ServiceNow integration on or off

Test Connection

After configuring credentials, use the Test Connection button to verify connectivity before enabling the integration. The test creates a minimal API call to confirm authentication and access.

Checking Integration Status

The Integration Status view shows which systems are configured and enabled at a glance:

Field	Description
Configured	Whether credentials have been provided
Enabled	Whether the integration is active
Last Test	Timestamp of the most recent connection test

Manual Ticket Creation

From any incident detail view, analysts can:

Preview Ticket — See exactly what the ticket summary, description, and priority will look like before pushing
Create Ticket — Select Jira or ServiceNow and push the incident

On success, the incident record is updated with the external ticket ID and URL for cross-referencing.

Ticket Content

Every ticket includes comprehensive context from the incident:

Section	Content
Actor Information	Actor name, type (user/host/IP), entity
Risk Assessment	Risk score (0–100), risk level, severity, 7-factor breakdown
Activity Summary	Total alarms, threat cases, unique rules triggered, primary detection rule
Timeline	First alert and last alert timestamps, active duration
SLA Status	SLA target, current status, percentage consumed
MITRE ATT&CK Coverage	Detected tactics and techniques
Alert Rules	Top 10 firing rules with overflow count
Investigation Notes	Analyst notes (if present)

Priority Mapping

Ticket priority is automatically set based on risk level:

Risk Level	Jira Priority	ServiceNow Priority
Critical	Highest	1 — Critical
High	High	2 — High
Medium	Medium	3 — Medium
Low	Low	4 — Low

Auto-Push

When enabled, RhythmX automatically pushes qualifying incidents to Jira and/or ServiceNow immediately after creation — no analyst intervention required.

How Auto-Push Works

A new incident is created (via automatic qualification or manual promotion)
The incident's severity is compared against the configured minimum severity threshold
If the incident qualifies, a ticket is created in each configured target system
The ticket reference is stored on the incident

Severity Determination

Risk Score	Severity
≥ 85	CRITICAL
≥ 70	HIGH
≥ 40	MEDIUM
< 40	LOW

Auto-Push Configuration

Setting	Default	Description
Minimum Severity	CRITICAL	Only push incidents at or above this severity
Target Systems	Jira	Which systems to push to (`jira`, `servicenow`, or both)

Delivery Retry

When a ticket creation fails (network timeout, API error, authentication issue), the system handles it gracefully:

The failure is logged with the error details
The failed delivery is enqueued for automatic retry
Retries use exponential backoff — each successive attempt waits longer before retrying
A maximum of 5 retry attempts is allowed

Retry Configuration

Setting	Default	Description
Max Attempts	5	Maximum number of delivery attempts
Base Delay	60 seconds	Initial wait time before first retry
Max Delay	3,600 seconds (1 hour)	Maximum wait time between retries

The retry processor runs on a 2-minute schedule, checking for pending retries and attempting redelivery.

Integration Workflow Summary

Step	Who	What Happens
1. Configure	Admin	Set up Jira and/or ServiceNow credentials in System Settings
2. Test	Admin	Verify connectivity with the Test Connection button
3. Enable	Admin	Toggle the integration on and configure auto-push thresholds
4. Auto-Push	System	Qualifying incidents are automatically pushed as tickets
5. Manual Push	Analyst	Optionally push any incident to Jira/ServiceNow from the detail view
6. Track	Analyst	Ticket references (ID + URL) are stored on the incident for cross-referencing
7. Retry	System	Failed deliveries are automatically retried with exponential backoff

Proactive Case API (MSSP deployments)

Some MSSP customers use a dedicated Proactive Case API instead of the standard ServiceNow Table API. This integration uses HTTP Basic authentication with an app-id / shared-secret pair and a custom case payload shape. It is enabled by setting TICKET_INTEGRATION=proactive in .env.production.

Once configured, RhythmX automatically produces an enriched ticket body on every push — significantly richer than the standard integration — and supports bi-directional state synchronisation (SNOW-side changes are polled back into the RhythmX incident record).

Configuration

All values are set in .env.production. No secrets are stored in code.

Setting	Description
`TICKET_INTEGRATION`	Set to `proactive` to enable this integration. Default `standard` (uses Jira / ServiceNow Table API).
`PROACTIVE_SNOW_BASE_URL`	Base URL of the Proactive Case API endpoint
`PROACTIVE_SNOW_APP_ID`	Application ID issued by the API provider
`PROACTIVE_SNOW_SECRET`	Shared secret paired with the app ID
`PROACTIVE_SNOW_TABLE`	Target ticket table name. Default `Case`.
`PROACTIVE_SNOW_SOURCE`	Source value sent in the request header. Default `Managed_services`.
`PROACTIVE_SNOW_SERVICE_IDENTIFIER`	Required. The registered CMDB Configuration Item (CI) the customer has provisioned for RhythmX-originated tickets. Ask your ServiceNow administrator for the correct value — tickets are rejected with HTTP 400 "serviceIdentifier is not available" if this does not match a registered CI.
`PROACTIVE_SNOW_VERIFY_SSL`	`true` in production. May be set to `false` only for test / UAT environments.
`SNOW_UPDATE_CADENCE_HOURS`	Minimum time between risk-update pushes to SNOW. Default `24`. P1 escalations bypass this gate (see below).
`RHYTHMX_BASE_URL`	RhythmX base URL included in tickets as a deep-link back to the incident view.

Enriched Ticket Body

Every Proactive Case ticket RhythmX creates contains these structured sections:

Section	Content
Threat Summary	One-paragraph narrative — attack type, affected actor, MITRE coverage
Threat Analysis	Extended description tying detections to the observed attack pattern
Incident Overview	Entity, actor, risk score (with previous value + trend arrow), confidence, primary driver, attack pattern, system state, campaign ID
Blast Radius	Affected hosts, affected users, total SIEM alarms, RhythmX detections, open threat cases
Detected Threats	Every triggering Sigma rule as a table row: rule name, severity, count, first-seen and last-seen timestamps
Sample Events per Rule	One representative event per triggered rule — time, host, user, event ID, detail
Cause of Risk Increment	On subsequent pushes, highlights the newest rule whose detections caused the risk to rise, with a sample event
Contributed SIEM Triggers	Cross-reference table of contributing SIEM alarm IDs with date, RBP, entity — for analysts to pivot back to the SIEM
MITRE ATT&CK	Observed tactics and technique count with an attack-chain arrow
Recommended Actions	Four sections — Containment, Eradication, Prevention, Best Practices — populated with concrete MITRE-grounded actions based on the observed tactics, hosts, and users
Timeline	First alert, last alert, escalation time, incident ID
Deep Dive link	Direct URL back to the RhythmX incident page

Update Cadence

RhythmX throttles risk-score updates to SNOW so analysts are not flooded with ticket notes for every small risk movement.

Event	Update Behaviour
Risk level changes within `SNOW_UPDATE_CADENCE_HOURS` of last push	Skipped — logged as `SNOW cadence gate: SKIP ... within-cadence`
Risk escalates to P1 / Critical from any lower level	Immediate push — bypasses the cadence gate; logged as `reason=p1-escalation`
Risk level changes and the cadence window has elapsed	Push — logged as `reason=cadence-elapsed-<N>h`
First push after ticket creation	Push — logged as `reason=first-push`

This means operators see: - One push at creation - An immediate push whenever an incident escalates to P1 - At most one additional push per 24 hours otherwise

Bi-Directional Sync

ServiceNow cannot reach RhythmX. To keep the RhythmX incident record in step with analyst actions taken in SNOW, RhythmX polls SNOW once per incident-sync cycle (every 5 minutes). Only RhythmX-created tickets that are still open are polled.

SNOW ticketStatus	RhythmX analyst_status
`Work in Progress` / `Work In Progress`	`IN_PROGRESS`
`Resolved`	`CLOSED`
`Closed`	`CLOSED`
`Cancelled` / `Canceled`	`FALSE_POSITIVE`
`New` / `Pending` / `Suspended`	(no status change — `snow_ticket_state` column updated only)

Writes to the incident record are gated on actual state change — unchanged tickets only have their snow_last_polled_at timestamp refreshed so operators can confirm the poller is alive. Every real state change is recorded in the incident_history audit table with action EXTERNAL_SYNC and source proactive-snow-sync.

Recommendations — Operator Guidance

The Recommended Actions section is produced dynamically from the observed tactics and affected entities. Generic filler phrases are explicitly avoided — every recommendation is a specific, operator-executable step. Examples of the patterns produced:

Containment: isolate host via EDR policy, disable / reset accounts, revoke active sessions and Kerberos TGTs, block C2 IOCs, apply egress rules against observed lateral-movement paths
Eradication: terminate process trees matching the primary detection, remove persistence artefacts (scheduled tasks, registry Run keys, WMI subscriptions, services), invalidate cached credentials, re-image as a last resort
Prevention: account-lockout thresholds, MFA enforcement, AppLocker / WDAC policies, LSA Protection, LAPS for local admin, DLP deployment
Best Practices: document the incident and indicators, verify identity-governance coverage for affected accounts, confirm EDR agent health across the entity, map observed MITRE techniques to the customer's detection coverage matrix, run a tabletop exercise for the attack pattern

Schema Support

The following columns are added to the incidents table to support cadence throttling and bi-directional polling. All are additive — the schema-upgrade path is idempotent and runs automatically via incidents/initializer.py.

Column	Type	Purpose
`last_snow_update_at`	`DATETIME`	Timestamp of the most recent push to SNOW. The cadence gate compares this against `SNOW_UPDATE_CADENCE_HOURS`.
`snow_last_priority`	`VARCHAR(10)`	Last priority value pushed to SNOW. Used to detect P1 escalations.
`snow_ticket_state`	`VARCHAR(50)`	Latest SNOW-side state as reported by the last poll cycle.
`snow_last_polled_at`	`DATETIME`	Timestamp of the most recent poll — stamped on every cycle regardless of whether state changed.