Owasp Capitolo 6: a quali situazioni può portare l’utilizzo di componenti obsoleti? Scoprilo con Cybe
Alla sesta posizione troviamo la presenza di componenti vulnerabili o datati, in salita dalla nona posizione rispetto al 2017.
La spiegazione per questo controllo in realtà è molto semplice.
Rischiamo di incappare in questo tipo di problematica se si verificano una o più delle seguenti situazioni:
- Non sei a conoscenza/non tieni traccia di tutte le versioni dei componenti utilizzati per l’applicativo (sia a livello client che server). Questo include sia i componenti usati direttamente, sia le eventuali dipendenze annidate
- Se il Software è vulnerabile, non supportato, o vecchio. Questo include il sistema operativo, il web/application server, il DBMS (database management system), le applicazioni, le API e tutti i componenti, l’ambiente di runtime e le librerie
- Se non effettui scansioni di vulnerabilità regolari, e se non effettui controlli incrociati con i comunicati di sicurezza legati ai componenti utilizzati
- Se non fixi/aggiorni, la piattaforma sottostanze, i framework, e le dipendenze in modalità strutturate basandosi sul rischio effettivo. Questo solitamente avviene quando le attività di patching è strutturata come attività mensile o trimestrale, lasciando quindi l’organizzazione vulnerabile per giorni o addirittura mesi a vulnerabilità già fixate dai rispettivi vendor
- Se gli sviluppatori non testano la compatibilità delle librerie aggiornate
- Se non vengono effettuate delle configurazioni sicure dei vari componenti dell’applicativo.
Come difendersi?
Un buon piano di gestione delle patch è il primo e fondamentale step per mitigare e difendersi da questa situazione. Tale piano dovrebbe prevedere:
- Rimozione delle dipendenze non utilizzare, componenti, funzionalità, file e documentazione non più utilizzati
- Avere un inventario costantemente aggiornato delle versioni, dei componenti (sia server side che client side, come ad esempio i framework e le librerie), e le rispettive dipendenze, usando vari tool, come ad esempio OWASP Dependency Check, retire.js etc… Monitorare costantemente le fonti come le CVE (common vulnerabilities and exposures) o NVD (national vulnerabilities database), per verificare le vulnerabilità dei vari componenti. Anche utilizzando degli strumenti di analisi composizione del software. Buona pratica è iscriversi agli alert via mail di nuove vulnerabilità collegati ai componenti utilizzati
- Usare solo componenti provenienti dalle fonti ufficiali e da link sicuri. Sempre preferire pacchetti con firma digitale per ridurre la possibilità che essi siano stati modificati o iniettati con codice malevolo
- Monitorare librerie e componenti non più manutenuti o sui quali non vengono rilasciati fix di sicurezza. Se non è possibile patchare, considerare di mettere in produzione delle patch virtuali che monitorano, rilevano o proteggono contro il problema riscontrato.
Ogni organizzazione deve assolutamente mettere in atto un piano per il monitoraggio, l’analisi e l’applicazione degli aggiornamenti o dei cambi di configurazione, per l’intero ciclo vita dell’applicativo.
