Browse docs

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.