Troubleshooting ServiceNow Threat Intelligence: A Practical Guide

Threat Intelligence problems fall into a few layers: data that never arrives from a feed, correlation rules that do not fire, alerts that are not delivered, severities that come out wrong or inconsistent, correlation that lags, and history that goes missing. The sections below take each symptom with its diagnosis and fix, then explain how to work out which layer is failing before changing anything, how to diagnose a programme that has gone silent, and how to tell a provider fault from a platform fault.

Symptom: Threats not appearing in Threat Intelligence

Threat feeds are configured but threat data is not appearing in Threat Intelligence or dashboards.

Diagnosis: Check if the feed integration is running and enabled. Check integration logs for errors (authentication, connectivity, data format). Verify the feed is providing data (access the feed directly if possible).

Fix: Enable the feed if disabled. Check feed authentication credentials (API keys, certificates) and update if expired. Verify network connectivity to the feed (firewall, proxy). Manually trigger a feed sync to test. Monitor logs for the next sync attempt.

Symptom: Threat correlations not triggering

Threat events match your correlation rules but alerts are not triggered.

Diagnosis: Check if the correlation rule is enabled. Check if the threat data contains the required fields for correlation (the rule might be looking for data that is not present). Check if alerts are configured to fire when the rule matches.

Fix: Enable the correlation rule if disabled. Review the rule logic: what conditions must match? Test with a sample threat event that should match. If the rule does not fire, check that all required fields are populated and the matching logic is correct. Update the rule if the logic is wrong.

Symptom: Alerts not being delivered to users

Correlation rules fire but users do not receive alert notifications.

Diagnosis: Check if alert notifications are configured (route, recipients, timing). Check if notification delivery is working (send a test notification). Check user notification preferences (some users might have notifications disabled).

Fix: Verify alert notification routing is set up (alerts should go to security team, incident response, or management). Resend alerts if missed. Check user notification settings and enable notifications if disabled. Test notification delivery with a test alert.

Symptom: Threat severity incorrect or inconsistent

Threats appear in Threat Intelligence but severity is wrong or varies from expected.

Diagnosis: Check severity mapping from source feeds. Different feeds use different severity scales (1-10, critical/high/medium/low). ServiceNow must map external severity to internal severity correctly.

Fix: Review and update severity mapping rules. If multiple feeds provide conflicting severity, define a rule for which feed takes priority or how to combine scores. Test mapping with sample threats.

Symptom: Correlation performance issues or lag

Threat data is appearing but correlation is slow or lagging (threats correlated hours after arrival).

Diagnosis: Check volume of threat data (incoming threats per hour). Correlation consumes resources. High volume can cause lag. Check correlation engine status and load.

Fix: Optimize correlation rules (simpler rules, fewer rules, narrower scope). Schedule correlation to run during off-peak hours if low-latency is not required. Add processing resources if available. Archive old threat data to reduce database size.

Symptom: External feed connectivity loss

Threat Intelligence cannot connect to external threat feeds.

Diagnosis: Check network connectivity to the feed (ping, port access). Check if the feed service is available (check feed status page). Check authentication credentials (API key, certificate).

Fix: Verify network connectivity and firewall rules allow access to the feed. Restart the feed connection if needed. Update authentication if expired. Contact the feed provider if their service is down. Have a fallback process if the feed is unavailable for extended period.

Symptom: Historical threat data missing or inconsistent

Threat records exist but historical data (when threat was first seen, when it was last seen, tracking over time) is missing or incorrect.

Diagnosis: Check if threat history tracking is enabled. Some feeds might not provide historical context. Check data retention (old threat data might be archived or deleted).

Fix: Enable threat history tracking if available. Import historical threat data if the feed provides it. Accept that some historical data might not be available from sources.

When to escalate

Escalate to your platform or security team if: troubleshooting does not resolve the issue, feeds are consistently unavailable, correlation engine has critical errors, or alert delivery is completely broken. Provide: the symptom, troubleshooting steps taken, logs, and list of affected systems/users.

Working out which layer is failing before changing anything

When threat intelligence stops producing useful output, the instinct is to open the rule that seems responsible and edit it. That instinct wastes time, because the fault often sits in a layer upstream of the rule. Threat intelligence has four layers that can each look like a rule problem: the feed that delivers indicators, the mapping that turns them into platform records, the matching logic that compares them with events, and the notification path that tells a person. A quick diagnosis order separates these layers before anyone touches configuration.

The most useful distinction is between no data arriving and data arriving but never matching. Those two states look identical from the analyst’s seat, because both produce silence. They have different causes and different fixes.

Ordered diagnosis for a silent program

1. Confirm the last successful run for each source separately. A dashboard that averages the sources can hide one that has been dark for days.
2. Pick one indicator you know should appear and trace it from the source to the stored record, noting each transformation it passes through.
3. Check the stored type and value of that indicator. Subtle problems such as letter case, trailing characters or a changed field name often surface only here.
4. Run the matching rule against that indicator with a known event. If it does not match, the rule’s conditions are the problem, not the feed.
5. If the rule matches but no alert appears, check whether the alert is suppressed by a deduplication or grouping rule that was added later.
6. Only after the path is clear, change one thing and re-run the same trace. Altering two settings in one pass leaves you unable to tell which one mattered.

Faults that look like success

A connector can report a successful run while delivering an empty or truncated batch, for example when a provider returns a valid response with no records because the account lost its subscription. The run succeeds and the counts fall, so the change only shows up if someone compares the counts with the previous period. Build a simple floor check on indicator volume per source, and treat a sudden drop as a fault until it is explained.

Another quiet fault is a rule that was disabled during an earlier incident and never re-enabled. Keep a list of rules that were switched off, with the reason and the date, and review it at every governance cycle.

When the fault is in the provider, not the platform

If the trace shows the provider sent nothing or sent malformed records for the same period, the fault is upstream. Raise it with the provider with the sample you traced, the time window and the expected format. Keep the platform configuration unchanged in the meantime, so that the provider’s recovery does not hide a change you made in the meantime.

Why does a rule match in testing but not in production?

Usually because the production events carry a field value in a different form, such as an address written with a different separator or a domain with a different case. Compare a real production event with the test event field by field.

Should a stale source be switched off to stop the noise?

Not without a decision. Switching a source off silently removes coverage the team may still rely on. Mark it as degraded, tell the owners, and set a date for a decision on whether to repair or retire it.

How do we know a fix worked?

Trace the same indicator again from source to notification and confirm that each layer now shows the expected state. A fix that only stops the visible symptom leaves the underlying gap open for the next change.

When should the platform team be called in?

When the trace points to the platform itself, such as a scheduled job that has stopped or a permission failure that spans several sources. Give them the trace, the layer where it stopped, and the exact time the problem began.

Bring the single indicator you traced and the times the source last delivered.