Attualmente stiamo costruendo un ciclo di vita per lo sviluppo della sicurezza nella nostra società di sviluppo software. La nostra idea principale è di avere un approccio asset-driven, in cui:
- Inserisci le risorse in un inventario di asset mentre il sistema è costruito;
- Determina gli obiettivi di sicurezza per ciascun asset (e implicitamente la criticità del bene);
- Segui le risorse critiche per tutto il loro ciclo di vita e applica le opportune attenuazioni dove lo riteniamo necessario.
Mentre asset come l'hardware e l'infrastruttura generale sono per lo più protetti a seguito di rafforzamento del sistema e altre attività basate su liste di controllo (oltre alla sicurezza fisica), siamo particolarmente interessati alle risorse di dati elettroniche, utilizzate e manipolate dal software.
Dato che il sistema è abbastanza grande e ci sono molti dati in giro, abbiamo scoperto che mantenere l'inventario delle risorse può essere un'attività faticosa. Vale a dire, ci sono molte risorse di dati che richiedono un'elevata integrità in quanto si tratta di un sistema di infrastrutture critiche, quindi non possiamo permetterci di trascurare queste risorse di dati.
Nel nostro approccio ogni asset ha un proprietario, una persona che è responsabile dell'introduzione del bene nell'inventario, e questo è più spesso un architetto che capisce l'immagine più ampia del componente. Tuttavia, i nostri sviluppatori sono liberi di aggiungere nuove risorse di dati secondarie sotto forma di strutture di dati per contenere i risultati del calcolo o del calcolo parziale. La domanda diventa quindi - dovrebbero essere aggiunti all'inventario?
In sostanza, si tratta della granularità delle risorse di dati nel nostro inventario. Se andiamo troppo nei dettagli, creiamo documentazione che non è gestibile, ma se raggruppiamo attività specifiche in categorie di attività rischiamo di perdere risorse specifiche che potrebbero risultare insufficientemente protette.
Quale sarebbe un livello ottimale di granularità? Come ragionerai su questo?
Ulteriori informazioni sul nostro precedente approccio incentrato sul software
Il metodo di modellazione delle minacce MS (descritto in Modellazione delle minacce: progettazione per la sicurezza) era qualcosa che inizialmente implementavamo. Abbiamo sviluppato materiali di formazione e utilizzato lo Strumento per la modellazione di minacce MS nel processo, che è stato insegnato ai nostri architetti di software. Sfortunatamente, il progetto non è stato un successo a causa di diversi fattori, in particolare dei finanziamenti adeguati.
Abbiamo riscontrato diversi problemi con questo approccio, che non siamo riusciti a risolvere correttamente (a causa della nostra mancanza di esperienza). Questo include:
- Sicurezza: è stato difficile convincere il cliente che particolari risorse di dati erano protette senza tracciare le risorse;
- Analisi del rischio - senza esaminare le risorse che un componente software stava manipolando (e in che modo una minaccia potrebbe mettere in pericolo un obiettivo di sicurezza di quell'asset), non siamo stati in grado di determinare il livello di rischio in modo affidabile.
- Priorità di modellazione delle minacce: senza le risorse non siamo stati in grado di determinare quali componenti fossero "più critici", ovvero quali componenti richiedevano un'analisi delle minacce più approfondita e l'aiuto delle risorse molto limitate del team di sicurezza.
Ancora una volta, tutti questi problemi potrebbero essere stati causati dalla nostra inesperienza con il metodo e non da qualsiasi errore del metodo stesso.