In che modo Atlassian applica le best practice nella sua infrastruttura cloud

Quasi tutti i nostri account AWS vengono scansionati ogni ora e i risultati vengono comunicati al team di sicurezza. Per consentire ai nostri sviluppatori di muoversi velocemente e rimuovere la sicurezza come gatekeeper, però, non ci siamo fermati qui. Al contrario, abbiamo integrato Cloud One - Conformity con la nostra pipeline di vulnerabilità che archivia i ticket Jira per qualsiasi risultato che scopriamo attraverso queste scansioni. I nostri sviluppatori vivono e respirano Jira giorno dopo giorno, quindi far emergere queste informazioni qui è molto più naturale per loro che dover cercare questi risultati in uno strumento di terze parti o aver bisogno di sicurezza come intermediario.

Chiunque abbia mai provato a implementare uno scanner di sicurezza all'interno di un'organizzazione sa di non essere mai impostato e dimenticato. Al contrario, richiedono una messa a punto per garantire che producano solo risultati significativi. Ogni ambiente aziendale è diverso e, in particolare, su larga scala, esistono casi edge che gli scanner non prevedono. Ad esempio, la nostra PaaS interna applica una serie di best practice sviluppate in collaborazione con il team di sicurezza. Alcune delle configurazioni che ne derivano sono sicure in questo contesto, ma lo scanner continuerà a segnalarle perché in genere non lo sarebbero. Di conseguenza, abbiamo dedicato del tempo a perfezionare il set di regole che ci interessano.

Nella nostra prima iterazione, abbiamo deciso di concentrarci sui nostri account AWS di massima gravità. Questi account conservano i dati dei nostri clienti o gestiscono la nostra infrastruttura, ad esempio il nostro CI/CD. Inoltre, abbiamo ridotto il set iniziale di regole a quelle che consideriamo di elevata gravità. Abbiamo quindi lavorato a stretto contatto con i team che possiedono questi importanti account AWS per garantire che tutti i risultati offrano un vantaggio significativo per la sicurezza. Sulla base di questo feedback, abbiamo modificato la configurazione delle nostre regole per adattarle direttamente alla nostra organizzazione. Solo per questo sottoinsieme di account e regole stiamo creando ticket Jira, poiché abbiamo verificato la qualità di questi risultati.

La prossima iterazione è già iniziata e sta espandendo l'ambito degli account che hanno creato ticket Jira, oltre a includere altre regole che vengono esaminate. Alla fine, tutti i nostri account AWS saranno sotto il nostro SLA di sicurezza e ogni controllo sarà stato esaminato e configurato in base alle specifiche del nostro ambiente.

Continuiamo inoltre a lavorare a stretto contatto con il team Conformity, che risponde al nostro feedback e risolve rapidamente eventuali bug che scopriamo nel loro prodotto. Sono bravi a includere le nostre richieste di funzionalità nella loro roadmap e ci tengono sempre informati su quando il lavoro inizia su tutto ciò che ci interessa. In questo modo, continuiamo ad aumentare il valore che il loro servizio ci offre, il che si traduce direttamente in un approccio alla sicurezza in continua crescita.

Quando il ricercatore di sicurezza "benmap" si è presentato di recente al DEF CON 27, la comunità ha appreso come i volumi pubblici di EBS vulnerabili possano lasciare un'azienda, ricordando a tutti che non solo i bucket S3 possono essere resi pubblici e contenere informazioni sensibili. Naturalmente, abbiamo indagato sul nostro ambiente per individuare tali volumi pubblici. Poiché Conformity stava già scansionando attivamente tutti i nostri account, siamo stati in grado di eseguire un'indagine rapida che ha fornito un quadro completo di tutti i volumi pubblici e abbiamo potuto rapidamente confermare che nessuno di essi conteneva informazioni sensibili. Inoltre, saremo avvisati di eventuali volumi futuri resi pubblici e potremo assicurarci di non esporre alcuna informazione sensibile attraverso di essi.

Come utile effetto collaterale, queste scansioni forniscono ai team una funzione di forzatura per entrare nei propri ambienti e ripulire eventuali risorse obsolete rimaste dagli esperimenti di sviluppo. Atlassian consente ai nostri sviluppatori di iterare rapidamente, provare nuove funzionalità e innovare i nostri servizi. In qualità di team di sicurezza, siamo responsabili di assicurarci che questi esperimenti avvengano in un ambiente adatto e in un modo che non metta a rischio i dati dei clienti. Parte di questa responsabilità è garantire che le risorse inutilizzate vengano pulite e Conformity ci aiuta a raggiungere questo obiettivo. Informiamo gli sviluppatori delle risorse con configurazioni non sicure e a volte gli sviluppatori si rendono conto di non aver più bisogno di tali risorse ed eliminarle.