Piattaforme di penetration test on-premise e air-gapped: guida all'acquisto

La maggior parte degli acquirenti confronta le piattaforme di pentest su ciò che trovano. Per le organizzazioni regolamentate il primo filtro spesso è un altro: dove girano il control plane e l'AI della piattaforma, e quindi dove finiscono finding, credenziali ed evidenze.

Questa scelta decide tre cose che interessano a un comitato rischi:

• Chi è terza parte. Il cloud di un fornitore che riceve i tuoi finding è un fornitore di servizi che tratta i tuoi dati di sicurezza, con le proprie sedi, i propri subfornitori e il proprio personale.
• Cosa va valutato e contrattualizzato. Ogni fornitore di questo tipo aggiunge due diligence, clausole contrattuali, monitoraggio e un piano di uscita.
• Cosa succede se il fornitore si ferma. Se il test dipende dal cloud del fornitore, una sospensione, un disservizio o un'insolvenza fermano anche i tuoi test.

Nessuna delle norme che seguono vieta una piattaforma di pentest ospitata nel cloud, e molte organizzazioni la usano dopo aver fatto quel lavoro. Lo scopo di questa guida è rendere visibile il lavoro prima dell'acquisto e mostrare cosa deve garantire davvero un'opzione on-premise o air-gapped per eliminarlo.

• Difesa, forze armate e industria della difesa. Informazioni classificate e controllate, reti air-gapped per regola e, per i fornitori della difesa statunitense, le regole di perimetro CMMC su dove possono finire CUI e dati di sicurezza. Vedi difesa e reti air-gapped e industria della difesa USA (CMMC).
• Pubblica amministrazione e governo. Regole di sicurezza nazionale e di classificazione dei dati, come il Perimetro di sicurezza nazionale cibernetica in Italia, e il principio per cui gli strumenti che difendono lo Stato restano sotto il suo controllo.
• Banche, assicurazioni e infrastrutture di mercato. Rischio ICT di terze parti, rischio di concentrazione e strategie di uscita con DORA nell'UE, e regole su esternalizzazione o localizzazione dei dati delle autorità di vigilanza nazionali altrove.
• Sanità e scienze della vita. Categorie particolari di dati personali (art. 9 GDPR), obblighi HIPAA per i business associate negli Stati Uniti e ospedali classificati come entità essenziali NIS2.
• Operatori di reti OT e industriali. Reti di stabilimento, energia e utility volutamente isolate, dove uno strumento che richiede una connessione internet permanente non si può proprio installare.

Il filo comune non è la dimensione, ma la sensibilità dei dati di sicurezza e l'isolamento della rete. L'elenco completo, con il riferimento normativo per ogni settore, è nella pagina red team AI on-premise.

DORA (entità finanziarie UE). L'articolo 3(21) definisce i servizi ICT come servizi digitali e di dati forniti in modo continuativo attraverso sistemi ICT, compresi i servizi hardware con assistenza tecnica tramite aggiornamenti software o firmware da parte del fornitore dell'hardware. Una piattaforma cloud è un servizio ICT; lo è anche un'appliance on-premise il cui fornitore distribuisce aggiornamenti. In entrambi i casi il fornitore entra nel registro delle informazioni dell'articolo 28(3), e l'articolo 28(4) richiede una valutazione precontrattuale che comprende il rischio di concentrazione. Il modello di deployment cambia ciò che quella valutazione deve coprire:

• L'articolo 30(2)(b) chiede che il contratto indichi le regioni o i paesi in cui il servizio è prestato e dove i dati sono trattati, compreso il luogo di conservazione, con preavviso di ogni cambiamento. Con il cloud di un fornitore è l'hosting del fornitore; on-premise è la tua sede.
• L'articolo 29(2) chiede di valutare le catene di subappalto e i fornitori stabiliti in paesi terzi, comprese la protezione dei dati e l'effettiva applicazione della legge in quei paesi. Una piattaforma SaaS che chiama un modello AI di terzi aggiunge un anello a quella catena.
• Per i servizi che supportano funzioni essenziali o importanti, l'articolo 28(8) richiede strategie di uscita testate e l'articolo 30(3)(f) un periodo di transizione. Se la capacità di test vive nel cloud del fornitore, uscire significa perderla; se gira su hardware che detieni, l'uscita è una questione di licenze e assistenza.

NIS2 (entità essenziali e importanti). L'articolo 21(2)(d) inserisce tra le misure di gestione del rischio obbligatorie la sicurezza della catena di approvvigionamento, compresi gli aspetti di sicurezza dei rapporti tra ciascuna entità e i suoi fornitori diretti o fornitori di servizi, e l'articolo 21(3) chiede di tenere conto delle vulnerabilità specifiche di ogni fornitore e della qualità dei suoi prodotti e delle sue pratiche di cybersecurity. Una piattaforma di test conosce in modo privilegiato le tue debolezze: dove invia quella conoscenza fa parte della valutazione del fornitore.

CMMC (fornitori della difesa USA). Il 32 CFR 170.4 definisce External Service Provider le persone, le tecnologie o le strutture esterne usate per servizi IT o di cybersecurity, e precisa che per rientrare nella definizione il fornitore deve trattare, conservare o trasmettere sui propri asset CUI o Security Protection Data. I Security Protection Data comprendono espressamente i dati sulla configurazione o sullo stato di vulnerabilità degli asset in perimetro e le password che danno accesso all'ambiente in perimetro. Un servizio di pentest in cloud che riceve finding o credenziali di test è quindi un ESP nel perimetro della tua valutazione. Il playbook sulle evidenze della Fase 2 CMMC ne descrive le conseguenze sul perimetro.

I fornitori chiamano on-premise architetture molto diverse: un sensore locale pilotato da una console cloud, un motore locale che chiama un modello AI in cloud, oppure un'appliance autosufficiente. Definisci il termine nel contratto, voce per voce:

• Nessuna telemetria per default. Elenca ogni connessione in uscita che il prodotto effettua nel funzionamento normale, con destinazione e contenuto. Tutto ciò che va oltre quell'elenco deve essere facoltativo e documentato.
• Modelli AI locali. Indica dove avviene l'inferenza. Se un prompt, un finding o una credenziale può raggiungere un endpoint di modello esterno, quel fornitore è una terza parte e rientra nella tua valutazione. Vedi AI privata nella cybersecurity.
• Licenza offline. La piattaforma deve continuare a funzionare anche se non raggiunge il fornitore, con la scadenza della licenza verificata in locale, così che un disservizio, una controversia o un'insolvenza del fornitore non spengano i tuoi test.
• Un processo di aggiornamento controllato. Aggiornamenti firmati dal fornitore, verificabili prima dell'installazione, applicabili offline dove la rete è isolata e installati quando decidi tu.
• Conservazione locale delle evidenze. Finding, evidenze e credenziali conservati sul tuo hardware, con un'integrità verificabile senza il fornitore e formati di esportazione che puoi tenere dopo la fine del contratto.
• Cancellazione dei dati. Come vengono cancellati i dati alla fine del contratto o quando l'hardware torna al fornitore per riparazione o sostituzione, e quale prova di distruzione viene fornita.
• Assistenza remota. Se il fornitore ha mai bisogno di accesso remoto, chi lo approva e come viene registrato.
• Comportamento in air-gap. Quali funzioni dipendono da internet e si perdono quando la piattaforma è completamente isolata, così da pianificare il perimetro dei test di conseguenza.

Le opzioni di deployment differiscono più di quanto suggeriscano le etichette di categoria. Dalla documentazione esaminata per le nostre pagine di confronto:

• Horizon3.ai NodeZero gira da un host presso il cliente ma è orchestrato dal cloud di Horizon3, verso cui quell'host richiede un accesso in uscita continuo durante il test; è disponibile un portale ospitato nell'UE e non è documentata un'edizione air-gapped.
• Pentera Core si installa sulla tua infrastruttura, mentre Pentera Surface è ospitato su AWS e le sue funzioni di AI generativa chiamano un servizio LLM in cloud; non è documentato un funzionamento pienamente air-gapped.
• Cymulate è solo SaaS: sulla tua rete girano punti di test leggeri, mentre la piattaforma e la sua AI girano nel cloud di Cymulate.
• XM Cyber è SaaS di default, con opzioni di hosting europeo e certificazione BSI C5; non abbiamo trovato un'edizione documentata pienamente on-premise o air-gapped.
• XBOW è erogato come SaaS su modelli di frontiera di terzi e si concentra su applicazioni web e API esposte su internet.
• Picus Security, vendor di breach and attack simulation (BAS), è SaaS-first ma documenta l'installazione on-premise e air-gapped.

Ne seguono due conclusioni oneste. Le piattaforme SaaS hanno vantaggi reali, attivazione più rapida e nessun hardware da gestire, e per le organizzazioni senza i vincoli descritti sopra possono essere la scelta giusta. E le opzioni on-premise o air-gapped non sono esclusiva di un solo fornitore: poni a ogni fornitore in lista le domande che seguono e leggi le risposte nel contratto, non nella scheda tecnica. La documentazione dei fornitori cambia: verifica ogni punto con il fornitore al momento dell'acquisto. I confronti diretti sono nella pagina alternative.

1. Elenca ogni connessione in uscita che la piattaforma effettua nel funzionamento normale, con destinazione e contenuto. Ciascuna si può disattivare?
2. Dove girano i modelli AI? Un prompt, un finding o una credenziale può raggiungere un endpoint di inferenza esterno, e di chi sono i modelli?
3. La piattaforma funziona per intero senza connessione a internet? Quali funzioni si perdono in air-gap?
4. C'è telemetria, compresi dati d'uso, crash o esito degli aggiornamenti? È disattivata per default, e cosa contiene?
5. Come viene fatta rispettare la licenza? La piattaforma continua a funzionare se non raggiunge il fornitore, e cosa succede alla scadenza?
6. Come vengono consegnati, firmati e verificati gli aggiornamenti, e si possono applicare offline nel momento che scegli tu?
7. Cosa contengono gli aggiornamenti, e vedi le note di rilascio prima di installarli?
8. Dove sono conservati finding, evidenze e credenziali di test, e puoi verificarne l'integrità senza il fornitore?
9. In quali formati si possono esportare evidenze e report perché restino utilizzabili dopo la fine del contratto?
10. Come vengono cancellati i dati a fine contratto o alla restituzione dell'hardware, e quale prova di distruzione viene fornita?
11. L'assistenza richiede mai un accesso remoto? Chi lo approva, e come viene limitato e registrato?
12. Quali subfornitori, fornitori di hosting o fornitori di AI toccano i tuoi dati, e in quali paesi (artt. 29(2) e 30(2)(b) DORA)?
13. È disponibile una distinta dei componenti software (SBOM) della piattaforma, e come vengono gestite e comunicate le vulnerabilità della piattaforma stessa?
14. Quali garanzie indipendenti coprono il fornitore e il prodotto: certificazioni e loro stato, penetration test di terza parte sulla piattaforma?
15. Come resta la piattaforma dentro il perimetro autorizzato, chi approva le azioni rischiose e come si ferma? La guida OWASP APTS per chi compra trasforma questa domanda in una valutazione strutturata.

Conserva le risposte insieme al contratto. Con DORA alimentano il registro delle informazioni e il piano di uscita; con NIS2 la valutazione del fornitore; con CMMC l'inventario degli asset e il system security plan.

Zero Hunt è un red team AI autonomo per reti e infrastrutture consegnato come appliance: un'unità desktop per le sedi più piccole o un rack 2U per enterprise e data center. Ciò che il sito dichiara sul deployment, riportato alla checklist:

• Connessioni in uscita e telemetria: l'intero stack, compresi modelli AI, archivio delle evidenze e console, gira sull'appliance e nessun dato del cliente esce. Quando è connessa, l'appliance effettua richieste in uscita solo per scaricare aggiornamenti firmati, threat intelligence pubblica e, per l'analisi gray box, il sorgente pubblicato della versione del software sotto test, funzione che si può disattivare o indirizzare a un tuo mirror interno. La segnalazione dell'esito degli aggiornamenti (ID release, stato, orario) è facoltativa.
• Modelli AI: i modelli propri ZeroHunt Apex girano sulla GPU dell'appliance, senza API AI esterne.
• Modalità air-gap: non esce nulla; gli aggiornamenti arrivano come pacchetti offline firmati e la threat intelligence come import offline. La ricognizione OSINT pubblica e il download del sorgente pubblicato lì sono disattivati, quindi quelle verifiche procedono in black box, a meno che l'appliance non raggiunga i tuoi mirror di codice interni.
• Licenza: con una licenza offline l'appliance verifica la propria scadenza in locale e non ha bisogno di contattare Zero Hunt per continuare a funzionare.
• Evidenze: ogni tentativo di attacco è registrato in un registro di evidenze firmato e concatenato con hash, conservato sull'appliance, e i report esportati sono firmati.
• Garanzie: il Trust Center riporta lo stato attuale senza filtri: l'immagine dell'appliance è sottoposta ogni anno a un pentest di una firma indipendente, la ISO/IEC 27001 è in corso e il SOC 2 Type II è pianificato. Vedi il Trust Center.

Due avvertenze oneste. L'on-premise non toglie Zero Hunt da un registro DORA: un fornitore che distribuisce aggiornamenti presta un servizio ICT ai sensi dell'articolo 3(21), quindi va comunque registrato e valutato, ma il luogo di trattamento dei dati è la tua sede. E temi come la cancellazione dei dati a fine contratto o alla restituzione dell'hardware si regolano nel contratto: chiedili per iscritto, come faresti con qualsiasi fornitore. Per verificare la compatibilità con il tuo ambiente, richiedi una demo.

• Regolamento (UE) 2022/2554 (DORA), articoli 3(21), 28, 29 e 30 (EUR-Lex)
• Direttiva (UE) 2022/2555 (NIS2), articolo 21(2)(d) e 21(3) (EUR-Lex)
• 32 CFR 170.4, definizioni di External Service Provider e Security Protection Data (eCFR)
• Dati sul deployment dei fornitori: pagine di confronto di Zero Hunt per Horizon3.ai, Pentera, Cymulate, XM Cyber, XBOW e Picus Security. Verifica le opzioni di deployment attuali con ciascun fornitore.