I mitt företag arbetar vi med att anta Microsoft Secure Development Lifecycle, och en del av MSDL-processen handlar om att skapa säkerhets- och sekretessfel i början av ett projekt. Jag har hört begreppet bugfält före MSDL och jag förstår att det i huvudsak är en definition av vilken nivå / mängd buggar du är villig att acceptera i en slutprodukt, men jag har har aldrig förstått hur man skapar en bugfält för ett projekt. Finns det några väldokumenterade processer för att skapa bugfält som jag kan lära mig av?
Jag har försökt göra en del googling för exempel eller verkliga scenarier av projekt definiera felstaplar i början av ett projekt, men jag kan inte tycka få några bra resultat eller tips om processen att skapa ett felfält. Det finns MSDL-exempel av vad som verkar vara färdiga felstaplar, men jag är intresserad av att lära mig om processen att definiera något liknande detta. Till exempel, för de som har gjort något liknande tidigare, har du definierat felstaplar på ett mycket specifikt sätt (t.ex. att säga " Det får inte finnas någon obehörig åtkomst till filsystemet: läsning från filsystem "), eller har du tagit ett uppskjutet tillvägagångssätt att säga att när vi hittar buggar kommer vi att betygsätta dem på en skala från 1 till 5 (5 är de allvarligaste), fastställ nu att inga buggar över en 3 ska skickas och lämna din rangordning av buggar tills de upptäcks? Jag känner att försöket att göra det förstnämnda är en dum och omöjlig aktivitet, men det senare är benäget för partiskhet mot förmån när ett projekt kommer ner till ledningen.
Återigen, för att slå upp allt detta i en kortfattad fråga, kan någon förse mig med ett väldokumenterat tillvägagångssätt för att definiera / skapa bugfält?
Svar
Låt ” s börjar med en grundläggande definition för bugfält:
Kvalitetsgrindar och bugfält används för att fastställa minimala acceptabla nivåer av säkerhet och integritetskvalitet. måste förhandla om kvalitetsgrindar (till exempel måste alla kompilatorvarningar triages och fixas före kodincheckning) för varje utvecklingsfas. En bugfält är en kvalitetsgrind som används för att definiera svårighetsgränserna för säkerhetssårbarheter – till exempel inga kända sårbarheter i applikationen med en ”kritisk” eller ”viktig” klassificering vid tidpunkten för utgåvan. Felfältet, när det väl har ställts in, bör aldrig avslappnas.
”d02e4c2ab6″>
När en programanvändare arkiverar en buggrapport måste de tilldela en STRIDE-kategori till felet, oavsett om felet är en klient- eller serverfel, och vilken omfattning felet påverkar. Användare kan vara programutvecklare och QA-personal. STRIDE står för:
- Spoofing
- Sabotage
- Repudiation
- Informationsupplysning
- Denial of Service (DoS)
- Förhöjning av privilegium (EoP)
De relevanta ”scope” -värdena är
- Client – Spoofed trusted UI in gemensamt / standardscenario
- Klient – Förfalskat pålitligt användargränssnitt i specifikt annat scenario
- Klient – Förfalskat användargränssnitt som en del av ett större attackscenario
- Server – Förfalskad specifik användare eller dator över säkert protokoll
- Server – Spoofed slumpmässig användare eller dator över säkert protokoll
- Klient – manipulerade betrodda data som kvarstår efter omstart
- Client – manipulerade data som kvarstår inte efter omstart
Därifrån skapas en matris som tilldelar en svårighetsgrad till varje kombination. De möjliga värdena för svårighetsgraden är:
- Kritisk
- Viktigt
- Måttlig
- Låg
- Ingen
Exempelpost i matris (det kan finnas flera sådana poster):
STRIDE Kategori: Spoofing
Omfattning: Client – Spoofed betrodd användargränssnitt i gemensamt / standardscenarioBeskrivning: Möjlighet för angriparen att presentera ett användargränssnitt som skiljer sig från men visuellt identiskt med det användargränssnitt som användare måste lita på för att fatta giltiga förtroendebeslut i ett standard / gemensamt scenario. Ett förtroendebeslut definieras som varje gång användaren vidtar en åtgärd i tron att viss information presenteras av en viss enhet – antingen systemet eller någon specifik lokal eller fjärrkälla.
Allvarlighetsnivå: Viktigt
Microsoft hävdar att de fixar alla buggar som är högre än ”låg” betydelse innan de distribueras.
Ytterligare läsning
Lägg till ett säkerhetsfel i Microsoft Team Foundation Server 2010
Ny SDLC: Säkerhetsutvecklings livscykel