Genormte und zertifizierte Anwendungen

Macht Standardisierung nach ISO/IEC 27001 eine Software wirklich sicher?

Seite: 3/3

Firmen zum Thema

ISO 27001 in der Software-Entwicklung

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 den weiter unten aufgelisteten 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

Desweiteren 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 weiter 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.

Solange 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 Lifecycle (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.

Juan Ceballos ist zertifizierter CISSP und CSSLP sowie ISO27001-Experte und arbeitet als Product Line Manager bei Alcatel-Lucent Deutschland.

(ID:2051870)