DevSecOps o SecDevSecOpsSec ?

Facciamo una pausa dal nostro excursus sulle conoscenze derivanti dalle varie certificazioni professionali esistenti,che possono essere utili per un buon DevOpper, per parlare di un argomento che ultimamente sta “tenendo banco” nella community del DevOps e che, come molte delle cose relative alla nostra metodologia preferita, non dovrebbe essere neanche argomento di discussione.

Sto parlando del:

Secure DevOps (DevSecOps per qualcuno)

Per coloro che non fossero addentro alla “materia DevOpsica” (ripassare please), da un po’ di tempo si è cominciato a porre l’accento su come e quando la realizzazione di un prodotto software dovrebbe preoccuparsi della sicurezza, in termini di dati, possibili falle e infrastruttura. Quindi, siccome non ci facciamo mancare nulla e il DevOps “va tanto di moda”, si è pensato bene di piazzare un bel “Sec” in mezzo al Dev e l’Ops (come se non fossero già abbastanza separati nella realtà!), un bell’apostrofo rosa tra le parole “sviluppo ma non opero” e “opero ma non mi importa di come sviluppi”.

Perché è sorta quest’esigenza? Perché i simpatici toollivendoli del “prendi quest’applicazione che ti fa il DevOps senza che tu debba pensare più a nulla”, essendo riusciti nel loro principale intento, cioè quello di aumentare il fatturato annuo delle proprie aziende, hanno ulteriormente aggravato il divario (culturale ricordiamocelo) tra i due gruppi, aggiungendo gravi problemi di sicurezza al già precario funzionamento di molte applicazioni prodotte grazie ai loro fantasmagorici tools.

Come è successo? E’ abbastanza semplice e si riassume in una frase:

“La sicurezza è una grossa rottura di scatole”.

Pensare un’applicazione sicura vuol dire, per prima cosa, STUDIARE. Studiare il Contesto di Business per analizzare i possibili rischi, studiare il Contesto Applicativo per capire quali parti dell’applicazione stessa possano essere più esposte di altre e studiare il Contesto Infrastrutturale per capire se e come l’ambiente in cui la nostra applicazione andrà ad operare possa mitigare o aumentare i rischi di sicurezza sull’applicazione stessa.

Per cui, come per molte cose del DevOps, è necessaria una certa dose di Comunicazione, molta Partecipazione e parecchia Traspirazione.

La maggior parte degli sviluppatori a cui venga chiesta un’attenzione alla sicurezza già in fase di sviluppo, invece, vi risponderà in questo modo:

“Io sviluppo, mica posso pensare pure a quello che succede dopo, già mi chiedono di dare una mano a quei rompiscatole delle Operations, mo’ pure la sicurezza? Non ci sono i firewall e i WAF per quello?”

No Ciccio, almeno sul cloud se è necessario o meno l’uso di un servizio WAF (per citarne uno) devi dirmelo tu, prima.

Invece, quando si è dato ai nostri fantastici eroi gli strumenti (cloud o non cloud) per accelerare il ciclo di rilascio delle applicazioni, questi li hanno usati per come gli sono stati dati, senza andare oltre quello che facevano (loro) in precedenza. Ergo, coloro che non pensavano le applicazioni in termini di sicurezza prima, quando operavano in ambienti tradizionali, non lo hanno fatto neanche dopo, quando si sono ritrovati nell’acceleratore del Cloud e del “Continuous Beta”.

Risultato? Un panorama desolante di applicazioni che hanno buchi che neanche le Top Ten OWASP dei primi anni del web prendono più in considerazione.

Questo perché, soprattutto in cloud, nell’ambito di un modello di sicurezza che si basa sulla Shared Responsability, chiunque esponga un servizio o un’applicazione su web deve preoccuparsi IN PRIMA PERSONA di attivare PREVENTIVAMENTE tutte le policy e i servizi disponibili sul provider di turno, per far si che la sua applicazione venga acceduta ed eroghi tutte e sole le informazioni che deve erogare.

Non a caso i signori di Amazon AWS hanno messo la sicurezza come principale pillar del loro ottimo framework Well Architected Applications e, sempre non a caso, sta “tornando di moda” una figura mitologica che si era quasi estinta nell’era del codice “un tanto al chilo”, l’Architetto (l’Ingegnere?) del Software, meglio se Evolutionary, perché si è ricominciato a capire che prima di scrivere del codice bisogna “pensare” l’applicazione e serve qualcuno che sappia sfruttare al meglio TUTTI i servizi che il cloud sforna di continuo, in particolare in ambito sicurezza (ma sto divagando come al solito).

A me invece è capitato di sentire persone in posizioni direttive dire:

“La sicurezza non può essere un freno all’innovazione”

Salvo poi defilarsi all’ennesimo orrore trovato in una delle “applicazioni innovative” che avevano avallato.

Ma il concetto di “sicurezza preventiva” è davvero così nuovo? Oppure ci troviamo davanti ad un’altra “regola del buon senso” ignorata per troppo tempo?

In verità qui siamo ancora una volta incappati nel “trappolone” che ci tende sempre l’accelerazione dovuta al cloud quando non è accompagnata da una consapevolezza delle cose che ci si vanno a fare (non bastano i firewall e i WAF?), nonché all’inasprimento della Guerra della Sicurezza che si sta combattendo ormai costantemente con coloro che vorrebbero usare i nostri server e/o i nostri dati per operazioni non lecite.

Quindi? Quindi a mio parere, come ho anticipato nel titolo, il Sec non va messo solo tra Dev e Ops, ma anche PRIMA e DOPO, come?

Magari facendoci aiutare dal nostro amico Deming e dal suo Ciclo PDCA:

• Plan – Quando analizzi e progetti la tua applicazione, valuta a quali rischi stai esponendo i tuoi dati e quali parti saranno più vulnerabili di altre; decidendo quindi quali saranno le contromisure e i servizi di sicurezza che sarà necessario attivare. (aka, ribadisco, se ti serve il servizio WAF del cloud, devi prevederlo e metterlo a budget “a monte”).
• Do – Quando scrivi la tua applicazione effettua un controllo costante della qualità del codice anche in termini di policy di sicurezza, magari “innestandovi” framework pensati per quello e, quando la esercisci, adotta le contromisure ed i servizi che avevi individuato in fase di Plan.
• Check – Verifica costantemente lo stato della tua applicazione, dei tuoi sistemi e dei tuoi dati, in particolare quando vengono rese note nuove vulnerabilità e nuove tipologie di attacco.
• Act – Definisci e individua le contromisure necessarie a “turare le falle” evidenziate nella fase precedente e… ricomincia dal Plan.

E non è che si dovesse aspettare il DevSecOps per fare tutto questo, ma sarebbe dovuta essere “buona pratica” da quando si è cominciato a mettere pagine su un sito web.

E’ una mia “elucubrazione mentale” eccessiva?

Forse, ma ho la sensazione che i signori di OWASP, nella loro Top 10 del 2017 hanno percepito la stessa esigenza di chiarezza sulla “Continuous Security Improvement”, soprattutto in termini di Check e Act, in particolare quando alle “classiche” cautele sulle Injection e l’XSS hanno aggiunto concetti nuovi quali l’Insecure Deserialization e, soprattutto, l’Insufficient Logging&Monitoring.

Per concludere.

A mio modesto parere, dire DevSecOps, invece di DevOps, implica mettere in risalto un aspetto di design e controllo dei prodotti software, la Sicurezza, che dovrebbe essere così “endemico” da essere pleonastico citarlo esplicitamente (o metterlo in una sigla “perché fa tendenza”), almeno per un DevOpper competente come lo intendiamo noi.

Alla prossima.