Bedrohungsmodellierung für Treiber

Treiberautoren und -architekten sollten die Bedrohungsmodellierung zu einem integralen Bestandteil des Entwurfsprozesses für jeden Treiber machen. Dieses Thema enthält Richtlinien zum Erstellen von Bedrohungsmodellen für Windows-Treiber.

Sicherheit sollte ein grundlegender Entwurfspunkt für jeden Treiber sein. Jedes erfolgreiche Produkt ist ein Ziel. Wenn Sie einen Treiber für Windows schreiben, müssen Sie davon ausgehen, dass irgendwann jemand versucht, Ihren Treiber zu verwenden, um die Systemsicherheit zu gefährden.

Das Entwerfen eines sicheren Treibers umfasst Folgendes:

• Identifizieren der Punkte, an denen der Treiber anfällig für einen Angriff sein könnte.
• Analysieren der Angriffstypen, die an jedem solchen Punkt eingebunden werden könnten.
• Sicherstellen, dass der Treiber so konzipiert ist, dass solche Angriffe verhindert werden.

Die Bedrohungsmodellierung ist ein strukturierter Ansatz für diese wichtigen Entwurfsaufgaben. Ein Bedrohungsmodell ist eine Möglichkeit, die Bedrohungen für ein Asset zu kategorisieren und zu analysieren. Aus Sicht eines Treiberautors sind die Ressourcen die Hardware, Software und Daten auf dem Computer oder Netzwerk.

Ein Bedrohungsmodell beantwortet die folgenden Fragen:

• Welche Ressourcen müssen geschützt werden?
• Für welche Bedrohungen sind die Ressourcen anfällig?
• Wie wichtig oder wahrscheinlich ist jede Bedrohung?
• Wie können Sie die Bedrohungen mindern?

Die Bedrohungsmodellierung ist ein wichtiger Bestandteil des Softwareentwurfs, da dadurch sichergestellt wird, dass die Sicherheit in das Produkt integriert ist und nicht im Nachgang behandelt wird. Ein gutes Bedrohungsmodell kann helfen, Fehler während des Entwurfsprozesses zu finden und zu verhindern, wodurch potenziell kostspielige Patches später und mögliche Reputationsschäden für Ihre organization beseitigt werden.

In diesem Abschnitt werden die Prinzipien der Bedrohungsmodellierung auf den Treiberentwurf angewendet und Beispiele für Bedrohungen bereitgestellt, für die ein Treiber möglicherweise anfällig ist. Eine ausführlichere Beschreibung der Bedrohungsmodellierung für das Softwaredesign finden Sie in diesen Ressourcen.

• Die Microsoft SDL-Website:

  https://www.microsoft.com/sdl

• Vereinfachte Implementierung von Microsoft SDL:

  Whitepaper herunterladen

• In diesem Blogbeitrag wird beschrieben, wie Sie ein kostenloses Exemplar von The Security Development Lifecycle: SDL von Michael Howard und Steve Lipner herunterladen:

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

Erstellen von Bedrohungsmodellen für Treiber

Das Erstellen eines Bedrohungsmodells erfordert ein gründliches Verständnis des Entwurfs des Treibers, der Arten von Bedrohungen, denen der Treiber ausgesetzt sein könnte, und der Folgen eines Sicherheitsangriffs, der eine bestimmte Bedrohung ausnutzt. Nachdem Sie das Bedrohungsmodell für einen Treiber erstellt haben, können Sie bestimmen, wie potenzielle Bedrohungen entschärft werden können.

Die Bedrohungsmodellierung ist am effektivsten, wenn sie während des Treiberentwurfs organisiert und strukturiert durchgeführt wird, anstatt während der Codierung planlos zu sein. Ein strukturierter Ansatz erhöht die Wahrscheinlichkeit, dass Sie Sicherheitsrisiken im Entwurf entdecken, und trägt so dazu bei, dass das Modell umfassend ist.

Eine Möglichkeit, eine Bedrohungsmodellierung zu organisieren, besteht darin, die folgenden Schritte auszuführen:

1. Erstellen Sie ein strukturiertes Diagramm, das den Datenfluss durch den Treiber zeigt. Schließen Sie alle möglichen Aufgaben ein, die der Treiber ausführt, sowie die Quelle und das Ziel aller Eingaben und Ausgaben des Treibers. Ein formales Datenflussdiagramm oder ein ähnliches strukturiertes Diagramm kann Ihnen helfen, den Pfad von Daten durch Ihren Treiber zu analysieren und die externen Schnittstellen, Grenzen und Interaktionen des Treibers zu identifizieren.
2. Analysieren Sie die potenziellen Sicherheitsbedrohungen basierend auf dem Datenflussdiagramm.
3. Bewerten Sie die Bedrohungen, die Sie im vorherigen Schritt identifiziert haben, und bestimmen Sie, wie sie entschärft werden können.

Erstellen eines Datenflussdiagramms

Ein Datenflussdiagramm zeigt in konzeptioneller Form den Datenfluss zwischen dem Treiber und den externen Entitäten, mit denen er interagiert – in der Regel dem Betriebssystem, einem Benutzerprozess und dem Gerät. Ein formales Datenflussdiagramm verwendet die folgenden Symbole:

Die folgende Abbildung zeigt ein Beispieldatenflussdiagramm für einen hypothetischen Kernelmodustreiber für Windows Driver Model (WDM). Unabhängig von der Architektur für Ihren bestimmten Treibertyp ist das konzeptionelle Modell identisch: Zeigen Sie alle Datenpfade an, und identifizieren Sie jede Datenquelle, die den Treiber ein- oder beendet.

Hinweis Die vorherige Abbildung zeigt Daten, die direkt zwischen einem Benutzerprozess und dem Treiber fließen, und es werden zwischengeschaltete Treiber weggelassen. In Der Realität werden jedoch alle Anforderungen über den E/A-Manager geleitet und können einen oder mehrere übergeordnete Treiber durchlaufen, bevor sie einen bestimmten Treiber erreichen. In der Abbildung werden diese Zwischenschritte weggelassen, um die Bedeutung der ursprünglichen Quelle der Daten und den Kontext des Threads hervorzuheben, der die Daten bereitgestellt hat. Kernelmodustreiber müssen Daten überprüfen, die aus dem Benutzermodus stammen.

Informationen werden aufgrund von Anforderungen vom Betriebssystem, Anforderungen von einem Benutzerprozess oder Anforderungen (in der Regel unterbrochen) vom Gerät in den Treiber eingegeben.

Der Treiber in der vorherigen Abbildung empfängt Daten vom Betriebssystem in verschiedenen Arten von Anforderungen:

• Anforderungen zum Ausführen von Verwaltungsaufgaben für den Treiber und sein Gerät über Aufrufe von DriverEntry-, DriverUnload- und AddDevice-Routinen
• Plug & Play Anforderungen (IRP_MJ_PNP)
• Energieverwaltungsanforderungen (IRP_MJ_POWER)
• Interne Geräte-E/A-Steuerungsanforderungen (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Als Reaktion auf diese Anforderungen fließen Daten vom Treiber zurück an das Betriebssystem als status Informationen. Der Treiber in der Abbildung empfängt Daten von einem Benutzerprozess in den folgenden Arten von Anforderungen:

• Erstellen, Lesen und Schreiben von Anforderungen (IRP_MJ_CREATE, IRP_MJ_READ oder IRP_MJ_WRITE)
• E/A-Steuerungsanforderungen für öffentliche Geräte (IRP_MJ_DEVICE_ CONTROL)

Als Reaktion auf diese Anforderungen werden Daten ausgegeben und status Informationen vom Treiber zurück an den Benutzerprozess gesendet.

Schließlich empfängt der Treiber Daten vom Gerät aufgrund von Geräte-E/A-Vorgängen oder Benutzeraktionen (z. B. öffnen der Leiste auf einem CD-Laufwerk), die das Gerät status ändern. Ebenso fließen Daten aus dem Treiber während E/A-Vorgängen und Änderungen in geräteinternen status an das Gerät.

Die vorherige Abbildung zeigt den Treiberdatenfluss auf einer umfassenden konzeptionellen Ebene. Jeder Kreis stellt eine relativ große Aufgabe dar und enthält keine Details. In einigen Fällen eignet sich ein Diagramm mit einer ebeneren Ebene, z. B. das Beispiel, um die Datenquellen und Pfade zu verstehen. Wenn Ihr Treiber viele verschiedene Arten von E/A-Anforderungen aus unterschiedlichen Quellen verarbeitet, müssen Sie möglicherweise ein oder mehrere zusätzliche Diagramme erstellen, die weitere Details zeigen. Beispielsweise kann der Kreis mit der Bezeichnung "E/A-Anforderungen behandeln" in ein separates Diagramm erweitert werden, ähnlich der folgenden Abbildung.

Das zweite Diagramm zeigt separate Aufgaben für jeden Typ von E/A-Anforderung im ersten Diagramm. (Der Einfachheit halber wurden Datenpfade zum Gerät weggelassen.)

Die externen Entitäten und die im Diagramm dargestellten Eingabe- und Ausgabetypen können je nach Gerätetyp variieren. Windows stellt beispielsweise Klassentreiber für viele gängige Gerätetypen bereit. Ein vom System bereitgestellter Klassentreiber funktioniert mit einem vom Hersteller bereitgestellten Minidriver, bei dem es sich in der Regel um eine DLL (Dynamic Link Library) handelt, die eine Reihe von Rückrufroutinen enthält. Benutzer-E/A-Anforderungen werden an den Klassentreiber weitergeleitet, der dann die Routinen im Minidriver aufruft, um bestimmte Aufgaben auszuführen. Der Minidriver empfängt in der Regel nicht das gesamte E/A-Anforderungspaket als Eingabe. Stattdessen empfängt jede Rückrufroutine nur die Daten, die für die jeweilige Aufgabe erforderlich sind.

Denken Sie beim Erstellen der Datenflussdiagramme an die Vielzahl von Quellen für Treiberanforderungen. Jeder Code, der auf dem Computer eines Benutzers ausgeführt wird, könnte eine E/A-Anforderung an einen Treiber generieren, von bekannten Anwendungen wie Microsoft Office bis hin zu Freeware, Shareware und Webdownloads potenziell zweifelhafter Herkunft. Abhängig von Ihrem spezifischen Gerät müssen Sie möglicherweise auch Mediencodecs oder Filter von Drittanbietern in Betracht ziehen, die Ihr Unternehmen zur Unterstützung des Geräts bereitstellt. Zu den möglichen Datenquellen zählen:

• IRP_MJ_XXX Anforderungen, die der Treiber verarbeitet
• IOCTLs, die der Treiber definiert oder verarbeitet
• APIs, die der Treiber aufruft
• Rückrufroutinen
• Alle anderen Schnittstellen, die der Treiber verfügbar macht
• Dateien, die der Treiber liest oder schreibt, einschließlich der dateien, die während der Installation verwendet werden
• Registrierungsschlüssel, die der Treiber liest oder schreibt
• Konfigurationseigenschaftenseiten und alle anderen vom Benutzer bereitgestellten Informationen, die der Treiber nutzt

Ihr Modell sollte auch die Installations- und Aktualisierungsprozeduren des Treibers abdecken. Schließen Sie alle Dateien, Verzeichnisse und Registrierungseinträge ein, die während der Treiberinstallation gelesen oder geschrieben werden. Berücksichtigen Sie auch die Schnittstellen, die in Geräteinstallationsprogrammen, Co-Installern und Eigenschaftenseiten verfügbar gemacht werden.

Jeder Punkt, an dem der Treiber Daten mit einer externen Entität austauscht, ist potenziell anfällig für Angriffe.

Analysieren potenzieller Bedrohungen

Nachdem Sie die Punkte identifiziert haben, an denen ein Treiber anfällig sein könnte, können Sie bestimmen, welche Arten von Bedrohungen an jedem Punkt auftreten können. Berücksichtigen Sie die folgenden Arten von Fragen:

• Welche Sicherheitsmechanismen gibt es zum Schutz der einzelnen Ressourcen?
• Sind alle Übergänge und Schnittstellen ordnungsgemäß gesichert?
• Könnte eine unsachgemäße Verwendung eines Features unbeabsichtigt die Sicherheit beeinträchtigen?
• Könnte die böswillige Verwendung eines Features die Sicherheit gefährden?
• Bieten Standardeinstellungen ausreichende Sicherheit?

Der STRIDE-Ansatz für die Bedrohungskategorisierung

Das Akronym STRIDE beschreibt sechs Kategorien von Bedrohungen für Software. Dieses Akronym ist abgeleitet von:

• SPoofing
• T-Ampering
• R-Epudiation
• Informations-Offenlegung
• DEnial of Service
• Rechteausweitung

Mithilfe von STRIDE als Leitfaden können Sie detaillierte Fragen zu den Arten von Angriffen stellen, die auf einen Treiber abzielen können. Das Ziel besteht darin, die Arten von Angriffen zu bestimmen, die an jedem anfälligen Punkt im Treiber möglich sein könnten, und dann ein Szenario für jeden möglichen Angriff zu erstellen.

• Spoofing verwendet die Anmeldeinformationen einer anderen Person, um Zugriff auf ressourcen zu erhalten, auf die ansonsten nicht zugegriffen werden kann. Ein Prozess bindet einen Spoofingangriff ein, indem gefälschte oder gestohlene Anmeldeinformationen übergeben werden.

• Manipulationen ändern Daten, um einen Angriff zu einbinden. Beispielsweise kann ein Treiber anfällig für Manipulationen sein, wenn die erforderlichen Treiberdateien nicht angemessen durch Treibersignatur- und Zugriffssteuerungslisten (AcLs) geschützt sind. In dieser Situation könnte ein böswilliger Benutzer die Dateien ändern, wodurch die Systemsicherheit verletzt wird.

• Die Ablehnung tritt auf, wenn ein Benutzer die Durchführung einer Aktion ablehnt, aber das Ziel der Aktion keine Möglichkeit hat, das Gegenteil zu beweisen. Ein Treiber kann anfällig für eine Ablehnungsbedrohung sein, wenn er keine Aktionen protokolliert, die die Sicherheit gefährden könnten. Beispielsweise kann ein Treiber für ein Videogerät anfällig für Ablehnung sein, wenn es keine Anforderungen protokolliert, um Die Merkmale des Geräts zu ändern, z. B. Fokus, gescannter Bereich, Häufigkeit der Bildaufnahme, Zielort der erfassten Bilder usw. Die resultierenden Images könnten beschädigt sein, aber Systemadministratoren hätten keine Möglichkeit, zu bestimmen, welcher Benutzer das Problem verursacht hat.

• Bedrohungen bei der Offenlegung von Informationen sind genau wie der Name schon sagt: die Weitergabe von Informationen an einen Benutzer, der nicht über die Berechtigung verfügt, sie zu sehen. Jeder Treiber, der Informationen an oder aus einem Benutzerpuffer übergibt, ist anfällig für Bedrohungen bei der Offenlegung von Informationen. Um Bedrohungen der Offenlegung von Informationen zu vermeiden, müssen Treiber die Länge jedes Benutzerpuffers überprüfen und die Puffer null initialisieren, bevor Sie Daten schreiben.

• Denial-of-Service-Angriffe gefährden die Fähigkeit gültiger Benutzer, auf Ressourcen zuzugreifen. Die Ressourcen können Speicherplatz, Netzwerkverbindungen oder ein physisches Gerät sein. Angriffe, die die Leistung auf inakzeptable Werte verlangsamen, werden auch als Denial-of-Service-Angriffe betrachtet. Ein Treiber, der es einem Benutzerprozess ermöglicht, eine Systemressource unnötigerweise zu monopolisieren, kann anfällig für einen Denial-of-Service-Angriff sein, wenn der Ressourcenverbrauch die Fähigkeit anderer gültiger Benutzer behindert, ihre Aufgaben auszuführen.

  Beispielsweise kann ein Treiber einen Semaphor verwenden, um eine Datenstruktur zu schützen, während er unter IRQL = PASSIVE_LEVEL ausgeführt wird. Der Treiber muss jedoch das Semaphor innerhalb eines KeEnterCriticalRegion/KeLeaveCriticalRegion-Paars abrufen und freigeben, wodurch die Übermittlung asynchroner Prozeduraufrufe (APCs) deaktiviert und wieder aktiviert wird. Wenn der Treiber diese Routinen nicht verwendet, kann ein APC dazu führen, dass das Betriebssystem den Thread anhält, der das Semaphor enthält. Daher könnten andere Prozesse (einschließlich der von einem Administrator erstellten) keinen Zugriff auf die Struktur erhalten.

• Ein Angriff auf Rechteerweiterungen kann auftreten, wenn ein nicht privilegierter Benutzer privilegierte status erhält. Ein Kernelmodustreiber, der ein Benutzermodushandle an eine ZwXxx-Routine übergibt, ist anfällig für Angriffe mit Rechteerweiterungen, da ZwXxx-Routinen Sicherheitsüberprüfungen umgehen. Kernelmodustreiber müssen jedes Handle überprüfen, das sie von Aufrufern im Benutzermodus erhalten.

  Angriffe mit Rechteerweiterungen können auch auftreten, wenn ein Kernelmodustreiber den RequestorMode-Wert im IRP-Header verwendet, um zu bestimmen, ob eine E/A-Anforderung von einem Kernelmodus- oder Benutzermodusaufrufer stammt. In IRPs, die aus dem Netzwerk oder dem Serverdienst (SRVSVC) eingehen, ist der Wert von RequestorModeKernelMode, unabhängig vom Ursprung der Anforderung. Um solche Angriffe zu vermeiden, müssen Treiber Zugriffssteuerungsprüfungen für solche Anforderungen durchführen, anstatt einfach den Wert von RequestorMode zu verwenden.

Treiberanalysetechniken

Eine einfache Möglichkeit, die Analyse zu organisieren, besteht darin, die anfälligen Bereiche zusammen mit den potenziellen Bedrohungen und ein oder mehrere Szenarien für jede Art von Bedrohung auflisten.

Um eine gründliche Analyse durchzuführen, müssen Sie die Möglichkeit von Bedrohungen an jedem potenziell anfälligen Punkt im Treiber untersuchen. Bestimmen Sie an jedem anfälligen Punkt jede mögliche Bedrohungskategorie (Spoofing, Manipulation, Ablehnung, Offenlegung von Informationen, Denial-of-Service und Rechteerweiterung). Erstellen Sie dann ein oder mehrere Angriffsszenarien für jede plausible Bedrohung.

Betrachten Sie beispielsweise den Datenfluss für IRP_MJ_DEVICE_CONTROL Anforderungen, wie in der vorherigen Abbildung gezeigt. In der folgenden Tabelle sind zwei Arten von Bedrohungen aufgeführt, die bei der Verarbeitung solcher Anforderungen für einen Treiber auftreten können:

Anfälliger Punkt	Potenzielle Bedrohung (STRIDE)	Szenario
IRP_MJ_DEVICE_CONTROL Anforderungen	Denial of Service Rechteerweiterungen	Der Benutzerprozess gibt eine Sequenz von IOCTLs aus, die zum Ausfall des Geräts führt. Der Benutzerprozess gibt eine IOCTL aus, die FILE_ANY_ACCESS zulässt.

Eine Bedrohung steht häufig im Zusammenhang mit einer anderen. Beispielsweise kann ein Angriff, der eine Bedrohung durch Rechteerweiterungen ausnutzt, zur Offenlegung von Informationen oder zum Denial-of-Service führen. Darüber hinaus hängen einige Arten von Angriffen von einer Abfolge von Ereignissen ab. Ein böswilliger Benutzer kann beginnen, indem er eine Bedrohung mit Rechteerweiterungen ausnutzt. Mit den zusätzlichen Funktionen, die mit erhöhten Berechtigungen bereitgestellt werden, kann der Benutzer zusätzliche Sicherheitsrisiken finden und ausnutzen.

Bedrohungsstrukturen und Gliederungen können bei der Modellierung solcher komplexen Szenarien nützlich sein.

Eine Bedrohungsstruktur ist ein Diagramm, das eine Hierarchie von Bedrohungen oder Sicherheitsrisiken zeigt. Im Wesentlichen imitiert eine Bedrohungsstruktur die Schritte des böswilligen Benutzers beim Einbinden eines Angriffs. Das ultimative Ziel des Angriffs ist oben im Baum. Jede untergeordnete Ebene zeigt die Schritte an, die zum Ausführen des Angriffs erforderlich sind. Die folgende Abbildung ist eine einfache Bedrohungsstruktur für das Denial-of-Service-Szenario im vorherigen Beispiel.

Die Bedrohungsstruktur zeigt die erforderlichen Schritte zum Einbinden eines bestimmten Angriffs und die Beziehungen zwischen den Schritten an. Eine Gliederung ist eine Alternative zu einer Bedrohungsstruktur.

Eine Gliederung listet einfach in hierarchischer Reihenfolge die Schritte zum Angriff auf eine bestimmte Bedrohung auf. Beispiel:

1.0 Bewirkt, dass das Gerät nicht mehr reagiert.

1.1 Geben Sie IOCTLS in Fehlersequenz aus.

1.1.1 Bestimmen Sie die Sequenz, die zum Ausfall des Geräts führt.

1.1.2 Erhalten Sie erhöhte Berechtigungen zum Ausgeben interner IOCTLs.

Beide Techniken können Ihnen helfen, zu verstehen, welche Bedrohungen am gefährlichsten sind und welche Sicherheitsrisiken in Ihrem Entwurf am kritischsten sind.

Schnellpfad-Bedrohungsmodellierung

Wenn die Ressourcen begrenzt sind, kann anstelle eines vollständigen Bedrohungsmodelldiagramms eine Zusammenfassung erstellt werden, um die Sicherheitsrisiken für den Treiber zu bewerten. Der folgende Text beschreibt beispielsweise einige der Oberflächenbereiche, die in dem im vorherigen Beispiel beschriebenen Beispieltreiber dargestellt sind.

Der Treiber empfängt Daten vom Betriebssystem in verschiedenen Arten von Anforderungen:

• Anforderungen zum Ausführen von Verwaltungsaufgaben für den Treiber und sein Gerät über Aufrufe von DriverEntry-, DriverUnload- und AddDevice-Routinen
• Plug & Play Anforderungen (IRP_MJ_PNP)
• Energieverwaltungsanforderungen (IRP_MJ_POWER)
• Interne Geräte-E/A-Steuerungsanforderungen (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Als Reaktion auf diese Anforderungen fließen Daten vom Treiber zurück zum Betriebssystem, als status Informationen. Der Treiber empfängt Daten von einem Benutzerprozess in den folgenden Arten von Anforderungen:

• Erstellen, Lesen und Schreiben von Anforderungen (IRP_MJ_CREATE, IRP_MJ_READ oder IRP_MJ_WRITE)
• E/A-Steuerungsanforderungen für öffentliche Geräte (IRP_MJ_DEVICE_ CONTROL)

Als Reaktion auf diese Anforderungen fließen Ausgabedaten und status Informationen vom Treiber zurück an den Benutzerprozess.

Mit diesem grundlegenden Verständnis des Datenflusses zu Ihrem Treiber können Sie jeden Eingabe- und Ausgabebereich auf mögliche Bedrohungen untersuchen.

Der DREAD-Ansatz für die Bedrohungsbewertung

Es reicht nicht aus, zu bestimmen, wie und wo ein Treiber angegriffen wird. Anschließend müssen Sie diese potenziellen Bedrohungen bewerten, ihre relativen Prioritäten bestimmen und eine Strategie zur Entschärfung entwickeln.

DREAD ist ein Akronym, das fünf Kriterien für die Bewertung von Bedrohungen für Software beschreibt. DREAD steht für:

• DAmage
• R-Herstellbarkeit
• Exploitability
• Eininfizierter Benutzer
• Discoverability

Um die Bedrohungen für Ihren Treiber zu priorisieren, ordnen Sie jede Bedrohung von 1 bis 10 auf alle 5 der DREAD-Bewertungskriterien an, und fügen Sie dann die Bewertungen hinzu, und dividieren Sie durch 5 (die Anzahl der Kriterien). Das Ergebnis ist eine numerische Bewertung zwischen 1 und 10 für jede Bedrohung. Hohe Bewertungen deuten auf ernste Bedrohungen hin.

• Schaden. Die Bewertung des Schadens, der durch einen Sicherheitsangriff entstehen könnte, ist offensichtlich ein wichtiger Bestandteil der Bedrohungsmodellierung. Schäden können Datenverluste, Hardware- oder Medienfehler, minderwertige Leistung oder eine ähnliche Maßnahme umfassen, die für Ihr Gerät und seine Betriebsumgebung gilt.

• Die Reproduzierbarkeit ist ein Maß dafür, wie oft ein festgelegter Angriffstyp erfolgreich ist. Eine leicht reproduzierbare Bedrohung wird wahrscheinlicher ausgenutzt als eine Seltenheit oder unvorhersehbare Sicherheitslücke. Beispielsweise sind Bedrohungen für Features, die standardmäßig installiert sind oder in jedem potenziellen Codepfad verwendet werden, hochgradig reproduzierbar.

• Die Ausnutzbarkeit bewertet den Aufwand und das Fachwissen, die für die Einbindung eines Angriffs erforderlich sind. Eine Bedrohung, die von einem relativ unerfahrenen Studenten angegriffen werden kann, ist hochgradig verwertbar. Ein Angriff, der hochqualifiziertes Personal erfordert und teuer durchzuführen ist, ist weniger verwertbar.

  Berücksichtigen Sie bei der Bewertung der Ausnutzbarkeit auch die Anzahl der potenziellen Angreifer. Eine Bedrohung, die von jedem anonymen Remotebenutzer ausgenutzt werden kann, ist besser ausnutzbar als eine Bedrohung, die einen vor Ort hoch autorisierten Benutzer erfordert.

• Betroffene Benutzer. Die Anzahl der Benutzer, die von einem Angriff betroffen sein könnten, ist ein weiterer wichtiger Faktor bei der Bewertung einer Bedrohung. Ein Angriff, der höchstens einen oder zwei Benutzer betreffen könnte, würde bei dieser Maßnahme relativ niedrig ausfallen. Umgekehrt könnte ein Denial-of-Service-Angriff, der einen Netzwerkserver abstürzt, Tausende von Benutzern betreffen und daher viel höher ausfallen.

• Die Auffindbarkeit ist die Wahrscheinlichkeit, dass eine Bedrohung ausgenutzt wird. Die Auffindbarkeit ist schwer genau abzuschätzen. Der sicherste Ansatz besteht darin, davon auszugehen, dass jede Sicherheitslücke schließlich ausgenutzt wird, und sich folglich auf die anderen Maßnahmen zu verlassen, um die relative Rangfolge der Bedrohung zu ermitteln.

Beispiel: Bewertung von Bedrohungen mithilfe von DREAD

Die folgende Tabelle zeigt, wie ein Designer den hypothetischen Denial-of-Service-Angriff bewerten kann:

DREAD-Kriterium	Bewertung	Kommentare
Damage	8	Stört die Arbeit vorübergehend, verursacht aber keinen dauerhaften Schaden oder Datenverlust.
Reproduzierbarkeit	10	Bewirkt, dass das Gerät jedes Mal ausfällt.
Ausnutzbarkeit	7	Erfordert einen fokussierten Aufwand, um die Befehlssequenz zu bestimmen.
Betroffene Benutzer	10	Wirkt sich auf jedes Modell dieses Geräts auf dem Markt aus.
Erkennbarkeit	10	Geht davon aus, dass jede potenzielle Bedrohung erkannt wird.
Gesamt:	9.0	Die Behebung dieses Problems hat hohe Priorität.

Bedrohungen minimieren

Ihr Treiberentwurf sollte gegen alle Bedrohungen, die Ihr Modell offenlegt, entschärfen. In einigen Fällen ist die Entschärfung jedoch möglicherweise nicht praktikabel. Betrachten Sie beispielsweise einen Angriff, der potenziell nur sehr wenige Benutzer betrifft und unwahrscheinlich ist, dass daten- oder systeminterne Benutzerfreundlichkeit verloren gehen. Wenn die Abwehr einer solchen Bedrohung mehrere Monate zusätzlichen Aufwand erfordert, können Sie stattdessen zusätzliche Zeit für das Testen des Treibers aufwenden. Denken Sie jedoch daran, dass möglicherweise ein böswilliger Benutzer die Sicherheitsanfälligkeit findet und einen Angriff einlagert, und dann benötigt der Treiber einen Patch für das Problem.

Einbeziehung der Bedrohungsmodellierung in einen umfassenderen Lebenszyklusprozess für die Sicherheitsentwicklung

Erwägen Sie, den Prozess der Bedrohungsmodellierung in einen umfassenderen Lebenszyklus der sicheren Entwicklung – SDL – zu einbeziehen.

Der Microsoft SDL-Prozess bietet eine Reihe empfohlener Softwareentwicklungsverfahren, die an eine beliebige Größe von organization angepasst werden können – einschließlich eines einzelnen Entwicklers. Erwägen Sie, Komponenten der SDL-Empfehlungen zu Ihrem Softwareentwicklungsprozess hinzuzufügen.

Weitere Informationen finden Sie unter Microsoft Security Development Lifecycle (SDL) – Prozessleitfaden.

Trainings- und Organisationsfunktionen : Führen Sie Sicherheitsschulungen zur Softwareentwicklung durch, um Ihre Fähigkeit zu erweitern, Softwarerisiken zu erkennen und zu beheben.

Microsoft stellt die vier sdl-Kernschulungskurse zum Download bereit. Microsoft Security Development Lifecycle Core-Trainingsklassen

Ausführlichere Informationen zur SDL-Schulung finden Sie in diesem Whitepaper. Essential Software Security Training für Microsoft SDL

Anforderungen und Entwurf : Die beste Möglichkeit, vertrauenswürdige Software zu erstellen, besteht in der ersten Planungsphase eines neuen Releases oder einer neuen Version, da Entwicklungsteams wichtige Objekte identifizieren und Sicherheit und Datenschutz integrieren können, wodurch Unterbrechungen in Pläne und Zeitpläne minimiert werden.

Eine wichtige Ausgabe in dieser Phase besteht darin, bestimmte Sicherheitsziele festzulegen. Beispielsweise wird entschieden, dass der gesamte Code die Visual Studio-Codeanalyse "Alle Regeln" mit null Warnungen übergeben soll.

Implementierung : Alle Entwicklungsteams sollten eine Liste genehmigter Tools und der zugehörigen Sicherheitsüberprüfungen wie Compiler-/Linkeroptionen und Warnungen definieren und veröffentlichen.

Für einen Treiberentwickler werden die meisten nützlichen Arbeiten in dieser Phase erledigt. Wenn Code geschrieben wird, wird er auf mögliche Schwächen überprüft. Tools wie die Codeanalyse und die Treiberüberprüfung werden verwendet, um nach Bereichen im Code zu suchen, die gehärtet werden können.

Überprüfung : Die Überprüfung ist der Punkt, an dem die Software funktionell vollständig ist und anhand der in der Anforderungs- und Entwurfsphase beschriebenen Sicherheitsziele getestet wird.

Zusätzliche Tools wie Binscope- und Fuzz-Tester können verwendet werden, um zu überprüfen, ob die Ziele des Sicherheitsentwurfs erreicht wurden und der Code versandbereit ist.

Release und Reaktion : In Vorbereitung auf die Veröffentlichung eines Produkts ist es wünschenswert, einen Plan zur Reaktion auf Vorfälle zu erstellen, der beschreibt, was Sie tun werden, um auf neue Bedrohungen zu reagieren und wie Sie den Treiber nach dem Versand warten. Wenn Sie diese Arbeit im Voraus ausführen, können Sie schneller reagieren, wenn Sicherheitsprobleme im ausgelieferten Code identifiziert werden.

Weitere Informationen zum SDL-Prozess finden Sie in den folgenden zusätzlichen Ressourcen:

• Dies ist die primäre Microsoft SDL-Website und bietet eine Übersicht über SDL. https://www.microsoft.com/sdl

• In diesem Blog wird beschrieben, wie Sie ein kostenloses Exemplar von The Security Development Lifecycle: SDL von Michael Howard und Steve Lipner herunterladen. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• Diese Seite enthält Links zu weiteren SDL-Veröffentlichungen. https://www.microsoft.com/SDL/Resources/publications.aspx

Handlungsaufforderung

Für Treiberentwickler:

• Machen Sie die Bedrohungsmodellierung zum Teil des Treiberentwurfs.
• Ergreifen Sie Schritte, um Bedrohungen in Ihrem Treibercode effizient zu mindern.
• Machen Sie sich mit den Sicherheits- und Zuverlässigkeitsproblemen vertraut, die für Ihren Treiber und Gerätetyp gelten. Weitere Informationen finden Sie in den gerätespezifischen Abschnitten des Windows Device Driver Kit (WDK).
• Erfahren Sie, welche Überprüfungen das Betriebssystem, der E/A-Manager und alle treiber auf höherer Ebene ausführen, bevor Benutzeranforderungen Ihren Treiber erreichen – und welche Überprüfungen nicht ausgeführt werden.
• Verwenden Sie Tools aus dem WDK, z. B. treiberprüfer, um Ihren Treiber zu testen und zu überprüfen.
• Überprüfen Sie öffentliche Datenbanken mit bekannten Bedrohungen und Softwarerisiken.

Weitere Treibersicherheitsressourcen finden Sie unter Checkliste für die Treibersicherheit.

Softwaresicherheitsressourcen

Bücher

Schreiben von Secure Code, Zweite Ausgabe von Michael Howard und David LeBlanc

24 Todsünden der Softwaresicherheit: Programmierfehler und Wie man sie behebt, First Edition von Michael Howard, David LeBlanc und John Viega

Die Kunst der Softwaresicherheitsbewertung: Identifizieren und Verhindern von Softwarerisiken, von Mark Dowd, John McDonald und Justin Schuh

Microsoft Hardware- und Treiberentwicklerinformationen

Whitepaper "Logik abbrechen" in Windows-Treibern

Windows-Sicherheitsmodell: Was jeder Treiberschreiber wissen muss

Microsoft Windows Driver Development Kit (DDK)

Weitere Informationen finden Sie unter Treiberprogrammierungstechniken in der Kernelmodustreiberarchitektur.

Test Tools

Informationen zu Leistung und Kompatibilität finden Sie unter Windows Hardware Lab Kit unter Testen.

Öffentliche Datenbanken mit bekannten Bedrohungen und Softwarerisiken

Um Ihr Wissen über Softwarebedrohungen zu erweitern, überprüfen Sie die verfügbaren öffentlichen Datenbanken mit bekannten Bedrohungen und Softwarerisiken.

• Allgemeine Sicherheitsrisiken und Risiken (CVE): https://cve.mitre.org/
• Allgemeine Schwachpunktaufzählung: https://cwe.mitre.org/
• Allgemeine Angriffsmusteraufzählung und Klassifizierung: https://capec.mitre.org/index.html
• NIST verwaltet eine Website, die beschreibt, wie Sicherheitsrisiken katalogisiert werden: https://samate.nist.gov/BF/

Weitere Informationen

Sicherheitsprüfliste für Treiber