VicOne ha identificato un set iniziale di 28 risultanze zero-day in meno di due giorni attraverso ricerca assistita dall'AI su software e strumenti che supportano l'ecosistema Physical AI. Secondo l'azienda, le risultanze includono progetti sviluppati o mantenuti da Google, NVIDIA e Meta, tra gli altri.
Sulla base della convalida iniziale, VicOne ha classificato tutte le 28 risultanze come vulnerabilità zero-day. L'azienda ha avvertito che il conteggio potrebbe cambiare dopo la revisione da parte dei fornitori e delle autorità per le vulnerabilità, e che alcune risultanze non hanno ancora numeri di tracciamento CVE. Una zero-day è una debolezza precedentemente sconosciuta senza una correzione disponibile; VicOne ha affermato che una scoperta più rapida non significa necessariamente che si sia verificato un attacco, ma i team devono comunque determinare se utilizzano il software interessato e a cosa un attaccante potrebbe accedere o cosa potrebbe modificare.
Molti degli strumenti interessati sono usati per addestrare, simulare, testare e far funzionare i robot. VicOne ha affermato che debolezze in essi potrebbero influenzare i modelli che i team costruiscono, i risultati dei test di cui si fidano e le istruzioni inviate ai robot. Ciò crea due esigenze per i team di robotica: rispondere mentre l'AI aiuta a scoprire le debolezze più rapidamente e valutare in che modo ciascuna risultanza potrebbe influire sulla sicurezza e sulle operazioni dei robot.
VicOne ha affermato che l'AI può accelerare parti della scoperta di vulnerabilità, inclusi l'esame del codice, il tracciamento delle comunicazioni di sistema e il test per stabilire se una debolezza sospetta possa essere sfruttata. Gli attaccanti potrebbero usare capacità simili. Quando una debolezza è una zero-day, una scoperta più rapida può lasciare ai team poco tempo per rispondere.
Le risultanze coprono tre fasi del ciclo di vita della robotica: sviluppo e addestramento, simulazione e convalida, e distribuzione e runtime. VicOne ha descritto scenari potenziali per ciascuna fase, osservando tuttavia che si tratta di conseguenze potenziali e non di esiti dimostrati per ogni risultanza. Gli effetti reali dipendono dall'accesso dell'attaccante, dal design del sistema e dal fatto che altre salvaguardie impediscano alle modifiche di raggiungere il comportamento fisico.
Nello sviluppo e nell'addestramento, un team potrebbe scaricare un modello preaddestrato da adattare al proprio robot. Il caricamento di un file malevolo potrebbe dare a un attaccante accesso al sistema di addestramento, consentendo modifiche ai dati di addestramento o al modello stesso. Un modello manipolato potrebbe comportarsi normalmente durante i test di routine ma rispondere in modo errato a un particolare oggetto, scena o comando dopo la distribuzione. Il rischio può entrare attraverso uno strumento di cui il team si fida prima che qualcuno attacchi direttamente il robot.
Nella simulazione e nella convalida, l'importazione di una scena o di un modello di robot compromesso potrebbe dare a un attaccante accesso all'ambiente di simulazione. Con un controllo sufficiente, l'attaccante potrebbe alterare letture simulate dei sensori, condizioni fisiche o risultati dei test. Un robot potrebbe quindi sembrare superare test che avrebbero dovuto esporre un comportamento non sicuro, inducendo un team ad approvarlo per l'uso nel mondo reale sulla base di prove fuorvianti.
Nella distribuzione e nel runtime, un attaccante potrebbe sfruttare debolezze per modificare file che influenzano la pianificazione del movimento o inviare dati di mappa malevoli che mandano in crash il display di monitoraggio di un operatore. Compromettere un computer per il funzionamento remoto potrebbe anche mettere a rischio le istruzioni inviate a un robot. A seconda del sistema e delle sue salvaguardie, ha affermato VicOne, queste debolezze potrebbero alterare il movimento del robot o lasciare gli operatori incapaci di vedere cosa sta succedendo e di rispondere prontamente.
VicOne ha anche descritto una dimostrazione separata in cui i suoi ricercatori hanno sfruttato una vulnerabilità per impedire il funzionamento del comando di arresto remoto di un robot. Il caso, secondo l'azienda, mostra perché i team devono verificare se le salvaguardie restano efficaci quando il software che le supporta è compromesso.
L'azienda ha affermato che una patch pubblicata deve comunque essere dimostrata sicura. Anche dopo che un manutentore del software rilascia una patch, i team di robotica devono identificare i sistemi interessati, verificare la compatibilità e controllare che l'aggiornamento preservi il comportamento previsto. Un test precedente andato a buon fine resta una prova utile, ma una debolezza scoperta di recente può rivelare condizioni che il test non ha mai esaminato.
VicOne ha suggerito tre domande per i team che rispondono alle risultanze: Dove utilizziamo il software interessato, inclusi computer per l'addestramento, ambienti di simulazione e robot distribuiti? Cosa potrebbe cambiare la debolezza, che si tratti di modelli, risultati dei test, visibilità per gli operatori o comportamento del robot? Come verifichiamo la protezione, confermando che la correzione affronta la debolezza e che il sistema aggiornato funziona ancora come previsto? Quando l'aggiornamento immediato non è praticabile, i team potrebbero aver bisogno di salvaguardie temporanee, come limitare l'accesso a un servizio interessato mentre viene preparata una correzione convalidata.
Man mano che i dettagli delle 28 risultanze diventano disponibili attraverso la divulgazione coordinata, VicOne ha affermato che il passo successivo per i produttori di robotica è collegare ciascuna risultanza al suo potenziale effetto su sviluppo, distribuzione e comportamento del robot. Tale lavoro richiede anche di comprendere in che modo le minacce potrebbero influire sul comportamento del robot e come proteggere i sistemi già in funzione. VicOne ha affermato che la sua offerta Radeis aiuta i team a identificare potenziali vulnerabilità zero-day, valutare la sicurezza dei modelli AI e dei sistemi e usare la simulazione per valutare in che modo i rischi potrebbero influire sul comportamento del robot prima della distribuzione, mentre la sua offerta Rthena supporta il rilevamento e la risposta alle minacce entro politiche approvate durante il funzionamento.
VicOne ha affermato che una scoperta più rapida delle vulnerabilità conta quando i team possono trasformare le risultanze in azione: identificare ciò che richiede attenzione, verificare che le salvaguardie tengano ancora e confermare che una correzione non introduca nuovi rischi.
Fonti: The Robot Report.