Modello di sicurezza Hoxey

L’intera infrastruttura Hoxey è costruita fin dall’inizio seguendo un approccio Zero-Trust e orientato alla sicurezza.
Non ci limitiamo a rispettare le best practice e i requisiti di compliance; andiamo oltre. Per noi la sicurezza è un principio fondamentale, non un problema secondario.

Per comprendere correttamente alcuni concetti, si consiglia di leggere prima la documentazione architetturale.

Filosofia di base

Sebbene la nostra infrastruttura rispetti standard di sicurezza molto elevati, ben oltre quanto richiesto dalle normative, il principio di progettazione principale è proteggere te, il cliente.

Conosciamo la sicurezza abbastanza bene da essere pienamente consapevoli che la sicurezza al 100% non esiste.
Per questo motivo abbiamo progettato la nostra infrastruttura per proteggerti: anche in caso di disastro, una completa compromissione di ogni singolo bit di informazione sui nostri server, un avversario non può accedere a ciò che non è nemmeno presente.
Non abbiamo accesso al Device nella tua rete e non memorizziamo nulla che non sia strettamente necessario.

Ciò significa che lo scenario apocalittico per noi consiste in un’interruzione temporanea del servizio e nella possibile divulgazione di nome ed email per te.

Il dispositivo non è sotto il nostro controllo

Il piccolo dispositivo che installiamo NON consente alcun tipo di connessione. Punto.

È progettato per inoltrare, senza elaborazione, i pacchetti destinati alla sua interfaccia di rete attraverso un tunnel Layer 3 cifrato e monodirezionale, e per consentire solo le risposte in ritorno.
Tutto il resto è rigorosamente e automaticamente bloccato.

Il dispositivo è progettato per non fidarsi di nessuno. Nemmeno di noi.
Non possiamo gestire il dispositivo da remoto in alcun modo.
Un avversario all’interno del vero Honeypot sul nostro cloud non può tornare indietro.
Non possiamo inviare aggiornamenti al dispositivo per modificare il suo comportamento in alcun modo.
Il dispositivo è immutabile, con filesystem in sola lettura.
Non ha servizi in ascolto, solo lo stack di rete del kernel che instrada i pacchetti.
In caso di emergenza o guasto, spediamo un’altra immagine del disco su una scheda SD pronta da inserire.

I nostri clienti possono richiederci il codice sorgente del dispositivo per eseguirne la revisione. Ci sono solo circa 500 righe di codice.

Minimizzazione dei dati

Memorizziamo solo ciò che è strettamente necessario per l’operatività. Se sei un cliente, potresti aver notato che nella tua pagina profilo non chiediamo informazioni aggiuntive come numero di telefono o indirizzo.
Ecco cosa abbiamo su di te e sulla tua azienda:

Nome e cognome
Indirizzo email
Indirizzo IP (solo su audit)
Nome dell’azienda e piano di servizio
Subnet del dispositivo (solo su audit)
Webhook impostati per le notifiche
Campo di testo con note di gestione dell’account, criptato a riposo

I pagamenti degli abbonamenti sono gestiti da Stripe. Non conosciamo alcun dettaglio sui tuoi metodi di pagamento.

POLP - Principio del privilegio minimo

Il nostro RBAC multi-tenant (Role-Based Access Controls) definisce due tipi separati di account: Management (nostro staff) e Clienti.
È importante sapere che gli account Management e Cliente utilizzano endpoint API completamente separati per le operazioni, imposti dal primo middleware che processa la richiesta, che usa rigorosamente il database come unica fonte di verità.
Gli account Management hanno tre livelli:

Admin con accesso globale in lettura e scrittura su tutta l’infrastruttura
Manager con accesso globale in lettura, scrittura abilitata solo per operazioni non critiche
Support con accesso in lettura ristretto e scrittura ancora più limitata, solo sui clienti assegnati

Gli account Cliente hanno due livelli:

Owner con accesso in lettura e scrittura strettamente limitato alla propria organizzazione
Seat con accesso in lettura e scrittura parziale sulla propria organizzazione

Sicurezza dell’applicazione web

L’app web segue rigorosamente i più alti standard:

Ogni input è rigorosamente validato
Ogni query al database è parametrizzata
Ogni output è sanificato
Ogni azione è cross-validata
MFA disponibile
Il database è l’unica fonte di verità
I JWT utilizzano HMAC-SHA256 (HS256) con un segreto a 256 bit
Alcuni campi sono criptati a riposo nel database con AES-256-GCM più HMAC
Gli endpoint API sono limitati in modo conservativo
I messaggi di errore sono generici per evitare fughe di informazioni
Tutte le dipendenze utilizzano versioni fisse e vengono aggiornate manualmente

Crittografia di alto livello

Tutto ciò che non richiede indicizzazione è criptato a riposo con crittografia simmetrica quantum-ready.

Le credenziali sono salate e criptate con bcrypt usando più passaggi. Pur non rivelando i parametri esatti, sono generosi e computazionalmente intensivi.

Token sicuri e UUID sono ampiamente utilizzati internamente. Nessuna risorsa è accessibile tramite ID incrementale o nome.

Ovviamente TLS è applicato ovunque. Nessuna connessione, nemmeno interna, è consentita senza crittografia. Nessun fallback - HSTS completo.

Logging e auditing completi

Oltre ai log di sistema standard, utilizziamo un sistema di auditing personalizzato per l’applicazione che memorizza gli eventi in diversi server.

Questi eventi sono correlati tramite un rayID e sanificati rimuovendo informazioni sensibili.

Isolamento a più livelli

Ogni servizio gira all’interno di un container non privilegiato. Il container stesso gira all’interno di una Virtual Machine.
I sistemi sono minimi e privi di componenti non necessari. Il sistema operativo scelto è Debian.
Le regole del firewall filtrano le comunicazioni interne ed esterne con approccio whitelist, limitando la superficie di attacco quasi a zero.

Gli Hypervisor che ospitano gli Honeypot non sono clusterizzati e sono trattati come sistemi non affidabili dal cuore della piattaforma: l’Orchestrator. Per noi, una fuga da una VM Honeypot è un esercizio forense interessante e un case study, non un disastro. L’infrastruttura è progettata per gestire senza problemi un guasto o la compromissione di un Hypervisor.

Continuità operativa e disaster recovery

La nostra infrastruttura e i nostri processi sono progettati per mantenere la continuità del servizio e recuperare rapidamente operatività in caso di disastro.
Sono costruiti con un approccio di automazione del deployment e consistono in più container portabili che possono diventare operativi in pochi minuti, sostituendo quelli malfunzionanti o compromessi.
Manteniamo playbook per rispondere rapidamente e piani predefiniti per reagire in modo appropriato ai diversi scenari.

Sicurezza di terze parti

Facciamo ampio uso di software open source che alimenta la maggior parte di internet. Utilizziamo rigorosamente soluzioni collaudate; nessun software nuovo o non verificato è consentito.
I fornitori sono limitati e selezionati con cura in base allo storico e alla conformità agli standard più elevati (Hetzner, Stripe e Cloudflare).

Manteniamo un programma continuo di valutazione e gestione dei rischi.
Questo processo valuta rischi tecnici, operativi e organizzativi e garantisce che i controlli appropriati siano implementati e mantenuti.
I rischi vengono rivisti a intervalli programmati e ogni volta che si verificano cambiamenti significativi nell’infrastruttura o nell’ambiente operativo.