How an Indicator Enters the Feed

A Cybora feed is not a raw collection of IPs, domains, and URLs. Every delivered indicator passes through an evaluation that connects technical threat signals with operational enforceability. This decision chain is what separates a large list from a feed admins can defend in production firewall policies.

The basic principle is simple:

The individual steps are intentionally described in a way admins can follow. Concrete thresholds, weights, partner sources, and internal scoring rules remain protected because they are part of the feed quality and should not be exploited by attackers or copied by competitors.

1. Sources provide signals, not final decisions

Cybora uses different signal sources: OSINT, commercial threat-intelligence feeds, honeypots, sensors, real firewall observations from production environments, and carefully evaluated identity signals such as repeated failed cloud logins.

No source is perfect on its own. OSINT can be broad and fast, but stale or low-context. Commercial feeds add coverage, but are not automatically firewall-ready. Honeypots see early internet noise, while production firewalls show which infrastructure touches real business perimeters with real services.

Cybora therefore treats sources as input signals. Only normalization, deduplication, behavior assessment, and correlation turn them into usable feed candidates.

2. Normalization makes signals comparable

Before a signal can be evaluated, it must be technically classified. IPs, domains, and URLs are different indicator types and later belong in different firewall functions.

In this phase, signals are standardized, duplicates are reduced, and obvious format issues are separated. This is not glamorous, but it matters: a firewall can only work reliably when the feed is delivered in a clear format and every indicator is used in the right place.

More about the output format is documented in Firewall-native Feed Format.

3. Behavior explains why an indicator matters

A pure reputation hit does not say enough. For production firewall policies, the observed behavior matters:

• mass scanning
• exploit attempts against exposed services
• botnet or command-and-control communication
• phishing or malware delivery
• repeated credential attacks
• suspicious activity across multiple observation points

This classification makes the feed more operational. An admin can better understand whether an indicator represents broad automated noise, active attacker infrastructure, or a stronger campaign signal.

More about this is documented in Behavior-based Signals.

4. Correlation increases confidence

A single hit may be noise. An indicator becomes much stronger when multiple independent observation points support the same infrastructure.

Examples:

• the same IP appears in OSINT and commercial feeds
• a sensor sees scanning while production firewalls also observe the same source
• identity signals repeat across independent environments
• a domain matches phishing behavior and is also confirmed by additional sources

Correlation does not mean blindly adding as many lists as possible. The key question is whether different signals plausibly and independently support the same risk.

More about this is documented in Confirmed across independent observation points.

5. Collateral damage decides firewall suitability

An indicator can be technically suspicious and still be too risky for hard blocking. Cybora treats the following with particular caution:

• large cloud and hosting providers
• CDNs and reverse proxies
• shared SaaS, mail, VPN, or identity infrastructure
• dynamic provider networks
• domains with legitimate primary use and compromised subpaths

The higher the risk of affecting legitimate traffic, the stronger the evidence must be. This is one of the most important differences between analysis intelligence and a feed for production firewall policies.

More about this is documented in Lower false-positive risk, more operational trust.

6. Aging keeps the feed current

Threat infrastructure changes. IPs are reassigned, domains change ownership, compromised systems get cleaned up, and old campaigns lose relevance. A feed does not improve simply because it grows.

Cybora therefore evaluates not only whether an indicator was once suspicious. What matters is how current the evidence is, whether it has been observed repeatedly, and whether the indicator’s role still appears plausible. Stale evidence loses weight in a controlled way.

More about this is documented in Current signals instead of stale evidence.

7. Delivery as a firewall-ready feed

If an indicator is suitable for the relevant feed, it is delivered in a simple firewall-ready format: one indicator per line, retrievable over HTTPS, separated into IP, domain, and URL feeds.

The position within a feed can be understood as operational prioritization. Indicators with stronger evidence, higher freshness, and lower expected collateral damage are delivered higher in the list. Every delivered entry still has to meet the internal criteria for the relevant feed.

The firewall retrieves the feed on its own polling interval and uses it in native external-list, dynamic-list, alias, or threat-feed functions.

What deliberately stays internal

Cybora documents the principle, not the exact recipe. The following remain internal:

• concrete scoring and weighting rules
• thresholds and time windows
• individual partner sources and customer details
• detection logic for abuse and evasion attempts
• exact rules for admission, prioritization, and removal

For admins, the key point is this: an indicator does not enter the feed simply because it was mentioned somewhere. It is evaluated as a signal, checked against other observations, assessed for production enforceability, and then delivered in a format firewalls can use directly.