Retrospettiva su Log4j - Parte 4: 5 lezioni apprese da Log4j
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.
