concepts
Privacy and Data Flow
How Cybora generally handles production firewall and identity signals without exposing sensitive customer environments.
Last updated: June 29, 2026
On this page
Cybora can evaluate threat-intelligence signals from different sources: OSINT, commercial feeds, honeypots, sensors, real firewall observations, and selected identity signals. Production firewall and login signals are especially valuable, but they must be treated with particular care.
The principle is simple: the security-relevant signal matters for the feed, not the exposure of a customer environment.
Which data is technically relevant
For a firewall threat feed, observations that help evaluate external infrastructure are most relevant. Examples include:
- an external IP, domain, or URL
- observed behavior such as scanning, botnet communication, or repeated login failures
- timestamp or freshness of the observation
- repetition across independent environments
- technical context relevant to confidence and collateral damage
Internal customer topologies, user identities, full raw logs, or confidential details of individual environments are not relevant for public feed delivery.
Data minimization and purpose limitation
Production Signals should be processed in a way that serves only the purpose of threat evaluation. That means as little context as possible and as much technical evidence as necessary. Where signals from customer or partner environments are included, they must be minimized, appropriately protected, and handled without unnecessary customer-specific details.
Cybora does not publish raw logs, customer names, internal thresholds, or source weights. Public documentation explains why a signal type is valuable, but not which concrete environment produced which hit.
Handle identity signals with special care
Repeated failed cloud logins across multiple independent environments can indicate password spraying, credential stuffing, or compromised infrastructure. At the same time, such signals are prone to misinterpretation: NAT, VPNs, proxies, mobile networks, or shared IPs can mix legitimate and malicious use.
Identity signals should therefore not be understood as isolated block decisions. They gain weight only when they match additional evidence, repetition, and context. More about this is documented in Identity Signals Against Password Spraying and Credential Attacks.
What admins can take from this
For admins, the important point is that the feed is not built from uncontrolled publication of raw data. The data pipeline should evaluate signals, normalize them, and check them for production firewall use. This strengthens trust without unnecessarily exposing what individual environments look like or which internal rules Cybora uses.
The technical feed delivery itself is documented in Feed URL Format and License Key. Guidance for handling feed URLs and keys is documented in Secure Feed URLs.