In meinem Unternehmen arbeiten wir an der Einführung des Microsoft Secure Development Lifecycle. Ein Teil des MSDL-Prozesses besteht darin, zu Beginn Sicherheits- und Datenschutz-Fehlerbalken einzurichten Ich habe das Konzept einer Fehlerleiste vor MSDL gehört, und ich verstehe, dass es im Wesentlichen eine Definition der Anzahl / Anzahl von Fehlern ist, die Sie in einem Endprodukt akzeptieren möchten, aber ich habe Ich habe nie verstanden, wie man eine Fehlerleiste für ein Projekt erstellt. Gibt es gut dokumentierte Prozesse zum Erstellen von Fehlerleisten, aus denen ich lernen kann?
Ich habe versucht, nach Beispielen oder realen Szenarien von Projekten zu googeln Definieren von Fehlerbalken zu Beginn eines Projekts, aber ich kann anscheinend keine guten Ergebnisse oder Tipps zum Einrichten eines Fehlerbalkens erhalten. Es gibt MSDL-Beispiele von scheinbar abgeschlossenen Bugbars, aber ich bin daran interessiert, etwas über den Prozess der Definition von so etwas zu lernen. Für diejenigen, die so etwas schon einmal gemacht haben, haben Sie beispielsweise Fehlerleisten auf eine ganz bestimmte Weise definiert (z. B. " Es darf kein unbefugter Dateisystemzugriff erfolgen: Lesen aus dem Dateisystem "), oder haben Sie einen verzögerten Ansatz gewählt, um zu sagen, wenn wir Fehler finden, werden wir sie auf einer Skala von 1 bis 5 bewerten (5 sind die schwerwiegendsten) dass keine Fehler über einer 3 versendet werden und Ihre Rangfolge der Fehler so lange belassen wird, bis sie entdeckt werden? Ich bin der Meinung, dass der Versuch, Ersteres zu tun, eine dumme und unmögliche Aktivität ist, aber Letzteres neigt dazu, zu Nachsicht zu tendieren, wenn ein Projekt auf den Draht kommt.
Nochmals, um all das zusammenzufassen Kann mir jemand einen gut dokumentierten Ansatz zum Definieren / Erstellen von Fehlerbalken geben?
Antwort
Let “ s Beginnen Sie mit einer grundlegenden Definition für die Fehlerleiste:
Qualitätstore und Fehlerleisten werden verwendet, um ein Mindestmaß an akzeptabler Sicherheit und Datenschutzqualität festzulegen. Ein Projektteam Für jede Entwicklungsphase müssen Qualitätsgatter ausgehandelt werden (z. B. müssen alle Compiler-Warnungen vor dem Einchecken des Codes getestet und behoben werden). Eine Fehlerleiste ist ein Qualitätsgatter, mit dem die Schweregradschwellen von Sicherheitslücken definiert werden, z. Keine bekannten Schwachstellen in der Anwendung mit einer „kritischen“ oder „wichtigen“ Bewertung zum Zeitpunkt der Veröffentlichung. Die einmal festgelegte Fehlerleiste sollte niemals gelockert werden.
Wenn ein Softwarebenutzer einen Fehlerbericht einreicht, muss er dem Fehler eine STRIDE-Kategorie zuweisen, unabhängig davon, ob es sich um einen Client- oder Serverfehler handelt und welchen Umfang der Fehler hat. Benutzer können Softwareentwickler und QS-Mitarbeiter sein. STRIDE steht für:
- Spoofing
- Manipulation
- Ablehnung
- Offenlegung von Informationen
- Denial of Service (DoS)
- Erhöhung der Berechtigung (EoP)
Die relevanten „Gültigkeitsbereich“ -Werte sind
- Client – Gefälschte vertrauenswürdige Benutzeroberfläche in Allgemeines / Standardszenario
- Client – Gefälschte vertrauenswürdige Benutzeroberfläche in einem bestimmten anderen Szenario
- Client – Gefälschte Benutzeroberfläche als Teil eines größeren Angriffsszenarios
- Server – Gefälschter bestimmter Benutzer oder Computer über sicheres Protokoll
- Server – Gefälschter zufälliger Benutzer oder Computer über sicheres Protokoll
- Client – Manipulierte vertrauenswürdige Daten, die nach dem Neustart bestehen bleiben
- Client – Manipulierte Daten, die bleibt nach dem Neustart nicht bestehen
Von dort aus wird eine Matrix erstellt, die jeder Kombination einen Schweregrad zuweist. Die möglichen Werte für den Schweregrad sind:
- Kritisch
- Wichtig
- Mittel
- Niedrig
- Keine
Beispieleintrag in der Matrix (es können mehrere solcher Einträge vorhanden sein):
STRIDE Kategorie: Spoofing
Gültigkeitsbereich: Client – Gefälschte vertrauenswürdige Benutzeroberfläche im allgemeinen / Standard-SzenarioBeschreibung: Fähigkeit des Angreifers zur Präsentation Eine Benutzeroberfläche, die sich von der Benutzeroberfläche unterscheidet, aber visuell identisch ist, auf die sich Benutzer verlassen müssen, um in einem Standard- / allgemeinen Szenario gültige Vertrauensentscheidungen zu treffen. Eine Vertrauensentscheidung ist definiert als jedes Mal, wenn der Benutzer eine Aktion ausführt, bei der er glaubt, dass einige Informationen von einer bestimmten Entität präsentiert werden – entweder vom System oder von einer bestimmten lokalen oder Remote-Quelle.
Schweregrad: Wichtig
Microsoft behauptet, dass alle Fehler behoben werden, die vor der Bereitstellung eine höhere als „niedrige“ Bedeutung haben.
Weiterführende Literatur
Fügen Sie Microsoft Team Foundation Server 2010 eine Sicherheitsfehlerleiste hinzu
Neuer SDLC: Lebenszyklus der Sicherheitsentwicklung