Seite 2: Transparenz & Schutzmechanismen

Inhaltsverzeichnis

Transparenz der Bemühungen

Investitionen in die Sicherheit der Software sind oft schwer zu rechtfertigen, insbesondere da sie nicht unmittelbar zu einem schnell sichtbaren Ergebnis führen. Im Gegenteil, oft ist die Software erst einmal weniger flexibel, und vielleicht dauert die Entwicklung auch länger. Um einer grundsätzlichen Ablehnung von Sicherheitsmaßnahmen im Entwicklungsprozess entgegenwirken zu können, ist es sinnvoll, die Auswirkung von Sicherheitsmaßnahmen messbar zu machen, indem zum Beispiel Angriffsfläche, Aufwand durch nachträgliches Lösen von Sicherheitsproblemen oder Anzahl gefundener Coding-Schwachstellen bei Blackbox-Tests regelmäßig gemessen werden und so der Effekt von Aktionen zur Verbesserung der Sicherheit von Software transparent wird.

Umfassende Mechanismen zum Schutz

Angriffe auf Software werden nicht selten gut vorbereitet, dafür ist es für den Angreifer oft hilfreich, wenn im Rahmen des Entwicklungsprozesses die Möglichkeit besteht, den Code einzusehen oder sogar zu manipulieren. Folgerichtig ist es in allen vorgenannten Phasen wichtig, dass man die Erkenntnisse und Ergebnisse der Arbeit entsprechend vertraulich hält beziehungsweise vor Eindringlingen – und im Extremfall auch Innentätern – schützt. Dazu gibt es eine Reihe von Techniken, die beim Projektstart beachtet werden sollten – und nicht erst am Ende, denn meist ist dann "das Kind schon in den Brunnen gefallen".

Es gibt eine Reihe gesamtheitlicher Methoden, die diese einzelnen Aspekte zusammenfassen, um den Softwareentwicklern einen möglichst leichten Einstieg in die Materie der sicheren Software zu geben. Diese sind zum Teil technik- beziehungsweise herstellerspezifisch (etwa Microsofts Secure Development Lifecycle, SDL) und zum Teil formalistisch, um möglichst viele Aspekte beweisbar nachzuhalten (etwa Common Criteria). Eine gute, offene Quelle zum Start ist das Open Web Application Security Project (OWASP).

Schlussbemerkung

Letztlich ist es wichtig, dass Softwareentwickler Schulungen in diesen Themen erhalten, damit sie hinsichtlich der Sicherheit die richtigen Entscheidungen treffen können. Davor steht natürlich eine Beschäftigung mit dem Thema Softwarequalität, denn ohne die Prinzipien des allgemeinen Qualitätsmanagements bleiben auch die hier kurz angerissenen Sicherheitsmaßnahmen oft nur einmalige Aktionen und werden nicht verstetigt.

Sachar Paulus
ist Professor für Unternehmenssicherheit und Risikomanagement an der Fachhochschule Brandenburg, Inhaber der Unternehmensberatung "paulus.consult" und Senior-Analyst für Governance, Risk & Compliance bei Kuppinger Cole.

Literatur & Onlinequellen

1. Sachar Paulus; Basiswissen Sichere Software. Das Buch zur CPSSE-Zertifizierung. dpunkt Verlag (voraussichtlich Juni 2011 ). Schulungsbuch zum Thema, mit Fokus auf Prozesskompetenzen
2. John Viega, Gary McGraw; Building Secure Software; How to Avoid Security Problems the Right Way; Addison-Wesley 2002
3. Michael Howard, David LeBlanc; Writing Secure Code; Microsoft Press Books, 2. Aufl. 2004 (der Klassiker für Microsoft-Freunder und -Hasser)
4. Michael Howard; Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users; MSDN Magazine, November 2004 (speziell zu "Attack Surface Minimization")
5. Tobias Klein; Aus dem Tagebuch eines Bughunters. Wie man Softwareschwachstellen aufspürt und behebt; dpunkt Verlag 2010 (speziell zu Security-Tests)
6. www.coresecuritypatterns.org (speziell für Security Patterns)
7. OWASP (mit Abstand das derzeit beste und aktuellste Sicherheitsportal

(ane)