Bedrohungsanalyse

Artikel
04/18/2008

* * *

Auf dieser Seite

Modulübersicht
Zielsetzung
Betrifft
Verwendung dieses Moduls
Vorbereitung:
Grundlagen der Bedrohungsanalyse
1. Schritt: Identifizieren zu schützender Daten/Komponenten
2. Schritt: Erstellen einer Architekturübersicht
3. Schritt: Gliedern der Anwendung
4. Schritt: Identifizieren der Bedrohungen
5. Schritt: Dokumentieren der Bedrohungen
6. Schritt: Bewerten der Bedrohungen
Was folgt nach der Bedrohungsanalyse?
Zusammenfassung
Weitere Links zum Thema

Modulübersicht

Mithilfe einer Bedrohungsanalyse ist eine systematische Identifikation und Abschätzung von Bedrohungen, denen ein System voraussichtlich ausgesetzt sein wird, möglich.

In einer Bedrohungsanalyse wird ein strukturierter Ansatz angewendet, durch den die Gefahrenbekämpfung weitaus kostengünstiger und effizienter ist als durch eine willkürliche Verwendung von Sicherheitsfunktionen, ohne genau zu wissen, gegen welche Bedrohung eine Funktion zu richten ist.

Nach der Lektüre dieses Moduls und der Durchführung einer Bedrohungsanalyse Ihrer Webanwendung haben Sie ein fundiertes Wissen über die Sicherheitslücken in Ihrer Anwendung und können die bestehenden Bedrohungen identifizieren und abschätzen. Dank diesen Wissens können Sie bestehenden Bedrohungen mit geeigneten Gegenmaßnahmen in einer logischen Reihenfolge begegnen, beginnend mit den Gefahren, die das höchste Risiko darstellen.

Ein hundertprozentig sicheres System gibt es nicht, wenn eine Webanwendung feindlichen Umgebungen wie dem Internet, einem Intranet oder einem Extranet ausgesetzt ist. Die einzige Möglichkeit besteht darin, die Existenz von Bedrohungen einzuräumen und die damit verbundenen Risiken zu entschärfen oder zu bewältigen. Durch eine Bedrohungsanalyse können Sie Ihre Ressourcen auf die relevanten Probleme konzentrieren und dadurch die Investitionsrendite maximieren.

Zielsetzung

Themenbereiche:

Erstellen von Bedrohungsanalysen
Abschätzen von Bedrohungen und Verwenden des DREAD-Modells
Gliedern einer Anwendungsarchitektur und Erkennen ihrer Sicherheitslücken
Identifizieren und Dokumentieren von Bedrohungen, die für eine Anwendung von Bedeutung sind.

Betrifft

Webanwendungen

Verwendung dieses Moduls

In diesem Modul wird ein Überblick über einen allgemeinen Prozess gegeben, durch den Bedrohungen für eine Anwendung identifiziert und dokumentiert werden können. Beachten Sie folgende Empfehlungen, damit Ihre Arbeit mit diesem Modul erfolgreich wird:

Legen Sie einen Prozess für die Bedrohungsanalyse fest. Falls Sie in Ihrem Unternehmen noch keinen Prozess zur Bedrohungsanalyse eingeführt haben, sollten Sie dieses Modul dazu nutzen. Wenn bereits ein Prozess existiert, können Sie diesen als Referenz für einen Vergleich verwenden.
Verwenden Sie auch die anderen Module dieses Handbuchs. In ihnen werden die bekanntesten Bedrohungen vorgestellt. In Modul 2, "Bedrohungen und Gegenmaßnahmen", finden Sie einen Überblick über häufige Bedrohungen auf Netzwerk-, Host- und Anwendungsebene.
- Informationen über konkrete Bedrohungen für Ihr Netzwerk finden Sie unter "Bedrohungen und Gegenmaßnahmen" in Modul 15, "Schützen des Netzwerks".
- Informationen über konkrete Bedrohungen für Ihren Webserver, Anwendungsserver und Datenbankserver finden Sie unter "Bedrohungen und Gegenmaßnahmen" in Modul 16, "Schützen des Webservers", Modul 17, "Schützen des Anwendungsservers" und in Modul 18, "Schützen des Datenbankservers".
- Informationen über konkrete Bedrohungen für Ihre Assemblys, ASP.NET, Dienstkomponenten, Remotekomponenten, Webdienste und den Datenzugriff finden Sie unter "Bedrohungen und Gegenmaßnahmen" in Modul 7, "Erstellen sicherer Assemblys", Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente", Modul 11, "Erstellen sicherer Serviced Components", Modul 12, "Erstellen sicherer Webdienste", Modul 13, "Erstellen sicherer Remotekomponenten" und Modul 14, "Erstellen eines sicheren Datenzugriffs".
Entwickeln Sie eine Bedrohungsanalyse. Eine Bedrohungsanalyse sollte früh erstellt und dann bei Bedarf erweitert werden. Es handelt sich um eine fortschreitende Arbeit. Sicherheitsbedrohungen entwickeln sich weiter, ebenso die Anwendung. Ein Dokument, mit dem die bekannten Bedrohungen identifiziert werden können und aus dem ersichtlich wird, wie ihnen entgegenzutreten ist (oder nicht), ermöglicht Ihnen, die Sicherheit der Anwendung zu überwachen.

Vorbereitung:

Bevor Sie eine Bedrohungsanalyse beginnen, sollten Sie mit den folgenden elementaren Begriffen vertraut sein:

Datenbestand: Eine sehr wichtige Ressource, zum Beispiel Daten in einer Datenbank oder im Dateisystem, eine Systemressource.
Bedrohung: Ein mögliches Ereignis, bösartig oder nicht, durch das Ihr Datenbestand geschädigt oder gefährdet werden kann.
Sicherheitslücken: Schwachstellen in Teilen oder Funktionen eines Systems, durch die eine Bedrohung ermöglicht wird. Sicherheitslücken können auf Netzwerk-, Host- oder Anwendungsebene vorhanden sein.
Angriff (oder Ausnutzung): Eine von irgendjemandem oder irgendetwas ausgehende Aktion, durch die ein Datenbestand beschädigt wird. Urheber kann zum Beispiel eine Person sein, die einer Bedrohung nachgeht oder eine Sicherheitslücke ausnutzt.
Gegenmaßnahme: Eine Schutzmaßnahme, die gegen eine Bedrohung gerichtet wird und durch die das Risiko entschärft wird.

Das Szenario kann mit einem Haus verglichen werden: Ein Schmuckstück im Haus entspricht dem Datenbestand und ein Einbrecher dem Angreifer. Eine Tür ist eine Funktion des Hauses und eine offene Tür ist eine Sicherheitslücke. Der Einbrecher kann die offene Tür ausnützen, um Zugang zum Haus zu erhalten und das Schmuckstück zu stehlen. In anderen Worten nützt der Angreifer eine Sicherheitslücke aus, um Zugang zu einem Datenbestand zu erhalten. Die passende Gegenmaßnahme ist in diesem Fall, die Tür zu schließen und abzusperren.

Grundlagen der Bedrohungsanalyse

Eine Bedrohungsanalyse sollte kein einmaliger Prozess sein. Sie sollte ein sich wiederholender Prozess sein, der während der frühen Entwicklungsphase der Anwendung beginnt und während des gesamten Lebenszyklus der Anwendung fortgesetzt wird. Dafür gibt es zwei Gründe. Zum einen ist es unmöglich, alle möglichen Bedrohungen in einem Durchgang zu identifizieren. Zum anderen sollte die Bedrohungsanalyse mit der Weiterentwicklung der Anwendung wiederholt werden, da Anwendungen selten statisch sind und erweitert und angepasst werden müssen, damit sie sich ändernden Unternehmensanforderungen gerecht werden.

Der Prozess

In Abbildung 3.1 wird eine als sechsstufiger Prozess durchgeführte Bedrohungsanalyse dargestellt.

Hinweis: Der im folgenden skizzierte Prozess kann für Anwendungen verwendet werden, die gerade entwickelt werden oder bereits existieren.

Überblick über die Bedrohungsanalyse

Abbildung 3.1
Überblick über die Bedrohungsanalyse

Identifizieren zu schützender Daten/Komponenten.
Identifizieren Sie die wichtigen Datenbestände, die durch das System geschützt werden müssen.
Erstellen einer Architekturübersicht.
Dokumentieren Sie die Architektur der Anwendung einschließlich Subsysteme, Vertrauensgrenzen und Datenfluss mithilfe von einfachen Diagrammen und Tabellen.
Gliedern der Anwendung.
Gliedern Sie die Anwendungsarchitektur einschließlich der darunter liegenden Netzwerk- und Hostinfrastrukturgestaltung, damit Sie ein Sicherheitsprofil für die Anwendung erstellen können. Das Sicherheitsprofil dient zur Aufdeckung von Sicherheitslücken in der Entwicklungs-, Implementierungs- oder Bereitstellungskonfiguration der Anwendung.
Identifizieren der Bedrohungen.
Identifizieren Sie unter Berücksichtigung der Ziele eines Angreifers und in Kenntnis der Architektur und möglichen Sicherheitslücken die Angriffe, durch die die Anwendung bedroht werden kann.
Dokumentieren der Bedrohungen.
Dokumentieren Sie jede Bedrohung unter Verwendung einer allgemeinen Vorlage, in der für jede Bedrohung ein Kernsatz der zu erfassenden Attribute definiert ist.
Bewerten der Bedrohungen.
Schätzen Sie die Bedrohungen ein, damit Sie den wichtigsten den Vorrang geben und ihnen zuerst entgegenwirken können. Diese Bedrohungen bergen die größte Gefahr in sich. Bei dieser Einschätzung sollten Sie ermitteln, wie hoch die Wahrscheinlichkeit eines Angriffs ist und diese gegen den Schaden, der im Falle eines Angriffs entstehen könnte, abwägen. Es kann sich herausstellen, dass bestimmte Bedrohungen keinerlei Handlungen rechtfertigen, wenn die durch die Bedrohungen auftretenden Risiken mit den Kosten für die Milderung verglichen werden.

Das Ergebnis

Das Ergebnis der Bedrohungsanalyse wird in einem Dokument für die Mitglieder des Projektteams festgehalten. In diesem Dokument müssen die Bedrohungen, denen entgegenzuwirken ist, eindeutig und verständlich beschrieben sein, und es muss erklärt werden, wie den Bedrohungen entgegengewirkt werden kann. Bedrohungsanalysen bestehen aus einer Definition der Architektur der Anwendung und einer Liste von Bedrohungen für das Anwendungsszenario. In Abbildung 3.2 wird der Aufbau einer Bedrohungsanalyse dargestellt.

Bestandteile einer Bedrohungsanalyse

Abbildung 3.2
Bestandteile einer Bedrohungsanalyse

1. Schritt: Identifizieren zu schützender Daten/Komponenten

Identifizieren Sie die zu schützenden Datenbestände. Dies können vertrauliche Daten wie die Kunden- oder Auftragsdatenbank bis hin zu Verfügbarkeitsdaten der Webseiten oder der Website sein.

2. Schritt: Erstellen einer Architekturübersicht

In dieser Phase ist das Ziel die Dokumentation der Funktion der Anwendung, ihrer Architektur und physischen Bereitstellungskonfiguration und der Technologien, die Teil der Lösung sind. Sie sollten nach möglichen Sicherheitslücken in der Gestaltung oder Implementierung der Anwendung suchen.

Folgende Aufgaben sind an dieser Stelle durchzuführen:

Funktion der Anwendung.
Erstellen eines Architekturschemas.
Identifizieren der Technologien.

Funktion der Anwendung

Stellen Sie fest, was die Anwendung macht, wie die Datenbestände verwendet werden und wie auf diese zugegriffen wird. Dokumentieren Sie Anwendungsfälle, damit für Sie und andere ersichtlich wird, wie die Anwendung eingesetzt wird. Dadurch können Sie auch herausfinden, wie die Anwendung falsch eingesetzt werden kann. Anwendungsfälle bringen die Funktionalität der Anwendung in einen Zusammenhang.

Die folgenden Beispiele könnten Anwendungsfälle für ein Mitarbeiter-Portal einer Personalverwaltungsanwendung sein:

Ein Mitarbeiter betrachtet Finanzstatistiken.
Ein Mitarbeiter aktualisiert persönliche Daten.
Der Geschäftsführer betrachtet Daten über einen Mitarbeiter.

In den oben genannten Fällen können Sie die Auswirkungen falsch angewendeter Unternehmensrichtlinien sehen. Denken Sie beispielsweise an einen Benutzer, der versucht, die persönlichen Daten eines anderen Benutzers zu ändern. Er oder sie sollte entsprechend den festgelegten Anforderungen an die Anwendung nicht befugt sein, auf diese Daten zuzugreifen.

Erstellen eines Architekturschemas

Beginnen Sie mit dem Erstellen eines ausführlichen Architekturschemas, in dem die Zusammensetzung und Struktur der Anwendung, ihrer Subsysteme sowie ihrer physikalischen Bereitstellungscharakteristika beschrieben werden. Ein Beispiel eines solchen Schemas finden Sie in Abbildung 3.3. Abhängig von der Komplexität des Systems kann es notwendig sein, zusätzliche Diagramme zu erstellen, die sich auf verschiedene Bereiche konzentrieren, beispielsweise ein Diagramm, in dem die Architektur eines Anwendungsservers der mittleren Schicht modelliert wird, oder eines, in dem die Wechselwirkung mit einem externen System beschrieben wird.

Musterdiagramm einer Anwendungsarchitektur

Abbildung 3.3
Musterdiagramm einer Anwendungsarchitektur

Beginnen Sie mit dem Entwurf eines groben Diagramms, in dem die Zusammensetzung und Struktur der Anwendung und ihrer Subsysteme zusammen mit ihren Bereitstellungscharakteristika vermittelt wird. Erweitern Sie dann das Diagramm durch Hinzufügen von Einzelheiten über Vertrauensgrenzen, die Authentifizierung und Autorisierungsmechanismen, sobald Sie diese entdecken (üblicherweise während des 3. Schrittes beim Gliedern der Anwendung).

Identifizieren der Technologien

Identifizieren Sie die einzelnen Technologien, die bei der Implementierung Ihrer Lösung verwendet werden. Dies erleichtert die Konzentration auf technologiespezifische Bedrohungen im weiteren Prozess und die Festlegung der richtigen und geeigneten Milderungstechniken. Unter den Techniken, die Sie identifizieren, sind wahrscheinlich ASP.NET, Webdienste, Enterprise Services, Microsoft .NET Remoting und ADO.NET. Identifizieren Sie auch alle nicht verwalteten Codes, die von der Anwendung aufgerufen werden.

Dokumentieren Sie die Technologien in einer Tabelle, ähnlich der weiter unten dargestellten Tabelle 3.1.

Tabelle 3.1. Implementierungstechnologien

Technologie / Plattform	Implementierungsinformationen
Microsoft SQL Server auf Microsoft Windows Advanced Server 2000	Enthält Anmeldungen, Datenbankbenutzer, benutzerdefinierte Datenbankfunktionen, Tabellen, gespeicherte Prozeduren, Ansichten, Einschränkungen und Trigger.
Microsoft .NET Framework	Verwendet für Formularauthentifizierungen.
Secure Sockets Layer (SSL)	Verwendet zum Verschlüsseln von HTTP-Datenverkehr.

3. Schritt: Gliedern der Anwendung

Gliedern Sie in diesem Schritt die Anwendung, damit Sie ein auf herkömmlichen Sicherheitslücken beruhendes Sicherheitsprofil für die Anwendung erstellen können. Weiterhin identifizieren Sie Vertrauensgrenzen, Datenfluss, Einstiegspunkte und privilegierten Code. Je mehr Sie über die Abläufe der Anwendung wissen, desto einfacher ist es, die Bedrohungen aufzudecken. In Abbildung 3.4 werden die verschiedenen Ziele des Gliederungsprozesses dargestellt.

Ziele der Anwendungsgliederung

Abbildung 3.4
Ziele der Anwendungsgliederung

Folgende Aufgaben sind an dieser Stelle durchzuführen:

Identifizieren von Vertrauensgrenzen.
Identifizieren des Datenflusses.
Identifizieren von Einstiegspunkten.
Identifizieren von privilegiertem Code.
Dokumentieren des Sicherheitsprofils.

Identifizieren von Vertrauensgrenzen

Identifizieren Sie die Vertrauensgrenzen, die alle Datenbestände Ihrer Anwendung umgeben. Diese Datenbestände wurden im Entwurf der Anwendung festgelegt. Berücksichtigen Sie bei jedem Subsystem, ob der Upstream-Datenfluss oder die Benutzereingabe vertrauenswürdig sind. Sollte dies nicht der Fall sein, ist zu bedenken, wie der Datenfluss und die Eingabe authentifiziert und autorisiert werden können. Ebenso ist zu prüfen, ob der Code, über den Daten aufgerufen werden, vertrauenswürdig ist. Auch hier ist zu überlegen, wie der Code authentifiziert und autorisiert werden kann, wenn er nicht vertrauenswürdig ist. Sie müssen sicherstellen, dass alle Einstiegspunkte in eine bestimmte Vertrauensgrenze durch die entsprechenden Gatekeeper überwacht werden, und dass am empfangenden Einstiegspunkt alle Daten, die die Vertrauensgrenze passieren, vollständig überprüft werden.

Beginnen Sie bei der Analyse der Vertrauensgrenze mit dem Code. Die Assembly, die einen Typ von Vertrauensgrenzen darstellt, ist für den Beginn geeignet. Zwischen welchen Assemblys bestehen Vertrauensbeziehungen? Besteht zwischen einer bestimmten Assembly und dem Code, über den sie aufgerufen wird, eine Vertrauensbeziehung oder ist sie mit einer Codezugriffssicherheit ausgestattet, um den aufrufenden Code zu autorisieren?

Berücksichtigen Sie auch die Serververtrauensstellung. Besteht zwischen einem bestimmten Server und einem Upstreamserver eine Vertrauensbeziehung in Hinsicht darauf, dass die Endbenutzer über den Upstreamserver authentifiziert und autorisiert werden, oder werden über den Server eigene Gatekeepingdienste zur Verfügung gestellt? Besteht zwischen einem Server und einem Upstreamserver auch in der Hinsicht eine Vertrauensbeziehung, das über den Upstreamserver Daten weitergeleitet werden dürfen, die richtig geformt und korrekt sind?

In Abbildung 3.3 wird beispielsweise von der Webanwendung mithilfe einer festen, vertrauenswürdigen Identität auf den Datenbankserver zugegriffen. In diesem Fall ist die Identität das ASPNET-Webanwendungsprozesskonto. In diesem Szenario besteht zwischen dem Datenbankserver und der Anwendung ein Vertrauensverhältnis dergestalt, dass über die Anwendung Benutzer authentifiziert und autorisiert werden können, sowie ausschließlich gültige Daten von Datenanforderungen im Auftrag von autorisierten Benutzern weitergeleitet werden dürfen.

Hinweis: In einer .NET Framework-Anwendung stellt die Assembly die kleinste Vertrauenseinheit dar. Wenn immer Daten die Grenzen einer Assembly passieren - wozu per Definition eine Anwendungsdomänen-, Prozess- oder Computergrenze zählt - sollten über den empfangenden Einstiegspunkt die Eingabedaten überprüft werden.

Identifizieren des Datenflusses

Ein einfacher Ansatz ist der Beginn auf der höchsten Ebene und ein wiederholtes Gliedern der Anwendung durch die Analyse des Datenflusses zwischen einzelnen Subsystemen. Analysieren Sie beispielsweise den Datenfluss zwischen einer Webanwendung und einer Enterprise Services-Anwendung und anschließend zwischen den einzelnen bedienten Komponenten.

Der Datenfluss über Vertrauensgrenzen hinaus ist besonders wichtig, da in der Grundannahme jedwede Daten außerhalb der Vertrauensgrenze als bösartig gelten und gründlich überprüft werden sollten.

Hinweis: Datenflussdiagramme (DFDs) und Ablaufdiagramme können bei der formalen Gliederung eines Systems hilfreich sein. Ein DFD ist eine grafische Darstellung von Datenflüssen, Datenspeichern und Beziehungen zwischen Datenquellen und -zielen. In einem Ablaufdiagramm wird gezeigt, wie eine Gruppe von Objekten im Sinne von chronologischen Ereignissen zusammenarbeitet.

Identifizieren von Einstiegspunkten

Die Einstiegspunkte einer Anwendung dienen auch als Einstiegspunkte für Angriffe. Einstiegspunkte können die Front-End-Webanwendung beinhalten, die auf HTTP-Anforderungen reagiert. Dieser Einstiegspunkt soll für Clients offen stehen. Andere Einstiegspunkte, wie interne Einstiegspunkte, die für Subkomponenten über die Reihen der Anwendung offen sind, dürfen nur eingerichtet werden, um die interne Kommunikation mit anderen Komponenten zu unterstützen. Wenn es ein Angreifer schafft, die Vordertür der Anwendung zu umgehen und einen inneren Einstiegspunkt direkt anzugreifen, sollten Sie wissen, wo sich diese befinden und welche Art von Eingaben diese erhalten.

Sie sollten in der Lage sein, für jeden Einstiegspunkt die Typen von Gatekeepern, die eine Autorisierung bieten, und den Grad der Überprüfung festzulegen.

Logische Einstiegspunkte von Anwendungen beinhalten Benutzerschnittstellen, die von Webseiten zur Verfügung gestellt werden, Dienstschnittstellen, die von Webdiensten zur Verfügung gestellt werden, bediente Komponenten, .NET-Remoting-Komponenten und Nachrichtenwarteschlangen, über die asynchrone Einstiegspunkte zur Verfügung gestellt werden. Physische und Plattform-Einstiegspunkte beinhalten Ports und Sockets.

Identifizieren von privilegiertem Code

Über privilegierten Code kann auf bestimmte Arten von sicheren Ressourcen zugegriffen werden und es können andere privilegierte Vorgänge ausgeführt werden. Sichere Ressourcen sind unter anderem DNS-Server, Verzeichnisdienste, Umgebungsvariablen, Ereignisprotokolle, Dateisysteme, Nachrichtenwarteschlangen, Leistungsindikatoren, Drucker, die Registrierung, Sockets und Webdienste. Sichere Vorgänge sind unter anderem nicht verwaltete Codeaufrufe, Spiegelung, Serialisierung, Codezugriffssicherheits-Berechtigungen und die Manipulation der Codezugriffssicherheits-Richtlinie, einschließlich der Erfolge.

Privilegiertem Code müssen geeignete Berechtigungen für die Codezugriffssicherheit über entsprechende Richtlinien gewährt werden. Bei privilegiertem Code muss sichergestellt werden, dass die Ressourcen und Vorgänge, die in ihm enthalten sind, keinem unvertrauenswürdigen und potenziell bösartigen Code ausgesetzt sind. Durch die Codezugriffssicherheit von .NET Framework werden die Berechtigungen geprüft, die aufrufendem Code durch die Durchführung von Stackwalks gewährt werden. Jedoch ist es manchmal notwendig, sich über dieses Verhalten hinwegzusetzen und den vollständigen Stackwalk zu umgehen, zum Beispiel wenn privilegierter Code durch eine Sandbox eingeschränkt oder sonst privilegierter Code isoliert werden soll. Dadurch wird der Code für Lockangriffe offen gelegt, bei denen Ihr Code über vertrauenswürdigen Zwischencode von bösartigem Code aufgerufen wird.

Immer, wenn das Standardsicherheitsverhalten umgangen wird, das durch die Codezugriffssicherheit zur Verfügung gestellt wird, sollten Sie den Code gewissenhaft überprüfen. Weitere Informationen über das Überprüfen von Code auf Sicherheitsmängel finden Sie in Modul 21, "Codeüberprüfung". Weitere Informationen über Codezugriffssicherheit, finden Sie in Modul 8, "Codezugriffssicherheit in der Praxis" und Modul 9, "Verwenden der Codezugriffssicherheit mit ASP.NET".

Dokumentieren des Sicherheitsprofils

Als Nächstes sollten Sie die Entwurfs- und Implementierungsansätze identifizieren, die für die Eingabeüberprüfung, Authentifizierung, Autorisierung, Konfigurationsverwaltung und die anderen Bereiche verwendet werden, bei denen Anwendungen äußerst anfällig für Sicherheitslücken sind. Damit erstellen Sie ein Sicherheitsprofil für die Anwendung.

In Tabelle 3.2 wird aufgeführt, welche Typen von Fragen bei der Analyse jedes einzelnen Aspekts des Entwurfs und der Implementierung der Anwendung zu stellen sind. Weitere Informationen über die Sicherheitsüberprüfung von Anwendungsarchitektur und -entwurf finden Sie in Modul 5, "Sicherheitsüberprüfung der Architektur und des Entwurfs".

Tabelle 3.2. Erstellen eines Sicherheitsprofils

Kategorie	Überlegungen
Eingabeüberprüfung	Wurden alle eingegebenen Daten überprüft? Könnte ein Angreifer Befehle oder bösartige Daten in die Anwendung einspeisen? Werden die Daten beim Passieren von Vertrauensgrenzen überprüft (über den empfangenden Einstiegspunkt)? Sind die Daten in der Datenbank sicher?
Authentifizierung	Sind die Anmeldeinformationen geschützt, wenn sie über das Netzwerk übertragen werden? Werden sichere Kontorichtlinien verwendet? Werden sichere Kennwörter erzwungen? Werden Zertifikate verwendet? Wird eine Kennwortüberprüfung (mithilfe von unidirektionalen Hashes) für die Benutzerkennwörter verwendet?
Autorisierung	Welche Gatekeeper werden an den Einstiegspunkten der Anwendung verwendet? Wie wird die Autorisierung an der Datenbank erzwungen? Wird eine Strategie für die Verteidigung in der Tiefe verwendet? Wird ein sicherer Abbruch ermöglicht und der Zugriff nur nach erfolgreicher Bestätigung der Anmeldeinformationen gewährt?
Konfigurationsverwaltung	Welche Verwaltungsschnittstellen unterstützt die Anwendung? Wie sind diese geschützt? Wie wird die Remoteverwaltung geschützt? Welche Konfigurationsspeicher werden verwendet und wie sind diese geschützt?
Sicherheitsrelevante Daten	Welche sicherheitsrelevanten Daten werden von der Anwendung behandelt? Wie werden sie über das Netzwerk und in beständigen Speichern geschützt? Welche Art der Verschlüsselung wird verwendet und wie sind Verschlüsselungsschlüssel geschützt?
Sitzungsverwaltung	Wie werden Sitzungscookies erzeugt? Wie werden diese geschützt, um ein Hijacking der Sitzung zu verhindern? Wie wird ein beständiger Sitzungszustand geschützt? Wie wird der Sitzungszustand geschützt, wenn er in das Netzwerk übertragen wird? Wie wird die Anwendung beim Sitzungsspeicher autorisiert? Werden Anmeldeinformationen per Kabel übertragen und werden diese von der Anwendung aufrechterhalten? Wenn ja, wie sind diese geschützt?
Kryptografie	Welche Algorithmen und kryptografischen Techniken werden verwendet? Wie lang sind Verschlüsselungsschlüssel und wie sind diese geschützt? Wird von der Anwendung eine eigene Verschlüsselung verwendet? Wie oft werden Schlüssel wiederverwendet?
Parametermanipulation	Werden verfälschte Parameter von der Anwendung erkannt? Werden alle Parameter in Formularfeldern, im Anzeigestatus, in Cookiedaten und HTTP-Headern von der Anwendung überprüft?
Ausnahmeverwaltung	Wie werden Fehlerbedingungen von der Anwendung behandelt? Besteht die Möglichkeit, dass Ausnahmen auf den Client zurückübertragen werden? Werden allgemeine Fehlermeldungen verwendet, die keine verwertbaren Informationen enthalten?
Überwachen und Protokollieren	Werden Aktivitäten über alle Reihen auf allen Servern von der Anwendung überwacht? Wie werden Protokolldateien geschützt?

4. Schritt: Identifizieren der Bedrohungen

Identifizieren Sie in diesem Schritt die Bedrohungen, die das System angreifen und die Datenbestände beeinträchtigen könnten. Um diesen Prozess durchführen zu können, sollten sich Mitglieder der Entwicklungs- und Testteams vor einer Magnettafel zusammensetzen und eine sachliche Gruppendiskussion führen. Dies ist eine einfache, jedoch effektive Methode zur Identifizierung potenzieller Bedrohungen. Idealerweise besteht das Team aus Anwendungsarchitekten, Sicherheitsexperten, Entwicklern, Testern und Systemadministratoren.

Sie können zwei grundsätzliche Ansätze verwenden:

Verwenden von STRIDE zur Identifikation von Bedrohungen. Berücksichtigen Sie die Breite an Bedrohungskategorien, zum Beispiel Spoofing, Intrigieren und Dienstverweigerung, und stellen Sie unter Zuhilfenahme des STRIDE-Modells aus Modul 2, "Bedrohungen und Gegenmaßnahmen", Fragen zu jedem Aspekt der Architektur und des Entwurfs der Anwendung. Bei diesem Ansatz werden die Ziele eines Angreifers berücksichtigt. Ein Angreifer könnte zum Beispiel eine Identität verschleiern, um auf den Webserver oder die Webanwendung zugreifen zu können. Könnte jemand mit Daten über das Netzwerk oder in einem Speicher intrigieren? Könnte jemand einen Dienst verweigern?
Verwenden von kategorisierten Bedrohungslisten. Bei diesem Ansatz beginnen Sie mit einer Liste mit allgemeinen Bedrohungen, die in Netzwerk-, Host- und Anwendungskategorien eingeteilt sind. Wenden Sie die Bedrohungsliste danach auf die eigene Anwendungsarchitektur und jegliche Sicherheitslücken an, die früher im Prozess identifiziert wurden. Einige Bedrohungen werden Sie sofort ausschließen können, da sie sich nicht gegen Ihr Szenario richten.

Die Verwendung folgender Ressourcen unterstützt den Bedrohungsidentifikationsprozess:

Eine Liste mit Bedrohungen, aufgeschlüsselt in Netzwerk-, Host- und Anwendungsebenen, sowie Erklärungen der Bedrohungen und zugehörige Gegenmaßnahmen finden Sie in Modul 2, "Bedrohungen und Gegenmaßnahmen".
Eine Liste mit Bedrohungen je nach Technologie finden Sie in "Bedrohungen und Gegenmaßnahmen" am Anfang jedes Moduls, dessen Titel mit "Erstellen" beginnt, in Teil III dieses Handbuchs.

Folgende Aufgaben sind an diese Stelle durchzuführen:

Identifizieren von Netzwerkbedrohungen.
Identifizieren von Hostbedrohungen.
Identifizieren von Anwendungsbedrohungen.

Identifizieren von Netzwerkbedrohungen

Dies ist eine Aufgabe für Netzwerkentwickler und -administratoren. Analysieren Sie die Netzwerktopologie und den Fluss der Datenpakete zusammen mit den Konfigurationen des Routers, der Firewall und der Switches, und suchen Sie nach potenziellen Sicherheitslücken. Beachten Sie auch die Endpunkte von virtuellen privaten Netzwerken (VPN). Überprüfen Sie die Verteidigung des Netzwerks gegen die bekanntesten Bedrohungen auf Netzwerkebene, die in Modul 2, "Bedrohungen und Gegenmaßnahmen" identifiziert wurden.

Die an vorderster Stelle stehenden Netzwerkbedrohungen während der Entwicklungsphase sind unter anderem:

Verwendung von Sicherheitsmechanismen, die sich auf die IP-Adresse des Absenders verlassen. Es ist relativ einfach, IP-Pakete mit falscher Quell-IP-Adresse zu senden (IP-Spoofing).
Weiterleiten von Sitzungskennungen oder Cookies über unverschlüsselte Netzwerkkanäle. Dies kann zu einem Hijacking der IP-Sitzung führen.
Weiterleiten von Anmeldeinformationen oder anderer sicherheitsrelevanter Daten über unverschlüsselte Kommunikationskanäle in Klartext. Dies könnte es einem Angreifer ermöglichen, das Netzwerk zu überwachen, Anmeldeinformationen oder andere sicherheitsrelevante Daten zu erhalten und möglicherweise zu verfälschen.

Es muss also sichergestellt werden, dass das Netzwerk nicht gegen Bedrohungen verwundbar ist, die von einer unsicheren Geräte- und Serverkonfiguration herrühren. Sind beispielsweise unnötige Ports und Protokolle geschlossen und deaktiviert? Sind Routingtabellen und DNS-Server geschützt? Sind die TCP-Netzwerkstapel auf den Servern abgesichert? Weitere Informationen über das Verhindern dieser Art von Sicherheitslücken finden Sie in Modul 15, "Schützen des Netzwerks".

Identifizieren von Hostbedrohungen

Der in diesem Handbuch durchgehend verwendete Ansatz für die Konfiguration der Hostsicherheit (das heißt die Konfiguration von Microsoft Windows 2000 und .NET Framework) ist, die Konfiguration in separate Kategorien zu teilen, um somit die Sicherheitseinstellungen in einer strukturierten und logischen Weise anwenden zu können. Dieser Ansatz ist auch zur Überprüfung der Sicherheit, zum Aufspüren von Sicherheitslücken und zur Identifikation von Bedrohungen sehr gut geeignet. Die allgemeinen Konfigurationskategorien, die für alle Serverrollen geeignet sind, sind unter anderem Patches und Updates, Dienste, Protokolle, Konten, Dateien und Verzeichnisse, Freigaben, Ports, sowie Überwachen und Protokollieren. Für jede Kategorie sind die potenziell sicherheitsgefährdenden Konfigurationseinstellungen zu identifizieren und aus diesen sind die Bedrohungen zu ermitteln.

Zu den gefährlichsten Sicherheitslücken, die zu berücksichtigen sind, zählen:

Server, auf denen keine Patches installiert sind. Diese sind durch Viren, Trojanische Pferde, Würmer und bekannte IIS-Angriffe gefährdet.
Verwendung von unnötigen Ports, Protokollen und Diensten, die das Angriffsprofil erhöhen und es Angreifern ermöglichen, Informationen über Ihre Umgebung zu erhalten und diese auszunutzen.
Ermöglichen von nicht authentifiziertem anonymen Zugriff.
Verwendung von schwachen Kennwort- und Kontorichtlinien, die zum Knacken von Kennwörtern, Identitätsvortäuschungen und Dienstverweigerungsangriffen führen, wenn Konten vorsätzlich gesperrt werden können.

Identifizieren von Anwendungsbedrohungen

In den vorangegangenen Schritten wurden die Architektur, der Datenfluss und die Vertrauensgrenzen der Anwendung definiert. Außerdem wurde ein Sicherheitsprofil erstellt, in dem beschrieben wird, wie die Kerngebiete, wie Authentifizierung, Autorisierung, Konfigurationsverwaltung und andere Gebiete, von der Anwendung behandelt werden.

Verwenden Sie nun die breit angelegten STRIDE-Bedrohungskategorien und vordefinierten Bedrohungslisten, um jeden Aspekt des Sicherheitsprofils Ihrer Anwendung genau zu untersuchen. Richten Sie Ihr Augenmerk auf Anwendungsbedrohungen, technologiespezifische Bedrohungen und Codebedrohungen. Zu den Sicherheitslücken mit Schlüsselfunktion, die zu berücksichtigen sind, zählen:

Mangelhafte Eingabeüberprüfung, die zu Cross-Site Skripting (XSS), SQL-Injektion und Pufferüberlaufangriffen führt.
Weiterleiten von Authentifizierungsinformationen oder Authentifizierungs-Cookies über nicht verschlüsselte Netzwerkverbindungen, was zum Abfangen der Anmeldeinformationen oder dem Hijacking von Sitzungen führen kann.
Verwenden von schwachen Kennwort- und Kontorichtlinien, was zu unberechtigten Zugriffen führen kann.
Vernachlässigen der Sicherung der Konfigurationsverwaltungsaspekte der Anwendung einschließlich der Verwaltungsschnittstellen.
Speichern von geheimen Konfigurationsinformationen in Klartext, zum Beispiel Verbindungszeichenfolgen und Anmeldeinformationen für Dienstkonten.
Verwendung überprivilegierter Prozess- und Dienstkonten.
Verwenden von unsicheren Kodiertechniken für den Datenzugriff, welche die Bedrohungen, die von einer SQL-Injektion ausgehen, erhöhen können.
Verwendung einer schwachen oder benutzerdefinierten Verschlüsselung und Vernachlässigen einer angemessenen Sicherung der Verschlüsselungsschlüssel.
Vertrauen auf die Integrität von Parametern, die von einem Webserver weitergeleitet werden, wie zum Beispiel Formularfelder, Abfragezeichenfolgen, Cookiedaten und HTTP-Header.
Verwenden einer unsicheren Ausnahmebehandlung, die zu Dienstverweigerungsangriffen und der Offenlegung von Informationen auf Systemebene, die für einen Angreifer hilfreich sind, führen kann.
Unzureichende Überprüfungen und Protokollierungen, die zu Ablehnungsbedrohungen führen können.

Verwenden von Angriffsbäumen und Angriffsmustern

Angriffsbäume und Angriffsmuster sind die wichtigsten Werkzeuge, die Sicherheitsexperten verwenden. Dies sind keine notwendigen Komponenten der Bedrohungsidentifizierungsphase, sie können jedoch sehr hilfreich sein. Sie ermöglichen eine tiefere Analyse der Bedrohungen, da Sie mit deren Hilfe über das was Sie bisher über die Identifizierung von Bedrohungen wissen, hinausgehen können.

Wichtig: Wenn Sie vorbereitete, kategorisierte Listen bekannter Bedrohungen verwenden, können Sie nur allgemeine, bekannte Bedrohungen aufdecken. Zusätzliche Ansätze wie die Verwendung von Angriffsbäumen und Angriffsmustern können bei der Identifizierung anderer potenzieller Bedrohungen hilfreich sein.

Mithilfe eines Angriffsbaums können potenzielle Angriffe auf das System in einer strukturierten und hierarchischen Weise gesammelt und dokumentiert werden. Die Baumstruktur ermöglicht eine anschauliche Aufschlüsselung der verschiedenen Angriffe, mit denen ein Angreifer das System zu beeinträchtigen versucht. Angriffsbäume sind eine wieder verwendbare Darstellung der Sicherheitsfragen, mit deren Hilfe Sie Ihre Anstrengungen konzentrieren können. Das Testteam kann Testpläne entwerfen, um die Sicherheitsgestaltung zu überprüfen. Die Entwickler können während der Entwicklung Kompromisse eingehen und die Vorgesetzten der Systemarchitekten oder Entwickler können die Sicherheitskosten anderer Ansätze bewerten.

Ein Angriffsmuster ist ein formaler Ansatz für das Abfangen von Angriffsinformationen im Unternehmen. Diese Muster können bei der Identifizierung allgemeiner Angriffstechniken helfen.

Erstellen von Angriffsbäumen

Obgleich in der Praxis verschiedene Ansätze verwendet werden können, besteht die allgemein anerkannte Methode darin, Ziele und Unterziele eines Angriffs, sowie die Aktionen, die notwendig sind, damit ein Angriff gelingt, zu ermitteln. Sie können ein hierarchisches Diagramm oder eine einfache Gliederung verwenden, um den Angriffsbaum darzustellen. Es ist wichtig, dass Sie am Ende eine Darstellung des Angriffsprofils Ihrer Anwendung haben. Dann können Sie voraussichtliche Sicherheitsrisiken bewerten, diese durch geeignete Gegenmaßnahmen entschärfen, zum Beispiel durch die Korrektur eines Gestaltungsentwurfs, das Absichern einer Konfigurationseinstellung oder andere Lösungen.

Beginnen Sie den Aufbau eines Angriffsbaums mit der Erstellung von Stammknoten, welche die Ziele des Angreifers darstellen. Fügen Sie dann die Endknoten hinzu, welche die Angriffsmethoden sind, die die einzelnen Angriffe darstellen. In Abbildung 3.5 ist ein einfaches Beispiel dargestellt.

Darstellung eines Angriffsbaums

Abbildung 3.5
Darstellung eines Angriffsbaums.

Endknoten können mit UND und ODER gekennzeichnet werden. In Abbildung 3.5 müssen beispielsweise sowohl 1.1 als auch 1.2 eintreten, damit aus der Bedrohung ein Angriff wird.

Angriffsbäume, wie der oben gezeigte, können schnell komplex werden. Außerdem ist es zeitaufwändig, diese zu erstellen. Ein alternativer Ansatz, der von einigen Teams bevorzugt wird, besteht darin, den Angriffsbaum mittels einer Gliederung zu strukturieren. Im folgenden Beispiel ist ein solcher Baum dargestellt.

1.  Ziel Eins
    1.1 Unterziel eins
    1.2 Unterziel zwei
2.  Ziel Zwei
    2.1 Unterziel eins
    2.2 Unterziel zwei

Hinweis: Zusätzlich zu Zielen und Unterzielen beinhalten Angriffsbäume Vorgehensweisen und notwendige Bedingungen.

In der Praxis sieht der Gliederungsansatz zum Beispiel wie folgt aus:

Bedrohung Nr. 1: Angreifer erhält durch Überwachen des Netzwerks Anmeldeinformationen
  1.1 Anmeldeinformationen werden im Klartext über das Netzwerk gesendet UND
  1.2 Angreifer verwendet Werkzeuge zur Netzwerküberwachung
      1.2.1 Angreifer erkennt Anmeldeinformationen

Ein vollständiges Beispiel finden Sie unter "Beispiele für Angriffsbäume" im Abschnitt "Spickzettel" dieses Handbuchs.

Angriffsmuster

Angriffsmuster sind allgemeine Darstellungen von üblicherweise auftretenden Angriffen, die in einer Reihe verschiedener Zusammenhänge auftreten können. Das Muster definiert das Ziel des Angriffs sowie die Bedingungen, die vorhanden sein müssen, damit der Angriff eintritt, die Schritte, die notwendig sind, um den Angriff auszuführen, und die Ergebnisse des Angriffs. Angriffsmuster sind auf Angriffstechniken fokussiert. Bei STRIDE-basierten Ansätzen geht es jedoch darum, die Ziele des Angreifers ausfindig zu machen.

Ein Beispiel ist das Angriffsmuster für die Code-Injektion, das verwendet wird, um Code-Injektionsangriffe in einer allgemeinen Weise zu beschreiben. In Tabelle 3.3. wird das Angriffsmuster für die Code-Injektion beschrieben.

Tabelle 3.3 Angriffsmuster Code-Injektion

Muster	Code-Injektionsangriffe
Angriffsziele	Befehls- oder Codeausführung
Notwendige Bedingungen	Schwache Eingabeüberprüfung Code des Angreifers hat ausreichende Privilegien auf dem Server.
Angriffstechnik	1. Identifizieren Sie Programme auf dem Zielsystem mit einer Sicherheitslücke bei der Eingabeüberprüfung. 2. Schreiben Sie injizierenden Code und führen Sie ihn im Sicherheitskontext der Zielanwendung aus. 3. Erstellen Sie Eingabewerte, die Code in den Adressspeicher der Zielanwendung einfügen, und erzwingen Sie einen Stapelfehler, der die Anwendung veranlasst, den injizierten Code auszuführen.
Angriffsergebnisse	Durch den Code des Angreifers werden bösartige Handlungen ausgeführt.

Weitere Informationen über Angriffsmuster finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Moduls.

5. Schritt: Dokumentieren der Bedrohungen

Um die Bedrohungen für die Anwendung zu dokumentieren, sollte eine Vorlage verwendet werden, in der mehrere Bedrohungsattribute, ähnlich den in Tabelle 3.4 aufgeführten, dargestellt werden. Die Beschreibung der Bedrohung und das Ziel der Bedrohung sind grundlegende Attribute. Lassen Sie zu diesem Zeitpunkt die Risikoeinschätzung unausgefüllt. Diese wird in der letzten Phase der Bedrohungsanalyse vorgenommen, wenn die identifizierte Bedrohungsliste in eine Rangordnung gebracht wird. Andere Attribute, die einbezogen werden können, sind Angriffstechniken, die auch die ausgenutzten Sicherheitslücken hervorheben können, und die Gegenmaßnahmen, die notwendig sind, um den Bedrohungen entgegenzutreten.

Tabelle 3.4. Bedrohung 1

Beschreibung der Bedrohung	Angreifer erhält Anmeldeinformationen durch Überwachen des Netzwerks
Ziel der Bedrohung	Benutzerauthentifizierungsprozess der Webanwendung
Risiko
Angriffstechniken	Verwendung von Programmen zur Netzwerküberwachung
Gegenmaßnahmen	Verwenden von SSL, um einen verschlüsselten Kanal bereitzustellen

Tabelle 3.5 Bedrohung 2

Beschreibung der Bedrohung	Injektion von SQL-Befehlen
Ziel der Bedrohung	Datenzugriffskomponente
Risiko
Angriffstechniken	Der Angreifer fügt SQL-Befehle an den Benutzernamen an, um eine SQL-Anfrage zu bilden.
Gegenmaßnahmen	Verwenden eines regulären Ausdrucks, um den Benutzernamen zu überprüfen, und Verwenden einer gespeicherten Prozedur, über die mithilfe von Parametern auf die Datenbank zugegriffen wird.

6. Schritt: Bewerten der Bedrohungen

In dieser Phase des Prozesses liegt Ihnen eine Liste der Bedrohungen vor, die auf Ihr spezielles Anwendungsszenario zutreffen. In der Endphase des Projekts werden die Risiken bewertet, die von den Bedrohungen ausgehen. Dadurch können Sie sich den Bedrohungen, welche die größten Risiken in sich bergen, zuerst zuwenden und danach die anderen Bedrohungen auflösen. In der Tat kann es sein, dass es wirtschaftlich nicht rentabel ist, sich allen identifizierten Bedrohungen zuzuwenden, und Sie können sich dazu entschließen, einige zu ignorieren, da die Wahrscheinlichkeit, dass sie eintreten, gering und der Schaden, den sie anrichten würden, minimal ist.

Risiko = Wahrscheinlichkeit * Schadenspotenzial

Durch diese Formel wird gezeigt, dass das Risiko, das von einer bestimmten Bedrohung ausgeht, gleich ist mit der Wahrscheinlichkeit, dass ein Angriff eintritt, multipliziert mit dem möglichen Schaden, der im Falle des Eintritts eines Angriffs auf das System entsteht.

Zur Bestimmung der Wahrscheinlichkeit können Sie eine Skala von 1 bis 10 verwenden, wobei mit 1 eine Bedrohung belegt wird, die wahrscheinlich nicht eintritt, und mit 10 eine Bedrohung, die fast sicher eintritt. Genauso können Sie eine Skala von 1 bis 10 für den möglichen Schaden anlegen, wobei 1 ein minimaler Schaden bedeutet, und 10 einer Katastrophe gleichkommt. Bei diesem Ansatz ist das Risiko, das von einer Bedrohung mit einer geringen Eintrittswahrscheinlichkeit, jedoch einem großen Schadenspotenzial ausgeht, gleich dem Risiko, das von einer Bedrohung mit beschränktem Schadenspotenzial, aber einer sehr hohen Eintrittswahrscheinlichkeit, ausgeht.

Wenn zum Beispiel gilt: Wahrscheinlichkeit=10 und Schadenspotenzial=1, ist das Risiko = 10 * 1 = 10. Wenn gilt: Wahrscheinlichkeit=1 und Schadenspotential=10, ist das Risiko = 1 * 10 = 10.

Aus diesem Ansatz lässt sich eine Skala von 1 bis 100 ableiten. Diese kann in drei Bewertungsbereiche einteilt werden: hohes, mittleres oder geringes Risiko.

Hohes, mittleres und geringes Risiko

Durch die Einteilung des Risikogrades in hoch, mittel oder gering können Sie Bedrohungen auf einfache Art und Weise in eine Rangordnung bringen. Wenn eine Bedrohung als hoch bewertet wird, stellt sie ein bedeutendes Risiko für die Anwendung dar und verlangt so bald als möglich nach Gegenmaßnahmen. Bei als mittel eingestuften Bedrohungen sind ebenso Gegenmaßnahmen erforderlich, wenn auch nicht ganz so dringend. Ist eine Bedrohung gering, kann sie, wenn die Kosten und der Aufwand für eine Gegenmaßnahme den Nutzen übersteigen, vernachlässigt werden.

DREAD

Das Problem bei einem stark vereinfachenden Bewertungssystem ist, dass die Teammitglieder sich nicht auf die Bewertungen einigen können. Um dies zu lösen, sind neue Dimensionen hinzuzufügen, die bei der Bestimmung der wirklichen Bedeutung der Auswirkungen einer Sicherheitsbedrohung hilfreich sind. Bei Microsoft wird das DREAD-Modell verwendet, um Risiken zu berechnen. Beim DREAD-Modell kommen Sie zu einer Risikobewertung für eine bestimmte Bedrohung, indem Sie folgende Fragen stellen:

Damage (Schadens-) potenzial: Wie groß ist der Schaden, wenn die Sicherheitslücke ausgenutzt wird?
Reproducibility (Reproduzierbarkeit): Wie leicht kann der Angriff reproduziert werden?
Exploitability (Ausnutzbarkeit): Wie leicht kann ein Angriff gestartet werden?
Affected (betroffene) Benutzer: Wie viele Benutzer können ungefähr betroffen sein (Angabe in Prozent)?
Discoverability (Auffindbarkeit): Wie leicht kann die Sicherheitslücke aufgefunden werden?

Mit diesen Fragen können Sie alle Bedrohungen bewerten. Sie können sie jedoch auch Ihren eigenen Bedürfnissen entsprechend erweitern. Sie können zum Beispiel eine Frage über eine mögliche Rufschädigung hinzufügen.

Ruf: Wie hoch ist der Einsatz? Besteht ein Risiko für den Ruf des Unternehmens, welches zu einem Vertrauensverlust des Kunden führen könnte?

Bewertungen sollten nicht breit gefächert werden. Dies erschwert lediglich die konsistente Bewertung von Bedrohungen im Vergleich mit anderen. Ein einfaches Schema wie hoch (1), mittel (2) und gering (3) reicht aus.

Wenn Sie klar definieren, was jeder Wert in einem Bewertungssystem bedeutet, hilft dies, Verwirrungen zu vermeiden. In Tabelle 3.6 wird ein typisches Beispiel einer Bewertungstabelle dargestellt, die von den Teammitgliedern für die Erstellung einer Rangordnung von Bedrohungen verwendet werden kann.

Tabelle 3.6. Bedrohungsbewertungstabelle

	Bewertung	Hoch (3)	Mittel (2)	Gering (1)
D	Damage potential (Schadenspotenzial)	Der Angreifer kann das Sicherheitssystem untergraben, volle Vertrauensautorisierung erlangen, als Administrator fungieren und Inhalte uploaden.	Verbreitung sicherheitsrelevanter Informationen	Verbreitung unbedeutender Informationen
R	Reproduzierbarkeit	Der Angriff kann jederzeit reproduziert werden, ein Zeitfenster ist nicht erforderlich.	Der Angriff kann reproduziert werden, jedoch nur in einem Zeitfenster und einer bestimmten Wettlaufsituation.	Der Angriff ist auch mit Kenntnis der Sicherheitslücke sehr schwer zu reproduzieren.
E	Exploitability (Ausnutzbarkeit)	Ein Programmieranfänger kann den Angriff in kurzer Zeit durchführen.	Ein erfahrener Programmierer kann den Angriff durchführen und dann die Schritte wiederholen.	Nur eine erfahrene Person mit eingehendem Fachwissen kann den Angriff ausführen.
A	Affected users (betroffene Benutzer)	Alle Benutzer, Standardkonfiguration, Schlüsselkunden	Einige Benutzer, keine Standardkonfiguration	Ein sehr geringer Prozentsatz von Benutzern, unbekannte Funktion, betrifft anonyme Benutzer
D	Discoverability (Auffindbarkeit)	Der Angriff wird über öffentlich zugängliche Medien erklärt. Die Sicherheitslücke findet sich in einer viel verwendeten Funktion und ist leicht wahrnehmbar.	Die Sicherheitslücke befindet sich in einem selten verwendeten Teil des Produkts, und nur wenige Benutzer entdecken sie zufällig. Es würde einiger Überlegungen bedürfen, um die bösartige Verwendbarkeit zu erkennen.	Der Fehler ist unbekannt und es ist unwahrscheinlich, dass Benutzer das Schadenspotenzial herausfinden.

Zählen Sie, nachdem Sie sich die oben genannten Fragen gestellt haben, die Werte (1 bis 3) für die Bedrohung zusammen. Das Ergebnis kann zwischen 5 und 15 liegen. Das Risiko von Bedrohungen mit einer Gesamtbewertung von 12 bis 15 ist als hoch einzustufen, 8 bis 11 stellt ein mittleres Risiko dar, und bei einem Wert von 5 bis 7 ist von einem geringen Risiko auszugehen.

Betrachten Sie beispielsweise die zuvor beschriebenen Bedrohungen:

Angreifer erhält Anmeldeinformationen durch Überwachen des Netzwerks.
SQL-Befehle werden in die Anwendung eingeschleust.

In Tabelle 3.7 wird eine beispielhafte DREAD-Bewertung für beide Bedrohungen dargestellt:

Tabelle 3.7. DREAD-Bewertung

Bedrohung	D	R	E	A	D	Gesamt	Bewertung
Angreifer erhält Anmeldeinformationen durch Überwachen des Netzwerks.	3	3	2	2	2	12	Hoch
SQL-Befehle werden in die Anwendung eingeschleust.	3	3	3	3	2	14	Hoch

Aktualisieren Sie die dokumentierten Bedrohungen, sobald Sie die Risikobewertung erhalten haben, und fügen Sie das ermittelte Bewertungsniveau hinzu, das bei beiden der oben besprochenen Bedrohungen hoch ist. In Tabelle 3.8 wird ein Beispiel gezeigt.

Tabelle 3.8 Bedrohung 1

Beschreibung der Bedrohung	Angreifer erhält Anmeldeinformationen durch Überwachen des Netzwerks
Ziel der Bedrohung	Benutzerauthentifizierung der Webanwendung
Risikobewertung	Hoch
Angriffstechniken	Verwenden von Programmen zur Netzwerküberwachung
Gegenmaßnahmen	Verwenden von SSL, um einen verschlüsselten Kanal bereitzustellen

Was folgt nach der Bedrohungsanalyse?

Das Ergebnis der Bedrohungsanalyse enthält die Dokumentation der Sicherheitsaspekte der Anwendungsarchitektur und eine Liste der bewerteten Bedrohungen. Die Bedrohungsanalyse ist beim Aufstellen der Mitglieder des Entwicklungsteams und bei der Identifizierung der stärksten Bedrohungen hilfreich.

Wichtig: Das Erstellen einer Bedrohungsanalyse ist ein sich wiederholender Prozess. Die Bedrohungsanalyse ist ein Dokument, das weiter entwickelt werden muss und mit dem verschiedene Teammitglieder arbeiten.

Die Bedrohungsanalyse kann von den folgenden Personengruppen verwendet werden:

Designer können es verwenden, um sichere Gestaltungsmöglichkeiten für Technologien und Funktionalitäten auszuwählen.
Entwickler, die den Code schreiben, können es verwenden, um Risiken zu entschärfen.
Tester können Testfälle schreiben, um zu testen, ob die Anwendung für die durch die Analyse identifizierten Bedrohungen anfällig ist.

Erstellen eines Arbeitselementberichts

Aus der anfänglichen Bedrohungsanalyse kann ein besser gestalteter Arbeitselementbericht erstellt werden, der zusätzliche Attribute beinhalten kann, wie eine Fehler-ID, die verwendet werden kann, um die Bedrohung mit dem bevorzugten Fehlerverfolgungssystem zu verbinden. Die identifizierten Bedrohungen können in ein Fehlerverfolgungssystem eingetragen und dessen Berichtsfunktionen dazu genutzt werden, um den Bericht zu erstellen. Es kann auch eine Statusspalte eingebunden werden, um anzuzeigen, ob der Fehler korrigiert wurde oder nicht. Es sollte sichergestellt werden, dass der Bericht die ursprünglichen Bedrohungsnummern enthält, damit sie in der Bedrohungsanalyse auffindbar sind.

Die Bedrohungen sollten im Bericht nach den Kategorien Netzwerk, Host und Anwendung geordnet werden. Dies erleichtert das Lesen des Berichts für verschiedene Teammitglieder in verschiedenen Rollen. Innerhalb jeder Kategorie sollten die Bedrohungen in absteigender Reihenfolge dargestellt werden, von den riskanten hin zu den weniger riskanten Bedrohungen.

Zusammenfassung

Während das Risiko eines Angriffs entschärft werden kann, kann die tatsächliche Bedrohung nicht entschärft oder eliminiert werden. Bedrohungen existieren immer, ungeachtet der Sicherheitsmaßnahmen, die getroffen werden, und der Gegenmaßnahmen, die angewendet werden. Die Wirklichkeit in der Welt der Sicherheit sieht so aus, dass das Vorhandensein von Bedrohungen eingeräumt und die Risiken bewältigt werden müssen. Eine Bedrohungsanalyse kann bei der Bewältigung von und dem Austausch über Sicherheitsrisiken im Team hilfreich sein.

Behandeln Sie die Erstellung einer Bedrohungsanalyse als einen permanenten Prozess. Eine Bedrohungsanalyse sollte dynamisch änderbar sein, um neuen Arten von Bedrohungen und Angriffen gerecht zu werden, sobald sie entdeckt werden. Sie sollte auch anpassungsfähig gestaltet sein, damit der natürlichen Entwicklung der Anwendung Folge geleistet werden kann, sobald diese erweitert und modifiziert wird und mit den sich ändernden Unternehmensanforderungen in Einklang gebracht wird.

Weitere Links zum Thema

Über die folgenden Quellen finden Sie zusätzliche Informationen:

Informationen über Angriffsmuster finden Sie in "Attack Modeling for Information Security and Survivability" von Andrew P. Moore, Robert J. Ellison und Richard C. Linger unter http://www.cert.org/archive/pdf/01tn001.pdf.
Informationen über die Bewertung von Bedrohungen, Ressourcen und Sicherheitslücken finden Sie in "Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0" auf der Website des Carnegie Mellon Software Engineering Institute unter http://www.sei.cmu.edu/publications/documents/99.reports/99tr017/99tr017figures.html.
Eine Darstellung über die Erstellung einer Bedrohungsanalyse finden Sie in "Architect WebCast: Using Threat Models to Design Secure Solutions" unter https://www.microsoft.com/usa/webcasts/ondemand/1617.asp.
Weitere Informationen über das Erstellen von DFDs finden Sie in Writing Secure Code, Second Edition, von Michael Howard, David C. LeBlanc.

Freigeben über