Sicherheit in sieben Schritten

Ein SDL für PHP-Anwendungen
Kommentare

Im PHP Magazin 1.2012 sahen Sie am Beispiel eines Gästebuchs, wie eine Anwendung so entwickelt wird, dass erst gar keine Schwachstellen entstehen. Aus diesem praktischen Beispiel leiten wir nun einige formale Regeln ab.

PHP Magazin

Der Artikel „Sicherheit in sieben Schritten“ von Carsten Eilers ist erstmalig erschienen im PHP Magazin 2.2012.

Von Microsofts Security Development Lifecycle [1] haben die meisten von Ihnen sicher zumindest schon einmal gehört. Wer sich näher damit befassen möchte, wird zunächst von seinem Umfang abgeschreckt: sieben Phasen, von denen fünf jeweils drei Schritte umfassen, und das alles „nur“, damit ein Programm sicherer wird? Muss das denn sein? Nun, erst einmal enthält der SDL viele Schritte, die im Rahmen einer „unsicheren“ Entwicklung sowieso gemacht werden. Es kommen lediglich jeweils ein paar zusätzliche Probleme hinzu, die berücksichtigt werden müssen. Und dann ist der SDL sehr erfolgreich: Windows Vista war das erste vollständig nach dem SDL entwickelte Betriebssystem von Microsoft, und im ersten Jahr nach seiner Veröffentlichung wurden 45 Prozent weniger Schwachstellen gefunden als in Windows XPs erstem „Lebensjahr“ [2], [3]. Der Aufwand lohnt sich also.

Microsofts SDL im Schnelldurchlauf

Werfen wir einen kleinen Blick auf den SDL. Er wurde zwar mit Blick auf Desktopanwendungen und Betriebssysteme entworfen, aber es spricht ja nichts dagegen, ihn an die eigenen Bedürfnisse und Webanwendungen anzupassen. Grundlage des SDL sind vier Best Practices:

  1. Secure by Design (Sicherheit als Entwurfsziel): Schon beim Entwurf des Programms wird seine Sicherheit berücksichtigt, z. B. indem mögliche Angriffe ermittelt und möglichst verhindert, zumindest aber erschwert werden.
  2. Secure by Default (Sichere Default-Konfiguration): Egal, wie sicher ein Programm auch entworfen und implementiert wird, es wird immer Schwachstellen enthalten. Daher müssen die Standardeinstellungen so gewählt werden, dass ein Angriff möglichst erschwert wird und seine Folgen gemindert werden.
  3. Secure by Deployment (Sichere Default-Installation): Das fertige Programm wird so ausgeliefert, dass es möglichst sicher installiert und konfiguriert wird.
  4. Communications (Reden Sie über Schwachstellen!): Es bleibt nicht aus, dass im fertigen Programm Schwachstellen entdeckt werden. Wenn das passiert, müssen die Benutzer darüber informiert und Workarounds und Patches entwickelt und verteilt werden.

Der SDL ist keine Garantie für ein schwachstellenfreies Programm, wie Sie schon am oft verwendeten Wort „möglichst“ und am Beispiel von Windows Vista sehen. Das soll er auch gar nicht sein, er soll nur dafür sorgen, dass das Programm bei der Auslieferung keine bekannten und damit vermeidbaren Schwachstellen oder -punkte enthält. Im Fall von Webanwendungen wäre zum Beispiel XSS so eine Schwachstelle: Jeder sollte sie kennen. Sie lässt sich einfach verhindern. Trotzdem tritt sie immer wieder auf. Im Folgenden wollen wir sehen, welche der im Kasten „Microsofts DSL“ genannten Punkte sich für Webanwendungen verwenden lassen. Los geht es mit der Voraussetzung sicherer Entwicklung: Sie müssen wissen, welche Angriffe es überhaupt gibt. Denn nur Angriffe, die Sie kennen, können Sie abwehren.

Microsofts SDL

Microsoft hat den SDL seit seiner ersten Veröffentlichung ständig weiterentwickelt. Aktuell ist ein „vereinfachter“ SDL [4], der aus sieben Phasen besteht:

  1. Training: Alle Mitarbeiter mit technischen Aufgaben wie Entwickler, Tester und Programmmanager müssen bei Microsoft mindestens einmal im Jahr einen Kurs besuchen, in dem sie über sichere Entwicklung informiert werden.
  2. Requirements: Alle Sicherheits- und Datenschutzanforderungen an das Programm werden schon vor seinem Entwurf spezifiziert, sodass sie schon beim Entwurf berücksichtigt werden können.
  3. Design: In der Entwurfsphase wird zusätzlich zum normalen Entwurf die Sicherheitsarchitektur des Programms definiert (und dokumentiert).
  4. Implementation: Während der Implementierung wird darauf geachtet, dass die entworfene Sicherheitsarchitektur korrekt umgesetzt wird.
  5. Verification: Nach der Implementierung muss sie überprüft werden: Werden alle aufgestellten Sicherheits- und Datenschutzanforderungen erfüllt?
  6. Release: Ist alles in Ordnung, kann das Programm veröffentlicht werden. Zuvor muss aber festgelegt werden, was passiert, wenn nach der Veröffentlichung eine Schwachstelle gefunden wird. Nach einer letzten Überprüfung des Programms kann es dann veröffentlicht werden.
  7. Response: Werden im veröffentlichten Programm Schwachstellen bekannt, muss angemessen darauf reagiert werden.

Wenn Sie sich für Microsofts SDL interessieren, finden Sie weiterführende Informationen zum Beispiel im Rahmen der Serie „Wie schreibe ich sicheren Code“ im Microsoft Security Developer Center unter [5], [6] und [7].


Themen der kommenden Seiten:

  • Schritt 1: Angriffe und Schwachstellen kennen
  • Schritt 2: Anforderungen festlegen
  • Schritt 3: Ein Bedrohungsmodell erstellen
  • STRIDE
  • Minimierung der Bedrohungen
  • Vereinfachung der Bedrohungsmodellierung
  • Schritt 4: Implementierung
  • Schritt 5: Sichere Default-Installation und -Konfiguration
  • Schritt 6: Schwachstellentests
  • Schritt 7: „Kommunikation“
  • Sieben Schritte zur sicheren Webanwendung
  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -