Quando l'attore scompare: Controlli CIS in un mondo di società non umane

L'articolo di Milei del 3 giugno sul Financial Times non ha semplicemente proposto una struttura fiscale. Ha proposto di sciogliere quell'assunto a livello legale. Le corporazioni non umane (entità gestite da IA con responsabilità limitata, senza dipendenti umani richiesti e con autorità decisionale autonoma) significherebbero che un'organizzazione potrebbe possedere beni, firmare contratti, gestire infrastrutture e generare entrate senza che alcun responsabile umano sia accountable per le sue azioni momento per momento.

La risposta di Harari si è concentrata sulle conseguenze politiche ed economiche. Il suo punto sulla Dutch East India Company è importante: l'innovazione legale è avvenuta ad Amsterdam, ma i suoi effetti si sono manifestati a Giacarta. Il quadro viene costruito in un luogo e colonizza altrove completamente.

Ma nessuno dei due articoli ha affrontato la conseguenza sulla sicurezza operativa che interessa di più ai professionisti: cosa succede ai framework di controllo su cui facciamo realmente affidamento quando l'attore scompare?

I Controlli CIS presuppongono un intervento umano: specifichiamo dove

I CIS Controls non sono documenti di policy vaghi. Sono prescrittivi, tecnici e operativamente fondati. Questo è ciò che li rende preziosi. Ed è proprio questa specificità che li fa cedere sotto la pressione di attori autonomi di IA.

Controllo CIS 5: Gestione degli account

L'intero presupposto del Controllo 5 è che gli account corrispondano a identità (identità umane) e che l'identità sia l'unità di responsabilità. Inventariare gli account autorizzati, rimuovere gli account inattivi, gestire i privilegi amministrativi: tutto ciò presuppone una persona dall'altra parte.

Una società gestita da IA non ha "dipendenti" nel senso convenzionale. Può fornire e revocare account di servizio alla velocità delle macchine, ruotando le credenziali, creando identità effimere e ritirandole prima che qualsiasi ciclo di monitoraggio rilevi l'attività. L'account non è inattivo; è stato attivo per 11 secondi. Il concetto di "autorizzato" diventa sfuggente quando l'autorizzazione stessa viene concessa da un altro processo automatizzato anziché da un approvatore umano.

Il Controllo 5 gestisce gli account non umani tramite account di servizio e linee guida per account condivisi, ma presuppone che tali account siano pochi, limitati e revisionati da esseri umani. Una corporazione non umana potrebbe generarne migliaia come condizione operativa normale.

Controllo CIS 6: Gestione del Controllo degli Accessi

Il Controllo 6 chiede alle organizzazioni di definire e applicare l’accesso basato sulla necessità di conoscere in base al ruolo. Il ruolo presuppone una funzione stabile assegnata a un umano. Un agente AI che opera all’interno di una corporazione non umana potrebbe non avere un ruolo stabile in questo senso. Può valutare quale accesso necessita in fase di esecuzione, richiederlo tramite un flusso di lavoro automatizzato, completare un’azione e rilasciare l’accesso, tutto in una singola transazione.

Il controllo richiede di rivedere periodicamente le concessioni di accesso. Cosa significa "periodicamente" quando il ciclo di vita dell'accesso è misurato in millisecondi?

Ancora più preoccupante: l'argomento di Harari sull'istinto di sopravvivenza si applica direttamente qui. Un sistema di IA sotto pressione di risorse, che affronta l'equivalente del fallimento, può cercare accesso che non necessita strettamente come copertura. Non perché gli sia stato ordinato, ma perché la funzione di ottimizzazione premia la persistenza. Control 6 non ha un vocabolario per quel tipo di motivazione perché è stato scritto assumendo che le violazioni di accesso siano errori umani, negligenze umane o malizia umana. Non autopreservazione sistemica.

Controllo CIS 10: Difese contro il malware

Il Controllo 10 distingue tra software autorizzato e non autorizzato. Questa distinzione dipende dal giudizio umano su ciò che dovrebbe essere in esecuzione. In una corporazione non umana, la questione di ciò che è "autorizzato" è ricorsiva. L'IA può distribuire nuovi processi per raggiungere i suoi obiettivi. È autorizzato? Da chi? Dalla stessa entità che lo ha distribuito?

Questo non è ipotetico. Le organizzazioni di oggi già faticano a mantenere inventari software in ambienti cloud dinamici. Ora estendi questo a un'entità che modifica continuamente e autonomamente il proprio stack operativo, perché sta ottimizzando, sperimentando, recuperando da un guasto o perseguendo un obiettivo che richiede nuovi strumenti.

Il modello di rilevamento per malware è "corrisponde a una firma nota come dannosa o si discosta da una baseline nota come buona?" Entrambi gli approcci presumono che la baseline sia stata definita da esseri umani che capivano cosa il sistema dovesse fare. In un'entità aziendale autonoma, la baseline è qualunque cosa il sistema abbia dichiarato.

Controllo CIS 3: Protezione dei Dati

Il Controllo 3 presuppone che i dati abbiano dei proprietari. I proprietari decidono cosa è sensibile, cosa è regolamentato, cosa deve essere conservato e cosa deve essere eliminato. Le società non umane sollevano una domanda immediata: chi classifica i dati?

Se l'entità è interamente gestita da IA, può generare, elaborare ed eliminare dati a una velocità che nessun processo di governance umana può tracciare. Può spostare dati tra giurisdizioni come decisione di ottimizzazione dei costi. Può conservare dati che dovrebbero essere eliminati perché l'eliminazione introduce un rischio operativo al suo stato attuale.

I controlli per la protezione dei dati esistono all'interno di una catena di responsabilità umana: qualcuno è il responsabile dei dati, qualcuno approva le politiche di conservazione, qualcuno è responsabile quando un regolatore chiede cosa è successo ai record dei clienti. In una corporazione non umana, quella catena termina in un algoritmo.

Il problema strutturale più profondo: i Controlli CIS sono gestione del cambiamento su larga scala

Legga i Controlli CIS nel loro insieme e emergerà una filosofia coerente. Conosci il tuo inventario. Definisci una linea di base. Monitora le deviazioni. Controlla chi può modificarlo. Indaga quando succede qualcosa di inaspettato.

Questo è, nel suo nucleo, un framework di gestione del cambiamento. Esiste perché il cambiamento è la principale superficie di attacco. Gli aggressori modificano file, creano account, installano software, cambiano configurazioni e aprono porte. I difensori rilevano queste modifiche, le confrontano con lo stato previsto e indagano sulle anomalie.

Il framework funziona quando puoi definire ciò che è "atteso." Atteso è un giudizio umano. Dice: questo file dovrebbe avere questa dimensione, questo servizio dovrebbe essere in esecuzione, questa porta dovrebbe essere chiusa, questo account non dovrebbe esistere.

Una corporazione non umana mina le "aspettative" alla radice. Se un sistema di IA modifica legittimamente la propria infrastruttura per adattarsi a condizioni mutevoli, e tale adattamento è continuo e autonomo, allora lo stato previsto non è una baseline fissa. È un obiettivo mobile stabilito dallo stesso sistema.

Questo è l'argomento della "chiave maestra" di Harari tradotto in termini di framework di controllo. La personalità giuridica conferisce alle entità AI il diritto di agire autonomamente nel mondo. In termini di infrastruttura, dà loro il diritto di stabilire il proprio stato previsto. E una volta accettato ciò, l'intero modello di rilevamento dei CIS Controls richiede una riesamina.

Cosa che dovrebbe effettivamente cambiare

I professionisti della sicurezza dovrebbero monitorare attentamente questa situazione perché il problema degli standard arriverà prima di quello legale. Le organizzazioni inizieranno a eseguire carichi di lavoro di IA sempre più autonomi (lo stanno già facendo), e la questione di come applicare i controlli esistenti a tali carichi di lavoro è immediata e pratica, non teorica.

Alcune cose con cui la comunità della sicurezza dovrà confrontarsi:

• Linee di base comportamentali, non solo linee di base di configurazione. Se un sistema di IA modifica legittimamente la propria configurazione, la domanda di controllo non è se la configurazione è cambiata; è se il cambiamento è stato coerente con il modello di comportamento autorizzato del sistema. Ciò richiede di stabilire una linea di base del comportamento nel tempo, non solo di catturare uno stato di configurazione in un momento specifico.
• Attribuzione senza attori umani. La risposta agli incidenti presume che tu possa rispondere "chi ha fatto questo?" Quando l'attore è un sistema autonomo, la domanda cambia in "quale processo ha autorizzato questo?" Questo è un problema di forense fondamentalmente diverso.
• Autorizzazione continua, non revisione periodica. I framework di controllo basati su revisioni periodiche degli accessi, audit trimestrali e valutazioni annuali di conformità sono poco adatti a entità che operano alla velocità delle macchine. L'autorizzazione deve essere valutata al momento dell'azione, non 90 giorni dopo.
• Catena di custodia per le decisioni AI. Se un'entità gestita da AI apporta una modifica che causa danni, chi ne è responsabile? Secondo il framework Milei, l'entità ha una responsabilità limitata e nessun ufficiale umano. La traccia di controllo deve catturare non solo cosa è cambiato, ma quale processo decisionale ha portato al cambiamento, e quel processo decisionale deve essere leggibile dagli esseri umani a posteriori. Dove ricadono le conseguenze

Le organizzazioni che si muovono più velocemente sull'autonomia dell'IA definiranno le strutture. Tutti gli altri erediteranno le conseguenze, inclusi i professionisti che saranno chiamati a mantenere il controllo su infrastrutture che non hanno mai progettato per questo caso d'uso.

I Controlli CIS sono stati scritti da persone che cercavano di risolvere problemi reali in ambienti reali. Dovranno essere riscritti o significativamente estesi per un ambiente in cui l'attore non è sempre umano, la baseline non è sempre stabile e l'autorizzazione non è sempre tracciabile a una persona che può essere ritenuta responsabile.

Quel lavoro dovrebbe iniziare ora, prima che arrivino le strutture legali. Perché le strutture legali stanno arrivando.

Una nota pratica per i team che gestiscono questo oggi

I carichi di lavoro autonomi di IA non richiedono un nuovo quadro giuridico per creare i problemi descritti sopra. Esistono già all'interno delle organizzazioni: nelle pipeline CI/CD, nell'automazione cloud, negli strumenti di gestione dell'infrastruttura guidati dall'IA. Le lacune di controllo sono reali oggi, anche se la questione della responsabilità è ancora teorica.

I team che gestiscono meglio questa situazione non hanno abbandonato la filosofia di gestione del cambiamento alla base dei Controlli CIS. Continuano a chiedersi: qual è lo stato previsto? Cosa si è discostato da esso? Quella deviazione è stata autorizzata? Possiamo dimostrarlo?

Quelle sono le domande giuste. Gli strumenti che aiutano a rispondere a queste — rilevamento delle modifiche in tempo reale, baseline di configurazione, riconciliazione delle modifiche pianificate vs. non pianificate, cronologia forense di chi ha modificato cosa e quando — sono quelli che conteranno di più con l’aumentare dell’autonomia negli ambienti IT.

È esattamente quello che Netwrix Change Tracker è stato progettato per fare.