In mijn bedrijf werken we aan de invoering van de Microsoft Secure Development Lifecycle, en een deel van het MSDL-proces omvat het instellen van beveiligings- en privacybugbalken in het begin van een project. Ik “heb het concept van een bugbar gehoord voorafgaand aan MSDL, en ik begrijp dat het in wezen een definitie is van welk niveau / aantal bugs je bereid bent te accepteren in een eindproduct, maar ik heb nooit begrepen hoe ik een bugbar voor een project moest maken. Zijn er goed gedocumenteerde processen voor het opzetten van bugbalken waarvan ik kan leren?
Ik heb geprobeerd te Googelen voor voorbeelden of praktijkscenarios van projecten het definiëren van bugbalken aan het begin van een project, maar ik kan “geen goede resultaten of tips krijgen voor het proces van het opzetten van een bugbalk. Er zijn MSDL-voorbeelden van wat voltooide bug bars lijken te zijn, maar ik ben geïnteresseerd in het proces van het definiëren van zoiets als dit. Heeft u bijvoorbeeld voor degenen die zoiets eerder hebben gedaan, bugs bars op een zeer specifieke manier gedefinieerd (bijvoorbeeld door " te zeggen. Er zal geen ongeautoriseerde toegang tot het bestandssysteem zijn: lezen van de bestandssysteem "), of heb je een uitgestelde benadering gevolgd door te zeggen dat wanneer we bugs vinden, we ze beoordelen op een schaal van 1 tot 5 (waarbij 5 de meest ernstige is), stel nu vast dat er geen bugs boven een 3 zullen worden verzonden, en uw rangorde van bugs verlaten totdat ze worden ontdekt? Ik heb het gevoel dat het proberen om het eerste te doen een dwaze en onmogelijke activiteit is, maar het laatste is geneigd tot clementie wanneer een project op het spel staat.
Nogmaals, om dat allemaal af te ronden tot een beknopte vraag, kan iemand mij een goed gedocumenteerde benadering geven voor het definiëren / maken van bugbalken?
Antwoord
Let ” s beginnen met een basisdefinitie voor Bug Bar:
Kwaliteitspoorten en bugbalken worden gebruikt om minimaal aanvaardbare niveaus van beveiliging en privacykwaliteit vast te stellen. Een projectteam kwaliteitspoorten moeten onderhandelen (alle compilatiewaarschuwingen moeten bijvoorbeeld worden getriaged en verholpen voordat de code wordt ingecheckt) voor elke ontwikkelingsfase. Een bugbalk is een kwaliteitspoort die wordt gebruikt om de ernstdrempels van beveiligingskwetsbaarheden te definiëren, bijvoorbeeld geen bekende kwetsbaarheden in de applicatie met een “kritieke” of “belangrijke” beoordeling op het moment van uitgave. De bugbalk, eenmaal ingesteld, mag nooit worden versoepeld.
Wanneer een softwaregebruiker een bugrapport indient, moet hij een STRIDE-categorie aan de bug toewijzen, of de bug een client- of serverbug is en welk bereik de bug beïnvloedt. Gebruikers kunnen softwareontwikkelaars en QA-personeel zijn. STRIDE staat voor:
- Spoofing
- Knoeien
- Afwijzing
- Openbaarmaking van informatie
- Denial of Service (DoS)
- Elevation of Privilege (EoP)
De relevante “scope” -waarden zijn
- Client – Vervalste vertrouwde gebruikersinterface in algemeen / standaard scenario
- Client – Vervalste vertrouwde gebruikersinterface in specifiek ander scenario
- Client – Vervalste gebruikersinterface als onderdeel van een groter aanvalsscenario
- Server – Vervalste specifieke gebruiker of computer via beveiligd protocol
- Server – vervalste willekeurige gebruiker of computer via beveiligd protocol
- Client – geknipte vertrouwde gegevens die blijven bestaan na opnieuw opstarten
- Client – geknipte gegevens die blijft niet bestaan na herstart
Van daaruit wordt een matrix gemaakt die een niveau van ernst aan elke combinatie toewijst. De mogelijke waarden voor het ernstniveau zijn:
- Kritiek
- Belangrijk
- Matig
- Laag
- Geen
Voorbeelditem in matrix (er kunnen meerdere van dergelijke items zijn):
STRIDE Categorie: Spoofing
Bereik: Client – Vervalste vertrouwde gebruikersinterface in algemeen / standaardscenarioBeschrijving: Mogelijkheid voor aanvaller om te presenteren een gebruikersinterface die verschilt van maar visueel identiek is aan de gebruikersinterface waarop gebruikers moeten vertrouwen om geldige vertrouwensbeslissingen te nemen in een standaard / algemeen scenario. Een vertrouwensbeslissing wordt gedefinieerd als elke keer dat de gebruiker een actie onderneemt in de overtuiging dat bepaalde informatie wordt gepresenteerd door een bepaalde entiteit – het systeem of een specifieke lokale of externe bron.
Ernstniveau: Belangrijk
Microsoft beweert dat ze alle bugs oplossen die belangrijker zijn dan “laag” voordat ze worden geïmplementeerd.
Verder lezen
Voeg een beveiligingsbugbalk toe aan Microsoft Team Foundation Server 2010
Nieuwe SDLC: levenscyclus van beveiligingsontwikkeling