Analyse der Anwendung

Bei existierenden Anwendungen bestehen üblicherweise erhebliche Komplexitäten, die im Lauf der Zeit erfahrungsgemäß oft nicht unbedingt an struktureller Qualität dazugewonnen haben. Deshalb folgt nun die Zerlegung der Anwendung in ihre einzelnen Bestandteile, die für die Analyse relevant sind.

Ziel dieser ersten Phase ist ein Verständnis der Anwendung zu erhalten, insbesondere wie sie mit externen Komponenten interagiert. Dieses Ziel wird erreicht, indem diese Informationen durch Analyse der Spezifikationen sowie des Quellcodes des Systems in Erfahrung gebracht und dokumentiert werden. Um sicherzustellen, dass die richtigen Informationen extrahiert werden, gibt es im Folgenden Tabellen-Vorlagen, die ausgefüllt werden können.

Ein Beispiel der Analyse soll im Folgenden anhand eines einfachen IT-Systems gezeigt werden. Bei dem IT-System handelt es sich um ein Bibliotheken-Verwaltungsprogramm.

Systeminformationen

Das erste Element im Bedrohungsmodell ist die Information zum System. Hilfreich ist es in dieser Phase, eine standardisierte, tabellarische Übersicht der Anwendung zu haben. Diese sollte folgenden Umfang haben:

  1. Application Name – der Name der Anwendung
  2. Application Version – die genaue Version der Anwendung
  3. Description – eine high level Beschreibung der Anwendung
  4. Document Owner – der Besitzer des Threat Model Dokuments
  5. Participant – beteiligte Personen die am Prozess zur Erstellung des Dokuments beteiligt sind
  6. Reviewer – alle Reviewer des Threat Model Dokuments

Thread Model Information
Application Name: Bibliotheken-Fix (BiFi)
Application Version: 1.0.0.12543
Description: BiFi ist die erste Implementierung einer Webseite, die es Personen verschiedene Online-Services anbietet. Bei der ersten Version sind die Funktionen limitiert. Es gibt 3 Benutzergruppen der Anwendung:

  1. Studenten
  2. Mitarbeiter
  3. Bibiothekare

Mitarbeiter und Studenten können sich anmelden und nach Büchern suchen. Mitarbeiter können Bücher anforndern.

Bibiothekare können sich anmelden, Bücher hinzufügen, Benutzer hinzufügen und Bücher suchen.
Document Owner: Bernhard Hirschmann
Participants: Max Mustermann
Reviewer: Sabine Musterfrau

Externe Abhängigkeiten

Abhängigkeiten zu externen Komponenten sollten aufgelistet und beschrieben werden, um ein umfassendes Bild der Anwendung und der von ihr verwendeten Ressourcen zu bekommen. Die Topologie der Betriebsumgebung ist dabei von besonderem Interesse. Wenn beispielsweise erwartet wird, dass die Anwendung auf gesicherten und gestählten ApplicationServern läuft und verschiedene Firewalls verwendet werden, dann sollte das in den External Dependencies dokumentiert werden.

Folgendes sollte erfasst werden:

  1. ID– eine eindeutige ID die dieser externen Abhängigkeit fest zugeordnet wird
  2. Description– eine textuelle Beschreibung der externen Abhängigkeit

Beispiel:

External Dependencies
ID Description
1 Die Webanwendung läuft auf einem Windows Server 2012 mit IBM WebSphere ApplicationServer V-8.1.

Der Server wird im Rechenzentrum des Kunden betrieben, das auf den hohen Sicherheitsstandard der Firma abgesichert ist. Neueste Updates und Security-Patches werden immer zeitnah aufgespielt.
2 Als vorgeschalteter Webserver wird ein IBM IHS V-8.1 eingesetzt.

Der Server wird im Rechenzentrum des Kunden betrieben, das auf den hohen Sicherheitsstandard der Firma abgesichert ist. Neueste Updates und Security-Patches werden immer zeitnah aufgespielt.
3 Der Datenbankserver ist eine Oracle DB 11g auf einem Linux OS.

Der Server wird im Rechenzentrum des Kunden betrieben, das auf den hohen Sicherheitsstandard der Firma abgesichert ist. Neueste Updates und Security-Patches werden immer zeitnah aufgespielt.
4 Die Verbindung zwischen WebServer und ApplicationServer wird über ein VPN gesichert.
5 Die Verbindung zwischen ApplicationServer und DB-Server wird über ein VPN gesichert.
6 Der Webserver befindet sich hinter einer Firewall und nur über TLS erreichbar.
7 Der ApplicationServer ist nur vom Webserver aus über TLS erreichbar. Vom Internet aus ist er nicht erreichbar.

Entry Points

Mit den Entry Points sind exponierte Schnittstellen und Eingabeelemente gemeint, über die ein Angreifer mit der Anwendung interagieren kann, oder sie mit Daten versorgen kann. Für einen Angreifer müssen Entry Points existieren, damit die Applikation angegriffen werden kann.

Eine Anwendung hat üblicherweise viele Entry Points, auch beispielsweise auf einer einzigen Webseite mehrere, wenn es mehrere Eingabeelemente gibt. Man spricht dann von „Layered Entry Points“ – mehrschichtig.

Folgende Elemente sollten bei Entry Points dokumentiert werden:

  1. ID– eine eindeutige ID für den Entry Point, der später von gefundenen Schwachpunkten referenziert werden kann. Als Notation sollten für Layered Entry Points eine Form wie <major>.<minor> verwendet werden.
  2. Name– ein beschreibender Name des Entry Points
  3. Description– eine textuelle Beschreibung, die die Interaktion und die Verarbeitung beschreibt
  4. Trust Levels– das Level der Berechtigung, das notwendig ist, um den Entry Point benutzen zu können. Wenn der Entry Point mit verschiedenen Berechtigungen verfügbar ist und ggf. sich die Funktionalität unterscheidet, sollte das auch mit dokumentiert werden

Beispiel:

Entry Points
ID Name Description Trust Levels
1 HTTPS Port Die Web-Anwendung ist nur über TLS erreichbar. Alle Seiten innerhalb der Website sind mehrschichtig (layered) auf diesem Entry Point. (1) Anonymer Web-Benutzer

(2) Benutzer mit gültigen Credentials

(3) Benutzer mit ungültigen Credentials

(4) Bibliothekar
2 Landing Page Die Einstiegsseite der Anwendung, für alle Benutzer zugreifbar (1) Anonymer Web-Benutzer

(2) Benutzer mit gültigen Credentials

(3) Benutzer mit ungültigen Credentials

(4) Bibliothekar
3 Login Page Benutzer müssen sich hier einloggen, um auf gesicherte Seiten zu kommen, um dort die Business Cases der Anwendung zu verwenden (1) Anonymer Web-Benutzer

(2) Benutzer mit gültigen Credentials

(3) Benutzer mit ungültigen Credentials

(4) Bibliothekar
4 Login Function Die Login Function nimmt die Benutzereingaben entgegen und prüft die Credentials mit den in der DB bekannten (2) Benutzer mit gültigen Credentials

(3) Benutzer mit ungültigen Credentials

(4) Bibliothekar
5 Such-Startseite Seite um eine Suchanfrage einzugeben (2) Benutzer mit gültigen Credentials

(4) Bibliothekar

Assets – Vermögenswerte

Die Anwendung bzw. das System hat verschiedene Daten, die für einen Angreifer von Interesse sind. Diese Informationen werden Assets genannt – Vermögenswerte. Assets sind essentielle Bedrohungsziele – sie sind der Grund warum eine überhaupt Bedrohung existiert. Als Beispiele kann man sowohl physisch existierende Daten nennen, wie z.B. Kunden-Adressen oder Kreditkartendaten. Oder auch abstrakte Vermögenswerte, wie z.B. die Reputation einer Firma.

Assets werden beim Threat-Modeling folgendermaßen dokumentiert:

  1. ID– eine eindeutige ID für das Asset, das später von gefundenen Bedrohungen oder Schwachpunkten referenziert werden kann.
  2. Name– ein beschreibender Name des Asset
  3. Description– eine textuelle Beschreibung, worum es sich bei dem Asset handelt und warum es schützenswert ist
  4. Trust Levels – das Level das für den Zugriff auf das Asset erforderlich ist. Jeweils für verschiedene Arten des Zugriffs (lesend, schreibend, …)

Assets
ID Name Description Trust Levels
1 Benutzer und Administratoren
1.1 Benutzer Login-Informationen Die Login Credentials, mit denen sich ein normaler Benutzer authentifiziert (2) Benutzer mit gültigen Credentials

(4) Bibliothekar

(5) DB-Admin

(7) WebServer User-Prozess

(8) DB-Benutzer lesend

(9) DB-Benutzer lesend und schreibend
1.2 Bibliothekar Login-Informationen Die Login Credentials, mit denen sich ein Benutzer mit Bibliothekar-Rolle authentifiziert (4) Bibliothekar

(5) DB-Admin

(7) WebServer User-Prozess

(8) DB-Benutzer lesend

(9) DB-Benutzer lesend und schreibend
1.3 Persönliche Daten Die Webanwendung speichert persönliche Daten der Benutzer und Bibliothekar, sowie weiteren Anwendern (4) Bibliothekar

(5) DB-Admin

(6) Webseiten Administrator

(7) WebServer User-Prozess

(8) DB-Benutzer lesend

(9) DB-Benutzer lesend und schreibend
2 System
2.1 Verfügbarkeit der Webanwendung Die Webanwendung soll 24 Stunden täglich verfügbar sein für alle Benutzer (5) DB-Admin

(6) Webseiten Administrator
2.2 Fähigkeit Code auszuführen als Webserver-Benutzer Auf dem Webserver muss Source Code als Webserver-Benutzer ausführbar sein – z.B. PHP-Code (6) Webseiten Administrator

(7) WebServer User-Prozess
2.3 Fähigkeit Anwendungen auf dem ApplicationServer auszuführen Auf dem ApplicationServer muss eine Anwendung ausführbar sein und ggf. entsprechende Rechte für die Infrastruktur haben – z.B. WAR- oder EAR-Dateien (10) ApplicationServer User-Prozess
2.4 Fähigkeit lesende SQL-Abfragen zu machen als ein DB-Benutzer Auf der DB müssen lesende SQL-Abfragen möglich sein (5) DB-Admin

(8) DB-Benutzer lesend
2.5 Fähigkeit lesende und schreibende SQL-Anweisungen auszuführen als DB-Benutzer Auf der DB müssen lesende und schreibende SQL-Anweisungen möglich sein (5) DB-Admin

(9) DB-Benutzer lesend und schreibend
3 Website
3.1 Login Session Die Login-Session eines Benutzers, durch die sämtliche Aktionen autorisiert werden (2) Benutzer mit gültigen Credentials

(4) Bibliothekar
3.2 Zugriff auf den DB-Server Zugriff auf den Datenbankserver erlaubt die DB zu administrieren und gibt vollen Zugriff auf alle Daten und DB-Benutzer (5) DB-Admin
3.3 Fähigkeit Benutzer zu erstellen Die Fähigkeit Benutzer anzulegen würde erlauben, beliebig viele neue Benutzer mit verschiedenen Rollen und Rechten anzulegen. (4) Bibliothekar

(6) Webseiten Administrator
3.4 Zugriff auf Audit-Daten Audit-Daten zeigen auditfähige Ereignisse die auf der Webapplikation eingetroffen sind und geloggt wurden. Unter anderem werden hier ggf. Angriffsversuche geloggt. (6) Webseiten Administrator

Trust Levels

Trust Levels repräsentieren Zugriffsrechte, die Benutzern üblicherweise durch Berechtigungs-Rollen zugewiesen werden. Sie erlauben Benutzer bestimmte Aktionen in der Webapplikation. Trust Levels werden querverbunden mir Entry Points und Assets. Dies erlaubt die Definition der Zugriffsrechte oder Privilegien für jeden Entry Point und diejenigen, die erforderlich sind mit den Assets zu interagieren.

Trust Levels werden im Threat Model folgendermaßen dokumentiert:

  1. ID– eine eindeutige ID für jedes Trust Level, um sie mit den Entry Points und Assets verknüpfen zu können.
  2. Name– ein beschreibender Name des Trust Levels, der es erlaubt, externe Entitäten zu identifizieren die damit berechtigt werden können.
  3. Description– eine textuelle Beschreibung worum es sich bei dem Trust Level handelt

Trust Levels
ID Name Description
1 Anonymer Web-Benutzer Ein Benutzer der Webapplikation der sich (noch) nicht authentifiziert hat
2 Benutzer mit gültigen Credentials Ein Benutzer der Webapplikation der sich erfolgreich authentifiziert hat
3 Benutzer mit ungültigen Credentials Ein Benutzer der Webapplikation der sich nicht erfolgreich authentifiziert hat
4 Bibliothekar Ein Benutzer der Webapplikation mit Bibliothekaren-Rolle
5 DB-Server-Admin Der DB-Server Administrator hat Lese- und Schreibrechte auf der DB sowie weitergehende administrative Rechte
6 Webseiten Administrator Der Webseiten Administrator kann die Webapplikation konfigurieren
7 WebServer User-Prozess Dies ist der Prozess/Benutzer mit dem der WebServer Code ausführt
8 DB-Benutzer lesend Der DB Benutzer-Account zum Ausführen von lesenden DB-Abfragen
9 DB-Benutzer lesend und schreibend Der DB Benutzer-Account zum Ausführen von lesenden und schreibenden DB-Abfragen
10 ApplicationServer User-Prozess Der Benutzer-Account des ApplicationServers

Weiter zum 3. Teil