Cosa deve contenere la politica di sicurezza delle informazioni per lo sviluppo software?
Una politica di sicurezza delle informazioni per lo sviluppo software è il documento in cui si definisce come la vostra organizzazione gestisce la sicurezza delle informazioni, dei sistemi e del codice. Per un'azienda di software riguarda due aspetti contemporaneamente: la sicurezza di ciò che costruite e la sicurezza dell'ambiente in cui lo costruite. Entrambi dovrebbero rientrare nello stesso documento, sebbene dal punto di vista dei contenuti si tratti di argomenti diversi.
In concreto, questo significa che la politica di solito affronta l'ambito di applicazione (quali sistemi e quali progetti di sviluppo rientrano), le responsabilità (chi decide, chi gestisce, chi controlla), il modo in cui viene regolato l'accesso al codice sorgente e agli ambienti di sviluppo, come vengono identificate e corrette le vulnerabilità nel codice proprio, come vengono gestiti gli ambienti di test rispetto agli ambienti di produzione, come vengono registrati gli incidenti e come la politica stessa viene mantenuta e revisionata. Un questionario di un cliente spesso richiede proprio questo tipo di documenti come prova, non una descrizione tecnica del vostro codice sorgente.
Due livelli: il prodotto e la catena di sviluppo
Il primo livello riguarda il prodotto: il software che fornite ai clienti. Vi rientra una descrizione di come gestite le vulnerabilità scoperte dopo la consegna, come gli aggiornamenti e le patch raggiungono i clienti, e chi all'interno dell'organizzazione è responsabile di seguire le segnalazioni su problemi di sicurezza nel prodotto.
Il secondo livello riguarda la catena di sviluppo: l'ambiente in cui lavora il vostro team. Si tratta dell'ambiente di controllo versioni, della pipeline di build e test, e della separazione tra ambienti di test e di produzione. Qui si affrontano domande come chi può accedere al codice sorgente, come vengono controllate le modifiche prima che diventino operative, e come viene revocato l'accesso quando qualcuno lascia il team. Entrambi i livelli possono rientrare nello stesso documento, ma spesso vengono descritti separatamente perché i rischi e i responsabili ad essi associati differiscono.
Perché un cliente vi chiede questo
Le organizzazioni che rientrano esse stesse nell'obbligo di diligenza sono obbligate a valutare i rischi presso i loro fornitori. Un'azienda di software che sviluppa per una tale organizzazione riceve quindi domande che non derivano da un obbligo proprio, ma dalla catena di fornitura. Una politica di sicurezza delle informazioni è spesso il primo documento richiesto, perché mostra in un unico documento come la sicurezza è stata affrontata in modo strutturato. Se manca, dovrete spiegare ogni aspetto separatamente in un questionario, il che richiede più tempo e risulta meno convincente di un documento esistente.
Se la vostra organizzazione rientra essa stessa nell'obbligo di diligenza, nella catena di fornitura, o in nessuno dei due, non è immediatamente evidente. in poche domande si vede dove si trova la vostra organizzazione secria.eu fornisce una prima indicazione a questo proposito, con la relativa spiegazione.
Come questa politica si relaziona con le singole misure
Una politica di sicurezza delle informazioni non esiste per se stessa. Descrive a livello generale come affrontate la sicurezza, mentre le singole misure — controllo degli accessi, backup, registrazione degli incidenti, valutazione dei fornitori — rappresentano l'esecuzione concreta di essa. Chi redige la politica senza avere in ordine le misure sottostanti, ha un documento che non corrisponde alla pratica. Anche l'inverso è problematico: misure isolate senza una politica onnicomprensiva sembrano frammentarie a chi le esamina. secria.eu fornisce una panoramica di tutti gli argomenti per ogni situazione mostra come questi componenti sono collegati tra loro.
Cosa spesso manca nella pratica
In molte prime versioni di una tale politica manca un chiaro responsabile per ogni sezione: chi è responsabile di mantenere aggiornata la politica di accesso, chi della politica di patch. Spesso manca anche una data fissa di valutazione, per cui una politica di due anni fa viene ancora presentata come attuale mentre la linea di sviluppo è nel frattempo cambiata. E un terzo punto che spesso non c'è: un collegamento esplicito tra la politica e le prove che dimostrano che viene effettivamente implementata, come i log dei diritti di accesso o un elenco delle patch applicate.
Valutare la vostra situazione specifica
Quali elementi esattamente ci si aspetta dipende dal ruolo della vostra organizzazione nella catena di fornitura e da ciò che chiede uno specifico cliente. Questo articolo descrive la struttura comune, non un modello obbligatorio, e il testo della legge stesso non prescrive un layout fisso. Per una valutazione della vostra situazione specifica, un avvocato o l'autorità di vigilanza competente sono la parte appropriata; le domande frequenti su questo tipo di documenti fornisce una panoramica supplementare di ciò che viene spesso chiesto.
Volete vedere come una tale politica, insieme alle misure sottostanti e alle prove, viene mantenuta in un fascicolo continuo invece che come documento separato? come secria.eu costruisce e mantiene le informazioni lo mostra. Altrimenti cominciate con la verifica NIS2 gratuita, oppure sfogliate la banca di conoscenze per vedere quali argomenti sono rilevanti per la vostra organizzazione.