Sichere SW-Entwicklung gemäß ISO 27001

Informationssicherheit ist ein weit verbreiteter Begriff. Jeder hat seine eigene Definition, und die kann vom Verständnis der ISO 27001 abweichen. Die häufigsten Irrtümer sind:

Irrtum: Informationssicherheit bekämpft (hauptsächlich) Hacker und von außen kommende Malware

Zahlreiche Studien belegen, dass die größte Gefahr für die Sicherheit von „innen“ kommt. Menschen machen Fehler, auch wenn sie mit sensiblen Daten umgehen. Schlimmer noch, Mitarbeiter können sich auf kriminelle Handlungen einlassen. Die „Datenleaks“ der Schweizer Banken zeigen deutlich, welchen Schaden ein Einzelner innerhalb einer großen Organisation anrichten kann.  Natürlich sind Hacker und Malware von außen auch eine Bedrohung für jedes Unternehmen. Unser Bild eines Hackers wird aber stark von Hollywood geprägt. In der Realität kämpfen Unternehmen aber immer häufiger gegen professionell organisierte und teilweise staatlich betriebener Industriespionage.

Irrtum: Informationssicherheit konzentriert sich (hauptsächlich) auf den Schutz sensibler Daten

Informationssicherheit erfordert den Schutz sensibler Daten. Vertraulichkeit ist jedoch nur einer von drei Aspekten.

1. Vertraulichkeit: Schutz sensibler Daten vor unberechtigtem Zugriff.
2. Integrität: Informationen dürfen nicht unangemessen verändert werden, weder versehentlich noch absichtlich.
3. Verfügbarkeit: Benutzer müssen in der Lage sein, Informationen bei Bedarf abzurufen; es dürfen keine Daten verloren gehen.

ISO 27001 deckt alle drei Aspekte ab.

Irrtum: SW Entwicklung findet in SW Entwicklungsabteilung statt

Auch Unternehmen ohne eigene SW Entwicklung haben typischerweise Entwicklungsprozesse im Sinn von ISO 27001. Dies betrifft zum Beispiel den IT Betrieb, der sich mittels „Skripten“ optimiert. Diese werden aber normalerweise von IT Profis mit entsprechendem Problembewusstsein erstellt und sind weniger problematischer als unternehmensweit verwendete Standarddokumente mit zum Beispiel Microsoft Office Makros. Eine von einem Sekretariat erstellte Briefvorlage oder von der kaufmännischen Abteilung erstelltes Abrechnungstool sind ein breites Einfallstor für jeden Hacker.

Irrtum: Informationssicherheit kann im Betrieb sichergestellt werden

Die Nutzung einer bereits im Sourcecode vorhandenen „Hintertür“ kann auch vom sichersten Betrieb nicht verhindert werden. Wie der Stuxnet Vorgang belegt, reicht selbst eine 100% Netzabschottung der Betriebs IT nicht aus, da ein zweistufiger Angriff über den SW-Importvorgang stattfinden kann.

Deshalb sollte nur SW von als sicher eingestuften Anbietern eingesetzt werden. Diese Einstufung kann stark davon abhängen, ob Geheimdienste als Bedrohung angesehen werden, da manche Hersteller in Ihren Herkunftsländern zur Zusammenarbeit mit Geheimdiensten rechtlich verpflichtet sind.

Entwicklung, Tests und Änderungsmanagement erfordern klare schriftliche Informationssicherheitsrichtlinien.

ISO 27001 erfordert keine spezifischen Organisationsformen oder Softwareprozesse. ISO 27001 betont jedoch klare Regeln und Richtlinien für den Umgang mit Informationsressourcen und den Engineering-Prozessen.

1. Zunächst müssen Sie klarstellen, welche Daten sensibel sind und wie mit ihnen umgegangen werden soll.
2. Sie müssen beschreiben, wie die Organisation sichere SW Entwicklung in einer sicheren Umgebung gewährleistet.
3. Sie müssen beschreiben, wie Software ohne Risiko für die Stabilität in den Produktivbetrieb übernommen werden kann.

Richtlinien durchsetzen und Nachweise erstellen.

ISO 27001 verlangt, dass die Richtlinien konsequent durchgesetzt werden und Nachweise vorliegen. Mit anderen Worten: Dokumentieren, dokumentieren, dokumentieren. Glücklicherweise bieten moderne SW Entwicklungs- und Testtools genügend Möglichkeiten, dies ohne großen Mehraufwand zu erreichen. Hier muss aber auf eine Personalisierung der Verantwortung und eine sichere Archivierung der Dokumentation geachtet werden. Außerdem müssen alle Mitarbeiter kontinuierlich geschult und motiviert werden, entsprechend zu handeln. Chaotische Genies oder nicht geniale Chaoten müssen in Teams und Prozesse eingebettet werden, die die Konformität mit ISO 27001 sicherstellen.

ISO 27001 hat Kapitel und einen Anhang A. Die Kapitel definieren einen Rahmen für die Informationssicherheit, und der Chief Security oder Chief Compliance Officer muss an diesen Themen arbeiten. Im Gegensatz dazu muss die IT-Abteilung im Allgemeinen die Mehrheit der 114 Controls aus Anhang A implementieren. Einige von ihnen sind nur für Entwickler, Tester und Änderungsmanager relevant.

Informationssicherheit beginnt mit der Identifizierung der Informationswerte sowie deren Klassifizierung und Kennzeichnung. Die zugangsberechtigten Benutzergruppen müssen geklärt werden. Datenzugriffs- und Schutzmechanismen müssen definiert werden.

Es gibt folgende Arten von Informationsbeständen:

• Produktionsdaten inklusive deren Dokumentbestände
• Entwicklungsdaten inklusive technischer Dokumente
• Testdaten

Im Falle von Produktionsdaten und -dokumenten arbeiten das Unternehmen, die Rechts- und Compliance-Abteilung und das Risikomanagement zusammen. Sie klassifizieren die Vermögenswerte und legen Richtlinien für den Umgang mit ihnen fest. Datenschutzgesetze haben Auswirkungen auf die Richtlinien, insbesondere in Europa. Die Richtlinien legen beispielsweise fest, ob Kundendaten sensibel sind, wer auf sie zugreifen darf usw. Tester und Ingenieure sind an der Klassifizierung nicht beteiligt, obwohl sich die Richtlinien auf sie auswirken können. Sie können z.B. die Speicherung von Kreditkartennummern von Kunden in Testsystemen verbieten.

Auch Informationswerte im Bereich der SW Entwicklung müssen klassifiziert werden. Die wichtigsten Vermögenswerte sind Quellcodes, Produktbeschreibungen, und Entwicklungs-Dokumentation, wie z.B. Anforderungen, Spezifikationen neuer Produktmerkmale, Architekturdokumente, Handelsalgorithmen von Hedge-Fonds usw., und sie können ebenso kritisch sein wie Produktionsdaten. ISO 27001 verlangt hier lediglich eine Klärung.

Notwendig ist Risikobewertung der Informationssicherheit zur Erzeugung von Sicherheitsanforderungen, die sowohl geschäftliche als auch technische Aspekte einbeziehen. Dies ist erforderlich, um funktionelle und technische Spezifikationen für Sicherheit und andere Funktionen, aber auch Verwendungs- und Missbrauchsfälle festzulegen.

Ebenso notwendig sind Konzepte des „ Security Risk Management Lifecycle „. Diese betreffen zum Beispiel die Anwendung der Sicherheitsrisikobeurteilung/-überprüfung, Verbesserungs- und Prüftechniken zur Software-Wartungs- und Aktualisierungsarbeiten sowie der angemessene Umgang mit End-of-Life-Systeme und ihre gespeicherten Daten sowie defekte Hardware

ISO 27001 definiert folgende Anforderungen:

• Richtlinie für sichere SW Entwicklung
  Hier werden Regeln für die Entwicklung von Software festgelegt. Während es über die sicheren Programmierstandards Bücher gibt, sind die ISO 27001 und sogar die ISO 27002 hier recht unspezifisch. Dies ist sicher der Gefahr geschuldet, dass spezifische Vorschriften nicht schnell genug an technologische Veränderungen angepasst werden könnten.
  Geforderte Aspekte für sichere SW Entwicklung sind:
  • Schriftliche Richtlinien in der Softwareentwicklungsmethodik, die allen bekannt sind und nachweislich angewendet werden.
    Zusätzlich sollen Sicherheitsanforderung in der Entwurfsphase schriftlich festgelegt werden.
  • Sichere Kodierungsstandards für die verwendeten Software-Plattformen, Verwendung von Sicherheitsfunktionen aus vertrauenswürdigen Bibliotheken, Verwendung von allgemein akzeptierte gute Sicherheitspraktiken, … sollen, müssen aber nicht verpflichtend gemacht werden. Ist ein Standard aber verpflichtend, kann die Nichteinhaltung vom Auditor als Nichtkonformität beurteilt werden.  Die Norm empfiehlt deshalb die Einhaltung der Standards durch Test und Code-Prüfungen zu verifizieren.
  • Sicherheitsbewusstsein und Schulung für Entwickler und andere Teammitglieder inklusive des Managements. Letzteres muss wissen, wie man Ressourcen für die Sicherheitsaspekte eines Entwicklungsprojekts plant. Entwickler müssen die Fähigkeit haben, Schwachstellen zu vermeiden, zu finden und zu beheben. Außerdem müssen die Mitarbeiter über das erforderliche Wissen bezüglich Anwendungssicherheit verfügen. Am Ende sollen auch Anwender geschult werden – oder Schulungsunterlagen zur Verfügung stehen.
  • Regelmäßige Sicherheitsüberprüfungen innerhalb der Projektmeilensteine erfordern typischerweise das Vorliegen einer – Sicherheitsarchitektur für die einzelne Systeme, Programme, Datenbasen, … und eine Dokumentation der Sicherheitsaspekte der Systeme, einschließlich ihrer Verwaltung, Wartung und natürlich ihrer Nutzung.
• Es soll während des gesamten Entwicklungsprozesses Sicherheitsüberprüfungen geben. Diese sind in frühen Projektphasen typischerweise reine Schreibtischtests, und sollen sich an der Risikoeinschätzung orientieren.  In Projektphasen, in denen bereits ablauffähiger Code vorliegt, kann ein automatisierter Test für diese Anforderung erstellt werden. ISO 27002 weist ausdrücklich darauf hin, dass Tests auch vom Entwicklungsteam durchgeführt werden sollen.
• Richtlinien zum Gebrauch kryptographischer Maßnahmen müssen existieren und angewendet werden.

• Systemabnahmetests – gegen funktionale und nicht-funktionale Anforderungen sind obligatorisch -, wobei letztere die Sicherheitsanforderungen einschließen.
• Spezifische Testanforderungen für Betriebsplattformänderungen, bei denen geschäftskritische Anwendungen gegen eine neue Plattform getestet werden müssen.
• Testen der Systemsicherheit. Es muss während des gesamten Entwicklungsprozesses Sicherheitsüberprüfungen geben. Der Fokus für Tester liegt auf „Abnahmeprüfungen“. Diese ersetzen aber nicht Prüfverfahren innerhalb der Entwicklung.
• Verwendung von Testdaten Ein höchst kritischer Aktivposten in Entwicklungs- und Testumgebungen sind die Testdaten. Viele Anwendungen – insbesondere Geschäftsanwendungen – enthalten Datenbanken. Tester benötigen geeignete Daten in den Datenbanken von Testumgebungen.
  Auch im Bereich der künstlichen Intelligenz haben Testdaten eine hohe Bedeutung. Allerdings gelten Daten, die zum Training einer KI verwendet werden, als Produktionsdaten (ähnlich wie ein Sourcecode). Die Norm verlangt, dass die Testdaten geschützt werden. Dies trifft ganz besonders zu, wenn es sich um personenbezogene Daten handelt. Betrachtet man den Leitfaden zur Norm, so wird deutlich, dass der Standard die Testdatenverwaltung „alten Stils“ widerspiegelt. Mit anderen Worten, die Testdaten stammen aus einer produktiv genutzten Umgebung. Der Schwerpunkt liegt auf der Minderung der Risiken, die mit der Verwendung von Produktionsdaten verbunden sind, wie z.B. die Möglichkeit, den Kopierprozess zu überprüfen und strenge Zugriffsregeln für Testumgebungen. Der Trend zu synthetischen Testdaten wird nicht widergespiegelt. Der Leitfaden ist jedoch nicht normativ. Organisationen können ISO 27001 auf ihre eigene Art und Weise implementieren. Insbesondere wenn Organisationen mit synthetischen Daten testen, sind viele Ideen des Leitfadens veraltet. Auch die Generierung von lohnenden Testdaten und Protokollen zur Prüfung der Sicherheit Funktionen und zum Testen von Sicherheitsaspekten von Benutzerfunktionen sollte betrachte werden.  

Die Anforderungen sind mit vielen Software-Entwicklungsprozessen wie Scrum oder dem älteren Wasserfallmodell kompatibel. Scrum erfordert jedoch mehr Gedanken als das Wasserfallmodell. IT-Abteilungen, die das Wasserfallmodell (oder das V-Modell) verwenden, verfügen oft über ein Testzentrum und Quality Gates. Quality Gates definieren die Kriterien dafür, wann Tests beginnen können und wann sie erfolgreich sind. Ein Kriterium vor dem Testbeginn kann sein, dass die Entwickler Sicherheitstests durchgeführt haben. Ein Ausstiegskriterium für Tests kann sein, dass Benutzerakzeptanztests in der Testumgebung für funktionale und nicht-funktionale Anforderungen erfolgreich waren. Wenn Tester in einem Testzentrum arbeiten und nicht Teil eines Entwicklungsteams sind, können Entwicklungsteams keinen großen Druck auf sie ausüben. So können Tester die Anforderungen für alle Projekte leichter durchsetzen.

In der Welt von Scrum und Agil gibt es oft keine Testzentren und keine zentrale Verwaltung. Das mag fragwürdig sein, aber es ist Realität. Entwicklung und Test überschneiden sich zeitlich. Rollen überschneiden sich. Dies ist jedoch keine Entschuldigung für fehlende Dokumentation oder nicht implementierte Controls bei einem ISO 27001-Audit. Dies ist die größte Herausforderung für agile Projekte bezüglich Normkonformität. Ein Lösungsansatz dazu wir im Kapitel Freigabe- und Änderungsmanagement beschrieben.

• Eine sichere Entwicklungsumgebungen für den gesamten Entwicklungszyklus. Die Forderung nach Vertraulichkeit, Verfügbarkeit und Integrität hat weitreichende Auswirkungen auf Zugriffskontrollmechanismen, die Einstellung und Beauftragung von Entwicklern und Testern sowie auf Backup-Strategien.
• Es werden sichere Repositorien und die Sicherheit bei der Versionskontrolle eingefordert. Repositorien sollen eine verlässliche und nachvollziehbare Zuordnung von Verantwortlichkeiten erlauben. Praxisorientierte ISO 27001 Anwendungen wie TISAX® sehen sinnvollerweise die Verwendung von Funktions- oder Sammelaccounts kritisch.
• Entwicklungs-, Test- und Betriebsumgebung müssen voneinander getrennt sein.
  Dies dient zur Verhinderung, dass „kleine“ Änderungen in Umgehung des Test- oder Änderungsprozesses eingebracht werden können.
• Der Zugriff auf den Quellcode muss durch entsprechende Maßnahmen überprüfbar eingeschränkt sein. Dies erfordert Zugangskontrollen zu den Entwicklungs-, Test- und Produktionsbereichen, Code-Bibliotheken usw., um unangemessene Änderungen wie die Einführung von Hintertüren, Logikbomben oder Trojanern zu Verhindern.  Eine Aufteilung der Verantwortung zwischen Nutzern, Architekten und Entwicklern, Testern, Betreibern ist sinnvoll. Dabei soll das Prinzip „so wenig Rechte wie nötig“ angewendet werden.

• Eine formales Änderungsmanagement ist vorgeschrieben, das alle IT-Änderungen umfasst – auch die der eigenen SW.
• Beschränkung an Änderungen von SW Paketen. Von anderen Anbietern bereitgestellte SW Pakete sollen möglichst ohne Änderungen verwendet werden. Wenn doch geändert werden muss, soll die Zustimmung des Anbieters eingeholt werden.
• Installation von SW auf Produktivsystemen. Hier wird nicht zwischen eigener und Fremdsoftware unterschieden. Kommentar siehe unten.
• Das Control zur Verwaltung von Systemänderungen im Entwicklungszyklus beschreibt ein strenges Änderungskontrollverfahren während der Entwicklung, um unerwünschte Änderungen zu verhindern. Dies umfasst neben dem eigenen Code auch die Umgebung wie Ablaufumgebung oder Middleware. Automatische Aktualisierungen sind nicht verboten – es wird aber bei kritischen Systemen davon abgeraten. Praxistipp: Über diese Empfehlung sollte man sich nur nach einer dokumentierten Risikoeinschätzung hinwegsetzen.

Die ISO 27001 beschreit ein Release-Management im Stil der alten Checkboxen. IT-Mitarbeiter haben eine Liste von Kriterien, die sie überprüfen. Wenn alle erfüllt sind, kann eine Änderung in Produktion gehen. Dieses Modell erfüllt die heutigen Bedürfnisse vieler Organisationen. Hochgradig agile Organisationen bevorzugen jedoch die kontinuierliche Integration und DevOps. Sie investieren in Testautomatisierung, um schnelle Rückkopplungsschleifen zu haben. Möglicherweise gibt es sogar keine manuellen Tests, bevor kleine Änderungen in die Produktion eingeführt werden, was die Frage aufwirft, ob dies mit ISO 27001 konform ist.

Diskussion darüber, ob ISO 27001 veraltet ist und Scrum, DevOps usw. dem Stand der Technik entsprechen, sind nicht hilfreich. Eine flexible Anwendung von ISO 27001 hilft besser, da eine Top-Management-Entscheidung für ISO 27001 ein höheres Gewicht als jeder Entwicklungs- oder Testprozess hat. ISO 27001 schreibt keine manuellen Tätigkeiten vor. Entwickler und Tester sollten ihre Zeit in die automatisierte Bereitstellung von für ISO 27001 geforderten Informationen investieren. Dies ist machbar, auch wenn zwischen der Codierung und dem produktiven Einsatz keine oder nur minimale menschliche Beteiligung besteht. Schriftliche Betriebsverfahren, archivierte Audit-Protokolle usw. helfen, die Konformität sicherzustellen.