I min virksomhed arbejder vi på at vedtage Microsoft Secure Development Lifecycle, og en del af MSDL-processen indebærer oprettelse af sikkerheds- og privatlivsfejlfelt ved starten af et projekt. Jeg har hørt konceptet med en bug bar forud for MSDL, og jeg forstår, at det i det væsentlige er en definition af, hvilket niveau / antal bugs du er villig til at acceptere i et slutprodukt, men jeg har har aldrig forstået, hvordan man opretter en bugbjælke til et projekt. Er der nogen veldokumenterede processer til oprettelse af fejlbjælker, som jeg kan lære af?
Jeg har prøvet at google nogle eksempler eller virkelige verdensscenarier af projekter definerer fejlbjælker ved starten af et projekt, men jeg kan ikke synes at få gode resultater eller tip til processen med at etablere en fejlbjælke. Der er MSDL-eksempler hvad der ser ud til at være afsluttet bugbjælker, men jeg er interesseret i at lære om processen med at definere noget som dette. For eksempel for dem, der har gjort noget lignende før, har du defineret bugs-bjælker på en meget specifik måde (f.eks. At sige " Der skal ikke være nogen uautoriseret filsystemadgang: læsning fra filsystem "), eller har du taget en udskudt tilgang til at sige, at når vi finder fejl, vil vi bedømme dem på en skala fra 1 til 5 (5 er den mest alvorlige), etabler nu at ingen bugs over en 3 skal sendes, og lad din rangordning af bugs, indtil de er opdaget? Jeg har lyst til, at forsøget på at gøre det førstnævnte er en tåbelig og umulig aktivitet, men den senere er tilbøjelig til bias mod bøjelighed, når et projekt kommer ned til ledningen.
Igen for at pakke alt dette op i et kortfattet spørgsmål, kan nogen give mig en veldokumenteret tilgang til at definere / oprette bugbjælker?
Svar
Lad ” s starter med en grundlæggende definition for buglinje:
Kvalitetsporte og bugbjælker bruges til at etablere minimumsacceptable niveauer af sikkerhed og privatlivskvalitet. skal forhandle kvalitetsporte (for eksempel skal alle kompilatoradvarsler triages og rettes inden kodecheck) for hver udviklingsfase. En bug bar er en kvalitetsport, der bruges til at definere sværhedsgrænserne for sikkerhedssårbarheder – for eksempel ingen kendte sårbarheder i applikationen med en “kritisk” eller “vigtig” vurdering på frigivelsestidspunktet. Fejlfeltet, når det er indstillet, bør aldrig lempes.
Når en softwarebruger arkiverer en fejlrapport, skal de tildele en STRIDE-kategori til bugten, uanset om bugten er en klient- eller serverfejl, og hvilket omfang bugten påvirker. Brugere kan være softwareudviklere og QA-medarbejdere. STRIDE står for:
- Spoofing
- Sabotage
- Afvisning
- Oplysning om oplysninger
- Denial of Service (DoS)
- Udvidelse af privilegium (EoP)
De relevante “scope” -værdier er
- Client – Spoofed trust UI in fælles / standardscenarie
- Klient – Forfalsket pålidelig brugergrænseflade i specifikt andet scenarie
- Klient – Forfalsket brugergrænseflade som en del af et større angrebsscenarie
- Server – Forfalsket specifik bruger eller computer over sikker protokol
- Server – Forfalsket tilfældig bruger eller computer over sikker protokol
- Klient – manipuleret pålidelige data, der vedvarer efter genstart
- Klient – manipuleret data, der vedvarer ikke efter genstart
Derfra oprettes en matrix, der tildeler et niveau af sværhedsgrad til hver kombination. De mulige værdier for sværhedsgrad er:
- Kritisk
- Vigtigt
- Moderat
- Lav
- Ingen
Eksempel på matrix (der kan være flere sådanne poster):
STRIDE Kategori: Spoofing
Omfang: Client – Spoofed betroet brugergrænseflade i fælles / standardscenarieBeskrivelse: Mulighed for angriber at præsentere et brugergrænseflade, der er forskelligt fra men visuelt identisk med det brugergrænseflade, som brugerne skal stole på for at træffe gyldige tillidsbeslutninger i et standard / fælles scenarie. En tillidsbeslutning defineres som ethvert tidspunkt, hvor brugeren foretager en handling, idet han mener, at nogle oplysninger præsenteres af en bestemt enhed – enten systemet eller en bestemt lokal eller ekstern kilde.
Alvorlighedsniveau: Vigtigt
Microsoft hævder, at de retter alle fejl, der er højere end “lav” betydning, inden de implementeres.
Yderligere læsning
Tilføj en sikkerhedsfejlbjælke til Microsoft Team Foundation Server 2010
Ny SDLC: Sikkerhedsudviklings livscyklus