Owasp Capitolo 5: una tra le più importanti vulnerabilità del sistema è quella relativa agli errori da parte di un esperto
Al quinto posto troviamo gli errori di configurazione, che guadagnano una posizione rispetto al 2017!
Quante volte avete sentito dire che la vulnerabilità numero uno di un sistema si trova fra il monitor e la sedia?
In questo caso tale affermazione assume un valore tutto nuovo, nel momento in cui anche un esperto può commettere l’errore di distrazione o per pigrizia, di non configurare correttamente un componente dal punto di vista della sicurezza informatica. In crescita dalla quinta posizione troviamo proprio questo elemento, ovvero errori di configurazione che possono potenzialmente sfociare in incidenti informatici.
Un applicativo potrebbe essere vulnerabile se…
- Manca la messa in sicurezza di ogni parte dello stack applicativo o i permessi di accesso sui servizi cloud non sono configurati correttamente
- Funzionalità non necessarie abilitate e/o installate (porte non necessarie, servizi, pagine, account o privilegi)
- Account e password di default abilitati e mai cambiati
- Errata gestione degli errori e delle eccezioni che possono rivelare troppe informazioni sullo stack
- Funzionalità avanzate e recenti di sicurezza disabilitate e/o non configurate correttamente sui sistemi aggiornati
- I settaggi di sicurezza nell’application server, nei framework, librerie e database non impostate su valori sicuri
- Server che non inviano gli header relativi alla sicurezza
- Il software è vecchio o vulnerabile
- Questo ci fa capire che è necessario stabilire un processo, orchestrato e ripetibile, di verifica delle configurazioni dei sistemi.
Come difendersi?
- Diventa necessario implementare processi di installazione sicura, come ad esempio: un processo di messa in sicurezza, rende facile e veloce il deploy di un altro ambiente che sia correttamente configurato. Gli ambienti di sviluppo, produzione e controllo qualità dovrebbe essere configurati nello stesso identico modo, con credenziali diverse per ogni istanza. Questo processo dovrebbe essere automatizzato per minimizzare lo sforzo richiesto per ricreare un nuovo ambiente sicuro
- Avere piattaforme essenziali, senza funzionalità, componenti, documentazione ed esempio non necessari. Rimuovere o non installare funzioni e frameworks non utilizzati
- Implementare, come parte del processo di patch management, anche dei processi di verifica, aggiornamento e revisione di tutte le configurazioni e della documentazione. Revisionare anche i permessi di accesso agli storage in cloud (ad esempio i permessi dei bucket S3)
- Suddividere l’architettura dell’applicativo, a livello di componenti o di tenant, tramite la segmentazione, la containerizzazione e i gruppi di sicurezza su cloud (ACLs)
- Inviare ai client le direttive di sicurezza (Security Headers)
- Implementare processi automatizzati per verificare l’efficacia e l’efficienza di configurazioni e settaggi in tutti gli ambienti.
