Cybersecurity
Infrastruttura di fiducia attraverso i confini organizzativi, senza un intermediario centrale
All’interno della vostra organizzazione Zero Trust sa rispetto a che cosa verificare: il vostro provider di identità e il vostro inventario dei dispositivi. Oltre il confine verso un fornitore, un prestatore di servizi o un’autorità di vigilanza, non lo sa. Vereign è costruita per quel confine.
Parlate con noi della fiducia tra organizzazioni
La NIS2 impone alle organizzazioni che rientrano nel suo ambito di applicazione di mettere in sicurezza la propria filiera, comprese le relazioni con i fornitori diretti e con i prestatori di servizi, e il Cyber Resilience Act stabilisce obblighi di sicurezza per i prodotti con elementi digitali lungo tutto il loro ciclo di vita. Entrambi gli obblighi attraversano i confini organizzativi, dove non esiste un fornitore di identità condiviso rispetto a cui verificare, a meno che entrambe le parti non aderiscano a una federazione. Vereign costruisce infrastruttura di fiducia attraverso i confini organizzativi, senza un intermediario centrale: le organizzazioni che verificano rispetto ai registri degli eventi di chiave le une delle altre controllano da sole identità e integrità, e lo stesso modello si estenderebbe agli agenti AI e ai dispositivi connessi che agiscono per loro. SEAL, il prodotto di consegna di Vereign, gestisce già oltre 1.000.000 consegne verificate al mese nella sanità svizzera.
Fattori normativi
Adozione di Zero Trust
Un sondaggio Gartner pubblicato nell’aprile 2024 ha rilevato che il 63% delle organizzazioni aveva implementato in tutto o in parte una strategia Zero Trust, per lo più con una copertura pari o inferiore alla metà del proprio ambiente. Per la collaborazione attraverso i confini aziendali, il NIST SP 800-207 propone la federazione.
63% ha implementato in tutto o in parte (Gartner, 2024)
Cyber Resilience Act
I fabbricanti di prodotti con elementi digitali devono rispettare requisiti di sicurezza, gestire le vulnerabilità per tutto il periodo di supporto del prodotto e segnalare le vulnerabilità attivamente sfruttate. Importatori e distributori devono verificare che il fabbricante abbia adempiuto a questi obblighi, così le evidenze sulla sicurezza di un prodotto passano da un’organizzazione all’altra.
Gli obblighi di segnalazione si applicano dall’11 settembre 2026
Sicurezza della filiera secondo NIS2
L’articolo 21(2)(d) richiede misure di sicurezza della filiera, compresa la sicurezza delle relazioni con i fornitori diretti e i prestatori di servizi. I CISO devono stabilire fiducia in tutto il proprio ecosistema di fornitori, oltre il proprio perimetro.
Articolo 21(2)(d): sicurezza della filiera
La soluzione in sintesi
La fiducia tra organizzazioni per la cybersecurity significa che ciò che attraversa un confine tra organizzazioni porta con sé una prova crittografica di origine, integrità e autorizzazione: le controparti che verificano rispetto ai registri degli eventi di chiave possono controllarla da sole. I messaggi sono il caso in cui questo funziona oggi, in produzione nella sanità svizzera. Lo scambio di dati strutturati, le chiamate API, gli agenti AI e le attestazioni di dispositivo sono casi a cui lo stesso modello si estenderebbe. La comunicazione è solo uno dei casi d’uso: la capacità principale è la fiducia dove le organizzazioni si incontrano.
Scoprite come funziona →OSSTMM misura la sicurezza operativa in modo quantitativo, come controlli di sicurezza, visibilità, fiducia ed esposizioni. Ma tutti gli altri framework di test si fermano al perimetro organizzativo. La fiducia tra organizzazioni, oltre quel confine, è una lacuna che nessun penetration test può misurare. La fiducia in sé è qualcosa che nessun altro framework riesce a misurare. DKMS invece la rende verificabile e testabile: per la prima volta i team di sicurezza possono davvero convalidare la fiducia tra organizzazioni.
Dove si estenderebbe: l’identità non umana
I team di sicurezza usano sempre più spesso il termine identità non umana (NHI) per servizi, workload, agenti AI e dispositivi. La nostra definizione: Un’identità non umana è l’identità di un attore software o hardware: un identificatore stabile, legato all’autorità che l’attore detiene in quel momento e alla persona che ne risponde. Le sue credenziali provano quell’identità; non sono l’identità.
Responsabilità per costruzione
In DKMS una NHI sarebbe modellata come un identificatore delegato il cui delegante è l’organizzazione che ne risponde. Le sue rotazioni richiedono l’ancoraggio di quell’organizzazione e la sua autorità è espressa come credenziali che risalgono all’organizzazione. Il protocollo sottostante non distingue tra controller umani e non umani.
Tra organizzazioni
All’interno di un singolo dominio di fiducia i sistemi di identità dei workload come SPIFFE funzionano bene. Le proprietà di DKMS contano quando una NHI agisce per un’organizzazione e un’altra organizzazione deve verificarla: identificatori autocertificanti, pre-rotazione e catene di delega che un verificatore può controllare senza rivolgersi all’emittente.
VERIMESH Agent (roadmap)
VERIMESH Agent, un’edizione in roadmap, darebbe agli agenti AI e ai sistemi automatizzati un’identità di servizio zero-trust su questo modello, e un’organizzazione ricevente sarebbe così in grado di verificare per quale organizzazione agisce un agente ed entro quale ambito. Non è ancora disponibile e oggi non esiste alcuna API pubblica per agenti.
Progetti di integrazione per l’identità non umana
Le organizzazioni che hanno bisogno di un’identità verificabile per agenti IA, servizi automatizzati o dispositivi che operano oltre i confini organizzativi possono definirne l’ambito con Vereign come progetto di integrazione. Il progetto modellerebbe ogni agente, servizio o dispositivo come un identificatore delegato (DKMS, basato su KERI) le cui credenziali sono emesse, e possono essere revocate, dall’organizzazione che ne risponde. VERIMESH Agent e VERIMESH Edge sono edizioni in roadmap, non ancora disponibili, e oggi non esiste alcuna API pubblica per agenti. Un progetto coprirebbe ciò di cui l’organizzazione ha bisogno: identificatori delegati per i suoi agenti, servizi o dispositivi, le credenziali che stabiliscono che cosa ciascuno può fare, la revoca di tali credenziali da parte dell’organizzazione in quanto emittente e la verifica da parte delle controparti in altre organizzazioni. Costruirebbe o configurerebbe quel percorso di identificatori delegati per l’organizzazione; non è una funzione dei deployment di produzione attuali di Vereign. Una collaborazione inizia con un confronto sull’architettura, seguito dalla definizione dell’ambito e poi dal progetto vero e proprio.
Richiedete una revisione tecnica dell’architetturaArchitettura pronta per il post-quantum
Il quantum computing non deve ancora arrivare per costituire una minaccia. I dati raccolti oggi da canali cifrati potranno essere decifrati quando la capacità quantistica sarà matura. KERI, la base crittografica dell’infrastruttura di fiducia di Vereign, è pronta a livello architetturale per la transizione post-quantum: non perché usi già algoritmi post-quantistici, ma perché la sua progettazione rende la transizione fluida.
Raccogliere oggi, decifrare domani
Gli avversari raccolgono già oggi dati cifrati per decifrarli in futuro con i computer quantistici. NSA, CISA e NIST avvertono insieme che i dati a lunga conservazione (dati sanitari, transazioni finanziarie, documenti legali) hanno finestre di esposizione misurabili in decenni. La minaccia non è futura: la raccolta dei dati è già in corso.
Standard NIST finalizzati
I FIPS 203, 204 e 205 sono stati finalizzati nell’agosto 2024 e hanno stabilito ML-KEM, ML-DSA e SLH-DSA come standard crittografici post-quantum. La finestra di migrazione è aperta. Chi aspetta l’arrivo dei computer quantistici si troverà anni indietro rispetto a chi prepara oggi la propria infrastruttura crittografica.
Cripto-agilità di KERI
Il meccanismo di pre-rotazione di KERI e la sua indipendenza dagli algoritmi consentono di ruotare le chiavi verso algoritmi post-quantum senza interrompere la catena di fiducia. A differenza dei sistemi basati su PKI/CA, vincolati a ipotesi crittografiche specifiche, KERI permette una migrazione incrementale: ogni organizzazione procede al proprio ritmo, senza rifare l’infrastruttura.
Collaudato su larga scala
La sanità è infrastruttura critica. Verimesh è in produzione nella sanità svizzera: il gateway e la CA centrale presso HIN sono in piena produzione nella maggior parte della rete HIN, e la migrazione è nella fase conclusiva, con il completamento previsto entro la fine del primo trimestre 2027. L’architettura non è specifica della sanità: lo stesso modello di fiducia si applicherebbe alle attestazioni di sicurezza scambiate tra organizzazioni.
1.000.000+
consegne verificate al mese, in tutta la sanità svizzera
Infrastruttura in produzione nella sanità svizzera. Verimesh è progettato in modo che le controparti che verificano rispetto ai registri degli eventi di chiave si controllino a vicenda senza un’autorità di fiducia centrale. Dove una controparte convalida solo X.509, come oggi presso HIN, un’autorità di certificazione ponte collega le due parti.
Architettura di riferimento
Cliccate per ingrandire
Come collaborare
Lavorate direttamente con Vereign
Per le organizzazioni che vogliono definire e realizzare l’infrastruttura di fiducia con il team di ingegneria e consulenza di Vereign: ideale per i pionieri e per chi ha competenze tecniche interne.
Scoprite i servizi →Lavorate tramite un partner
Per le organizzazioni che preferiscono affidarsi a una consulenza già formata sull’infrastruttura di fiducia di Vereign: i partner uniscono competenza di settore e capacità di implementazione.
Scoprite il programma partner →Infrastruttura di fiducia per le organizzazioni con cui lavorate, senza un intermediario centrale
Che siate un CISO che estende un programma Zero Trust a fornitori e partner o una società di consulenza in sicurezza che apre una nuova area di attività, definiamo insieme come la fiducia tra organizzazioni si inserisce nel vostro stack attuale.