Nella mia azienda, stiamo lavorando per adottare il ciclo di vita di sviluppo sicuro di Microsoft e parte del processo MSDL prevede la definizione di barre dei bug di sicurezza e privacy allinizio di un progetto. Ho sentito il concetto di una barra dei bug prima di MSDL, e capisco che sia essenzialmente una definizione di quale livello / quantità di bug sei disposto ad accettare in un prodotto finale, ma ho non ho mai capito come creare una barra dei bug per un progetto. Esistono processi ben documentati per stabilire le barre dei bug da cui posso imparare?
Ho provato a cercare su Google esempi o scenari di progetti del mondo reale definire le barre dei bug allinizio di un progetto, ma non riesco a ottenere buoni risultati o suggerimenti sul processo di creazione di una barra dei bug. Ci sono esempi di MSDL di quelle che sembrano essere barre di bug completate, ma mi interessa conoscere il processo di definizione di qualcosa di simile. Ad esempio, per coloro che hanno già fatto qualcosa di simile in precedenza, hai definito le barre dei bug in un modo molto specifico (ad esempio dicendo " Non ci deve essere accesso non autorizzato al file system: lettura dal file system ") o hai adottato un approccio differito dicendo che quando troviamo bug li classificheremo su una scala da 1 a 5 (5 è il più grave), stabilisci ora che nessun bug superiore a 3 deve essere spedito e lasciare la tua classifica dei bug finché non vengono scoperti? Mi sembra che provare a fare la prima sia unattività sciocca e impossibile, ma la seconda tende a essere incline alla clemenza quando un progetto sta per finire.
Ancora una volta, per concludere tutto questo in una domanda succinta, qualcuno può fornirmi un approccio ben documentato per la definizione / creazione di barre di bug?
Risposta
Lascia ” Iniziano con una definizione di base di Bug Bar:
Quality gate e bug bar vengono utilizzati per stabilire livelli minimi accettabili di sicurezza e qualità della privacy. Un team di progetto deve negoziare i quality gate (ad esempio, tutti gli avvisi del compilatore devono essere analizzati e corretti prima del check-in del codice) per ogni fase di sviluppo. Una barra dei bug è un quality gate utilizzato per definire le soglie di gravità delle vulnerabilità di sicurezza, ad esempio, nessuna vulnerabilità nota nellapplicazione con una valutazione “critica” o “importante” al momento del rilascio. La barra dei bug, una volta impostata, non dovrebbe mai essere allentata.
Quando un utente di software invia una segnalazione di bug, deve assegnare una categoria STRIDE al bug, indipendentemente dal fatto che il bug sia un bug del client o del server e quale ambito influisce sul bug. Gli utenti possono essere sviluppatori di software e personale addetto al controllo qualità. STRIDE sta per:
- Spoofing
- Tampering
- Repudiation
- Divulgazione di informazioni
- Denial of Service (DoS)
- Elevation of Privilege (EoP)
I valori di “ambito” pertinenti sono
- Client – Interfaccia utente attendibile falsificata in scenario comune / predefinito
- Client: interfaccia utente attendibile falsificata in un altro scenario specifico
- Client: interfaccia utente falsa come parte di uno scenario di attacco più ampio
- Server: utente specifico falsificata o computer su protocollo protetto
- Server: utente casuale o computer falsificato su protocollo protetto
- Client: dati attendibili manomessi che persistono dopo il riavvio
- Client: dati manomessi che non persiste dopo il riavvio
Da lì, viene creata una matrice che assegna un livello di gravità a ciascuna combinazione. I possibili valori per il livello di gravità sono:
- Critico
- Importante
- Moderato
- Basso
- Nessuno
Voce di esempio in matrice (possono essere presenti diverse voci di questo tipo):
STRIDE Categoria: Spoofing
Ambito: Client – Interfaccia utente attendibile falsificata in uno scenario comune / predefinitoDescrizione: Capacità di presentazione da parte dellautore dellattacco uninterfaccia utente diversa ma visivamente identica allinterfaccia utente su cui gli utenti devono fare affidamento per prendere decisioni di attendibilità valide in uno scenario predefinito / comune. Una decisione di fiducia è definita come ogni volta che lutente intraprende unazione credendo che alcune informazioni vengano presentate da una particolare entità: il sistema o una specifica fonte locale o remota.
Livello di gravità: Importante
Microsoft afferma di correggere tutti i bug di importanza “bassa” prima della distribuzione.
Ulteriori letture
Aggiungi una barra dei bug di sicurezza a Microsoft Team Foundation Server 2010
Nuovo SDLC: ciclo di vita dello sviluppo della sicurezza