Qual è il processo di creazione di una bug bar?

3

Nella mia azienda, stiamo lavorando all'adozione del ciclo di vita di Microsoft Secure Development e parte del processo MSDL prevede l'instaurazione di barre di sicurezza e di privacy all'inizio di un progetto. Ho sentito il concetto di una barra dei bug prima di MSDL, e capisco che è essenzialmente una definizione di quale livello / quantità di bug siete disposti ad accettare in un prodotto finale, ma non ho mai capito come creare un bug bar per un progetto. Esistono processi ben documentati per stabilire le barre dei bug da cui posso imparare?

Ho provato a fare qualche ricerca su Google per esempi o scenari di progetti reali che definiscono le barre dei bug all'inizio di un progetto, ma non riesco a ottenere alcun risultato o suggerimento sul processo di creazione di una barra dei bug. Esistono esempi MSDL di ciò che sembra essere una barra di errore completata, ma io Sono interessato a conoscere il processo di definizione di qualcosa di simile. Ad esempio, per coloro che hanno già fatto qualcosa del genere, hai definito le barre degli errori in un modo molto specifico (ad esempio, "Non ci sarà accesso non autorizzato al file system: lettura dal file system"), o hai fatto una differita approccio di dire quando troveremo bug li classificheremo su una scala da 1 a 5 (5 è il più grave), stabilisci ora che nessun bug sopra un 3 deve essere spedito, e lascia il tuo ranking di bug fino a che non vengono scoperti? Ho l'impressione che provare a fare il primo sia un'attività sciocca e impossibile, ma la successiva è incline a privilegiare la clemenza quando un progetto sta arrivando al filo.

Ancora una volta, per riassumere tutto ciò in una succinta domanda, qualcuno può fornirmi un approccio ben documentato per la definizione / creazione di barre dei bug?

    
posta butallmj 14.03.2014 - 21:18
fonte

1 risposta

3

Iniziamo con una definizione di base per Bug Bar:

Quality gates and bug bars are used to establish minimum acceptable levels of security and privacy quality. A project team must negotiate quality gates (for example, all compiler warnings must be triaged and fixed prior to code check-in) for each development phase. A bug bar is a quality gate which is used to define the severity thresholds of security vulnerabilities—for example, no known vulnerabilities in the application with a “critical” or “important” rating at time of release. The bug bar, once set, should never be relaxed.

Quando un utente di un software presenta una segnalazione di bug, deve assegnare una categoria STRIDE al bug, sia che il bug sia un bug di un client o di un server, sia quale ambito sia interessato dal bug. Gli utenti possono essere sviluppatori software e personale addetto al controllo qualità. STRIDE sta per:

  • spoofing
  • Manomissione
  • Ripudio
  • Informazioni sull'informazione
  • Denial of Service (DoS)
  • Elevazione di privilegio (EoP)

I valori "ambito" rilevanti sono

  • Client - Interfaccia utente attendibile con spoofing nello scenario comune / predefinito
  • Cliente - Interfaccia utente affidabile con spoofing in un altro specifico scenario
  • Client - Interfaccia utente falsificata come parte di uno scenario di attacco più grande
  • Server: specifico utente o computer con spoofing su protocollo sicuro
  • Server: utente casuale o computer con spoofing su protocollo sicuro
  • Cliente: dati affidabili manomessi che persistono dopo il riavvio
  • Cliente: dati manomessi che non persistono dopo il riavvio

Da lì, viene creata una matrice che assegna un livello di severità a ciascuna combinazione. I possibili valori per il livello di gravità sono:

  1. Critical
  2. Importante
  3. Medio
  4. Basso
  5. Nessuno

Esempio di inserimento in matrice (possono esserci più voci di questo tipo):

STRIDE Category: Spoofing
Scope: Client - Spoofed trusted UI in common/default scenario

Description: Ability for attacker to present a UI that is different from but visually identical to the UI that users must rely on to make valid trust decisions in a default/common scenario. A trust decision is defined as any time the user takes an action believing some information is being presented by a particular entity—either the system or some specific local or remote source.

Severity Level: Important

Microsoft sostiene che risolvono tutti i bug che sono più alti di importanza "bassa" prima della distribuzione.

Ulteriori letture
Aggiungi una barra dei problemi di sicurezza a Microsoft Team Foundation Server 2010
Nuovo SDLC: sicurezza sviluppo vita ciclo

    
risposta data 14.03.2014 - 23:44
fonte

Leggi altre domande sui tag