Macht ISO 27001 Software wirklich sicher?

Norm räumt sehr viel Freiraum bei der Auswahl von Kontrollen ein

(21.06.11) - Der Standard ISO 27001 lässt sich durchaus bei der Entwicklung von Software nutzen. Die Frage ist jedoch, welche Vorteile das mit sich bringt, denn diese Vorgehensweise ermöglicht lediglich eine Momentaufnahme für Softwaresicherheit. Erst zusammen mit einer am Softwarelebenszyklus orientierten Entwicklungsmethode, lässt sich die Sicherheit nachhaltig verbessern.

Von: Juan Ceballos, Product Line Manager bei Alcatel-Lucent Deutschland

Seit einigen Jahren investieren vor allem im asiatischen Raum viele Unternehmen in Standards. Dazu gehört auch die Norm ISO/IEC 27001 für Informationssicherheits-Managementsysteme (ISMS). Dabei handelt es sich nicht nur um IT-Dienstleister, sondern auch um Softwareentwick-lungshäuser. Durch eine international anerkannte Zertifizierung wie ISO/IEC 27001, soll sowohl die Sicherheit eines Produktes nachgewiesen, als auch die eigene Position im Markt verbessert werden. Bei dieser Vorgehensweise gibt es vorab zwei wesentliche Fragen, die geklärt werden müssen:

1. Ist eine ISO 27001 Zertifizierung für kommerzielle Produkte genauso sinnvoll wie für interne IT-Systeme?

2. Wie sicher sind ISO 27001-zertifizierte Produkte wirklich?

Was ist ISO 27000 und was spricht dafür?

Zu ISO 27000 gehören ISO 27001 und ISO 27002. ISO 27001 formuliert Anforderungen, Zielsetzungen und Prozesse zur Informationssicherheit sowie konkrete Sicherheitskontrollen anhand der individuellen Bedürfnisse einer Organisation. ISO 27002 ist ein "Best Practices Guide" mit detaillierten Spezifikationen für die Einführung des ISMS. Einige Gründe, die dafür sprechen, ein ISMS nach ISO einzuführen sind:

· Effizienzsteigerung und Transparenz: Ein ISMS stellt sicher, dass die Sicherheitsanforderungen des Kunden erfüllt und eine höhere Effizienz durch einen systematischen Prozessansatz erzielt werden. Durch das ISMS kann ein Unternehmen bestehende Risiken besser verstehen und entsprechende Gegenmaßnahmen ergreifen.

· Wettbewerbsvorteil: Häufig wird eine ISO 27001 Zertifizierung angestrebt, weil Konkurrenten bereits eine besitzen oder daran arbeiten. Ein ISO-Siegel auf der eigenen Webseite hat oft eine positive Wirkung auf Kunden und Medien.

· Business Enabler: Ein ISMS wird immer häufiger von Kunden als Geschäftsvoraussetzung angefordert, um das eigene Risiko bei dem Erwerb von externen Dienstleistungen zu reduzieren und um die eigene Zertifizierung erhalten zu können.

Kann ISO 27001 die Sicherheit eines kommerziellen Produktes (Software) gewährleisten?

Die Sicherheit von Softwareprodukten ist nicht ohne geeignete Kontrollmaßnahmen zu haben. Die konsequente Implementierung von Kontrollmaßnahmen stellt aber gerade im Softwarelebenszyklus eine große Herausforderung dar. Aus diesem Grund werden Zertifizierungen für Softwareprodukte und deren Entwicklungsprozesse nur sehr zögerlich eingesetzt. Trotzdem findet man einige Hersteller, die behaupten, sichere Software anhand ISO 27001-Prozesse zu entwickeln.

Dazu muss gesagt werden, dass es nicht verpflichtend ist, den Anwendungsbereich der Zertifizierung zu veröffentlichen. Die Beschränkung auf einen Prozess, ein System oder einen Standort macht es einem Unternehmen natürlich einfacher, eine Zertifizierung erfolgreich einzuführen. So kann es auch vorkommen, dass sich die Anwendungsbereiche der Zertifizierung nicht auf die Produktherstellung beziehen, sondern auf Dienstleistungen, IT- oder Beratungs-prozesse.

Implementierung von ISO 27001 mit Hilfe des Secure Software Development Life Cycle

Secure Software Development Life Cycle (S-SDLC) ist eine Softwareentwicklungsmethode, die die Sicherheit eines Produktes bereits während der Konzeption berücksichtigt. Deshalb ergänzen sich S-SDLC und ISO-Kontrollmaßnahmen optimal, da ISO-Kontrollen als Teil des S-SDLC strukturiert werden können.

Das ISMS wird als Ergänzung des bestehenden Qualitätsmodells implementiert und unabhängig von der Entwicklungsmethode definiert. ISO erfordert dabei hauptsächlich eine klare Dokumentation der folgenden Aspekte:

· ISMS-Definition und Festlegung

· Verantwortlichkeiten

· Interne ISMS-Audits

· Management des ISMS

· Verbesserung des ISMS

· Interne Organisation

· Management von externen Dienstleistungen

Die Grundlage des S-SDLC ist das so genannte CIA-Prinzip, das für Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability) steht. ISO-Kontrollen, die eine Einhaltung der CIA bezwecken, werden als Leistungsmerkmale betrachtet. Deshalb spielt Sicherheit im Zusammenhang mit dem S-SDLC eine genauso wichtige Rolle, wie die Entwicklung der kommerziellen Leistungsmerkmale eines Produktes.

Nichtfunktionale ISO-Kontrollen werden in folgende Entwicklungsphasen direkt integriert und als formale Entscheidungskriterien der Prozess-Meilensteine geprüft:

· Anforderungen: In dieser Phase wird der Schutzbedarf des Produktes definiert. ISO-Kontrollen werden zusammen mit funktionellen Leistungsmerkmalen anhand einer Risikoanalyse betrachtet sowie entsprechend priorisiert. Risiken werden adressiert, minimiert oder akzeptiert, aber nie ignoriert. Damit werden ISO-Kontrollen wie bspw. Leitlinie zur Anwendung von Kryptographie abgedeckt.

· Spezifikation & Design: Softwaresicherheit setzt voraus, dass Sicherheit als Teil des Entwicklungsprozesses behandelt wird. Ein Risk Mitigation Plan, der die Modellierung der Bedrohungen beinhaltet, bietet die notwendigen Rahmenbedingungen für die Entwicklung. Damit werden ISO-Kontrollen wie bspw. Analyse und Spezifikation von Sicherheitsanforderungen abgedeckt.

· Implementierung: Sichere Produkte können nur von Softwareentwicklern produziert werden, die in der Lage sind, einen sicheren Code zu schreiben. Durch gezielte Schulungen über Best Practices bei bestimmten Programmiersprachen, Datenbanken oder Open-source Software lernen Entwickler, wie typische Sicherheitslücken bei der Codierung vermieden werden könnten (z.B. Buffer Overflows). Außerdem ermöglichen Code Reviews mit Security-Fokus nicht nur die Identifizierung von Sicherheitslücken, sondern auch die Aufdeckung neuer Angriffsmethoden. Dadurch können ISO-Kontrollen wie bspw. Korrekte Verarbeitung in Anwendungen erfüllt werden.

· Integration und Test: In dieser Phase werden eigene und fremde Komponenten integriert und die Sicherheitsfunktionen überprüft. Angesichts der möglichen Angriffe sollten Tests auch unter Stressbedingungen durchgeführt werden und unvorgesehene Aktionen umfassen, die von den normalen Nutzerszenarien abweichen. Dabei spielen Vulnerability Tests und Penetration Tests mit Security-Tools, die bekannte Angriffsmuster und Hacker-Methoden nachbilden, eine wichtige Rolle. Auf dieser Weise könnten nichtfunktionale ISO-Anforderungen wie bspw. Schutz vor Schadsoftware und mobilen Programmcode verifiziert werden.

· Wartung: Hackerangriffe laufen häufig über neu entdeckte Sicherheitslücken. Die Schwachstellen können aus Programmfehlern in der eigenen Software oder von anderen Herstellern stammen. Diese Fehler sollen in dieser Phase so schnell wie möglich beseitigt werden, um das Angriffsrisiko zu reduzieren. Damit werden ISO-Kontrollen wie bspw. Umgang mit Informationssicherheitsvorfällen abgedeckt

Des Weiteren finden kontinuierliche Verbesserungen über neue Produktversionen bzw. Iterationen statt, während das S-SDLC ein externes Audit für eine ISO 27001 Zertifizierung nicht ausschließt, obwohl ein Audit nicht das Ziel ist.

S-SDLC und ISO 27001

Wie oben dargestellt, ist eine Implementierung des ISO 27001 Standards für die Entwicklung von Software möglich, auch wenn die Homogenität an manchen Stellen fehlt. Neue ISO Normen für Applikationssicherheit, wie das ISO/IEC 27034 sind jedoch in Planung und es besteht eine hohe Wahrscheinlichkeit, dass sich diese am S-SDLC Ansatz orientieren werden.

So lange die neuen Normen nicht verfügbar sind, ist es wichtig zu erkennen, dass die isolierte Anwendung von ISO 27001/2 bei der Entwicklung eines Produktes keine brauchbare Garantie für seine Sicherheit darstellt. Das liegt daran, dass diese Normen sehr viel Freiraum bei der Auswahl von Kontrollen einräumen und keine konkreten Empfehlungen bezüglich Entwicklungsprozesse und -modelle abgeben. Darüber hinaus ist eine Zertifizierung nur eine Momentaufnahme des Produktes unter bestimmten Annahmen, da Aspekte wie Produktlebenszyklus und Produktversionen nicht berücksichtigt werden.

Es empfiehlt sich daher die ISO 27000 Normen als Teil des Secure Software Development Life Cycle (S-SDLC) einzusetzen. Basierend auf diesem Konzept werden ISO-Kontrollen als formale Produktanforderungen eingeführt und in den verschiedenen Prozessstadien kontinuierlich geprüft. Dabei ist eine systematische Integration der ISO Normen anhand S-SDLC nicht unbedingt teurer als eine ISO 27001 Zertifizierung und vereinfacht die Übereinstimmung mit nationalen Richtlinien und Standards wie Datenschutzgesetzen und IT-Grundschutz. (Alcatel-Lucent: ma)