Le minacce dell'IA si muovono rapidamente. Anche le tue difese dovrebbero farlo.

Di recente, Vincent Danen di Red Hat ha evidenziato come i modelli di IA abbiano rilevato 271 difetti di sicurezza reali in Firefox, in un unico passaggio durante la collaborazione di Mozilla con Anthropic. Se si può sfruttare l'IA per difendersi, la si può usare anche per attaccare. Come ha affermato Danen: "se la tua strategia di sicurezza si basa esclusivamente sul presupposto che il software sia privo di vulnerabilità, hai già perso". 

Le vulnerabilità nel codice sono solo il punto di accesso. I veri problemi si presentano in un secondo momento: movimenti laterali attraverso reti configurate in modo errato, credenziali con privilegi eccessivi, segreti non ruotati e servizi che si fidano ciecamente l'uno dell'altro. Nessun ciclo di patch può tenere il passo. Ciò sottolinea la necessità di una maggiore "difesa in profondità" in tutte le aziende: un cambiamento culturale che presuppone l'inevitabilità di una violazione e si concentra sulla riduzione dell'impatto dell'esposizione stessa. 

Questa è la definizione di zero trust. Questa prima ondata di vulnerabilità di sicurezza è seguita da una seconda e da una terza; le organizzazioni devono adottare il modello Zero Trust per passare dalla pura prevenzione al contenimento della violazione, applicando il principio del privilegio minimo a identità, segreti, segmentazione della rete e policy a ogni livello. Le organizzazioni necessitano di un'applicazione automatizzata che operi alla velocità delle minacce basate sull'IA. Red Hat Ansible Automation Platform aiuta in questo senso.

L'evoluzione della superficie di attacco dell'IA

I tradizionali scanner delle vulnerabilità segnalano i potenziali problemi e li trasmettono a un operatore umano per il triage. L'IA ha reso gli attacchi informatici alla portata di tutti. Gli odierni strumenti di IA sono essenzialmente un intero team in un unico strumento, il tutto al costo dei token. Se violazioni devastanti come SolarWinds richiedevano tempo, competenze approfondite e fortuna, l'IA ora consente agli aggressori motivati di concatenare senza sforzo vulnerabilità complesse e multipiattaforma.

Queste debolezze, apparentemente minime, si sommano e non a tuo vantaggio. Ad esempio:

• Una pagina di login che ti consente di riprovare le password troppo rapidamente
• Una pagina delle impostazioni che non verifica nuovamente la tua identità
• Un'API che espone brevemente un token di sessione durante il logout

Nessuno di questi elementi è eccessivamente pericoloso se preso singolarmente. Singolarmente, ciascuno di essi resterebbe nel backlog con "priorità bassa", ma concatenati tra loro potrebbero consentire a un malintenzionato di forzare una password in modo aggressivo, sottrarre la sessione prima della scadenza e accedere alla pagina delle impostazioni come amministratore. Tre bug minori che però consentono un'intrusione efficace.

Questi modelli di IA avanzati scrivono, compilano ed eseguono codice exploit, utilizzando i risultati dei fallimenti per perfezionare e riprovare gli attacchi in modo iterativo. Se da un lato le organizzazioni sfruttano questi strumenti a proprio vantaggio per individuare e correggere rapidamente vulnerabilità prima ignote, la scomoda verità è che tale capacità è a disposizione anche degli aggressori. Come ha scritto Danen: "gli stessi strumenti che aiutano i difensori a trovare i bug aiuteranno inevitabilmente anche gli aggressori a individuarli". Il livello di competenze richiesto agli aggressori si è appena abbassato. Una distribuzione più rapida delle patch è un elemento della soluzione, ma deve essere integrata da valide difese. 

La difesa richiede un livello operativo automatizzato

Red Hat Enterprise Linux con SELinux e Red Hat OpenShift offrono già l'hardening a livello di piattaforma, ma queste difese devono essere integrate. Ad esempio, SELinux non stabilisce chi è autorizzato a distribuire un'applicazione. L'isolamento dei container non revoca le credenziali del database quando un sistema di gestione delle informazioni e degli eventi di sicurezza (Security Information and Event Management, SIEM) rileva un attacco brutale alle 03:00. L'automazione può fare tutto questo, al fine di creare una valida strategia difensiva. 

Le modifiche operative (distribuzioni, patch, riconfigurazioni di rete, rotazione delle credenziali) passano attraverso persone, script, pipeline e automazione. Se questi percorsi non sono regolati da policy, l'hardening della piattaforma protegge da una classe di attacchi, ma ne lascia un'altra completamente esposta. 

NIST SP 800-207 definisce il modello Zero Trust Architecture (ZTA), al centro del quale si trova il Policy Enforcement Point (PEP). Molti considerano il PEP come un firewall o un gateway che filtra il traffico di rete. Tuttavia, quando i team distribuiscono applicazioni, applicano patch ai server e modificano le configurazioni di rete, tali azioni non passano attraverso un firewall, ma attraverso l'automazione. In definitiva, lo zero trust è una disciplina operativa che richiede l'automazione per essere implementata su larga scala.

Ansible Automation Platform come Policy Enforcement Point

Quando Ansible Automation Platform funge da PEP, ogni azione operativa passa attraverso una piattaforma che controlla l'identità, valuta le policy, gestisce i segreti e registra i risultati. Non si tratta di funzionalità avanzate, ma dei controlli minimi praticabili richiesti dallo zero trust. L'operatore non interagisce mai direttamente con il sistema di destinazione. Questa operazione viene eseguita da Ansible Playbook, che viene avviato solo dopo che la piattaforma ha confermato l'autorizzazione dell'operatore.

Il vantaggio dell'architettura consiste nell'applicazione centralizzata con esecuzione distribuita. Le decisioni sulle policy avvengono su un unico piano di controllo, ma l'applicazione avviene ovunque venga eseguita l'automazione. Non esiste una connessione diretta ai server né l'esecuzione di script da laptop, il che riduce i rischi di "cowboy engineering" e della deriva della configurazione non tracciabile. In questo modo si affrontano anche anti-pattern come la proliferazione delle credenziali, la shadow automation o i movimenti laterali non gestiti.

Questa architettura mitiga le vulnerabilità di sicurezza critiche, eliminando le credenziali di produzione con privilegi elevati dagli endpoint locali vulnerabili. La piattaforma di automazione è l'unico punto di controllo e ogni modifica include identità, approvazione della policy e un registro degli audit. 

Ansible Automation Platform può implementare questo approccio tramite un modello di applicazione dual ring. L'anello esterno opera a livello di piattaforma. Prima di avviare un template di job, Ansible Automation Platform consulta il server Open Policy Agent (OPA) tramite la funzione di applicazione delle policy inclusa, fornendo il contesto completo del job: chi lo avvia, il team di appartenenza e il template in esecuzione. 

Fig.1 Applicazione delle policy ad anello esterno e interno con Ansible Automation Platform

OPA valuta la richiesta in base alla policy e restituisce un esito positivo o negativo. Il playbook non viene mai eseguito se l'anello esterno nega l'autorizzazione. La policy OPA associa l'appartenenza al team alle categorie di template consentite.

package aap.gateway
import rego.v1
default decision := {"allowed": true, "violations": []}
patching_teams := {"Infrastructure", "Security"}
network_teams := {"Infrastructure"}
app_teams := {"Applications", "DevOps"}
user_teams := {name | name := input.created_by.teams[_].name}
decision := {
    "allowed": false,
    "violations": [sprintf(
        "user '%s' is not in an authorised team for patching templates (requires: %v, has: %v)",
        [input.created_by.username, patching_teams, user_teams],
    )],
} if {
    not input.created_by.is_superuser
    is_patching_template
    not team_match(patching_teams)
}

Fig.2 Esempio di policy Rego per il controllo Policy as Code

L'anello interno opera nel modello o nel flusso di lavoro stesso. Per le operazioni con un potenziale impatto elevato, come le modifiche alle VLAN, il playbook recupera un'identità SPIFFE (un'identità crittografica del carico di lavoro) e la invia all'OPA. L'OPA valuta tre condizioni: 

• l'utente è autorizzato tramite l'appartenenza al team
• il carico di lavoro è legittimo, tramite SPIFFE Verifiable Identity
• la modifica richiesta rientra in un intervallo approvato

tutte e tre le condizioni devono essere soddisfatte.

Fig.3 Esempio di applicazione di più policy con Ansible Automation Platform

Questo aspetto è importante contro gli attacchi basati sull'IA perché la catena di attacchi si interrompe nel punto di applicazione, non in corrispondenza della vulnerabilità. Un agente di IA che concatena i bug per ottenere l'accesso a un server è intrappolato sul piano dati, dove le policy zero trust come la microsegmentazione della rete e le credenziali di breve durata ne impediscono l'accesso esterno o il movimento laterale. Non può sfruttare il tuo deployment per inviare applicazioni dannose né può alterare i criteri di rete aziendali senza passare da Ansible Automation Platform. Successivamente al rilevamento di una violazione locale, Event-Driven Ansible, incluso in Ansible Automation Platform, può isolare automaticamente il sistema e fornire un contesto immediato ai tuoi team di sicurezza.

Le credenziali utente rubate non superano il controllo SPIFFE perché l'identità del carico di lavoro non corrisponde. Un nodo di automazione compromesso non supera la verifica dell'appartenenza al team perché l'autore dell'attacco non controlla la sessione di Ansible Automation Platform dell'utente. Ogni anello è indipendente. Violare un solo anello non è sufficiente. Questa è la difesa in profondità in azione.

Riduci il potenziale impatto con credenziali dinamiche e la microsegmentazione

Anche con l'applicazione delle policy a livello di automazione, le credenziali e i percorsi di rete costituiscono una superficie di attacco. Con una rotazione mensile delle password del database, un utente malintenzionato che ottiene l'accesso ha una finestra temporale di un mese. Se le liste di controllo degli accessi alla rete (ACL) sono permanentemente aperte tra i livelli dell'applicazione e del database, il percorso è sempre disponibile.

Durante l'esecuzione del flusso di lavoro di deployment di un'applicazione, Ansible Automation Platform può richiedere una credenziale dinamica del database a HashiCorp Vault, ovvero un ruolo PostgresSQL associato allo schema dell'applicazione con un time-to-live (TTL) di cinque minuti. La credenziale esiste solo per la finestra di deployment. Allo scadere del TTL, il ruolo viene eliminato. Non può avvenire nessun furto, perché non vi è persistenza.

Nello stesso flusso di lavoro, Ansible Automation Platform configura la rete per aprire una voce ACL e consentire il traffico dall'indirizzo IP dell'applicazione alla porta del database.

Rispetto alle catene di exploit dell'IA, questo approccio cambia l'attacco. Gli strumenti potrebbero concatenare i bug per raggiungere un livello del database, ma troverebbero una credenziale già scaduta 4 minuti prima. La finestra di sfruttabilità si riduce da "fino alla modifica della password" a "fino al termine dell'automazione": si parla di minuti e non di mesi. Inoltre, quando l'applicazione viene eseguita in produzione, l'agente del vault gestirà il ciclo di vita delle credenziali.

Risposta agli incidenti alla velocità della macchina

Se gli agenti di IA possono generare exploit e concatenarli, l'analista del Security Operations Center (SOC) che riceve la notifica, accede, legge l'avviso, indaga e revoca manualmente le credenziali opera secondo tempistiche umane contro una minaccia digitale.

Event-Driven Ansible aiuta a colmare questa lacuna. Un SIEM come Splunk rileva un pattern aggressivo contro l'endpoint di autenticazione di un'applicazione. Splunk può inviare un avviso a Event-Driven Ansible tramite un flusso di eventi; Event-Driven Ansible valuta l'evento e avvia un processo di automazione per intervenire. Questo processo richiama l'API di HashiCorp Vault per revocare ogni lease di database dinamico attivo dell'applicazione. L'applicazione perde immediatamente la connettività al database.

—  
  name: Splunk Brute-Force credential revocation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Revoke credentials on SSH brute-force detection
      condition: event.payload.search_name is search("SSH Brute Force Detected")
      action:
        run_job_template:
          name: "Emergency: Revoke App Credentials"
          organization: Default

Fig. 4 Esempio di Event-Driven Ansible Rulebook per eventi attacco aggressivi da Splunk
 

Il ciclo dal rilevamento al contenimento si conclude in pochi secondi, riducendo il tempo medio di risoluzione da ore a secondi. L'impatto potenziale si riduce da "l'autore dell'attacco potrebbe avere accesso al database" a "l'autore dell'attacco ha accesso a un'applicazione che non può più raggiungere i suoi dati".

Fig. 5 Esempio di risposta agli incidenti di attacco per un'architettura zero trust con Event-Driven Ansible
 

Si tratta di un contenimento automatizzato, che può essere seguito da un ripristino manuale. Event-Driven Ansible può revocare le credenziali senza l'approvazione umana perché la revoca è un'impostazione predefinita sicura: l'applicazione interrompe la distribuzione dei dati, ma nulla viene distrutto. Il ripristino richiede un intervento umano per esaminare la situazione, confermare la risoluzione della minaccia e avviare un flusso di lavoro di ripristino per ridistribuire l'applicazione. Il punto di controllo nel percorso di ripristino esiste perché il ripristino dell'accesso dopo una compromissione non è un'operazione da automatizzare senza un'indagine umana.

Più livelli, una sola difesa

L'individuazione delle vulnerabilità assistita dall'IA rende la difesa in profondità non negoziabile. Tuttavia, una difesa in profondità senza un livello operativo automatizzato lascia una lacuna che gli attacchi alla velocità di macchina troveranno.

Tre livelli possono colmare questa lacuna, ciascuno interrompendo la catena di attacchi dell'IA in un punto diverso.

• Il rafforzamento della piattaforma (flag del compilatore, SELinux, isolamento dei container, Address Space Layout Randomization (ASLR)) rende più difficile sfruttare il bug iniziale. Un modello di IA potrebbe individuare la vulnerabilità, ma la piattaforma consolidata impone una procedura articolata solo per ottenere l'esecuzione del codice.
• L'applicazione delle policy con Ansible Automation Platform blocca i percorsi operativi non autorizzati. Anche se la catena di attacchi ha esito positivo, l'autore dell'attacco non può distribuire, applicare patch, riconfigurare o accedere ai segreti senza passare dal piano di controllo dell'automazione. Il solo furto delle credenziali non è sufficiente.
• La risposta automatizzata con Event-Driven Ansible aiuta a contenere le violazioni prima che inizi il movimento laterale. La velocità di rilevamento e contenimento in pochi secondi eguaglia quella degli attacchi basati sull'IA in un modo che la risposta umana non può fare.

Ogni livello funziona in modo indipendente. Il consolidamento della piattaforma non dipende dall'applicazione delle policy. L'applicazione delle policy non dipende dalla risposta automatizzata. Se un singolo livello cede, gli altri due limitano comunque i danni. Questa indipendenza consente ai team di sicurezza di dedicare tempo alla riduzione dei rischi strategici anziché alla gestione degli avvisi, e consente alle organizzazioni di adottare operazioni assistite dall'IA con la certezza che le protezioni funzioneranno anche quando gli strumenti si evolvono più rapidamente rispetto alle policy.

La maggior parte delle organizzazioni adotta il consolidamento della piattaforma. Molte realtà adottano i principi zero trust. Sono ancora poche le realtà che hanno collegato l'applicazione delle policy all'automazione alla velocità richiesta da queste minacce. Questo divario è il punto in cui si verificherà la prossima violazione. Combinando i tre livelli sopra descritti, rafforzerai le tue difese contro gli effetti di un attacco basato sull'IA.  

Risorse

• Webinar: Implementing Zero Trust with Red Hat Ansible Automation Platform
• Webinar: Automate Security. Align ITOps
• Ebook: Automatizza la sicurezza per allineare l'IT aziendalePagina disponibile in Inglese (Italiano non disponibile)
• Ebook: Red Hat Ansible Automation Platform: guida introduttiva
• Guida interattiva: Automazione dell'IT, inclusa l'automazione della sicurezza
• Pagina web: Automazione della sicurezza