Sicherer Entwicklungszyklus
Nicht erst seit der Verbreitung der App-Entwicklung wirken die Begriffe Software-Entwicklungsprozess und Vorgehensmodell leicht angestaubt. Monumentale Vorgehensmodelle wie das V-Modell, das Spiralmodell oder RUP wirken schon durch ihre Namen wie Steine am Bein von Architekten und Programmierern – nur dazu geeignet, jegliche Kreativität im Keim zu ersticken und alles unter einer dicken Schicht von Formalismen und Richtlinien zu begraben. Das Schlagwort im Bereich der Software-Entwicklung lautet daher agil.
Agile Methoden – allen voran Scrum [http://de.wikipedia.org/wiki/Scrum], das mittlerweile aus kaum einem Entwicklungsteam mehr wegzudenken ist, oder Extreme Programming-->[http://de.wikipedia.org/wiki/Extreme_Programming] – scheinen wie geschaffen für Anforderungen, wie sie bei der App-Entwicklung auftauchen: Einzelprogrammierer oder kleine Teams, schnelle Umsetzung, lösungsorientierter Ansatz. Allen Vorgehensweisen ist gemeinsam, dass sie zwar (mehr oder weniger) sinnvolle Rahmen für die Software-Entwicklung vorgeben, den Entwickler am Ende aber mit seinem Know-how allein lassen. Dies gilt auch und insbesondere für das Thema Sicherheit.
Sind Prozesse nicht nur etwas für Juristen?
Techniker, und zu solchen zählen Programmierer auch, verziehen bei der Erwähnung des Begriffs Prozess allzu gerne das Gesicht. Dabei ist insbesondere Sicherheit nur durch die richtige Mischung aus technischen Maßnahmen und funktionierenden, unterstützenden Prozessen möglich. Die alte Faustregel von Security-Auditoren lautet nicht umsonst: »Mache einen Pentest [http://de.wikipedia.org/wiki/Penetrationstest_%28Informatik%29] , und Du weißt, wie ein System heute aussieht. Untersuche die Prozesse, und Du weißt, wie das System morgen aussieht.«
Es existieren mittlerweile verschiedene Ansätze, um den Software-Entwicklungsprozess so zu erweitern, dass er das Produzieren sicherer Software unterstützt oder ermöglicht. Der bekannteste Ansatz ist wohl der SDL (vormals SSDL), der Secure Development Lifecycle der Firma Microsoft. Ein weiterer bekannter Ansatz ist der vom International Secure Software Engineering Council (ISSECO) konzipierte Standard. Für Letzteren existiert sogar eine Personenzertifizierung, mit der sich Interessierte zum Certified Professional for Secure Software Engineering (CPSSE) ausbilden und zertifizieren lassen können.
Allen existierenden Modellen ist gemeinsam, dass sie recht starr sind und ihre Einführung zu merklichen Änderungen im gesamten Entwicklungszyklus führt. Das ist aber wenig wünschenswert, denn Änderungen führen in der Hauptsache zu einer Störung der Produktivität. Daher ist eine weniger invasive Methode hilfreich und hat sich in der Praxis bereits mehrfach in Entwicklungsteams verschiedener Größe – von ganz klein bis ganz groß – bewährt. Ihren Ursprung hat diese Methodik in der Tätigkeit eines der beiden Autoren als Consultant für IT-Security. Nach Jahren der fast ausschließlich analytischen IT-Sicherheit, d. h. der Überprüfung bereits implementierter Systeme, hat sich das Bewusstsein im Markt gewandelt, und die proaktive Sicherheit, also das Erstellen sicherer Software, rückt immer weiter in den Vordergrund.
Aus den Erfahrungen in einer Vielzahl von Beratungsprojekten ist ein Anforderungskatalog entstanden, der die wichtigsten Rahmenparameter definiert, die in einem Entwicklungszyklus vorhanden sein müssen, damit er sichere Software produziert. Dieser Anforderungskatalog ist durch die in den folgenden Abschnitten beschriebenen in elf Objectives gegliedert, die durch dazugehörige Controls näher definiert werden.
Bei der Anwendung des Anforderungskatalogs auf den eigenen Entwicklungsprozess ist stets zu prüfen, ob die Maßnahmen angemessen sind. In keinem Fall ist die wortgetreue Adaption zielführend, denn die zu treffenden Maßnahmen müssen in einem sinnvollen Verhältnis zu den gegebenen Umständen und der Wirtschaftlichkeit stehen. Wo für große Entwicklungsteams beispielsweise die Sicherung des Quelltextes über ein zentrales Repository und entsprechend mächtige Backup-Mechanismen notwendig sind, reicht für einen einzelnen Entwickler von Apps ein lokales Git-Repository und die Sicherung per Time Machine auf eine externe Platte vollkommen aus.
Lassen Sie sich daher nicht von manchem nach Beamtendeutsch und Befehlston klingenden Wortlaut im Anforderungskatalog abschrecken – der Katalog soll eine Leitlinie sein, um alle relevanten Themen zu adressieren, und die dort aufgeführten Vorgaben sollen nicht wörtlich, sondern dem Geiste nach verstanden werden. Der Katalog gibt keine Vorgabe bezüglich der konkreten Umsetzung von Maßnahmen, und das ist – um es mit den Worten des regierenden Bürgermeisters von Berlin zu sagen – gut so.
Wundern Sie sich nicht, wenn Ihnen bei einigen Controls der direkte Bezug zur App?Entwicklung fehlt, z. B. bei den Controls zum Deployment. Für eine singuläre App mögen diese Controls nicht von Belang sein, aber viele Apps sind Bestandteil von Client-Server-Strukturen, und in solchen Umgebungen spielt das Deployment von Software und das Härten der Zielplattform (der Server) eine wichtige Rolle.
A.1 Awareness
Objective: Das Management muss sich zur Umsetzung der Maßnahmen bekennen, die für einen sicheren Entwicklungsprozess notwendig sind, und diesen durch die Zuweisung von Verantwortung und die Bereitstellung von Ressourcen aktiv unterstützen.
Control 1.1: Security Policy
Es sollte eine vom Management bestätigte Leitlinie über die Sicherheit im Entwicklungsprozess existieren, die allen am Prozess Beteiligten in ihrer jeweils akutellen Fassung bekannt ist. Die Leitlinie muss für jeden Adressaten zugänglich sein. Die Leitlinie sollte eine Aussage über die Motivation für den sicheren Entwicklungsprozess beinhalten.
Control 1.2: Review der Security Policy
Die Security Policy für den SDL sollte regelmäßigen Prüfungen unterliegen und immer auf aktuellem Stand gehalten werden.
Control 1.3: Verantwortlichkeiten
Alle Aktivitäten, die Sicherheit im Entwicklungsprozess betreffen, sollten von einer klar definierten und zentralen Rolle koordiniert und überwacht werden. Diese Rolle sollte überdies Fragen zur Security beantworten oder an geeignete Stellen delegieren können.
Control 1.4: Einbettung in ein ISMS
Ist in der Organisation ein ISMS (Informationssicherheitsmanagementsystem) nach ISO 27001 vorhanden, sollten die Sicherheitsmaßnahmen im Entwicklungsprozess in dieses ISMS eingegliedert werden. Sich möglicherweise überschneidende Controls sind nach dem Aspekt der größtmöglichen Sicherheit gegeneinander abzuwägen.
Control 1.5: PDCA
Die sicherheitsbezogenen Maßnahmen des Software-Entwicklungsprozesses sollten nach dem PDCA-Modell [https://secure.wikimedia.org/wikipedia/en/wiki/PDCA] kontinuierlich überprüft und verbessert werden.
Control 1.6: Management-Awareness
Das Management sollte durch das Zuweisen von Verantwortung für die Sicherheit im Entwicklungsprozess sichtbare und aktive Unterstützung geben.
Control 1.7: Ausgelagerte Software-Entwicklung
Ausgelagerte Software-Entwicklung muss denselben in dem Anforderungskatalog definierten Regularien unterliegen wie die interne Entwicklung. Schriftliche Vereinbarungen sollten Sicherheitsanforderungen an Externe definieren.
Control 1.8: Prozessmodelle
Kommen für die Software-Entwicklung verschiedene Prozessmodelle zum Einsatz, sollte für jedes Modell eine eigene Anpassung der Sicherheitsmaßnahmen dokumentiert sein.
Control 1.9: Dokumentation
Alle Sicherheitsmaßnahmen im Software-Entwicklungsprozess sollten zentral dokumentiert sein, und die Dokumentation sollte regelmäßig geprüft und aktualisiert werden. Jede Dokumentation muss allen am Entwicklungsprozess Beteiligten bekannt und leicht zugänglich sein. Aus der Dokumentation muss eindeutig hervorgehen, welche Sicherheitsmaßnahmen zu welchem Zeitpunkt im Prozess ausgeführt werden müssen.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
