Come DevSecOps può rendere più maturo il vostro ISMS basato sulla ISO 27001

Prefazione

Cominciamo con un quadro un po' troppo ampio della sicurezza delle informazioni. Perché? Perché è una cosa strana. Quasi tutti la conoscono. La maggior parte delle persone ne è già venuta a contatto direttamente o indirettamente. Ci dicono quanto sia importante e quanto sarebbe grave se si verificasse un attacco informatico. Ma d'altro canto, i responsabili della sicurezza che cercano di implementare le misure di sicurezza devono spesso fare i conti con le resistenze:

  • I "ragazzi della sicurezza" bloccano o rallentano sempre i progetti più redditizi per l'azienda.
  • Gli sviluppatori e gli amministratori di sistema vedono solo il carico di lavoro aggiuntivo dovuto alla sicurezza.
  • Per molti utenti finali sembra una sorta di sport aggirare le misure di sicurezza nel modo più creativo possibile.

Come può essere pratica la sicurezza

Non vogliamo fare i guastafeste, non è sempre così grave come l'abbiamo appena descritto, ma chi lavora nella sicurezza informatica potrebbe riconoscere alcune delle storie di cui sopra da più tempo. Lamentarsi non è il motivo di questo articolo; esso spiega come sia possibile implementare la sicurezza pratica in una fase molto precoce di sviluppo del software utilizzando DevSecOps.

Allo stesso tempo, si ricollega ai sistemi di gestione della sicurezza delle informazioni (ISMS), più teorici e orientati alla conformità, che la maggior parte delle aziende ha oggi. Esistono diverse idee su come combinare i due approcci. Ci concentreremo su una relativamente nuova: OWASP DSOMM, il DevSecOps Maturity Model dell'Open Web Application Security Project.

ISO 27001: ben nota e ampiamente utilizzata

Cominciamo con la ISO 27001, lo standard di sicurezza delle informazioni su cui si basa la maggior parte degli ISMS dei nostri clienti. Mentre la ISO 27001 definisce i requisiti generali, la ISO 27002 associata fornisce un elenco dettagliato dei documenti richiesti e consigliati. Misura i controlli a partire da argomenti organizzativi come un'organizzazione per la sicurezza delle informazioni ben definita sui processi (on/offboarding, risposta agli incidenti, gestione dei fornitori), fino a requisiti dettagliati come una politica sulle password o una matrice ben definita di ruoli e responsabilità.

Cosa serve davvero

Le persone si lamentano dei requisiti e dei controlli delle norme ISO perché cambiano le loro attività quotidiane; è un livello troppo alto. Molti vorrebbero avere requisiti precisi da poter utilizzare e implementare direttamente, ma purtroppo la pura ISO 27001 / 27002 non funziona a questo livello. È necessaria una mappatura tra l'alto livello e l'implementazione pratica di basso livello per le operazioni quotidiane.

Pertanto, ci concentriamo su una nuova idea di mappatura: una parte dei requisiti elencati nella ISO 27002 è un "processo di sviluppo del sistema documentato" (sezione A.14). È qui che entrano in gioco DevSecOps e l'OWASP DevSecOps Maturity Model (DSOMM).

Perché DevSecOps ha senso per la vostra organizzazione

DevOps (combinazione di sviluppo software - "Dev"; e operazioni IT "Ops") è noto da anni anche nel settore dello sviluppo software. Il suo obiettivo è abbreviare il ciclo di vita dello sviluppo dei sistemi e fornire una consegna continua con un'elevata qualità del software. Lo sviluppo software basato su DevOps è spesso implementato nell'ambito di approcci agili come Scrum o Kanban, poiché entrambe le idee mirano allo stesso obiettivo: cicli di vita brevi e consegna continua.

DevSecOps (DevOps con sicurezza profondamente integrata - "Sec") è stato aggiunto a DevOps in un secondo momento, quando ci si è resi conto che l'implementazione della sicurezza già nelle prime fasi di sviluppo presenta diversi vantaggi. I possibili problemi di sicurezza vengono riconosciuti tempestivamente e non è necessario trovare una soluzione durante o in una fase avanzata di sviluppo. Come regola generale, più tardi si identifica un problema di sicurezza nel ciclo di vita del software, più costoso sarà risolverlo.

Identificazione dei problemi di sicurezza

Costi relativi per la correzione dei bug, in base al momento del rilevamento

Occuparsi dei bug di sicurezza già durante la fase di sviluppo (requisiti, architettura, codifica, integrazione, test dei componenti) potrebbe far risparmiare molte risorse - tempo e budget, oltre a una scarsa motivazione del team.

Tornando alle resistenze iniziali che i responsabili della sicurezza devono affrontare, DevSecOps soddisferebbe diverse parti:

  1. In primo luogo, il lato commerciale
    1. non riceve (o almeno meno) "blocchi" tardivi dalla sicurezza
    2. ottiene costi inferiori e progetti più puntuali e in linea con il budget grazie alla correzione precoce dei bug.
  2. In secondo luogo, gli sviluppatori e gli amministratori di sistema
    1. devono affrontare un minor numero di problemi di sicurezza durante i test e l'implementazione, il che potrebbe far risparmiare molto tempo.
    2. si istruiscono automaticamente a farlo nello stesso modo e in modo più sicuro nei progetti futuri, poiché il processo complessivo è stato più semplice e meno frustrante.

Come appena descritto, eseguire lo sviluppo del software con l'approccio DevSecOps presenta molti vantaggi. Il problema è come utilizzare questo approccio piuttosto pratico e orientato allo sviluppo come input per un ISMS basato sulla ISO 27001, ad esempio:

  • come conservare i segreti,
  • come consegnare i parametri riservati, o
  • come fare un inventario dei manufatti in esecuzione e così via.

Questo approccio non gestisce questi argomenti a un livello così dettagliato. L'input è necessario per documentare e dimostrare ciò che viene fatto per raggiungere i controlli specifici della ISO 27002. Chiunque abbia partecipato a un audit basato sulla ISO 27001 sa quanto siano importanti queste informazioni e quanto la maggior parte degli auditor si concentri sulla SoA (Statement of Applicability). La SoA documenta esattamente questi collegamenti tra un controllo ISO 27002 e la misura tecnica o organizzativa che un'azienda ha implementato per affrontarlo.

Combinarli: l'approccio OWASP DSOMM

Anche il team del progetto OWASP DSOMM ha riconosciuto questa esigenza. Recentemente è stata aggiunta una mappatura degli argomenti DSOMM ai controlli ISO 27002. Alcuni dei nostri clienti che lavorano in DevSecOps utilizzano già questa mappatura. Il responsabile ISMS può mappare direttamente le misure eseguite durante il DevSecOps ai corrispondenti controlli ISO 27002 elencati nel SoA. La maggior parte delle mappature DSOMM si riferisce a A.14 (processo di sviluppo del sistema documentato) e alcune a controlli come A.12 (operazioni, backup, monitoraggio, ecc.), quindi la copertura è già relativamente ampia.

Pertanto, l'utilizzo della nuova mappatura DSOMM-ISO27701 potrebbe essere un ponte tra l'ISMS di alto livello e il processo di sviluppo del software di basso livello. Consigliamo vivamente di discutere questo argomento tra i responsabili dei prodotti e dei rischi dei team di sviluppo e i responsabili della sicurezza delle informazioni (CISO). È un passo avanti verso un software più maturo e sicuro. Allo stesso tempo, anche un passo avanti verso un ISMS maturo.

Conclusione

Vi occupate di sviluppo di software nella vostra azienda, sia per uso personale che come prodotto per altri? Vi interessa la sicurezza delle informazioni, non solo a livello teorico ma anche pratico? Allora dovreste assolutamente dare un'occhiata più da vicino a DevSecOps in generale, soprattutto se i vostri team di sviluppo lavorano già in modo agile. Noi di CISO AG vi aiutiamo ad automatizzare le attività di sicurezza principali e a implementarle nel vostro flusso di lavoro DevOps.