I mitt firma jobber vi med å vedta Microsoft Secure Development Lifecycle, og en del av MSDL-prosessen innebærer å etablere sikkerhets- og personvernfeilfelt ved begynnelsen av et prosjekt. Jeg har hørt konseptet med en bug bar før MSDL, og jeg forstår at det egentlig er en definisjon av hvilket nivå / mengde bugs du er villig til å godta i et sluttprodukt, men jeg har har aldri forstått hvordan jeg lager en bug bar for et prosjekt. Er det noen veldokumenterte prosesser for å etablere bug barer som jeg kan lære av?
Jeg har prøvd å gjøre noen googling for eksempler eller virkelige scenarier av prosjekter definere feilfelt ved begynnelsen av et prosjekt, men jeg ser ikke ut til å få noen gode resultater eller tips om prosessen med å etablere en feilfelt. Det er MSDL-eksempler av det som ser ut til å være fullført feilfelt, men jeg er interessert i å lære om prosessen med å definere noe som dette. For eksempel, for de som har gjort noe slikt før, har du definert feilfelt på en veldig spesifikk måte (f.eks. Å si " Det skal ikke være uautorisert tilgang til filsystem: lesing fra filsystem "), eller har du tatt en utsatt tilnærming for å si at når vi finner feil vil vi rangere dem på en skala fra 1 til 5 (5 er den mest alvorlige), etabler nå at ingen feil over en 3 skal sendes, og la din rangering av feil være til de er oppdaget? Jeg føler at det å prøve å gjøre førstnevnte er en tåpelig og umulig aktivitet, men den senere er tilbøyelig til forspenning mot mildhet når et prosjekt kommer ned til ledningen.
Igjen, å pakke alt dette opp i et kortfattet spørsmål, kan noen gi meg en godt dokumentert tilnærming for å definere / lage feilfelt?
Svar
La » s starter med en grunnleggende definisjon for feilfelt:
Kvalitetsporter og feilfelt brukes til å etablere minimum akseptable nivåer av sikkerhet og personvernkvalitet. må forhandle om kvalitetsporter (for eksempel alle kompilatoradvarsler må triages og fikses før kodeinnsjekking) for hver utviklingsfase. En feillinje er en kvalitetsport som brukes til å definere alvorlighetsgrensene for sikkerhetsproblemer – for eksempel ingen kjente sårbarheter i applikasjonen med en «kritisk» eller «viktig» vurdering på utgivelsestidspunktet. Feilfeltet, når det er angitt, skal aldri slappes av.
«d02e4c2ab6″>
Når en programvarebruker arkiverer en feilrapport, må de tildele en STRIDE-kategori til feilen, enten feilen er en klient- eller serverfeil, og hvilket omfang feilen påvirker. Brukere kan være programvareutviklere og ansatte i kvalitetssikring. STRIDE står for:
- Spoofing
- Sabotasje
- Repudiation
- Informasjon avsløring
- Denial of Service (DoS)
- Utvidelse av privilegium (EoP)
De relevante «scope» -verdiene er
- Client – Spoofed trust UI in vanlig / standardscenario
- Klient – Spoofed pålitelig brukergrensesnitt i spesifikt annet scenario
- Client – Spoofed UI som en del av et større angrepsscenario
- Server – Spoofed spesifikk bruker eller datamaskin over sikker protokoll
- Server – Spoofed random user eller computer over secure protocol
- Client – manipulert pålitelige data som vedvarer etter omstart
- Client – manipulert data som vedvarer ikke etter omstart
Derfra opprettes en matrise som tildeler et alvorlighetsnivå til hver kombinasjon. De mulige verdiene for alvorlighetsnivå er:
- Kritisk
- Viktig
- Moderat
- Lav
- Ingen
Eksempeloppføring i matrise (det kan være flere slike oppføringer):
STRIDE Kategori: Spoofing
Omfang: Client – Spoofed klarert brukergrensesnitt i felles / standard scenarioBeskrivelse: Evne for angriper å presentere et brukergrensesnitt som er forskjellig fra men visuelt identisk med brukergrensesnittet som brukerne må stole på for å ta gyldige tillitsbeslutninger i et standard / vanlig scenario. En tillitsbeslutning defineres som når som helst brukeren foretar seg noe som tror at informasjon blir presentert av en bestemt enhet – enten systemet eller en bestemt lokal eller ekstern kilde.
Alvorlighetsnivå: Viktig
Microsoft hevder at de fikser alle feil som er høyere enn «lav» betydning før de distribueres.
Videre lesing
Legg til en sikkerhetsfeil i Microsoft Team Foundation Server 2010
Ny SDLC: Sikkerhetsutvikling livssyklus