Security Logging and Monitoring Failures
Home » Security Logging and Monitoring Failures
Owasp Capitolo 9: l’importanza delle strategie di observability
Alla posizione numero 9, in crescita rispetto al 2017 troviamo questo importante elemento. Più che una vulnerabilità di codice, questa rappresenta una scarsa implementazione delle strategie di observability in ambito sicurezza informatica. Senza un adeguato monitoraggio delle infrastrutture e delle nostre web app, non abbiamo la possibilità di identificare potenziali data breach, infiltrazioni, e quindi impedirci di rispondere in maniera tempestiva a eventi sospetti o attacchi veri e propri.
Entrando nel dettaglio il monitoraggio è importante per vari aspetti, e la mancata osservazione e raccolta dei dati relativi è particolarmente grave in in svariati casi fra cui:
- Eventi verificabili quali login, errati o corretti e transazioni ad alto valore non vengono loggati
- Allarmi ed errori non generano messaggi di allerta o i messaggi stessi sono poco chiari o inadeguati
- I registri delle applicazioni e delle API non sono monitorati in ottica di attività sospette
- I registri sono immagazzinati solo a livello locale
- Soglie di allerta appropriate e i processi di risposta e intervento non sono state studiate a dovere o non sono efficaci
- Attività di penetration test e scansioni effettuate da strumenti di testing dinamici (come Owasp Zap) non scatenano allarmi e/o segnalazione di allerta
- L’applicazione non è in grado di rilevare, scalare e/o allertare il personale in caso di attacchi attivi in tempo real o in semi tempo reale
Un altro problema legato all’attività di monitoraggio è la possibilità per un utente basic (e quindi di riflesso ad un potenziale attaccante) di accedere ai dati e quindi rendere visibili tali dati in maniera indiscriminata, creando di fatto una pericolosa information disclosure.
Come ci difendiamo?
Gli sviluppatori dovrebbero implementare severi controlli sul proprio applicativo. In particolar modo alcuni aspetti particolarmente importanti sono:
- Assicurarsi che ogni login, ogni controllo di accessi, e ogni fallimento lato server della validazione degli input, possano essere monitorati, con un livello di contesto a livello di utenza sufficiente per identificare account malevoli o comunque sospetti, e che tali dati di monitoraggio vengano conservati abbastanza a lungo per permettere eventuali indagini forensi in caso di incidente
- Assicurarsi che i logs vengano generati in modo tale che i sistemi centralizzati di gestione possano raccoglierli e indicizzarli correttamente e facilmente
- Assicurarsi che i log vengano cifrati e codificati correttamente per impedire attacchi e iniezioni malevole a danno dei sistemi di monitoraggio
- Assicurarsi che ogni transazione ad alto valore lascia una traccia verificabile, con controlli di integrità per prevenire la manomissione o cancellazione degli stessi
- I team di DevSecOps dovrebbero adottare monitoraggi efficienti e sistemi di allerta in modo tale che attività sospette vengano identificate e mitigate velocemente
- Stabilire o adottare degli incident response plan e business continuity plan, come ad esempio le linee guida proveniente dal NIST800-61r2 o successivi
Ci sono svariati strumenti, a pagamento e open source che permettono di fare ciò. Alcuni di essi sono framework sui quale gli sviluppatori possono costruire le proprie soluzioni di monitoraggio, ingestione e aggregazione dati, per rendere i flussi di detection and reponse più rapidi ed efficienti, come ad esempio lo stack ELK (Elastic, Logstash, Kibana).