DevSecOps: cinque motivi per cui non si parla di sport

Di Mike Bursell, Chief Security Architect, Red Hat

Ci sono i Mondiali di calcio, ma ci sono anche basket, pallavolo, rugby, Wimbledon – più tornei sportivi di quanti si possano seguire con attenzione. A me piace guardare diversi sport – attività nella quale eccello, a differenza delle mie capacità nel praticarli – e mi domandavo quale sport possa essere considerato simile al mondo del software e, nello specifico, accostato al processo utile e diffuso dei DevOps. E mi sono reso conto che se c’è una cosa che è davvero diversa dallo sport, questa sono proprio i DevSecOps. Ecco alcuni esempi.

1.     Non si può dare la colpa al portiere

Mi dispiace esordire con un esempio così specifico, ma è uno a cui tengo: soprattutto perché quando si sceglievano le squadre a scuola ero spesso l’ultimo, e finivo per fare il portiere, il ruolo meno ambito. Quando la palla sfrecciava o rotolava di fianco a me per finire in rete, la colpa veniva sempre addossata a me.

Non solo è negativo da un punto di vista del morale del gruppo, ma non dovrebbe neanche riflettere il modo in cui un team lavora. Sono sempre un po’ cauto con la frase “con il DevSecOps, la sicurezza è responsabilità di tutti”, perché non tutti sono esperti di sicurezza, ma ognuno deve prendersi una parte della responsabilità legata alla comprensione e all’adesione ai processi autorizzati, e la colpa non dovrebbe mai essere addossata a un’unica persona quando qualcosa va storto. E non dimenticate: con DevSecOps si ha sempre la possibilità di sistemare ciò che è andato storto, di farlo rapidamente e di prevedere dei test al fine di non essere più esposti alla stessa vulnerabilità.

2. Non conosci il tuo avversario

Quando si pratica uno sport, di solito è abbastanza chiaro chi è l’avversario, dove si trova e che cosa sta facendo. Potreste non essere in grado di fermarli sempre, ma sapete chi sono e che cosa stanno cercando di ottenere. Con il DevSecOps questo è ancora meno vero che con altri progetti software perché si sviluppano, testano e gestiscono molteplici strati dello stack, e gli avversari potrebbero essere molti, con diverse competenze, skill e risorse. La buona notizia è quel ‘si sta’. Se si lavora come un vero team, la conoscenza combinate dei vari esperti può essere applicate su strati di astrazione in modi tipicamente molto difficili nel modello “design, develop, test, deploy” standard, il che ti offre maggiori informazioni circa nuovi modi per potenziare la sicurezza del progetto.

3. Non giochi con le stesse regole dei tuoi avversari

Questa è difficile. Nello sport ci sono delle regole ed entrambe le parti devono seguirle, altrimenti l’arbitro li sanzionerà. Sarebbe bello vivere in un mondo in cui i malviventi vengono sempre presi e puniti quando attaccano la tua infrastruttura e le tue applicazioni, ma, purtroppo, non è così. Poiché è improbabile riuscire a inseguire l’avversario in tempo reale con un contrattacco attivo, bisogna considerare quali forme di difesa possono essere considerate, come implementarle e in quanto tempo possono essere efficaci. E’ fondamentale che questa attività non sia destinata unicamente al team di sicurezza. Anche se gli esperti potrebbero fornire previsioni accurate circa gli attacchi probabili, sono le persone dell’engineering e delle operation a essere meglio posizionate per anticiparne l’impatto sul sistema, e che quindi dovrebbero disegnare le contromisure più appropriate.

4. L’intera squadra gioca sempre, per tutto il tempo

Nella maggior parte degli sport di squadra, è possibile avere solo una parte del team in campo. Una delle gioie di DevSecOps è che tutti possono essere coinvolti nell’intero processo. L’allenatore non deve stare in panchina, ma può coinvolgere lo psicologo, l’esperto di performance e il tecnico in qualunque momento. Poiché l’iterazione è costante, non ci vorrà molto prima che ogni membro del team abbia la possibilità di contribuire.

5. Si può perdere, anche ripetutamente

Se pensiamo allo sport, vogliamo che la nostra squadra vinca sempre. In realtà, i migliori sportivi sanno anche perdere, e come far tesoro delle sconfitte per ritornare ancora più forti. In tema di DevSecOps dovremmo incoraggiare i nostri team a fallire – spesso e velocemente – perché è solo attraverso l’esperienza e l’osservazione del fallimento che applicazioni e progetti saranno migliori. Nessuno crede più che sistemi o applicazioni siano invulnerabili: non si tratta di se, ma di quando si verrà attaccati. E’ così che dovete progettare i processi: monitorate alla ricerca di comportamenti anomali, siate pronti a mitigare ma, soprattutto, assicuratevi di disporre di processi per capire che cosa non ha funzionato e realizzare progetti – e team – più robusti e resilienti nella prossima iterazione.

Conclusione

Non voglio dire che non ci sono similitudini tra DevSecOps e lo sport: ci sono, ovviamente, molte sovrapposizioni. L’intenzione di cambiare deve prevedere un impegno dall’alto, così come dal basso; l’importanza di creare un team i cui membri comunicano bene tra di loro e la capacità di reagire alle minacce in real-time. Non è sempre tutto incentrato sulle differenze. A volte però è più utile confrontare le differenze piuttosto che le similitudini. Buone vacanze di sport – e di DevSecOps.