Attacking Containerized Systems and Infrastructures

Attualmente, l'utilizzo di piattaforme cloud e l'impiego di containers ricoprono un ruolo sempre più di rilievo per la fornitura dei servizi di cui ci facciamo uso. Questi ambienti, però, non sono immuni alle insidie che il mondo digitale nasconde e, perciò, sono spesso bersaglio di attacchi informatici. È dunque necessario, per chi fornisce un servizio, la piena consapevolezza dei problemi di sicurezza che possono verificarsi nel prodotto finale e, per gli sviluppatori, conoscere le buone norme per lo sviluppo sicuro. Per questo lavoro di tesi, si è deciso di definire un framework per lo sviluppo sicuro di un servizio containerizzato. Esso si compone di due soluzioni: la prima permetterà di rintracciare eventuali vulnerabilità o errori di configurazione, la seconda di attuare delle contromisure in caso di attacco. La trattazione definirà, in prima analisi, i servizi utilizzati e delle possibili criticità, successivamente verranno illustrate le best practices da rispettare per lo sviluppo sicuro. Successivamente, si procederà con la presentazione della prima parte del framework, ovvero la creazione di una pipeline di sicurezza composta da tre tools: Sonarqube che permetterà di effettuare l'analisi statica del codice, OWASP Dependency-check per l'analisi delle librerie e Trivy per quella dei file IaC e delle immagini. Ognuno dei precedenti stages, sarà seguito da un Quality Gate, in grado di bloccare l'esecuzione della pipeline nel caso in cui non vengano rispettati determinati criteri. Il passo seguente, prevede l'uso di Kubescape per la ricerca delle vulnerabilità e degli errori di configurazione all'interno dell'infrastruttura cloud. Per la seconda parte del framework, è stata realizzata una possibile architettura di un Response Engine, che tramite l'applicazione dei concetti di run-time security e di serverless computing, propone di fornire una contromisura automatica in caso di attacco ad un pod. Per la gestione della run-time security all'interno del Response Engine si è scelto di utilizzare Falco e il suo plug-in Falco Sidekick. Il primo ha il compito di generare degli alerts da eventi scatenati da systemcalls, Kubernetes audit logs e AWS CloudTrail, mentre il secondo, quello di raccogliere gli alerts in una dashboard e di inoltrarli sia ad un canale Slack che ad OpenFaas, un tool per la creazione e gestione di servizi Function as a Service. OpenFaas a questo punto, si occuperà dell'ispezione dell'alert e, nel caso in cui esso abbia un alto grado di criticità, di invocare un servizio FaaS che identificherà il pod sotto attacco per poi sospenderlo. Infine, si produrrà un'applicazione containerizzata, scritta in Java SpringBoot e deployata su un cluster Kubernetes, sulla quale verrà applicato il framework. Per concludere, si può constatare che il framework è stato validato in entrambe le sue parti: nella prima, lo si verificherà attraverso il riconoscimento, da parte della pipeline, del 100% delle vulnerabilità volutamente inserite durante lo sviluppo; nella seconda, in seguito alla simulazione di un attacco che il response engine sarà in grado di bloccare.