Dark background with blue code overlay
Blog

Retrospettiva su Log4j - Parte 4: 5 lezioni apprese da Log4j

Charlie Gero

Written by

Charlie Gero

January 13, 2022

Charlie Gero è VP & CTO della Enterprise Division di Akamai e guida l'Advanced Projects Group. Attualmente il suo lavoro si concentra su ricerche all'avanguardia nei settori della sicurezza, della matematica applicata, della crittografia e degli algoritmi distribuiti, al fine di sviluppare la prossima generazione di tecnologie che proteggeranno la crescente base di clienti di Akamai. Grazie alle sue ricerche in Akamai ha depositato quasi 30 brevetti in crittografia, compressione, sistemi di rete performanti, distribuzione di contenuti multimediali in tempo reale e molto altro; è laureato in fisica e in informatica. Lavora in Akamai da quasi 15 anni, dopo aver fondato una start-up e aver ricoperto posizioni chiave nel settore delle scienze informatiche in aziende farmaceutiche e del networking.

lessons.png

Nella Parte 4 della serie di retrospettive su Log4j, desidero evidenziare i concetti chiave. Molte altre lezioni verranno apprese col procedere della ricerca per sradicare questa vulnerabilità. Tuttavia, sono già stati individuati cinque concetti chiave.

1. La nuova norma

Sia la complessità del software che la velocità con cui gli utenti finali richiedono nuove funzionalità continuano a crescere rapidamente e in modo illimitato. Per soddisfare le esigenze degli utenti finali nei tempi richiesti, gli sviluppatori devono affidarsi a un insieme di librerie, ecosistemi linguistici e infrastrutture e servizi di terze parti disponibili in rapida crescita. Di conseguenza, porzioni sempre maggiori delle funzionalità di qualsiasi software sono composte da componenti che gli sviluppatori stessi potrebbero non aver mai toccato o compreso completamente.

In qualsiasi grafico delle dipendenze software, le vulnerabilità vengono ereditate dai nodi foglia o dal codice e dai servizi condivisi, fino al nodo radice o al prodotto in fase di programmazione. Man mano che un numero sempre maggiore di questi nodi foglia viene aggiunto a un progetto, in base alle necessità come riportato sopra, aumenta anche il rischio di una vulnerabilità.

Tutto questo porta a una conclusione inevitabile: questi tipi di vulnerabilità non solo sono destinati a rimanere a lungo, ma continueranno ad espandersi in termini di frequenza e impatto.

Questa è la nuova norma.

2. Il rischio è ricorrente

Spesso pensiamo erroneamente al rischio in correlazione ai sistemi, al software e alle funzioni che possiamo controllare direttamente. Le organizzazioni più avanzate stanno iniziando a valutare il rischio a un livello superiore; per esempio, chiedendo ai propri sviluppatori di esaminare l'affidabilità di una determinata libreria.

Ma, poiché sempre più sistemi e software continuano a essere composti su diversi livelli di codice di terze parti, le organizzazioni dovranno valutare non solo il rischio di una determinata libreria o partner, ma anche le pratiche di tale community di sviluppo o fornitore, per assicurarsi di esaminare anche le rispettive dipendenze.

Ogni nodo nell'albero delle dipendenze e nella supply chain dovrebbe essere valutato da te, dai tuoi partner e/o dalla rispettiva community di sviluppo per determinare se i livelli di rischio tollerabili sono soddisfatti.

3. La visibilità consente la velocità

Anche con le valutazioni del rischio riportate sopra, si verificheranno delle vulnerabilità. Bisogna accettare questo fatto. La domanda da porsi è come possiamo affrontare in modo più efficace la situazione quando si verifica, non come possiamo prevenirla del tutto.

A tale scopo, la visibilità è fondamentale. Molte organizzazioni hanno difficoltà con le patch, in primo luogo perché non sanno quali computer sono interessati. Le aziende devono disporre di sistemi che forniscano visibilità sui processi in esecuzione nel data center e nel cloud.

Quanto più completa e accurata è la visibilità, tanto più velocemente un'organizzazione può reagire e correggere le risorse necessarie.

4. Filtra l'ovvio

Molte vulnerabilità possono essere attaccate solo attraverso una catena di exploit. Eliminare qualsiasi pezzo della catena è spesso sufficiente per impedirne il pieno sfruttamento. Pertanto, i sistemi che filtrano gli attacchi sia precedenti che evidenti sono fondamentali.

Le organizzazioni dovrebbero dare la priorità ai seguenti sistemi:

  • Piattaforme di protezione degli endpoint (PPE)
Proteggi gli endpoint da software dannosi noti
  • WAF (Web Application Firewall)

Proteggi le applicazioni web dai payload dannosi noti e dagli autori delle minacce: prendi in considerazione la migliore protezione Kona di Akamai
  • Firewall DNS

Proteggi gli endpoint dalla visita di domini dannosi e filtra i payload DNS dannosi: prendi in considerazione la soluzione Akamai Enterprise Threat Protection
  • SWG (Secure Web Gateway)

Proteggi gli endpoint dal download di malware e dalla visita di siti dannosi su Internet: prendi in considerazione la soluzione Akamai Enterprise Threat Protection
  • MFA (Multi-Factor Authentication)

Riduci il rischio di furto delle credenziali consentendo l'accesso all'azienda dove è possibile che possa essere distribuita una catena di exploit: prendi in considerazione Akamai MFA
  • Segmentazione basata sull'identità

Limita il software e i sistemi alla comunicazione solo con i computer necessari per completare le relative attività: prendi in considerazione la soluzione Akamai Guardicore Segmentation
  • ZTNA (Zero Trust Network Access)

Limita l'impatto degli utenti finali infetti che accedono alla rete: prendi in considerazione Akamai Enterprise Application Access

5. Il privilegio minimo regna sovrano

Infine, le organizzazioni dovrebbero adottare pienamente il principio del privilegio minimo. Blocca server, computer e software in modo che possano raggiungere solo i sistemi necessari per svolgere le relative attività.

Ad esempio, molti dei sistemi che effettuano chiamate LDAP in uscita come parte dell'exploit di Log4j non hanno mai avuto la necessità di utilizzare LDAP. Tali sistemi dovrebbero avere un accesso protetto da firewall a LDAP.  Un altro esempio: se un servizio risponde solo alle richieste in entrata, blocca le connessioni in uscita.

Applicando i principi del privilegio minimo a tutti i sistemi e i software sotto il tuo controllo, puoi ridurre notevolmente la superficie delle minacce quando viene rilevata una vulnerabilità e, in molti casi, fermare la catena di attacco prima di venire colpito.

Scopri di più

Grazie per essere stato con me fino alla fine di questa serie. Sebbene questa serie di blog finisca qui, la nostra ricerca e la protezione dei clienti dalle vulnerabilità continuano. Non esitare a contattare il tuo contatto Akamai se desideri saperne di più sulle nostre raccomandazioni per la mitigazione di Log4j e altre minacce.

 



Charlie Gero

Written by

Charlie Gero

January 13, 2022

Charlie Gero è VP & CTO della Enterprise Division di Akamai e guida l'Advanced Projects Group. Attualmente il suo lavoro si concentra su ricerche all'avanguardia nei settori della sicurezza, della matematica applicata, della crittografia e degli algoritmi distribuiti, al fine di sviluppare la prossima generazione di tecnologie che proteggeranno la crescente base di clienti di Akamai. Grazie alle sue ricerche in Akamai ha depositato quasi 30 brevetti in crittografia, compressione, sistemi di rete performanti, distribuzione di contenuti multimediali in tempo reale e molto altro; è laureato in fisica e in informatica. Lavora in Akamai da quasi 15 anni, dopo aver fondato una start-up e aver ricoperto posizioni chiave nel settore delle scienze informatiche in aziende farmaceutiche e del networking.