SecOps, DevSecOps, SecDevOps… la sicurezza al centro dell’azione di delivery

Per fortuna che esistono gli acronimi! Senza di essi che mondo sarebbe!! (ok, mi sono ispirato ad una famosa pubblicità nostrana :-))

Senza acronimi, però, il mondo dell’IT sembrerebbe in stallo perenne e alcuni temi portanti finirebbero pericolosamente nel dimenticatoio, sopraffatti dalla moda del momento.

In questo caso la domanda è banale: ma serve creare un nuovo acronimo per ricordarci ancora oggi che gli aspetti di Sicurezza devono essere al centro delle attenzioni dei team di delivery? Ovviamente, no! Ma forse può esserci d’aiuto per “rinfrescarci” la memoria.

Abbiamo più volte parlato di sicurezza, anche in relazione al mondo dell’IoT, raccontando come, ad esempio, AgileIoT ponga questo aspetto nei “ballons” fondamentali per la produzione di soluzioni massive di mercato. In ugual modo lo fano Disciplined Agile 2, SAFe e gli altri framework di scaling, per non parlare di Lean. Anche l’ISO ha formalizzato da tempo il proprio standard a riguardo, ovvero l’ISO 27001, che molte aziende si stanno quanto meno impegnando a “capire”.

secdevops

Sia che vogliate chiamarlo SecOps, DevSecOps, SecDevOps, o diversamente, resta il fatto che la Sicurezza è un vostro problema, e come tale dovete ponderare il vostro lavoro quotidiano in sua funzione. L’approccio che si cela dietro questi acronimi trova le fondamenta nel Threat modeling, dove si cerca, pragmaticamente, di identificare, enumerare e priorizzare gli ipotetici rischi ponendosi nei panni di colui che prova a violare i nostri sistemi.

Gli aspetti operativi di questo approccio si legano al value stream generale, specializzandosi in specifiche azioni da parte dei Devs e degli Ops. Un elemento da sottolineare è che applicando DevOps in tutta la sua potenzialità, ottenendo quindi un ambiente di delivery estremamente dinamico, si ha la necessità di rendere tale anche l’approccio alla sicurezza, concretizzando un “fast security approach” (the third way: learning), in modo da avere processi sempre aggiornati ed evitare l’accumulo di debito tecnico in tale area.

Diventa così evidente come ogni nuova iniziativa nasca di base con una serie di quesiti annessi:

  • Quali sono i dati che (andremo) si andrà a raccogliere?
  • Come verranno protetti i dati da attacchi interni ed esterni?
  • Qual è la sicurezza degli ambienti in cui le soluzioni vengono rese disponibili?
  • Che cosa si è imparato dall’esperienza e dalle release precedenti?
  • Quali sono le principali sfide incontrate?

Si tratta di tasselli estremamente importanti nell’impostazione generale del progetto, tanto da impattare, ad esempio, sulla Definition of Done e, di conseguenza, sull’effort complessivo (the first way: flow).

Se si va poi a guardare più da vicino le attività dei Developer, si evidenziano aspetti direttamente correlati alle attività di sviluppo in un’ottica di “secure engineering” (the first way: flow):

  • Implementare modelli adeguati di crittografia e di protezione dei dati;
  • Integrare scansioni di sicurezza automatizzati nei processi di sviluppo e condividerne rapidamente i risultati;
  • Coinvolgere gruppi di “hacking etico” per rafforzare la capacità di realizzare ed eseguire test di penetrazione sempre più efficaci;
  • Fare delle considerazioni sul possibile utilizzo malevole delle API pubbliche e registrarne gli abusi nei sistemi di monitoring;
  • Inserire nel codice strumenti di logging non-invasivo per tracciare adeguatamente i fault di sicurezza;
  • Essere costantemente aggiornati sulle nuove tipologie di attacchi e sulle tecniche di risposta e prevenzione;
  • Sperimentare e condividere successi e fallimenti.

Parallelamente, gli Operation hanno in dote tutti quegli approcci e quelle tecniche che mirano a rendere sicuri gli ambienti di erogazione e raccogliere dati a riguardo (the second way: feedback):

  • Osservare cosa accade in seguito ai nuovi rilasci e come essi impattano sui livelli di sicurezza;
  • Assicurarsi che i software di base siano dotati degli ultimi aggiornamenti;
  • Validare costantemente le autorizzazioni d’accesso e proiettarle verso il livello minimo;
  • Assicurarsi che le diverse postazioni operative siano utilizzate solo da utenti autorizzati;
  • Settare strumenti di monitoraggio, attivi e passivi, che consentano di verificare lo stato di sicurezza in modo automatizzato e creare feedback rapidi sulla base delle informazioni ottenute;
  • Attuare scansioni di networking e tentativi di intrusione per validarne la robustezza;
  • Registrare qualsiasi anomalia e classificarla in funzione dei rischi;
  • Trasparenza e condivisione dello stato generale.

Come ripetiamo da tempo, realizzare oggi una soluzione IT ha un grado di complessità e di ingegnerizzazione completamente diverso da quello di soli cinque anni fa, per cui è necessario una nuova cultura e nuove competenze, permettendo così di sfruttare, inoltre, adeguatamente anche le nuove tecnologie a disposizione.

 

Stay tuned :-)

Comments are closed.