ServiceNow Threat Intelligence Best Practices

Establish Threat Data Sources and Feeds

Threat intelligence comes from many sources: public threat feeds (vendor feeds, government advisories), proprietary threat intel from your security tools, incident history from your own organisation, and peer sharing from industry partners.

Good practice is to consume multiple threat feeds and normalise them. Different feeds report on different threats; combining them gives broader coverage. Normalisation means mapping different feed formats (one feed reports IP addresses, another reports domains) into a common structure in ServiceNow.

Evaluate feeds carefully. Some feeds are accurate and timely; others are noisy (many false positives). Some feeds are free (open intelligence) but may have delays (weeks old). Some are paid (fresher, less noise). Choose feeds based on your threat model: if you care about cloud security, subscribe to feeds focused on cloud threats. If you are in finance, focus on threats to financial systems.

Update feeds automatically and frequently. Threat intelligence that is weeks old is less valuable. Configure feed updates to run daily or multiple times per day for the most critical threats.

Create and Manage Indicators of Compromise (IOCs)

IOCs are artifacts that indicate compromise: malicious IP addresses, malicious domains, known malware file hashes, known phishing sender addresses. IOCs let you detect attacks in progress.

Store IOCs in ServiceNow with metadata: what is the IOC (IP, domain, hash?), where did it come from (which threat feed?), what is its severity (how confident are we it is malicious?), when was it first seen and last seen, and what threat does it represent (ransomware, botnet, phishing?).

Use IOCs to detect attacks. Compare incoming network traffic to known malicious IPs (if traffic comes from a known malicious IP, alert). Compare email senders to known phishing addresses. Compare file hashes of uploaded files to known malware hashes. Feed IOCs to your detection tools (SIEM, email gateway, firewall) so they can block malicious traffic before it reaches users.

Manage IOC lifecycle: When an IOC is first received, set its status as New. After it is verified and fed to detection systems, mark as Active. When the threat goes out of scope (old attacks no longer relevant, threat actor is inactive), mark as Retired. Do not keep IOCs active forever; old, expired intelligence creates noise.

Correlate Threat Intelligence With Your Environment

Threat intelligence is most valuable when correlated with your own data. A threat feed reports attacks on financial services; you work in healthcare. That threat is less relevant than a threat targeting healthcare organisations.

Correlate: Check whether known malicious IPs have connected to your network. Check whether known malware has been detected in your environment. Check whether users have visited known malicious domains. Use this correlation to prioritise: alerts for threats in your environment get high priority; threats to unrelated industries get lower priority.

Use correlation to track threat actor activity. If multiple attacks use the same malware, they might be from the same actor. Track the actor and their patterns: what industries do they target? What attack technique do they use? What is their typical time zone? Use this to anticipate and prepare for future attacks from the same actor.

Produce Actionable Intelligence, Not Just Data

There is a difference between data and intelligence. A threat feed delivers data (lists of malicious IPs). Intelligence is actionable insight (your organisation has been targeted by actor X, here is what they typically do, here is how to defend against them).

Transform data into intelligence by adding context. A malicious IP is data; “malicious IP used by ransomware group Y for command-and-control, last seen in attacks on financial institutions in North America” is intelligence. The second version tells a security team what to do (watch for this IP, focus on north america exposure, prepare for ransomware scenarios).

Produce intelligence products for different audiences. For security operations, produce a daily alert of new IOCs and correlation with your network. For leadership, produce a monthly threat summary (what threats are most relevant, what is the attack trend, what are we doing about it?). For incident response, produce threat actor profiles (who attacks organisations like ours, what is their modus operandi, how do we detect and respond?).

Integrate Threat Intelligence Into Detection and Response

Intelligence is only valuable if it guides action. Feed IOCs to your security tools (SIEM, firewall, email gateway, endpoint protection). When a file hash matches known malware, block it. When traffic comes from a known malicious IP, drop it. When an email comes from a phishing domain, quarantine it.

Link threat intelligence to incidents and investigations. When an incident is detected, check threat feeds to see if this attack is known. Is it a known ransomware strain? Is it a known threat actor? Use that context to inform response (how serious is this, how fast do we need to respond, what is the threat actor’s goal?).

Maintain Threat Intelligence Quality and Hygiene

Threat intelligence can be wrong. An IP flagged as malicious might actually be compromised infrastructure (a legitimate server taken over). A domain flagged as phishing might be a legitimate domain that was flagged incorrectly. Poor-quality intelligence leads to poor security decisions.

Review threat intelligence regularly. Remove IOCs that are outdated (the threat no longer exists). Investigate false positives (does this IP really need to be blocked?). Update metadata (if new information comes in about an IOC, update it). Source quality (which feeds are giving us good data, which should we drop?).

Share Threat Intelligence With Peers and Industry Groups

Threat intelligence is more valuable when shared. Industry information sharing and analysis centres (ISACs) collect intelligence from member organisations. Peer sharing (within your supply chain or industry) gives visibility into threats affecting similar organisations.

Contribute your own threat data. If you detect an attack, share IOCs with peers and ISACs so they can defend. This helps the broader community and builds relationships that can help you in return.

Setting a weekly operating rhythm for intelligence work

Threat intelligence practice depends heavily on rhythm. A team that produces insight whenever someone has time can find that the insight arrives after the decision it was meant to shape. A fixed weekly cycle, with a small set of standing outputs, keeps intelligence aligned with the calendar of the people who act on it.

The cycle should be short enough to finish inside a working session. If preparing the weekly review takes the whole week, the cycle is too large, and the reduction should come from fewer sources rather than from skipping the review.

A weekly cycle and who owns each part

Part of the cycle	Owner	Output	Evidence that the output was used
Review of new matching indicators	Intelligence analyst	A short list with keep, watch or discard decisions	Discarded items carry a reason
Priority threat update	Threat intelligence lead	Ranked list of current threats with one-line reasons	A detection or review ticket references the ranking
Change log for detection and prioritization	Detection engineering	Changes made, with the intelligence item that prompted each one	The item can be traced to a live rule or priority
Distribution of the week’s summary	Security operations manager	One summary sent to the people who act on it	Recipients name at least one action taken

Practices that make intelligence easy to act on

1. Keep a short register of intelligence requirements, written as questions the business needs answered, and tag every item to one question. Items that answer no question are candidates for discard.
2. Give each indicator a single confidence level agreed by the team, and explain in one sentence what the level means in practice.
3. Write every assessment so that the first paragraph states the action it supports, and the detail follows for those who need to check it.
4. Record where each piece of intelligence came from in terms a reviewer can follow, without relying on the analyst’s memory.
5. Close each item with an outcome: acted on, monitored, or discarded with a reason. Items that never reach an outcome are the first ones to review.

Handling sharing constraints as part of the practice

Good practice includes deciding in advance who may see each piece of intelligence. Some material is safe to share with a wide operations audience, some only with the response team, and some should not leave the intelligence function at all. Settle the handling categories with the security lead and apply them the same way every time. The rules for who can open which category live in the security and access design guide; a well-meaning colleague forwarding a restricted item is still a leak. Where the organization takes part in a sharing group, check its rules on what may be passed on and on how contributed material is attributed.

Keeping the practice honest over time

Intelligence teams can drift toward producing material that is interesting rather than useful. A quarterly review of the register of requirements helps counter that drift. Ask which requirements produced outcomes in the last quarter and which produced only reading. Requirements that never produced an outcome should be retired or rewritten, even if they sounded important when they were first written. The governance model covers ownership structure for the cycle roles.

Questions teams ask when formalising the practice

How long should a weekly threat intelligence review take?

Long enough to decide the three standing items and no longer. A review that runs well beyond its slot is often carrying work that belongs to a different cycle, such as a deep actor analysis, and that work should be scheduled separately.

Who should attend the review?

The intelligence analyst, the detection engineer who will act on the changes, and a representative from security operations. Attendees who only listen are better served by the written summary. The operations review agenda article covers structured reviews of this kind.

What do we do when an item is important but no one can act on it?

Record it with the reason it cannot be acted on, and name the person who will check again when the condition changes. An item that stays on the list with no owner has quietly become a source of noise.

Next step

A first weekly review run on your own indicators can test whether the rhythm fits. The risk management accountability article covers who answers for a decision.

Checking New Threat Intelligence Against Historical Data

To check new threat intelligence against history, run a retrospective match whenever an indicator becomes active: compare it with stored DNS, network flow and proxy records covering the period before the indicator was published. Compromise often predates the feed, so a match against old logs can reveal an intrusion no live alert would catch.

In most implementations the logs live in a SIEM or log platform, the match runs there, and the threat intelligence record in ServiceNow keeps the outcome so the indicator carries its own history. The look-back window should reach at least as far as the indicator was circulating before you received it.

1. Take indicators newly marked active and group them by type: addresses, domains and file hashes.
2. Match each group against the stored records for the look-back window.
3. Record every hit with the first and last time seen and the asset involved.
4. Triage hits on shared hosting and content delivery addresses first.
5. Write the verdict back to the indicator and to the quality record for the feed it came from.

The same loop answers the false positive problem. Address-only indicators are the noisiest, because one address can serve a malicious site and thousands of harmless ones at different times. Require a second signal before action on an address, such as a matching domain or a hit from an unrelated feed, and let indicators expire on a set date instead of living on by default.

Keep a simple score per feed: hits that turned out to be real, divided by hits that needed triage. A feed with many hits and few confirmations loses weight or is dropped. The wider cycle this fits into is described in ServiceNow threat intelligence guides, and the response side in security operations and incident response.

How far back should a new indicator be checked?

As far as your retained logs and the indicator’s known activity allow. If the indicator was first reported weeks earlier, look back at least that long. Where retention is short, say so in the record so nobody reads a clean result as proof.

Why do indicator feeds produce so many false positives?

Common causes are shared hosting addresses, expired indicators and domains taken over after a threat ended; legitimate services reusing addresses adds to it. Corroboration, expiry dates and per-feed scoring cut the volume.

What happens when a historical match is confirmed?

Treat it as a live incident. Open a security incident, link the indicator and the affected assets, and scope the window between first and last seen. Details of the incident path sit in security operations.