V mé společnosti pracujeme na přijetí životního cyklu Microsoft Secure Development a část procesu MSDL zahrnuje vytvoření pruhů chyb zabezpečení a ochrany soukromí na začátku projektu. Slyšel jsem koncept chybového pruhu před MSDL a chápu, že je to v podstatě definice toho, jakou úroveň / množství chyb jste v konečném produktu ochotni přijmout, ale já nikdy jsem nepochopil, jak vytvořit chybovou lištu pro projekt. Existují nějaké dobře zdokumentované procesy pro stanovení chybových pruhů, ze kterých se mohu učit?
Snažil jsem se udělat nějaký Googling pro příklady nebo scénáře reálného světa projektů definování chybových pruhů na začátku projektu, ale nezdá se, že bych získal nějaké dobré výsledky nebo tipy na proces stanovení chybového pruhu. Existuje příklady MSDL co se jeví jako dokončené pruhy chyb, ale zajímá mě, jak se dozvědět o procesu definování něčeho takového. Například pro ty, kteří již něco takového udělali, jste definovali pruhy chyb velmi konkrétním způsobem (např. Řeknutím " Nesmí dojít k žádnému neoprávněnému přístupu k souborovému systému: čtení z souborový systém "), nebo jste zvolili odložený přístup a řekli, že když najdeme chyby, ohodnocíme je na stupnici od 1 do 5 (5 je nejzávažnější), vytvořte nyní že žádné chyby nad 3 nebudou odeslány, a nechte své hodnocení chyb, dokud nebudou znovu objeveny? Mám pocit, že snaha dělat to první je pošetilá a nemožná aktivita, ale pozdější je náchylná k zaujatosti vůči shovívavosti, když se projekt blíží k drátu.
Opět vše zabalit do stručné otázky, může mi někdo poskytnout dobře zdokumentovaný přístup k definování / vytváření pruhů chyb?
Odpověď
Nechte “ Začínáme se základní definicí pro Bug Bar:
Kvalitní brány a pruhy chyb se používají ke stanovení minimální přijatelné úrovně zabezpečení a kvality soukromí. Projektový tým musí vyjednat brány kvality (například všechna upozornění kompilátoru musí být tříděna a opravena před odbavením kódu) pro každou vývojovou fázi. Panel chyby je brána kvality, která se používá k definování prahů závažnosti bezpečnostních chyb zabezpečení – například žádné známé chyby zabezpečení v aplikaci s „kritickým“ nebo „důležitým“ hodnocením v době vydání. Lišta s chybou, jakmile je nastavena, by nikdy neměla být uvolněna.
Když uživatel softwaru nahraje hlášení o chybě, musí této chybě přiřadit kategorii STRIDE, ať už jde o chybu klienta nebo serveru a jaký rozsah má chyba vliv. Uživatelé mohou být vývojáři softwaru a zaměstnanci QA. STRIDE znamená:
- Spoofing
- manipulace
- odmítnutí
- zveřejnění informací
- odmítnutí služby (DoS)
- Elevation of Privilege (EoP)
Relevantní hodnoty „scope“ jsou
- Klient – Spoofed trusted UI in běžný / výchozí scénář
- Klient – spoofed důvěryhodné uživatelské rozhraní v konkrétním jiném scénáři
- Client – spoofed UI jako součást většího scénáře útoku
- Server – spoofed konkrétní uživatel nebo počítač přes zabezpečený protokol
- Server – zfalšovaný náhodný uživatel nebo počítač přes zabezpečený protokol
- Klient – zfalšovaná důvěryhodná data, která přetrvají i po restartu
- klient – zfalšovaná data, která po restartu přetrvává
Odtud se vytvoří matice, která každé kombinaci přiřadí úroveň závažnosti. Možné hodnoty pro úroveň závažnosti jsou:
- kritické
- důležité
- střední
- nízké
- Žádné
Příklad záznamu v matici (takových záznamů může být několik):
STRIDE Kategorie: Spoofing
Rozsah: Klient – spoofed trusted UI in common / default scenarioPopis: Schopnost útočníka prezentovat uživatelské rozhraní, které se liší od vizuálně identického uživatelského rozhraní, na které se uživatelé musí spolehnout, aby mohli učinit platná rozhodnutí o důvěryhodnosti ve výchozím / běžném scénáři. Rozhodnutí o důvěryhodnosti je definováno jako kdykoli, kdy uživatel provede akci a věří, že některé informace jsou prezentovány určitou entitou – systémem nebo nějakým konkrétním místním nebo vzdáleným zdrojem.
Úroveň závažnosti: Důležité
Společnost Microsoft tvrdí, že před nasazením opraví všechny chyby, které mají vyšší než „nízkou“ důležitost.
Další čtení
Přidání pruhu chyb zabezpečení na Microsoft Team Foundation Server 2010
Nové SDLC: životní cyklus vývoje zabezpečení