SDL (Parte 7: Stima rischi)

Stima rischi
Lo scopo della stima dei rischi del prodotto è chiarire il livello di impegno necessario al compimento dei requisiti SDL. Sarà quindi necessario identificare:
·         Quale parte del progetto richiede un threat model prima del rilascio
·         Quale parte richiede un security design review
·         Quale parte ha bisogno di test funzionali
·         Dove applicare i Fuzz test
Valutazione dei rischi del sistema
Per capire in che grado il nostro sistema è sottoposto a vulnerabilità, in Microsoft, hanno riunito i loro esperti in sicurezza per stilare un utile questionario:
Setup Questions
·         In quale sistema operativo verrà installato il software?
·         Il sistema di installazione ha bisogno della password dell’amministratore?
·         L’applicazione configura l’Access Control List? Se si, perchè non si stanno usando le configurazione di default?
·         Viene modificato lo schema di servizio dell’Active Directory? Se si, cosa cambia?
Attack Surface Questions
·         La feature è installata di default? Se si, perchè?
·         è eseguita di default? Se si, perchè?
·         è eseguita con privilegi alti? Se si, perchè?
·         Sta in ascolto su una rete? Se si, che porta usa?
·         Ha connessioni di rete accessibili da internet? Se si, perchè non sono ristretti a un set di indirizzi più piccolo?
·         Setta delle policy nel firewall? Se si, qual’è la policy?
·         Ha connessione non autenticate alla rete? Se si, quali sono e perchè?
Mobile-Code Questions
·         Vengono usati ActiveX? Usano l’interfaccia IDispatch? Se ce ne sono, perchè ci sono?
·         Perchè non sono stati sviluppati componenti in .NET o Java invece che ActiveX?
·         Se devi usare ActiveX, è stata abilitata la proprietà safe for scripting? Se si, perchè?
·         La feature include script code? Se si, cosa fa e che linguaggio usa?
Security Feature-Related Questions
·         L’applicazione implementa un qualsiasi meccanismo di sicurezza come l’autenticazione e/o l’autorizzazione?
·         L’applicazione implementa o usa (meglio) un sistema di crittografia?
General Questions
·         È un nuovo prodotto? Se no, quanto è grande il delta con la versione precedente?
·         Questo prodotto ha avuto bug di sicurezza? Se si, in che numero?
·         Sono stati fatti dei test in profondità nella versione precedente?
·         L’applicazione parsa files o traffico di rete?
·         L’applicazione fa query ad un db?
·         L’applicazione include un’applicazione o un filtro Internet Server Application Programming Interface (ISAPI)
·         L’applicazione include codice d’esempio?
·         Che tipo di meccanismi di estensione ha?
·         Che tipo di componenti può donwloadare ed eseguire?
·         L’applicazione ha componenti user-mode o kernel-mode?
·         L’applicazione interagisce con servizi o processi elevati?
 
Analisi del questionario
Anche se non esistono risposte perfette alle domande del questionario, se rispondiamo in maniera affermativa alla maggior parte di quelle domande, allora siamo nella cacca :D
Il motivo è semplice, il nostro security team dovrà analizzare in profondità il lavoro svolto dagli sviluppatori, per valutare le difese sul lavoro svolto.
Ecco alcune regole generali alle quali il gruppo farà riferimento:
·         Tutti i metodi e leproprietà di tutti gli ActiveX devono essere riviste per verificarne l’affidabilità
·         Se è un nuovo applicativo, richiederà un accurato design review
·         Se ha un’interfaccia di rete, se ha interazione di tipo kernel-mode o un user-mode, se gira con alti privilegi o se ha una feature per la sicurezza, deve essere threat modeled
·         Il codice d’esempio deve avere lo stesso standard e la stessa qualità del codice che verrà rilasciato, quindi dovrà seguire le richieste SDL
·         Se l’applicazione fa parsing di dati allora dovrà essere sottoposta a Fuzz Logic (vedremo in futuro)
Valutazione dell’impatto sulla Privacy
Giusto per capire tutti gli acronomi ecco una tabella che potrà tornarci utile in futuro:
Data Type
Description
Anonymous data
Dati non univoci o che non possono essere legati a un utente specifico e che non possono essere usati per rintracciare la persona a cui i dati fanno riferimento.
Questi dati possono includere colore dei capelli, configurazione del sistema, il metodo con il quale il prodotto viene venduto  (retail, online, and so on), etc.
 
Se i dati anonimi sono associate con il personally identifiable information (PII), questi dovranno essere trattati come PII.
 
 
Personally identifiable information (PII)
Dati che identificano in maniera univoca un utente (nome, indirizzo, numero di telefono, indirizzo e-mail, etc).
-o-
Dati correlate o mixati con il PII, per esempio, salvataggio demografico con dati PII dell’utente o ID che può esser collegato al PII dell’utente.
-o-
Dati sensibili al PII.
 
 
Sensitive PII
Dati che identificano un individuo e potrebbero facilitarne il furto di identità o la frode:
Numero carta di credito, numero carta d’identità, codice fiscal o numero conto corrente (in america possono essere il social security numbers o il tax IDs).
-o-
Dati mixati o legati con PII e usati come chiave di autorizzazione, come password o PINs (personal identification numbers), informazioni biometriche usate come riconoscimento, cognome della madre prima del matrimonio, etc.
-o-
Dati che possono essere mixati o correlate al PII e possono essere usati per discriminare, come preferenze sessuali o abitudini sessuali, politiche o religiose, razza o etnia, etc.
-o-
Dati legati al PII e che contengono la storia medica (operazioni, malattie, allergie etc) o informazioni finanziari.
-o-
Dati sconosciuti al momento in cui vengono presi ma che contengono informazioni di tipo PII, esempio un raw memory dump.
 
 
 
Privacy Ranking 1
·         Il PII viene salvato o trasferito ad un’altro software o agli sviluppatori
·         L’applicazione è rivolta ai bambini
·         Monitorizza le azioni dell’utente
·         Installa un nuovo software o cambia l’associazione delle estenzioni dei files, o l’home page, o la search page o altre configurazioni del sistema.
Se una delle precedenti affermazioni fa al caso vostro, dovrete collocare la vostra applicazione nella fascia più alta della tabella di privacy ranking.
Privacy Ranking 2
Se l’applicazione trasferisce i dati in maniera anonima ad altre applicazioni o agli sviluppatori.
Privacy Ranking 3
Se l’applicazione non può essere catalogata con un ranking precedente allora verrà catalogata con il livello 3.
Mettere tutto insieme
Una volta determinato il livello di rischio di sicurezza e privacy, potremo stimare il tempo di cui abbiamo per ridurre i rischi del nostro cliente.
 

 

Tags: