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.