Cybersecurity e Intelligenza Artificiale nel cuore del Summit Cyber del Texas

Cybersecurity e Intelligenza Artificiale al centro del Summit Cyber del Texas

Austin, Texas, è la decima città più grande degli Stati Uniti e sta crescendo costantemente, sia in termini di popolazione che di industria. Ogni anno, decine di grandi aziende si spostano o si espandono nella zona di Austin. È anche sede di sei università, come The University of Texas at Austin e Texas State. Essendo la capitale dello stato del Texas, ci sono anche molte agenzie governative presenti. Persone provenienti da tutti questi settori si sono riunite nell’ultima settimana di settembre per imparare l’una dall’altra al Texas Cyber Summit 2023.

Ecco solo alcuni dei momenti salienti di questo evento incentrato sulla sicurezza.

L’AI è centrale nella maggior parte delle conversazioni sulla sicurezza

Il tema dell’evento di quest’anno è stata l’intelligenza artificiale, AI, e il suo ruolo in continua evoluzione nella sicurezza. Hanno scelto il tema nel novembre dello scorso anno, un po’ prima del boom di ChatGPT. Hanno previsto correttamente che quasi tutte le conversazioni sugli strumenti di sicurezza e sull’automazione si concentrerebbero sul tema dell’IA e dei grandi modelli di linguaggio, LLM. Questo tema è stato sicuramente al centro di molte conversazioni nei corridoi e durante gli incontri sociali.

Quasi ogni relatore ha avuto qualcosa da dire sull’IA e sui LLM, incluso Holly Baroody, Direttore Esecutivo del United States Cyber Command. Nel suo discorso principale, “Come il Cyber Command sta plasmando il suo futuro attraverso l’innovazione e le partnership”, ha parlato di come il suo team stia lavorando per proteggere oltre 15.000 reti e oltre 3 milioni di endpoint; stanno sfruttando l’IA ovunque possibile a nostro vantaggio. Ma ha avvertito che i nostri avversari stanno facendo la stessa cosa, usando l’IA per creare nuove minacce e vulnerabilità a un ritmo sempre crescente.

• Sfruttare gli LLM per completare i grafi di conoscenza delle raccomandazioni
• Analisi dei sentimenti di Twitter in Python – Sklearn | Elaborazione del linguaggio naturale
• Recensione di HitPaw Photo Enhancer il miglior potenziatore di foto con intelligenza artificiale?

Come il Cyber Command sta plasmando il suo futuro attraverso l’innovazione e le partnership di Holly Baroody Direttore Esecutivo del United States Cyber Command

Cosa significa l’IA per la sicurezza informatica

Potrebbe essere facile guardare ai progressi fatti con l’IA e presumere che sia necessario essere una grande azienda per cogliere i benefici. Nel suo intervento, “Come cambierà l’IA il panorama della sicurezza informatica?” Raffaele Mautone, CEO e fondatore di Judy Security, ha spiegato che le piccole e medie imprese, PMI, hanno molto da guadagnare. L’IA aiuta in due modi significativi: automatizzando e consentendo una scala mai vista prima.

Un ostacolo che ogni azienda deve superare è la paura che l’IA sostituisca un ruolo specifico. La realtà è che le moderne imprese di tutte le dimensioni hanno semplicemente troppi dati per una singola persona o un team per gestirli. L’IA può integrare la base di conoscenza di qualsiasi team per tutte le attività che devono svolgere, come verificare la configurazione della stampante per impostazioni di sicurezza corrette evidenziando nuove e note vulnerabilità. I modelli di IA possono essere addestrati per individuare attacchi di phishing e avviare il piano di risposta automatica.

Dobbiamo vedere l’IA come un modo per potenziare i “bravi ragazzi”. Ci sono team e prodotti che lavorano su rilevamento delle minacce alimentato dall’IA, analisi dei dati su larga scala, strategie di autenticazione avanzate e analisi predittive, solo per citarne alcuni casi d’uso. Ritiene che possiamo arrivare a un mondo di patch automatiche e potenzialmente generare formazione sulla consapevolezza della sicurezza basata su nuovi rapporti e vulnerabilità annunciate.

“Come cambierà l’IA il panorama della sicurezza informatica?” di Raffaele Mautone, CEO & Fondatore di Judy Security #texascybersummit

GitHub sta lavorando per una migliore sicurezza per tutti

Jose Palafox, Responsabile della Sicurezza delle Applicazioni presso GitHub, ha illustrato alcuni modi in cui il suo team sta lavorando per migliorare la sicurezza nel suo intervento “Sicurezza dei progetti open-source su GitHub.com”. Essendo la piattaforma di hosting del codice più grande al mondo, si considerano in prima linea nella lotta per aiutare le persone a proteggere non solo il proprio codice, ma l’intera catena di approvvigionamento software.

Ha detto che ci sono già molti avvisi e scansioni disponibili, ma il volume di falsi positivi e rumore ha portato molti sviluppatori a ignorarli. Il passaggio del contesto dall’indagine per investigare un nuovo avviso è spesso altamente dannoso per il loro flusso di lavoro, soprattutto quando non c’è bisogno di agire, quindi la maggior parte degli avvisi viene ignorata.

GitHub sta lavorando all’iniziativa Security Lab, cercando nuove vulnerabilità e presentando rapporti sulle Vulnerabilità Comuni e Esposizioni (CVE). Hanno appena presentato il loro 500° rapporto di recente. Jose ha detto che possono mostrare un tasso di correzione del 95% da parte dei responsabili una volta che vengono avvisati.

Jose ha detto che il miglior passo che un individuo può fare è attivare l’autenticazione a più fattori, MFA, ovunque sia possibile. GitHub imporrà l’MFA per l’utilizzo della piattaforma entro la fine dell’anno, qualcosa di cui avvertono le persone dal 2021. Hanno inviato YubiKeys a oltre 500 organizzazioni per assicurarsi che siano pronte a questo cambiamento e che rimangano protette.

Le sessioni pomeridiane al #texascybersummit sono iniziate con “Securing open-source projects on GitHub” @Josepalafox, responsabile della sicurezza delle applicazioni presso GitHub/Microsoft

Zero Trust richiede applicazioni che lo consentano

Nel suo intervento “The hole in your Zero Trust strategy – unmanageable applications,” Matthew Chiodi, Chief Trust Officer – Cerby, ha detto che 1 violazione su 7 è dovuta a applicazioni che non possono essere gestite con un provider di identità. Secondo una ricerca di IBM, quando fatto correttamente, una strategia di Zero Trust riduce drasticamente gli effetti e il costo di una violazione. Tuttavia, molte organizzazioni faticano a rendere Zero Trust una realtà, con alcuni che credono erroneamente che l’MFA sia sufficiente. Nel vero Zero Trust, l’autorizzazione è un processo continuo, non solo eseguito una volta all’inizio dell’autenticazione, come avviene con l’MFA.

La vera sfida nell’implementazione di Zero Trust viene da ciò che ha definito applicazioni “non standard”, che ha definito come quelle che non supportano i criteri di autenticazione singola, la sicurezza e gli standard di identificazione. La portata del problema è molto ampia. Secondo la sua ricerca:

• Il 61% delle prime 10.000 applicazioni SaaS non supporta l’autenticazione singola
• Il 42% non supporta l’MFA
• L’85% ha solo un controllo di accesso a livello di alto raggio, il che significa che offrono ruoli di amministratore e utente, ma nessun modo per definire regole personalizzate.
• Il 94% non supporta un sistema per la gestione dell’identità tra domini (SCIM).
• Il 95% non ha API di sicurezza

Anche se non esiste una singola soluzione chiara che si adatti a ogni organizzazione, vuole sensibilizzare su questo problema. Ha anche definito quattro passaggi di base che dobbiamo seguire come settore per una migliore sicurezza riguardo alle applicazioni non standard:

1. Le organizzazioni di sicurezza devono trovare un modo per individuare queste applicazioni
2. Persuadere i fornitori a estendere le capacità del provider di identità alle applicazioni non standard
3. Automatizzare compiti di sicurezza come la configurazione del 2FA e l’accesso/uscita degli utenti per tener conto di queste applicazioni.
4. Segnalare l’attività verso questi obiettivi.

Un’altra fantastica sessione questo pomeriggio al #texascybersummit, “The hole in your Zero Trust strategy – unmanageable applications” di @mattchiodi, Chief Trust Officer – Cerby

Zero Trust in tutto il SSC

Zero Trust è stato un altro argomento ricorrente durante le sessioni. JC Herz, Senior Vice President delle soluzioni per la catena di approvvigionamento del software presso Exiger, ha proseguito il tema nella sua sessione “Zero Trust nella catena di approvvigionamento del software”. Ha detto che il mondo delle catene di approvvigionamento del software, SSC, e la sicurezza sono molto una guerra, e ha citato le famose parole del ex Segretario alla Difesa degli Stati Uniti Donald Rumsfeld: “Ci sono le cose che sappiamo di sapere. Sappiamo anche che ci sono delle cose che sappiamo di non sapere, ma ci sono anche delle cose che non sappiamo di non sapere”. Ci ha guidato nello stato di Zero Trust nel SSC, collegandolo a queste tre categorie di conoscenza. Le “cose che sappiamo di sapere” sono cose come le vulnerabilità e il debito tecnico, con cui dovremmo occuparci. Le “cose che sappiamo di non sapere” includono la risoluzione delle entità, la capacità di mappare qualcosa alla sua vera fonte, e i rischi dei fornitori. Ci sono anche rischi sconosciuti per ciò che succede alla manutenzione del progetto, specialmente se un manutentore non ha un piano di successione chiaro pubblicato. Gli “sconosciuti sconosciuti” sono, beh, sconosciuti. Una grande interruzione su larga scala nel SSC potrebbe derivare da grandi questioni che interessano l’intero mercato o importanti fornitori. Dobbiamo rimanere vigili di fronte ai rischi emergenti.

Cosa dobbiamo fare per avanzare verso un futuro migliore di Zero Trust è richiederlo ai nostri fornitori. Assicuriamoci che mantengano e aggiornino il loro software per tener conto di questo cambiamento architettonico. Ha avvertito che spesso, nella sua ricerca, trova gli strumenti di sicurezza come i peggiori in questo aspetto. Ha detto che dovremmo richiedere a ciascun fornitore un elenco di fornitori così come un piano di supporto continuativo per assicurarsi che ciascun componente nel nostro SSC sia appropriato. Se è disponibile un SLA, assicuriamoci che lo rispettino.

“Zero Trust nella catena di fornitura del software” di JC Herz, Vicepresidente Senior delle Soluzioni per la Catena di Fornitura del Software presso Exiger al #texascybersummit

Cosa fare e cosa non fare in un attacco di ransomware

Donovan Farrow, Fondatore e CEO di Alias Infosec, ha presentato diverse storie dell’orrore così come alcune storie di successo nell’affrontare il ransomware nel suo intervento “The Good. The Bad. The Hacked.” Il problema principale per la maggior parte delle aziende che subiscono un attacco di ransomware è che non hanno esperienza pratica nella gestione degli incidenti. Di conseguenza, molte organizzazioni tendono ad attendere e affrontare la situazione da sole all’inizio anziché chiamare immediatamente squadre esperte che si concentrano su questo tipo di attacco.

Ha definito la differenza tra una buona risposta e una cattiva risposta, così come le cose brutte che ha visto in alcuni casi estremi. Cosa implica una buona risposta al ransomware?

• Avere un piano di risposta agli incidenti in atto e praticato.
• Contattare il team corretto tempestivamente.
• Preservare tutti i record e le comunicazioni.
• Trovare rapidamente l’exploit e prevenire futuri accessi.
• Muoversi come un team.

Al contrario, una cattiva risposta al ransomware significa:

• Non avere un piano di risposta agli incidenti in atto.
• Nessuno sa a chi chiamare. È il fornitore? Chi conosce il processo e la politica necessari?
• “Vai avanti e stampa quel curriculum.” Gli attacchi di ransomware sono spesso anche eventi di turnover, con membri chiave del team che trovano altre opportunità poiché l’azienda potrebbe non sopravvivere.
• Agire come se non ci fosse una minaccia reale fino a quando è troppo tardi.

Donovan ha condiviso alcune delle cose che ha visto lavorando su casi molto gravi che dovresti evitare, “L’Orribile”:

• Negare che sia successo qualcosa.
• Assumere avvocati inesperti che non hanno esperienza in ambito di ransomware.
• Mentire ai tuoi clienti.

#texascybersummit ultima sessione del giorno 1 “The Good. The Bad. The Hacked.” di Donovan Farrow, Fondatore e CEO di Alias Infosec

Cosa ci ha insegnato Log4JShell sulla sicurezza di Kubernetes

Come molti ricorderanno, Log4Shell è stato un importante evento di sicurezza che ha scosso il mondo della tecnologia. Nella loro sessione molto tecnica “The Platform Engineer Playbook – 5 Modi per la Sicurezza dei Contenitori”, Eric Smalling, Sr. Developer Advocate presso Snyk, e Marino Wijay, Developer Advocate presso Solo.io, hanno parlato di alcuni modi pratici per evitare che un altro incidente simile influenzi i tuoi deployment di container.

Il problema centrale con Log4Shell è che una volta aperto un terminale sull’host remoto, gli hacker spesso hanno pieni privilegi e strumenti Linux a loro disposizione. Assicurarsi che chiunque possa ottenere accesso non abbia accesso completo e illimitato a tutti i sistemi e gli strumenti possibili è un primo passo enorme. È inoltre vitale capire come funzionano gli strati sia durante la compilazione che durante l’esecuzione. Dovresti sfruttare compilazioni a più fasi che consentono controlli in vari punti lungo il percorso di compilazione. È anche fondamentale utilizzare solo compilazioni di immagini note e ripetibili, ed è qui che interviene Chainguard. Consentire solo determinati strumenti e disabilitare la possibilità di installarne di nuovi dopo la compilazione completata rafforzerebbe ulteriormente la tua sicurezza.

La scansione del codice è uno step molto vitale nel processo. Oltre alle versioni aggiornate e alle vulnerabilità conosciute, le scansioni dovrebbero anche verificare le errate configurazioni. Quando si configura un contenitore, hanno condiviso una lista di cose da fare e da evitare:

• Non eseguire come root: probabilmente non ne hai bisogno e consente a chiunque abbia accesso il controllo completo.
• Usa gli UUID dell’utente quando concedi le autorizzazioni. Rende più difficile capire quale ruolo ha ogni utente.
• Non utilizzare contenitori privilegiati. Questo darebbe accesso a tutti i dispositivi.
• Imposta `allowPriviledgeEscalation: false`.
• Non consentire l’elenco completo degli strumenti Linux.
• Riduci le capacità di un contenitore solo a ciò che è necessario.
• Esegui il contenitore con `readOnlyRootFilesystem: true`. Questo livello di immutabilità rende più difficile sfruttare il tuo contenitore.

Dovresti utilizzare un agente di polizia per assicurarti che queste migliori pratiche vengano seguite. Raccomandano di prendere in considerazione OpenPolicyAgent, Kyverno e Pod Security Admission, che è integrato in Kubernetes.

Inoltre, devi preoccuparti del traffico di rete. Imposta regole di ingresso ed uscita, consentendo il traffico solo da fonti conosciute e dirigendolo solo verso indirizzi predefiniti. Ogni richiesta dovrebbe anche poter essere autorizzata. Se sfruttiamo le architetture Zero Trust, dovremmo rifiutare qualsiasi richiesta che non possiamo autorizzare.

Hanno concluso che una corretta sicurezza dei contenitori comporta la considerazione di tutti i seguenti elementi:

1. Scansione del codice e dell’immagine del contenitore
2. Implementazione delle migliori pratiche per la configurazione dell’ambiente di runtime del contenitore
3. Applicazione delle politiche in Kubernetes
4. Autenticazione e autorizzazione per i contenitori
5. Crittografia e identificazione per tutti i servizi

The Platform Engineer Playbook: 5 modi per garantire la sicurezza dei contenitori di Eric Smalling, Sr. Developer Advocate presso Snyk e Marino Wijay, Developer Advocate presso Solo.io al #texascybersummit

Git e OWASP

Sono stato fortunato a presentare due sessioni diverse. Nella mia sessione “Non commettere i tuoi segreti: i git hook vengono in soccorso”, sono riuscito a insegnare alle persone alcune nozioni di base di git e come tenere i segreti fuori dai tuoi repository con un git hook. Configurare i giusti git hook per fare ciò è molto rapido con ggshield, il GitGuardian CLI.

La seconda sessione riguardava OWASP, chiamata “La sicurezza delle app non deve essere divertente: ignorare OWASP per avere un’esperienza terribile”. GitGuardian è orgoglioso di sponsorizzare diversi progetti OWASP, inclusa la sezione di Austin OWASP. La sessione si è concentrata sul “Wayfinder della sicurezza delle applicazioni” e sulle offerte che la comunità ha mappato per ciascuna fase del ciclo di sviluppo del software. Il mio obiettivo è rendere le persone consapevoli degli strumenti OWASP disponibili, con la speranza di facilitare la collaborazione tra sviluppatori e team di sicurezza.

Migliorare come comunità

Con oltre 1300 partecipanti, il Texas Cyber Summit di quest’anno ha riunito una vasta gamma di persone. Le esperienze variano dalla NSA e CYBERCOM a esperti del settore come Snyk e GitHub e ha accolto studenti e persone che desiderano iniziare nel campo della sicurezza informatica. Gli obiettivi comuni che avevamo erano imparare, condividere le nostre conoscenze e crescere come comunità. Quest’anno, il focus era estremamente attuale, poiché l’AI è stata al centro di così tante conversazioni. Non vedo l’ora di vedere quale tema la comunità del Texas Cyber Summit sceglierà per il prossimo anno ed essere testimone delle conversazioni che ne derivano.

Non importa dove ti trovi nel mondo o nel tuo percorso di sicurezza, siamo tutti insieme in questo. Se hai bisogno di aiuto per navigare nel mondo del rilevamento dei segreti, della scansione della sicurezza dell’infrastruttura come codice o del rilevamento intrusioni e fughe, come offriamo tramite GitGuardian Honeytoken, saremo lieti di aiutarti. Possiamo persino aiutarti a capire in quale punto ti trovi nel tuo percorso di gestione dei segreti attraverso il nostro questionario.