Sicherheit ist Risikomanagement

Veröffentlicht: 10. Aug 2005

Von Michael Willers

Qualität und Microsoft – geht das? Angesichts der scheinbar immer noch andauernden Flut von Patches ist man geneigt, diese Frage eindeutig zu Ungunsten von Microsoft zu beantworten. Erst recht wenn man an die Meldung zurückdenkt, dass Anfang 2004 die Entwicklung von Windows für rund einen Monat angehalten wurde. Blickt man jedoch hinter die Kulissen sind Patches aber sogar gewollt und das Resultat eines langfristigen Prozesses in Sachen Sicherheit und Qualitätsverbesserung bei Microsoft.Dieser Beitrag beschreibt Hintergründe.

Auf dieser Seite

 Veränderte Entwicklung
 Ein Prozess muss her – STRIDE und DREAD!
 Fazit
 Weitere Ressourcen

Veränderte Entwicklung

Betrachten wir zunächst die Frage, warum Angriffe heutzutage eine solche Bedrohung darstellen. Die Welt hat sich verändert - auch in punkto Sicherheit. Während des Zeitalters ohne Internet lief alles auf dem geschlossenen lokalen System ab. Heutzutage holen sich Programme Updates dynamisch aus dem Web oder werden komplett via Internet installiert - die Vision vom „Internet aus der Steckdose“ ist Realität. Webanwendungen und Web Services erhöhen das Sicherheitsrisiko weiter. Damit verändern sich die Rahmenbedingungen völlig:

• Sicherheitsbedrohungen sind ständig präsent, da man „always online“ ist. Dadurch bedingt sind völlig neue Angriffsszenarien entstanden, deren Auswirkungen beim Design von Anwendungen (noch) nicht in Betracht gezogen wurden. Das prominenteste Beispiel ist der sogenannte Buffer Overrun, mit dem sich fremder Code in ein System einschmuggeln und ausführen lässt. In geschlossenen Umgebungen ein beherrschbares Problem, aber in einer offenen Umgebung nicht mehr zu kontrollieren.

• Das Internet ist ein perfektes Medium für die Verbreitung von Angriffswerkzeugen. Nur der allererste Angreifer muss fachlich versiert sein; alle übrigen können seine Software nutzen z.B. per Download nutzen. Sobald der erste Angreifer seine Werkzeuge zum Download freigibt, sind diese praktisch nicht mehr zu kontrollieren. Anders gesagt: Computerbasierte Angriffe bedeuten heutzutage nichts anderes, als das die Verursacher keine technischen Kenntnisse mehr besitzen müssen, um erfolgreich zu sein. Denken Sie z.B. an die rasante Ausbreitung von schädlichen Scripts.

• Virenscanner helfen auf absehbare Zeit nicht mehr weiter, da die Abstände zwischen dem Auftreten einer Sicherheitslücke und einem Angriff, der diese Lücke ausnutzt immer kürzer werden.

• Die Vernetzung hat dazu geführt, dass Systeme immer komplexer werden. Ein Beispiel für diesen rasanten Anstieg liefert Windows. Während Windows 95 aus noch knapp 15 Millionen Codezeile bestand, waren es bei den Serversystem Windows 2000 bzw. Red Hat 7.1. bereits geschätzte 40 bzw. 30 Millionen). Das bedeutet: Systeme definieren für Ihre Zusammenarbeit klar definierte Schnittstellen. Ein einzelner Mensch ist nicht mehr in der Lage sämtliche Interna zu kennen. Die Kenntnis auf welche Weise Systeme miteinander interagieren wird damit zum entscheidenden Faktor.

• Man kann sich nur gegen Bedrohungen schützen, die man bereits kennt. Da es aber unmöglich ist 100% sichere und fehlerfreie Software zu entwickeln bleibt nur eine Möglichkeit: Sie müssen die Anwendungsfälle (Use Cases) kennen! Nur dann können systematisch vorgehen und Ihre Anwendung im Hinblick auf Schwachstellen bewerten.

Zusammenfassend kann man sagen, dass die Prozesssicht enorm an Bedeutung gewinnt. Nur wenn man die Use-Cases kennt, kann man Schwachstellen analysieren. Nur mit dem Erfassen von Use-Cases ist es nicht getan. Dazu ein Beispiel: Das Abhören der Kommunikation zweier Partner lässt sich durch Verschlüsselung verhindern. Das Problem dabei: Ein Angreifer überwacht die Kommunikation nicht passiv!

Er bricht in eine Firewall ein, er manipuliert ein digitales Netzwerk, er stiehlt mit fremden Zugangsdaten Geld von irgendwelchen Konten. Aber es geht dabei eben nicht um „alles oder nichts“. Wenn man eine Kommunikation schützen will, funktioniert es aber so: Entweder ich kann mithören oder nicht. Ein Angreifer hingegen bricht vielleicht in ein Netzwerk ein und stiehlt ein wenig Geld aber eben nicht alles. Oder er bricht in ein Netzwerk ein und sieht sich dort vielleicht fünf Minuten um bevor er entdeckt wird.

Kurz: Angriffe funktionieren fast nie nach dem „Alles oder nichts“-Prinzip. Deswegen reicht es eben nicht, allein nur Use-Cases und Maßnahmen zu kennen. Oder um auf das Beispiel zurück zu kommen: Die interessante Frage ist: Wenn es einem Angreifer gelungen ist in, ein Netzwerk einzudringen – Wie lang darf er unentdeckt bleiben bis er Schaden anrichten kann? Fünf Minuten oder mehr? Ist es vielleicht sogar unerheblich weil er keinen Zugang zu wichtigen Daten hat?

Kurz: Sicherheit bedeutet Risikomanagement! Nur wer die Risiken eines Angriffs für seinen speziellen Anwendungsfall kennt, hat die Chance zur erfolgreichen Abwehr.

Ein Prozess muss her – STRIDE und DREAD!

Microsoft ist zu dieser Erkenntnis im Verlauf der Entwicklung des Betriebssystems Windows 2000 gelangt. Im Verlauf dieses Projektes hat man festgestellt, dass im Hinblick auf Internetszenarien ernste Sicherheitslücken vorhanden sind. Als Hauptproblem hat sich dabei herausgestellt, dass das Bewusstsein für Sicherheit erst noch geschaffen werden musste: Auch hier ein Beispiel: Das World Trade Center wurde mit höchsten Sicherheitsvorkehrungen gebaut. Es hatte allerdings niemand in Betracht gezogen, dass es mit vollgetankten Passagierflugzeugen angegriffen würde. Zu abwegig erschien dieses Bedrohungsszenario.

Und aus genau diesem Grund würde die Entwicklung von Windows für einen Monat gestoppt. Um Entwickler zu schulen, um das Bewusstsein für Sicherheit zu schaffen und die Aufmerksamkeit verstärkt auf Sicherheitsprobleme zu lenken.

Damit steigt zwar langfristig die Qualität des produzierten Codes, sie geht aber zunächst einher mit vermehrten Fehlerbehebungen. Die Folge: Die eingangs erwähnte „Patchwelle“ als Folge der neuen Denkweise in der Praxis.

Weit weniger öffentlichkeitswirksam ist begleitend zu dieser Vorgehensweise ein Prozess für die Identifikation von Sicherheitslücken und deren Schadensrisiko implementiert worden, der für jedes Produktteam innerhalb von Microsoft bindend ist. Er ermöglicht es, für alle Beteiligten, Sicherheitslücken nicht nur zu dokumentieren sondern auch darzustellen ob und wie hoch ihr Gefahrdungspotential ist und welche Gegenmaßnahmen zu ergreifen sind. Die Methoden, die dabei zum Einsatz kommen, hören auf die Bezeichnungen STRIDE und DREAD. Dabei steht STRIDE als Abkürzung für folgende Begriffe:

• Spoofing Identity

• Tampering with Data

• Repudiation

• Information Disclosure

• Denial of Service

• Elevation of Privilege

Zum besseren Verständnis sollen diese Begriffe nun ein wenig näher erläutert werden.

Spoofing Identity
Ein Angreifer täuscht eine falsche Identität vor. Davon existieren zwei Varianten:

• Vortäuschen einer falschen Client Identität

  • Zugriff auf einen Server als legitimer Benutzer

  • Zugriff auf sensitive Daten

• Vortäuschen einer falschen Server Identität

  • Einem Client einen legitimen Server vortäuschen

  • Vertrauliche Daten von einem Client erfragen

Gegenmaßnahmen: Starke Authentifizierung, z.B. mit Hilfe von Kryptografie und Mehr-Faktoren Authentifizierung

Tampering with Data
Ein Angreifer manipuliert Daten. Auch hier gibt es im Wesentlichen zwei Ausprägungen:

• Manipulieren von persistenten Daten

  • Password-Datenbanken

  • Modifizieren von Preisen in einem Online-Shop

  • Modifizieren von Audit-Logs, um Spuren zu verwischen

• Manipulieren von Netzwerk-Paketen

Gegenmaßnahmen: Hash Codes, Digitale Signaturen, Verschlüsselung, Einsatz entsprechender Netzwerk-Protokolle

Repudiation
Ein Angreifer führt eine Aktion durch, und das Opfer kann es ihm nicht beweisen. Ein Angreifer könnte behaupten:

• Eine Datei nicht gelöscht zu haben

• Eine Bestellung nicht getätigt zu haben

• Ware nicht entgegengenommen zu haben

Gegenmaßnahmen: Audit Logs, Empfangsbestätigungen, digitale Signaturen, Zeitstempel

Information Disclosure
Ein Angreifer sieht Daten, die er nicht sehen soll. Dazu zählen:

• Lokale Dateien

• Daten, die zwischen Rechnern übertragen werden

• Unautorisierte Datenbank-Zugriffe

• Informationen über die Infrastruktur

• Sogar Fehlermeldungen sind vertrauliche Informationen

Gegenmaßnahmen: starke Authentifizierung, Zugriffs-Kontrollen, Verschlüsselung, sensibler Umgang mit Informationen

Denial of Service (DoS)
Ein Angreifer stört die Verfügbarkeit einer Anwendung. Diese kann beispielsweise geschehen durch:

• Distributed Denial of Service Attacks (DDoS)

• Ausnutzen von Race conditions

Generelles Ziel ist das Aufbrauchen von Bandbreite, Speicher und CPU Zyklen

Gegenmaßnahmen: Verfügbarkeit und Zuverlässigkeit erhöhen

Elevation of Privileges
Ein Angreifer findet einen Weg seine Berechtigungen zu erhöhen

• Administrative Rechte sind das End-Ziel

• “Buffer Overflow” ist das klassische Beispiel

• SQL Injection ist insbesondere bei Webanwendungen ein bewährtes Mittel

Gegenmaßnahmen: Robuster Code, Least Privilege, Eingabevalidierung

Nach diesen Kriterien wird jede Anwendung auf Sicherheitslücken hin untersucht und die dazugehörigen Maßnahmen dokumentiert. Bild 1 illustriert diesen Zusammenhang am Beispiel einer allgemeinen Webanwendung (die einzelnen Kriterien sind dabei mit Buchstaben abgekürzt).

Bild 1: Untersuchen einer Anwendung anhand von STRIDE

Im zweiten Schritt erfolgt dann die Bewertung und Priorisierung der möglichen Bedrohungen anhand von DREAD. Konkret bedeutet dies, dass bei der Risikobewertung folgende Fragestellungen berücksichtigt werden:

• 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?

Die Bewertung sollte dabei einem einfachen System folgen. So reicht ein einfaches Schema bei der Bewertung wie hoch (1), mittel (2) und gering (3) in der Regel völlig aus. 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. Die nachfolgende Tabelle 1 zeigt zwei Beispiele.

Tabelle 1: DREAD-Bewertung

Die Anwendung dieser Verfahren führt zu einem klaren und für alle Beteiligen nachvollziehbaren Prozess für die Identifizierung und Bewertung von Sicherheitslücken hinsichtlich des Risikos im laufenden Projekt und ermöglicht so eine systematische Vorgehensweise für die Reaktion auf Angriffe bereits im Vorfeld. Oder anders gesagt: Sicherheit muss bereits in der Designphase eines Softwaresystems integraler Bestandteil sein. Dazu gehört, dass:

• Assets und Sicherheits-Ziele formuliert werden

• Eine Risiko/Bedrohungs-Analyse durchgeführt wird

• Bedrohungen priorisiert werden

• Gegenmaßnahmen implementiert werden

• Überwachungs- und Reaktions-Maßnahmen designed, implementiert und getestet werden.

Dabei handelt es sich aber keineswegs um eine statische Angelegenheit. Bei jeder Änderung an der Software müssen diese Strategien neu überdacht werden.

Microsoft beschreitet diesen Weg konsequent seit der Entwicklung des Betriebsystems Windows 2000. Die Umsetzung dieses Prozesses hat zunächst mal dazu geführt, dass vermehrt Sicherheitslücken entdeckt und behoben worden sind. Die Folge davon war zunächst ein erhöhtes Aufkommen von Patches. Betrachtet man jedoch heutzutage das Serversystem Windows 2003 sind Meldungen und Patches deutlich seltener geworden.

Fazit

Sicherheit ist kein Feature, welches einem Softwareprodukt nachtäglich hinzugefügt werden kann. Bedingt durch die heutzutage enge Vernetzung bieten Computer ein leichtes Angriffsziel und die Geschwindigkeit in der Verbreitung von Schädlingen hat enorm zugenommen. Das hat nicht zuletzt Melissa leider eindrucksvoll gezeigt. Andererseits ist es nahezu unmöglich 100% sichere Software zu schreiben. Die Kunst besteht darin, Angriffszenarien zu kennen und ihr Bedrohungspotential im Hinblick auf die eigenen Anwendungen zu bewerten. Nur dann können im Falle eines Angriffes wirkungsvolle Maßnahmen ergriffen werden. Kurz: Sicherheit ist ein Prozess!

Oder anders gesagt: Es gewinnt nicht derjenige, der Bedrohungen am Besten verhindern kann, sondern derjenige der am Besten mit den Risiken umgeht.

Weitere Ressourcen

[1] Entwicklungszyklus für sichere Software
Dieser Beitrag erläutert den Trustworthy Computing Security Development Lifecycle (SDL – Entwicklungszyklus für vertrauenswürdigen Computereinsatz). Diesen Prozess hat Microsoft für die Entwicklung von Software übernommen, die böswilligen Angriffen standhalten muss. Er erweitert Phasen der Softwareentwicklung bei Microsoft um mehrere auf Sicherheit abzielende Aktivitäten und Projektergebnisse. Zu diesen Aktivitäten und Projektergebnissen zählen die Entwicklung von Bedrohungsmodellen beim Softwareentwurf, die Verwendung von Tools zur statischen Codeanalyse bei der Implementierung sowie das Durchführen von Codeüberprüfungen und Sicherheitstests bei einer gezielten Suche nach Sicherheitsmängeln („Security Push“ – Sicherheitsinitiative).

[2] Bedrohungsanalysen am Beispiel von Webanwendungen
Mithilfe einer Bedrohungsanalyse ist eine systematische Identifikation und Abschätzung von Bedrohungen möglich, denen ein System voraussichtlich ausgesetzt sein wird. 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.