Data methodology

Where the data comes from

A threat feed is only worth what its collection is worth. This page states exactly what CTIF observes, how often, how an indicator is scored, how long it stays, and what the feed does not cover. Read it before you buy, and hold us to it afterwards. Live freshness per source is on the status page.

Collection

CTIF runs its own internet-facing sensors. They are ordinary hosts exposing real services, so the traffic that hits them is unsolicited by definition: nobody has a legitimate reason to brute-force SSH on a machine whose address was never published. Every ban, exploit attempt and blocked request is recorded with the source address, the service attacked, the raw log line and the time.

The collector pulls from every sensor every 6 hours. Between runs, an indicator's last-seen time can therefore be up to 6 hours behind the event that produced it. We would rather say that than print the word "real time".

• Sweden edge sensorfail2ban_se

  First-party sensor in SE. Its bans are evidence we produced, and its country is what appears as the targeted country on every indicator it saw.

• Switzerland edge sensorfail2ban_alivpn

  First-party sensor in CH. Its bans are evidence we produced, and its country is what appears as the targeted country on every indicator it saw.

Imported public feeds, kept separate

Alongside our sensors we import a small number of public lists, currently Tor exit node list and Blocklist.de and AbuseIPDB. They are never merged into our own observations: each indicator keeps the source that produced it, imported entries contribute no targeted country, and the blocklist endpoint accepts first_party_only=true to drop them entirely. If you already ingest those lists yourself, use that flag and pay us only for what we saw.

Enrichment

Every address is resolved to country, ASN and network operator, checked for reverse DNS, Tor exit membership and CDN ownership, and mapped to MITRE ATT&CK tactics and techniques from the behaviour that flagged it, not from a single blanket label. RDAP and WHOIS records are attached where the registry publishes them.

Hostility score

Every indicator carries one 0–100 number. The ordering principle is that what our sensors observed outranks what an address merely is:

The raw total is then decayed by recency with a 30-day half-life: an address we have not seen for a month scores about half of what it did, and keeps halving. Nothing is deleted to make this happen, so an indicator's history stays queryable while its score honestly reflects how stale the evidence is. The same function produces the score in the dashboard, the REST API, the STIX export and the blocklist, so the four can never disagree.

False positives

Addresses can be flagged as false positives and are then hidden from the feed, the blocklist and the API by default rather than silently deleted, so a mistake stays auditable. CDN edges and known research scanners are handled by the score cap above instead of removal, because they are legitimate traffic you should not block but may still want to see. If you believe an address is wrongly listed, write to support@orvteam.com with the address and we will review it.

What this feed does not do

It is IPv4 and IP-centric: no domains-as-product, no file hashes, no malware families, no passive DNS. Coverage is what our sensors saw, which is a real but finite slice of the internet, so an address missing from the feed is not evidence that it is safe. It is not a reputation-by-consensus service: there is no community reporting and no vote, only observations and public lists we name. And it is not a compliance product: use it to triage, enrich and block, not to accuse.

Suitable use

Enriching alerts in a SIEM, prioritising an alert queue by score, feeding an edge blocklist at a threshold you choose, and answering "have we seen this address before" during an investigation. The integration guides show each of those wired into a real tool.