Perché sto costruendo Shorium

Di solito qui non scrivo delle mie aziende.

Questa volta ho un buon motivo per fare un’eccezione.

Negli ultimi mesi gran parte del mio lavoro è andata in Shorium, un’azienda di cybersecurity che sto costruendo come co-founder e CTO.

È un posto curioso in cui ritrovarsi, dopo venticinque anni passati tra product design, tecnologia e interazione uomo-macchina.

Ma più ci lavoro, più mi rendo conto che i problemi che cerchiamo di risolvere sono strettamente legati a quelli che mi hanno interessato per tutta la carriera.

Solo che stavolta di mezzo ci sono la crittografia, i dispositivi connessi e una domanda piuttosto scomoda sul futuro della fiducia digitale.

Un prodotto non deve rompersi per diventare insicuro

Pensate a un prodotto connesso.

Può essere un terminale di pagamento, un sensore industriale, un dispositivo medico o un’auto.

Quando interagiamo con questi prodotti, vediamo quello che fanno. Raramente vediamo i sistemi che permettono loro di funzionare in sicurezza. Dietro l’interfaccia ci sono hardware, firmware, software, certificati, chiavi crittografiche, identità, fornitori e meccanismi di aggiornamento.

Tutti questi componenti dipendono l’uno dall’altro.

E molte di queste dipendenze si basano su ipotesi fatte quando il prodotto è stato progettato.

Ora immaginate quel prodotto in funzione per quindici anni.

In quel periodo i certificati scadono, gli algoritmi diventano obsoleti, i fornitori cambiano, si scoprono vulnerabilità e le normative evolvono. Il prodotto può continuare a funzionare perfettamente. Si accende. Si connette. Fa il suo lavoro. Dal punto di vista dell’utente non è cambiato nulla.

Ma sotto, le condizioni che lo rendevano affidabile potrebbero non esistere più.

Un sistema che funziona non è necessariamente un sistema affidabile.

Ho passato buona parte della mia carriera a progettare prodotti che devono restare comprensibili e usabili mentre diventano più complessi.

Una cosa che ho imparato è che la complessità non sparisce solo perché smettiamo di mostrarla. Nella sicurezza, quella complessità nascosta può diventare un problema serio.

Soprattutto quando nessuno sa spiegare con chiarezza cosa dipende da cosa.

Il quantum computing non è il vero punto di partenza

Ogni volta che si parla di crittografia post-quantum, la conversazione si sposta subito sui computer quantistici.

• Quando saranno abbastanza potenti da violare la crittografia di oggi?
• Cinque anni? Dieci? Venti?

La domanda mi interessa, ma da un punto di vista ingegneristico non è da lì che partirei. Sappiamo già che i sistemi di crittografia a chiave pubblica più diffusi dovranno migrare.

Il NIST ha pubblicato i primi standard di crittografia post-quantum nel 2024. L’Unione Europea ha definito una roadmap coordinata, con il 2030 come traguardo importante per i casi d’uso ad alto rischio.

La transizione è iniziata, indipendentemente da quando sarà disponibile un computer quantistico abbastanza potente.

E la difficoltà non sta semplicemente nello scegliere un nuovo algoritmo.

Immaginate di dover sostituire la crittografia usata da un dispositivo industriale già distribuito in migliaia di installazioni.

• Il suo firmware potrebbe dipendere da un particolare meccanismo di firma.
• Il suo hardware potrebbe non supportare il nuovo algoritmo.
• La sua identità potrebbe dipendere da certificati emessi tramite un’infrastruttura esistente.
• Il suo processo di aggiornamento potrebbe coinvolgere diversi fornitori.

Cambiare un componente può avere effetti sull’intera catena.

Non si può affrontare una migrazione del genere come se si stesse aggiornando un’applicazione sul proprio laptop.

E di certo non si può dare per scontato che ogni dispositivo possa essere richiamato, sostituito o messo offline. Stiamo cercando di cambiare meccanismi di sicurezza fondamentali dentro sistemi che devono continuare a funzionare.

Continuità crittografica

È qui che entra in gioco Shorium.

Il nome viene dall’algoritmo di Shor, che ha dimostrato come un computer quantistico sufficientemente capace potrebbe violare i sistemi di crittografia a chiave pubblica più diffusi.

C’è qualcosa che mi piace nel dare a un’azienda il nome dell’algoritmo che ha messo a nudo il problema.

Perché non stiamo costruendo un’azienda sull’idea che la crittografia non si romperà mai. La stiamo costruendo sull’idea che la fiducia deve sopravvivere al cambiamento.

Il focus di Shorium è la continuità crittografica.

In pratica, stiamo sviluppando una piattaforma pensata per scoprire, modellare e gestire le relazioni di fiducia crittografica all’interno dei prodotti connessi.

Il concetto centrale è quello che chiamiamo Trust Twin.

Pensatelo come un modello vivo delle dipendenze crittografiche su cui si regge un prodotto.

Non solo un inventario di certificati o algoritmi.

Una rappresentazione di come questi elementi sono collegati tra loro.

• Quale chiave firma quale firmware?
• Quale certificato stabilisce quale identità?
• Quali componenti dipendono da un particolare meccanismo crittografico?
• Cosa succede quando un algoritmo viene deprecato?
• Cosa cambia quando un fornitore sostituisce un componente?
• E come possiamo dimostrare che un prodotto resta affidabile dopo questi cambiamenti?

Sono domande a cui è difficile rispondere quando le informazioni sono sparse tra team di ingegneria, sistemi di produzione, fornitori e documentazione.

Il nostro approccio è organizzato attorno a quattro capacità: Observe, Connect, Simulate e Orchestrate.

• Prima, scoprire i segnali crittografici rilevanti.
• Poi, ricostruire le relazioni tra di loro.
• Usare quelle relazioni per valutare il possibile impatto dei cambiamenti.
• E infine, aiutare i team a pianificare e coordinare la transizione, conservando le prove di ciò che è successo.

L’obiettivo non è produrre l’ennesima dashboard piena di indicatori verdi.

È fare della continuità crittografica qualcosa che gli ingegneri possano capire, valutare e dimostrare.

C’è una distinzione importante da fare: questa è l’architettura e la direzione di prodotto verso cui stiamo lavorando. Siamo un’azienda in fase iniziale, e non voglio confondere una visione tecnica con un prodotto finito e validato.

Ma il problema è reale, e la direzione è chiara.

Perché un product designer lavora sulla crittografia

Non sono un crittografo.

E non ho intenzione di fingere il contrario.

In Shorium ci sono persone che hanno passato anni a fare ricerca crittografica. Il mio lavoro è un altro. Ho passato circa venticinque anni a progettare prodotti digitali, interfacce e sistemi complessi.

Ho lavorato in settori diversi, dai servizi digitali al software enterprise fino alla cybersecurity embedded. Per tre anni sono stato Design Lead in Exein, lavorando su prodotti in un contesto in cui il rapporto tra hardware, software e sicurezza è particolarmente importante.

E in tutti questi anni sono sempre tornato allo stesso problema.

La tecnologia diventa utile quando le persone capiscono cosa ci stanno facendo.

Può sembrare ovvio.

In pratica, non lo è.

Ho visto prodotti tecnicamente sofisticati diventare inutilmente difficili da gestire, perché la loro architettura aveva senso per gli ingegneri che li avevano costruiti ma non per chi doveva usarli.

Ho visto anche il contrario: interfacce disegnate per sembrare semplici che nascondono così tanta complessità da togliere agli utenti la possibilità di capire cosa sta succedendo davvero.

Nessuno dei due è un gran design.

E nella cybersecurity, entrambi possono diventare pericolosi.

Immaginate di essere responsabili della sicurezza di diverse migliaia di dispositivi connessi.

Un algoritmo crittografico deve essere sostituito.

Avete una lista di prodotti coinvolti, diversi team di ingegneria, fornitori, requisiti di compliance e una scadenza. Non vi serve una bella interfaccia che vi dica che qualcosa non va.

Vi serve capire le conseguenze delle vostre decisioni.

• Quali dispositivi sono coinvolti?
• Cosa si può cambiare?
• Cosa no?
• Cosa succede se migrate una dipendenza prima di un’altra?
• Potete dimostrare che il sistema resta sicuro anche dopo?
• È qui che vedo il legame tra il mio percorso e quello che stiamo costruendo.

La mia responsabilità come CTO non è soltanto assicurarmi che scegliamo le tecnologie giuste.

È contribuire a costruire un’architettura in cui correttezza scientifica, vincoli di ingegneria e decisioni umane possano convivere.

• La crittografia deve essere solida.
• Il software deve essere affidabile.
• E chi lo gestisce deve capire abbastanza del sistema da prendere decisioni informate.

Non è qualcosa che si risolve aggiungendo una dashboard più bella alla fine dello sviluppo.

Deve influenzare l’architettura fin dall’inizio.

Rendere comprensibile la complessità non significa nasconderla

C’è un principio che seguo da anni nel product design.

Non far sembrare semplice una cosa togliendo le informazioni di cui le persone hanno bisogno.

Rendila comprensibile.

Credo che questa distinzione sia particolarmente rilevante oggi, mentre sempre più prodotti software introducono automazione e AI in flussi di lavoro sempre più complessi.

Siamo diventati molto bravi a far produrre risposte ai sistemi.

Non sempre siamo altrettanto bravi ad aiutare le persone a capire da dove vengono quelle risposte, da quali ipotesi dipendono o cosa succede quando quelle ipotesi cambiano. In un’applicazione consumer, questo può creare un’esperienza frustrante. In un sistema critico per la sicurezza, le conseguenze possono essere molto più serie.

In Shorium, questo influenza il modo in cui penso al Trust Twin.

Un modello di dipendenze crittografiche è utile solo se aiuta qualcuno a ragionare sul sistema.

Non basta scoprire una relazione.

Dobbiamo capirne l’origine, il contesto e quali prove la sostengono.

Se una dipendenza cambia, il sistema dovrebbe aiutare a spiegarne le conseguenze.

Se viene data una raccomandazione, chi deve agire di conseguenza ha bisogno di informazioni sufficienti per valutarla. E quando viene presa una decisione, deve esserci un modo per ricostruire cosa è successo. Quest’ultima parte conta più di quanto possa sembrare.

Nella cybersecurity, saper spiegare una decisione sei mesi dopo può essere importante quanto averla presa correttamente all’inizio.

Ecco perché trovo così interessante l’intersezione tra product design, architettura software e sicurezza.

Il buon design non è una decorazione applicata all’ingegneria.

È parte del modo in cui un sistema comunica il proprio comportamento.

E a volte è ciò che fa la differenza tra avere un’informazione ed essere in grado di agire di conseguenza.

Le persone dietro Shorium

Uno dei motivi per cui ho deciso di accettare questa sfida è il team.

Danilo Bontà, il nostro Founder & CEO, ha passato più di quindici anni tra cybersecurity e tecnologia internazionale. La sua esperienza comprende la costruzione dell’ecosistema globale di partner di Moodle, il lavoro nell’area Asia-Pacifico e la collaborazione con istituzioni tra cui la NATO e organizzazioni governative.

Dan e io abbiamo già lavorato insieme in Exein.

Conoscevamo già il modo in cui l’altro affronta i problemi, e condividevamo l’interesse per quello che succede quando la cybersecurity deve funzionare dentro prodotti reali e non in architetture teoriche.

Dariia Porechna, Co-founder & Chief Scientific Officer, viene da un percorso molto diverso.

È una crittografa post-quantum che ha passato sei anni in Wolfram Research, lavorando con Stephen Wolfram e sviluppando funzionalità crittografiche per il Wolfram Language. È anche co-autrice di SILMARILS, una costruzione di firma digitale post-quantum. Dariia porta le basi scientifiche di cui un prodotto come Shorium ha bisogno.

Il team più ampio comprende anche ricercatori in crittografia, ingegneri e persone responsabili di trasformare quella ricerca in qualcosa che possiamo costruire e gestire.

Mi piace lavorare in un ambiente così.

Le persone che affrontano lo stesso problema con modelli mentali diversi tendono a fare domande diverse.

Un crittografo può chiedersi se una costruzione è matematicamente solida.

Un ingegnere può chiedersi se è possibile implementarla in modo affidabile entro i vincoli di un particolare dispositivo.

Un product designer può chiedersi se la persona responsabile di quel dispositivo è in grado di capire cosa deve succedere dopo.

Tutte e tre le domande contano.

E come CTO, parte della mia responsabilità è fare in modo che non diventino tre conversazioni separate.

Perché è anche un problema brownfield

C’è un altro motivo per cui scrivo qui di Shorium.

Alla maggior parte dell’industria tecnologica piace parlare di cose nuove.

Nuove architetture. Nuovi framework. Nuove infrastrutture. Nuovi prodotti.

Tendiamo a descrivere il progresso tecnologico come se tutto cominciasse da un ambiente pulito e da un sistema progettato alla perfezione.

Succede di rado. Le organizzazioni reali hanno prodotti esistenti. Infrastrutture esistenti. Fornitori, processi, certificazioni e decisioni tecniche esistenti, prese anni fa.

Alcune di quelle decisioni erano perfettamente ragionevoli quando sono state prese. Altre erano compromessi. E alcune sono diventate difficili da cambiare perché ormai troppe cose dipendono da loro.

Questa è la realtà dell’ingegneria brownfield. Non puoi riprogettare tutto da zero. Erediti un sistema, ne capisci i vincoli e trovi un modo per farlo evolvere senza distruggere ciò che già funziona.

La transizione post-quantum è un esempio particolarmente interessante. Non sostituiremo l’infrastruttura crittografica mondiale dall’oggi al domani. Dovremo migrarla mentre è in funzione. Alcuni prodotti saranno facili da aggiornare.

Altri richiederanno modifiche a firmware, hardware, processi di produzione o intere catene di fiducia. Alcuni resteranno in campo molto tempo dopo che chi li ha progettati sarà passato ad altro.

E per tutto il processo, i produttori dovranno comunque garantire sicurezza, disponibilità e compliance. Per me, questo è molto più interessante della solita discussione su quando i computer quantistici saranno abbastanza potenti da violare la crittografia attuale.

Il vero lavoro di ingegneria comincia molto prima che accada.

E si svolge dentro sistemi che esistono già.

Diventare CTO non ha significato lasciare il design

C’è un’altra cosa di cui voglio parlare, perché riguarda il modo in cui vedo il mio ruolo.

Per gran parte della mia vita professionale sono stato identificato come designer.

Product Designer. UX Designer. Design Lead.

Quei titoli sono cambiati nel tempo, ma il lavoro di fondo ha sempre riguardato la comprensione dei sistemi, dei loro vincoli e delle persone che interagiscono con loro.

Non ho mai pensato che il design si limitasse alle interfacce.

Un’interfaccia è semplicemente la parte di un sistema che diventa visibile.

Dietro ci sono decisioni su architettura, informazione, comportamento, prestazioni, affidabilità e sul modo in cui i diversi componenti interagiscono.

Non si può progettare una buona esperienza senza capire almeno una parte di quelle decisioni.

E più il prodotto diventa complesso, meno serve trattare design e ingegneria come discipline completamente separate.

Passare al ruolo di CTO in Shorium non ha cambiato questa prospettiva.

L’ha estesa.

Oggi passo molto più tempo a pensare all’architettura, alle scelte tecnologiche, ai processi di ingegneria e a come costruire una piattaforma che possa evolvere senza accumulare complessità inutile.

Le prestazioni contano, per me. Anche la manutenibilità. Anche la possibilità di capire perché un sistema si comporta in un certo modo.

Le interfacce continuano a starmi a cuore, ovviamente.

Ma mi interessa altrettanto quello che succede prima che qualcosa arrivi sullo schermo.

• Come vengono raccolti i dati.
• Come vengono rappresentate le relazioni.
• Come comunicano i sistemi.
• Come vengono conservate le prove.
• Come evitiamo di creare dipendenze che più avanti diventeranno problemi.
• E come costruiamo qualcosa che resti comprensibile mentre cresce.

Non lo vedo come un allontanarmi dal design.

Lo vedo come applicare lo stesso modo di pensare a un livello diverso del sistema.

Forse è questa la parte più interessante di questa transizione, per me.

Dopo venticinque anni, sto ancora lavorando sul rapporto tra le persone e la tecnologia.

Solo molto più in basso nello stack.

Da qui in avanti

Shorium è ancora all’inizio.

Stiamo costruendo l’azienda a Torino, sviluppando la piattaforma e affrontando le sfide scientifiche e ingegneristiche che comporta.

Ci sono cose che sappiamo. Ci sono cose che dobbiamo ancora validare. E ci aspettano parecchie decisioni difficili.

Non mi interessa granché annunciare capacità prima che esistano, o fingere che costruire un prodotto tecnicamente ambizioso sia semplice.

Non lo è.

Soprattutto quando si lavora all’incrocio tra crittografia, sistemi embedded, architettura software e requisiti normativi.

Ma credo che il problema di fondo valga la pena di essere risolto.

Per anni abbiamo trattato la sicurezza come qualcosa che si può valutare in un determinato momento.

• Un prodotto supera un audit.
• Un certificato è valido.
• Un algoritmo è considerato sicuro.
• Un dispositivo rispetta uno standard.
• E poi il tempo passa.
• Il prodotto cambia.
• Le sue dipendenze cambiano.
• Il mondo intorno a lui cambia.

La domanda è se possiamo costruire sistemi che capiscano quei cambiamenti abbastanza bene da mantenere la fiducia per tutto il loro ciclo di vita.

È quello che stiamo cercando di fare in Shorium.

Ed è per questo che ho deciso di dedicarci la prossima parte della mia carriera.

Un prodotto può continuare a funzionare molto tempo dopo che le ipotesi che lo rendevano affidabile sono cambiate.

Credo che dovremmo poter sapere quando succede.

Preferibilmente prima che qualcosa si rompa.

Shorium — Cybersecurity for Continuity

Pubblicato originariamente su Brownfield AI.