Sfoglia docs

Funzionalità

Feed curati sulle minacce invece di elenchi grezzi rischiosi

Come Cybora ricava un feed delle minacce pronto per il firewall da OSINT, feed commerciali, sensori e segnali reali.

Ultimo aggiornamento: 26 giugno 2026

In questa pagina

Un buon feed firewall non è semplicemente l’elenco più ampio possibile. I dati grezzi contengono duplicati, voci obsolete, fonti contrastanti, categorie poco chiare e segnali troppo rischiosi per il blocco della produzione. Cybora cura questi segnali prima di fornirli come feed.

La cura è il valore reale del servizio. Riduce il lavoro che un amministratore dovrebbe altrimenti svolgere manualmente: confrontare fonti, normalizzare le voci, rimuovere dati obsoleti, controllare obiettivi rischiosi e trasformare il risultato in un formato che il firewall può effettivamente utilizzare.

La catena di cura

Cybora segue una catena tecnica semplice:

Source -> observed behavior -> independent evidence -> confidence -> collateral damage -> aging -> feed delivery

Questa catena è deliberatamente più forte di un singolo colpo alla reputazione. Un indicatore diventa più prezioso quando è aggiornato, osservato ripetutamente, legato a un comportamento chiaro e non crea rischi evidenti per l’infrastruttura aziendale legittima.

Il contesto comportamentale è decisivo. Un IP non è semplicemente “cattivo” perché appare in un elenco. Ciò che conta è se si distingue attraverso la scansione, i tentativi di exploit, la comunicazione botnet, il phishing, la distribuzione di malware o gli attacchi ripetuti alle credenziali. Ulteriori informazioni su questo argomento sono documentate in Segnali basati sul comportamento.

Perché le liste grezze sono problematiche

Gli elenchi pubblici possono essere molto utili, ma raramente vengono ottimizzati direttamente per le policy firewall di produzione. I problemi comuni includono:

  • IP o domini obsoleti che ora vengono utilizzati legittimamente
  • tipi di indicatori misti in un unico file
  • informazioni mancanti sulla freschezza del segnale
  • contesto insufficiente per hosting condiviso, CDN o provider cloud
  • elenchi più grandi della capacità di alcuni modelli di firewall

Cybora non accetta ciecamente tali fonti. Vengono trattati come segnali di input, non come blocklist finite.

Quali fonti sono incluse

Cybora continua a utilizzare elenchi OSINT pubblici e feed commerciali di intelligence sulle minacce come importanti segnali di input. Sono completati da honeypot proprietari e dati di sensori, segnali firewall reali provenienti da ambienti di produzione partecipanti e segnali di identità attentamente valutati come ripetuti accessi al cloud non riusciti in più ambienti indipendenti.

Ogni fonte ha punti di forza e limiti. OSINT può essere ampio e veloce, ma obsoleto o di basso contesto. I feed commerciali aggiungono copertura, ma non sono automaticamente predisposti per il firewall. Gli honeypot rilevano i primi rumori di Internet, i firewall reali mostrano la realtà del perimetro di produzione e i segnali di identità possono indicare la diffusione di password o il riempimento di credenziali.

Cybora tratta quindi queste fonti come segnali, non come decisioni finali. Diventano preziosi attraverso la normalizzazione, la deduplicazione, la correlazione, la valutazione dell’aggiornamento e il controllo se un indicatore può essere utilizzato in una policy firewall di produzione con un rischio accettabile.

Cosa rimane pubblico e cosa rimane interno

Il principio pubblico è importante: Cybora combina più tipi di segnali, ne controlla la pertinenza e fornisce solo indicatori pronti per il firewall. I pesi concreti, le soglie, le priorità delle fonti e i dettagli dei singoli partner rimangono interni. Ciò mantiene il processo comprensibile senza esporre l’effettiva logica di curation.

Il formato di output tecnico è documentato in Formato URL del feed e chiave di licenza.