Threat Intelligence Analysis: Prioritizing Risk in the AI Era

Monday, nine in the morning. Forty-one new feed items, six vendor reports, two government advisories, and one message asking whether any of it matters. Threat intelligence analysis is what happens next. Too often, it ends with reading, and by Friday nothing in the security program has changed.

The work is to compare reported activity with your own environment and decide which items require a hunt, a new detection, a coverage ticket, or no further action. The result is a ranked list of work, based on both what the report says and what your asset, identity, and telemetry data reveal about its relevance.

Key takeaways about threat intelligence analysis

• Relevance is a property of the pairing between a threat and an environment. A score computed from the report alone, with no environment data on the other side of the equation, is a guess wearing a number.
• Severity and relevance are different. The CISA KEV catalog represents only a small share of NVD records, but absence from KEV does not prove a vulnerability has never been exploited.
• The criteria that survive contact with a real week are the ones your own systems answer: asset inventory, identity topology, and whether you collect the telemetry the technique would appear in.
• A method that never produces an archive decision is not a method. Sector targeting is a weak filter; technique reuse across verticals is the reason a report about someone else's industry can still change your queries.
• When the inventory is stale, treat unknown as present and use available asset and telemetry data to investigate. One search may answer both questions.

What Is Threat Intelligence Analysis?

Threat intelligence analysis is the judgment layer between a report arriving and your team spending an afternoon on it. Collection gives you volume. Analysis gives you a decision: this one changes what we do, that one does not, and here is the environment fact that settles it.

Severity scores are the usual stand-in, but they do not measure relevance to your environment. As of September 7, 2026, the CISA KEV catalog held 1,695 entries, compared with 387,073 records in the NVD CVE database, or roughly 0.44 percent.

KEV confirms exploitation for the vulnerabilities it lists, but it is not a complete record of every vulnerability ever exploited. Absence from KEV does not prove absence of exploitation.

CVSS base severity describes characteristics of a vulnerability. Relevance depends on your environment. Cyber threat analysis that stops at “critical, patch it” relies on a rating created without knowledge of your network. KEV adds evidence of exploitation, but it still cannot tell you whether you run the affected software.

How the AI Era Is Expanding the Threat Landscape

On November 13, 2025, Anthropic published a report describing what it believed was the first documented large-scale cyberattack executed without substantial human intervention. According to Anthropic, a Chinese state-sponsored group manipulated Claude Code to conduct reconnaissance, develop exploit code, harvest credentials, and stage data exfiltration across roughly 30 targets, succeeding in a small number of cases.

Two details matter for scoring, and neither is the headline. The campaign targeted technology companies, financial institutions, chemical manufacturers, and government agencies in one operation, showing why vertical alone can be a weak filter. The disclosure also came from a model provider rather than a conventional security vendor, widening the set of sources analysts may need to weigh.

Volume goes up. Time to read does not. That gap is the same one that opened between attacker technique and static rule sets, which is the argument behind how attacker behavior outpaced rules.

Identifying the Threats Most Relevant to Your Environment

Five questions help determine relevance, and each is answered using systems you own. Work through them in order, but do not treat every “no” the same way: some justify archiving the campaign, while others expose a hunt or coverage requirement.

Note the asymmetry. Unknowns about the attacker count against you, and so do unknowns about your own visibility. Both defaults push toward doing the work.

The caveat that breaks most scoring models. Every question above assumes you can answer it, and most teams cannot. The CMDB stopped being true two reorganizations ago, the service-account list lives in a spreadsheet, and nobody has audited log source coverage since the last migration. A model built on that data returns confident, wrong answers, and it returns them quickly.

That's not an intelligence problem. It's an inventory problem.

When the inventory is unreliable, invert the default and let the investigation do double duty. If you cannot confirm that you run the affected technology, search available asset, package, configuration, and telemetry data for evidence of it. Where the relevant data exists, the hunt may answer both questions. Log the answer back.

Hold one worked case through the rest of this article. On July 30, 2026, CISA urged the water and wastewater sector to remove internet-exposed PLCs, after actors changed passwords to lock operators out of them. Assume you run security for a payments company: no PLCs, no boil water notices, no obvious reason to read past the headline.

Mapping TTPs to Business Risk and Security Exposure

This is the translation a CISO will read, and where most analysis stalls. A technique ID becomes an exposure when you name the asset it reaches, the identity it needs, and what the business loses if it succeeds.

Two rules keep this table honest. Name the specific asset rather than the class: “the payment gateway’s admin interface” beats “internet-facing systems.” And name the identity, because its permissions and trust relationships can determine how far an attacker moves.

Back to the CISA alert. Its most transferable line has nothing to do with water. CISA warns that the exposed devices include cellular modems installed by operators, vendors, or integrators that may not be documented or included in routine attack surface scans. Map that to the T1133 row and the exposure stops being sector-specific. It may be a remote access path absent from your inventory and therefore missing from the allowlists and monitoring built around documented access routes.

Separating High-Priority Signals From Intelligence Noise

The honest counterargument is stronger than most analysts admit.

The maximalist position says to treat everything as potentially relevant. Sector alone is a weak predictor, actors often reuse tradecraft across verticals, and the operation Anthropic documented targeted four different sectors. Filter only on vertical and you risk discarding a report about a technique that later reaches your environment. Every discard is a bet made with incomplete information.

That argument is stronger at the technique layer than at the campaign layer. Target lists, victim names, sector indicators, and infrastructure may be short-lived or specific to someone else. The underlying behavior often transfers more readily. Filter on the campaign layer, stay open on the technique layer, and record what you kept.

The payments company gets both outcomes from one advisory. The PLC lockout activity, the vendor restoration guidance, and the water sector indicators go to row one: archived, dated, with a reason a colleague can audit in six months. The undocumented vendor connectivity goes to row two, because a payments company may have integrators and vendor tunnels of its own that are missing from the network diagram.

That second verdict is the discipline working. A method that always concludes "yes, act on this" is a queue, not an analysis.

Turning Analysis Into Security Priorities and Detection Opportunities

A score is only worth the work it commissions. Each verdict maps to one artifact, small on purpose: a hypothesis someone tests this week rather than a program someone funds next quarter.

Opportunity one: administrative sessions to management interfaces from outside the engineering allowlist. The hunt asks which source addresses authenticated to device and appliance management planes, then subtracts the known engineering ranges. What legitimately looks the same: a vendor support engineer inside a scheduled maintenance window, an integrator on a hotel network, and your own on-call engineer tethered to a phone during an outage. All three produce the same record, so any detection here needs an approved-maintenance source of truth or it pages you weekly.

Opportunity two: network paths present in traffic data and absent from the inventory. Compare observed endpoints against the documented asset list and flag the difference. What legitimately looks the same: a test environment provisioned this morning and not yet registered, a contractor's survey device, and any cloud resource created outside the tagging pipeline. The inventory correction is worth as much as the finding.

This article sits on the synthesis side of the problem: many sources weighed against one environment. Building the logic is a separate discipline with its own failure modes, and the one that follows a good score is intel that never becomes a detection. Score it here, convert it there.

How Mars Security Converts Relevant Intelligence Into Action

That's what we work on at Mars Security. Running the comparison above once, for one report, on a quiet afternoon, is easy. Running it for every report that lands, against an environment that changed since anyone last checked, is what fails in a busy quarter.

Mars keeps both sides of that comparison current. It ingests CTI, extracts the attacker behavior underneath the campaign detail, and helps teams hunt across the log sources, cloud services, and endpoints already in their environment. It queries existing data in place, without requiring a separate ingestion pipeline.

The judgment stays with your analysts, where it belongs. What changes is how often the comparison runs.

Frequently Asked Questions About Threat Intelligence Analysis

Is cyber threat analysis the same thing as threat intelligence analysis?

They overlap heavily and most teams use them interchangeably. Where a distinction helps: cyber threat analysis examines the threat itself, its tooling, infrastructure, and behavior. Threat intelligence analysis weighs finished intelligence against a specific environment to produce a decision about what your team does next.

Where does threat analysis and risk assessment fit in?

Threat analysis and risk assessment is the governance-side practice: likelihood and impact ratings feed a risk register and longer-term planning. The scoring described here operates more frequently and produces hunts and coverage tickets. Both need reliable asset data, and the risk register may provide another source against which to check it.

Who should own this on a team with no dedicated CTI function?

Whoever owns detection coverage is often the practical choice, because that function already works with two datasets that strongly influence relevance: available telemetry and current detection coverage. If intelligence analysis and coverage remain separate, give one person explicit responsibility for moving scored items into hunts, detections, or documented archive decisions.

Can you do relevance scoring without a threat intelligence platform?

Yes. OpenCTI and MISP handle storage and correlation if you want them, and plenty of teams run the criteria out of a shared document against a live asset export. The platform helps with volume and history. It does not supply the environment data, and the environment data is what makes the score mean anything.

Does the KEV catalog replace relevance scoring?

No, though it narrows the field usefully. KEV answers one question well: whether CISA has evidence that the vulnerability has been exploited in the wild. It cannot tell you whether you run the affected product, whether the affected instance is reachable, or whether you would see the exploitation attempt in the telemetry you collect.

How do you tell whether the analysis is working?

Count archive decisions. A program that scores fifty items a month and archives none is not filtering, and a program that archives everything is not reading. Then check how many of the last quarter's archived items came back, and why. The re-open rate tells you whether the criteria are calibrated or merely convenient.

Stop scoring intelligence on what the report claims. Start scoring it on what your environment answers back, and accept that a defensible no is the output most intel programs never produce. If you want that comparison running continuously rather than whenever someone has a free afternoon, matching intelligence to your environment is the problem we built around.