Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort des Gutachters
Vorwort
1 Einführung
2 Einstieg in die Praxis
3 Aufwachen – analoger Wecker
4 Daten, Tabellen und Controller
5 Animationen und Layer
6 Programmieren, aber sicher
7 Jahrmarkt der Nützlichkeiten
A Die Buch-DVD
Stichwort

Download:
- ZIP, ca. 23,6 MB
Buch bestellen
Ihre Meinung?

Spacer
Apps entwickeln für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das Praxisbuch
Buch: Apps entwickeln für iPhone und iPad

Apps entwickeln für iPhone und iPad
geb., mit DVD
515 S., 34,90 Euro
Galileo Computing
ISBN 978-3-8362-1463-6
Pfeil 6 Programmieren, aber sicher
Pfeil 6.1 Sicherheitsmechanismen von iOS
Pfeil 6.2 Bedrohungen, Angriffe, Sicherheitslücken und Maßnahmen
Pfeil 6.2.1 Arten von Sicherheitslücken
Pfeil 6.3 Threat Modeling
Pfeil 6.3.1 Erstellen eines Datenflussdiagramms
Pfeil 6.3.2 STRIDE
Pfeil 6.3.3 Generische Design-Grundsätze
Pfeil 6.3.4 Threat Modeling aus der Tube – das Microsoft SDL Threat Modeling Tool
Pfeil 6.4 Sicherer Entwicklungszyklus
Pfeil 6.4.1 Awareness
Pfeil 6.4.2 Umgebung
Pfeil 6.4.3 Training
Pfeil 6.4.4 Dokumentation
Pfeil 6.4.5 Requirements
Pfeil 6.4.6 Design
Pfeil 6.4.7 Implementierung
Pfeil 6.4.8 Security-Testing
Pfeil 6.4.9 Deployment
Pfeil 6.4.10 Security Response
Pfeil 6.4.11 Sicherheitsmetriken
Pfeil 6.4.12 Abschließende Bemerkung
Pfeil 6.5 Sicherheit in der iOS-API
Pfeil 6.5.1 Keychain
Pfeil 6.5.2 Dateiattribute
Pfeil 6.5.3 Jailbreak-Erkennung
Pfeil 6.5.4 Event-Handling

Galileo Computing - Zum Seitenanfang

6.4 Sicherer EntwicklungszyklusZur nächsten Überschrift

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, die nur dazu geeignet sind, 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 ist daher agil.

Agile Methoden, allen voran Scrum, das mittlerweile aus kaum einem Entwicklungsteam mehr wegzudenken ist, oder 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 alleine 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[29](https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m05/m05150.html), 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 zur 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. Ein Grund dafür mag sein, dass sich der in Abbildung 6.2 dargestellte Sachverhalt langsam bis in die Entscheider-Ebene herumgesprochen hat.

Aus den Erfahrungen in einer Vielzahl von Beratungsprojekten 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 das Stichwort der Angemessenheit zu beachten. 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.


Galileo Computing - Zum Seitenanfang

6.4.1 AwarenessZur nächsten ÜberschriftZur vorigen Überschrift

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 geignete 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 [30](https://secure.wikimedia.org/wikipedia/en/wiki/PDCA) kontinuierlich überprüft und verbessert werden.

Control 1.6: Management-Awareness

Das Management sollte durch die Bestätigung 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.


Galileo Computing - Zum Seitenanfang

6.4.2 UmgebungZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Die für die Software-Entwicklung verwendete IT-Infrastruktur muss geeignet sein, um Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität des Quellcodes und der Dokumentation sicherstellen zu können.

Control 2.1: Sicherheit der Ausstattung

Alle für den Entwicklungsprozess verwendeten IT-Systeme sollten sicher, gehärtet, gepatcht und vom Produktionsnetz und der Internetkommunikation getrennt sein.

Control 2.2: Sicherheit des Quelltextes

Der Quelltext sollte gesichert und gegen Manipulation geschützt sein.

Control 2.3: Bugtracking

Es sollte ein Bugtracking-System in Gebrauch sein, das projektbezogen die explizite Markierung und Nachverfolgung von sicherheitsrelevanten Fehlern ermöglicht.

Control 2.4: Physische Sicherheit

Alle Räumlichkeiten, die zur Software-Entwicklung genutzt werden, sollten gegen Zugang durch Unbefugte geschützt sein.

Control 2.5: Clean Desk Policy

Quelltext, Dokumentationen, Architekturpläne, Konzepte und andere Informationen aus dem Entwicklungsprozess sollten grundsätzlich nur zum Gebrauch verwendet und nach Dienstschluss in ein geschlossenes Gewahr verbracht werden.

Control 2.6: Verschlüsselte Kommunikation

Die Übermittlung sensibler Informationen (Quelltext, Zugangsdaten etc.) sollte grundsätzlich verschlüsselt erfolgen.

Control 2.7: Schutz mobiler Geräte

Für die Entwicklung relevante mobile Geräte sollten gegen unbefugten Zugriff gesichert und mit Verschlüsselungssoftware gegen den Zugriff auf die Datenträger geschützt werden.

Control 2.8: Entsorgung von Altgeräten

Bei der Entsorgung von Altgeräten, die Bestandteil des Software-Entwicklungsprozesses waren, sollten alle Datenträger entweder physisch zerstört oder durch mehrfaches Überschreiben gelöscht werden.

Control 2.9: Aufteilung von Systemen

Entwicklungs-, Test- und Produktionssystem sollten getrennt sein, um das Risiko unbefugten Zugriffs zu minimieren.

Control 2.10: Erzeugen von Testdaten

Testdaten mit sensiblen oder personenbezogenen Informationen dürfen nicht aus Produktionsdaten erzeugt werden bzw. müssen vor ihrer Verwendung ausreichend anonymisiert werden.

Control 2.11: Zugriff auf Quelltext

Der Zugriff auf Quelltext sollte so reglementiert sein, dass jeder Entwickler nur das für ihn relevante Modul einsehen und verändern kann (Need to know). Der Zugriff auf den Quelltext sollte protokolliert werden.

Control 2.12: Versionsverwaltung

Ein System zur Versionsverwaltung (SCM) sollte verwendet werden.

Control 2.13: Backup

Alle für den Entwicklungsprozess relevanten Daten, insbesondere der Quelltext, sollten regelmäßig auf externe Medien gesichert werden. Diese Medien müssen gegen unbefugten Zugriff geschützt und störfallsicher dezentral aufbewahrt werden. Es muss eine regelmäßige Überprüfung der Backup-Daten stattfinden, um deren Brauchbarkeit für die Wiederherstellung sicherzustellen.


Galileo Computing - Zum Seitenanfang

6.4.3 TrainingZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Alle am Entwicklungsprozess beteiligten Architekten und Entwickler müssen regelmäßig zu grundlegenden Themen der sicheren Software-Entwicklung geschult werden, um sicherheitsbezogenes Wissen auf einem aktuellen Stand zu halten und Awareness für die Sicherheit im Entwicklungsprozess aufrechtzuerhalten.

Control 3.1: Trainingsplan

Es muss ein Trainingsplan existieren, mit dem sicherheitsrelevante Trainings für alle am Entwicklungsprozess Beteiligten verwaltet werden. Der Trainingsplan sollte mindestens einmal pro Jahr auf einen aktuellen Stand gebracht werden und vorsehen, dass jede relevante Person ein Security-Training pro Jahr besucht.

Control 3.2: Durchführung von Security-Trainings

Alle am Entwicklungsprozess beteiligten Personen sollten dem Trainingsplan entsprechend Schulungen für die Thema Requirements Engineering, Secure Design und Secure Coding wahrnehmen.

Control 3.3: Threat Modeling

Alle am Entwicklungsprozess beteiligten Personen sollten dem Trainingsplan entsprechend Schulungen zum Thema Threat Modeling wahrnehmen und mit der Anwendung des STRIDE-Modells vertraut sein.

Control 3.4: Umgang mit Tools

Alle Mitarbeiter, die mit für die Sicherheit im Entwicklungsprozess relevanten Tools arbeiten (Threat Modeling Tool, Code-Analyse, Fuzzing etc.), müssen im Umgang mit diesen Tools angemessen geschult sein.

Control 3.5: Umgang mit Sprachen, Tools und Plattformen

Alle Entwickler sollten in der Verwendung ihrer Programmiersprachen, Tools und Plattformen geschult sein.


Galileo Computing - Zum Seitenanfang

6.4.4 DokumentationZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Aussagekräftige Dokumentation ermöglicht das Nachvollziehen sicherheitsrelevanter Tätigkeiten im Entwicklungsprozess. Das kontinuierliche Dokumentieren sicherheitsbezogener Erkenntnisse ermöglicht die fortlaufende Verbesserung von Sicherheitsmaßnahmen.

Control 4.1: Dokumentation und Pflege von Fremdcode

Alle im Projekt verwendeten Frameworks, Programme und Bibliotheken externer Anbieter müssen dokumentiert und Bestandteil des Patchmanagement-Prozesses sein.

Control 4.2: Security-Datenbank

Es sollte eine Datenbank mit Standard-Techniken für sicheres Design und Maßnahmenlisten gegen die häufigsten Bedrohungen geben.

Control 4.3: Erstellen von Sicherheitskonzepten

Für jedes Produkt sollte ein Sicherheitskonzept erstellt werden, das alle sicherheitsrelevanten Informationen enthält.

Control 4.4: Betriebsdokumentation

Für jedes Produkt sollte eine Betriebsdokumentation erstellt werden, in der alle für den Betrieb relevanten Angaben zur Sicherheit enthalten sind.


Galileo Computing - Zum Seitenanfang

6.4.5 RequirementsZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Das Adressieren von Sicherheit und Datenschutz in der Anforderungsphase ist die Grundlage sicherer Software und orientiert sich an Compliance-Anforderungen und den aus den funktionalen Anforderungen abgeleiteten Sicherheitsanforderungen.

Control 5.1: Security Advisor

Für jedes Software-Projekt sollte ein Sicherheitsbeauftragter (Security Advisor) benannt werden, der die Verantwortung für die Sicherheit des Produktes trägt und Ansprechpartner für Sicherheitsfragen in der Entwicklung ist.

Control 5.2: Sicherheitsüberprüfung

Für jedes Software-Projekt sollte eine Risiko-Abwägung darüber getroffen werden, ob und in welchem Umfang es den sicheren Software-Entwicklungsprozess durchlaufen muss. Die Entscheidung ist durch den Sicherheitsverantwortlichen im Unternehmen zu bestätigen, und die Entscheidung ist schriftlich zu begründen und dokumentieren.

Control 5.3: Verwendung von Fremdcode

Bei der Verwendung fremden Codes (Frameworks, Bibliotheken etc.) sollte geprüft werden, ob die Sicherheit dieses Fremdcodes unterstellt werden kann. Die Entscheidung ist durch den Security Advisor zu bestätigen und schriftlich zu dokumentieren.

Control 5.4: Vorabkontrolle

Im Geltungsbereich des Bundesdatenschutzgesetzes (BDSG) ist für Software, die dem BDSG unterliegt, in der Anforderungsphase eine Vorabkontrolle gemäß §4d, Absatz 5 BDSG durchzuführen.

Control 5.5: Angemessenheit

Die Angemessenheit von Sicherheitsmaßnahmen innerhalb eines Software-Projektes sollte durch eine Risiko-Analyse ermittelt werden.

Control 5.6: Security-Expertise

Das Requirements Engineering sollte von mit gängigen Angriffsmustern und Sicherheitsarchitekturen und -mechanismen vertrauten Personen begleitet werden.

Control 5.7: Compliance-Prüfung

Für jedes Projekt sollte eine Compliance-Prüfung durchgeführt werden, um festzustellen, welchen regulatorischen Vorgaben die Software unterliegt. Die Sicherheitsanforderungen sind entsprechend den Vorgaben der entsprechenden Regularien zu formulieren.

Control 5.8: Ermitteln von Sicherheitsanforderungen

Für jedes Projekt sollten die relevanten Sicherheitsanforderungen bezüglich Vertraulichkeit, Integrität und Verfügbarkeit der zu verarbeitenden Daten identifiziert werden. Entsprechende Maßnahmen zur Befriedigung dieser Anforderungen müssen dokumentiert und berücksichtigt werden.

Control 5.9: Richtlinien für Sicherheitsanforderungen

Es sollten Richtlinien für das Ermitteln von Sicherheitsanforderungen vorhanden und allen Beteiligten bekannt sein. Die Richtlinien sollten regelmäßig überprüft und aktualisiert werden.


Galileo Computing - Zum Seitenanfang

6.4.6 DesignZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Sicheres Design ist die Grundlage sicherer Software. Das Adressieren von Sicherheit bei der Planung der Architektur und das methodische Identifizieren spezifischer Bedrohungen ermöglicht die proaktive Implementierung von Sicherheit und vermeidet die aufwendige Beseitigung von Sicherheitslücken im Nachhinein.

Control 6.1: Anwenden von Sicherheitsprinzipien

Es sollten grundsätzlich gängige Anforderungsprinzipien (wie Attack Surface Reduction, Defense in Depth, Least Privilege etc.) genutzt werden. Die zu berücksichtigenden Prinzipien sind schriftlich dokumentiert und allen am Design Beteiligten bekannt.

Control 6.2: Anwendung von Trust-Modellen

Der Zugriff auf Daten sollte grundsätzlich über Trust-Modelle abgebildet werden.

Control 6.3: Threat Modeling

Die spezifischen Bedrohungen für ein System sollten über ein Threat Model ermittelt und klassifiziert werden. Das Threat Model muss bei jeder Änderung der Software auf Vollständigkeit überprüft und ggf. erweitert werden. Dies gilt insbesondere bei agiler Entwicklung.

Control 6.4: Bewertung von Bedrohungen

Den im Threat Model ermittelten Bedrohungen sollte durch angemessene Maßnahmen begegnet werden. Alternativ ist das Akzeptieren von Bedrohungen möglich. Diese Entscheidung ist vom Security Advisor mit dem Management zu treffen und dokumentieren.

Control 6.5: Katalogisieren von Maßnahmen

Umzusetzende Gegenmaßnahmen zu den im Threat Model identifizierten Bedrohungen sollten in den Projektplan aufgenommen und entsprechend dokumentiert bzw. katalogisiert werden.

Control 6.6: Begleitung durch Security-Expertise

Das Threat Modeling sollte durch einen geschulten Sicherheitsfachmann geleitet oder begleitet werden, um sicherzustellen, dass aktuelles Know-how bezüglich möglicher Bedrohungen in das Threat Model einfließt.

Control 6.7: Bedrohungsdatenbank

Die im Threat Model ermittelten Bedrohungen sollten in generischer Form in einer speziellen Datenbank katalogisiert werden, um den Aufbau einer Bedrohungsdatenbank zu ermöglichen.

Control 6.8: Teilnahme am Threat Model

Am Threat Model sollten neben Architekten und Entwicklern auch Projektleiter teilnehmen, um sicherheitsrelevante Informationen in die Entscheider-Ebene zu transportieren.

Control 6.9: Tools

Das Threat Modeling sollte mit geeigneten Tools durchgeführt werden, um eine systematische Bearbeitung aller Bedrohungen sicherzustellen.

Control 6.10: Bedrohungsmodell

Die im Threat Model ermittelten Bedrohungen sollten anhand eines feststehenden Modells kategorisiert werden (z. B. STRIDE).


Galileo Computing - Zum Seitenanfang

6.4.7 ImplementierungZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Die Anwendung der Prinzipien sicherer Implementierung vermeidet Sicherheitslücken durch die Verwendung unsicherer Funktionen und Bibliotheken.

Control 7.1: Vorgaben zum Umgang mit Daten

Es sollte Richtlinien zur Pseudonymisierung, Verschlüsselung und Übermittlung und Speicherung sensibler Daten geben. Diese Richtlinien müssen regelmäßig überprüft und auf einen aktuellen Stand gebracht werden.

Control 7.2: Verwendung von Kryptografie

Die Art und Verwendung von kryptografischen Funktionen sollte dokumentiert sein. Die Art sollte in Form einer Whitelist definiert werden. Nicht auf dieser Whitelist befindliche Algorithmen dürfen nicht verwendet werden.

Control 7.3: Verwendung von Bibliotheken

Bei der Verwendung von Bibliotheken externer Anbieter muss die Sicherheit dieser Bibliotheken gewährleistet sein.

Control 7.4: Verbotene Funktionen

Es sollte eine Blacklist definiert werden, auf der verbotene Funktionen aufgelistet sind.

Control 7.5: Implementierungsrichtlinien

Für jede verwendete Programmiersprache sollten Implementierungsrichtlinien vorhanden sein. Diese Richtlinien müssen regelmäßig geprüft und auf einen aktuellen Stand gebracht werden.

Control 7.6: Vorgaben zur Fehlerbehandlung

Für die Fehlerbehandlungen in Programmen sollte eine verbindliche Richtlinie bestehen, um sicherzustellen, dass sicherheitskritische Fehler ausreichend abgefangen werden.

Control 7.7: Ein- und Ausgabe-Validierung

In allen Programmteilen muss zwingend Ein- und Ausgabe-Validierung stattfinden. Hierzu sollten ausschließlich Bibliotheken oder Funktionen zum Einsatz kommen, die eine ausreichende Ein- und Ausgabe-Validierung sicherstellen.

Control 7.8: Tool-Unterstützung

Es sollten Tools in den Build-Prozess eingebunden sein, die die Einhaltung der Implementierungsvorgaben prüfen und Aktionen bei Nichteinhaltung initiieren können.

Control 7.9: Auswahl von Sprachen und Technologien

Programmiersprachen und Technologien sollten stets im Rahmen einer Risikobewertung ausgewählt werden.

Control 7.10: Dokumentation aller Tools

Sämtliche im Implementierungsprozess zum Einsatz kommende Tools (Compiler, Build-Tools, Code-Checker etc.) müssen dokumentiert sein. Die Dokumentation muss stets auf einem aktuellen Stand sein, d. h., ins Patchmanagement eingebunden sein.

Control 7.11: Richtlinien für Code-Kommentierung

Kommentare im Quelltext sollten in Art und Anzahl so beschaffen sein, dass sie manuelles Code-Audit unterstützen können.

Control 7.12: Versionsstände von Tools

Für die Entwicklung verwendete Tools müssen stets für alle Entwickler eines Projekts auf demselben Versionsstand sein.


Galileo Computing - Zum Seitenanfang

6.4.8 Security-TestingZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Das Testen der fertigen Software durch verschiedene Methoden stellt eine zweite Sicherheitsstufe neben den vorgelagerten proaktiven Phasen Design und Implementierung dar. In Abhängigkeit von den jeweiligen Rahmenbedingungen sind verschiedene Formen der Testdurchführung angebracht.

Control 8.1: Code-Analyse

Entsprechend einer Policy klassifizierter Code sollte vor dem Release einer statischen Code-Analyse unterzogen werden.

Control 8.2: Binäranalyse

Es sollten Binäranalysen komplilierten Codes durchgeführt werden, um z. B. toten Code zu identifizieren oder um den Ablauf von Programmen zu verifizieren.

Control 8.3: Fuzzing

Exponierte Teile einer Applikation sollten mit Fuzzing-Werkzeugen auf Robustheit geprüft werden.

Control 8.4: Pentesting

Es sollten regelmäßig Penetrationstests entlang des Bedrohungskataloges aus dem Threat Modeling durchgeführt werden, um die Wirksamkeit implementierter Maßnahmen zu überprüfen.

Control 8.5: Ermitteln von Kennzahlen

Ergebnisse aus dem Security Testing sollten zur Auswertung von Sicherheitsmetriken verwendet werden.

Control 8.6: Richtlinien zum Security-Testing

Es sollte Richtlinien darüber geben, welche Teile einer Applikation mit welchen Methoden und in welchen Intervallen getestet werden.

Control 8.7: Externe Überprüfung

Pentests, Code-Audits, Binäranalysen und Fuzzing sollten periodisch durch externe Dienstleister durchgeführt werden, um eigene Erkenntnisse durch externe Expertise anzureichern.

Control 8.8: Automatisierte Schwachstellenanalyse

Sofern es möglich ist, sollten Applikationen parallel zu Penetration-Tests mit automatischen Schwachstellenscannern untersucht werden.

Control 8.9: Test-Methodik

Es sollte eine einheitliche Test-Methodik existieren, um die Nachvollziehbarkeit und Vergleichbarkeit von Test-Ergebnissen zu ermöglichen.

Control 8.10: Dokumentation von Test-Ergebnissen

Es sollten einheitliche Vorlagen für die Dokumentation von Test-Ergebnissen vorhanden sein. Die Test-Ergebnisse sollten zentral gesammelt und vor unbefugtem Zugriff geschützt aufbewahrt werden.


Galileo Computing - Zum Seitenanfang

6.4.9 DeploymentZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Sichere Software erfordert eine sichere Betriebsumgebung. Diese und der Weg der Software vom Entwicklungssystem auf die Betriebsplattform müssen durch geeignete Maßnahmen gesichert werden.

Control 9.1: Entfernen von Fehlerausgaben

Vor der Auslieferung sollten Fehlerausgaben so eingeschränkt werden, dass sie nur in Logfiles oder Datenbanken sichtbar sind, aber nicht vom Benutzer gesehen werden.

Control 9.2: Entfernen von Debug-Informationen

Bei nativer Software sollte der finale Build als Release erfolgen, und Debug-Informationen sollten entfernt werden.

Control 9.3: Installationshandbuch

Für die Installation von Software sollte ein Installationshandbuch vorhanden sein, das alle sicherheitsrelevanten Installationsparameter adressiert.

Control 9.4: Installationsprozess

Die Installation von Software auf einem Zielsystem sollte in den Schritten Release, Install, Activate, Adapt, Update erfolgen. Für jeden dieser Prozess-Schritte sollte eine angemessene Dokumentation vorhanden sein.

Control 9.5: Integrität von Software

Es sollte ein kryptografisches Verfahren eingesetzt werden, um die Integrität von Software auf dem Weg zur Zielplattform sicherzustellen.

Control 9.6: Schlüsselmanagement

Für betriebsrelevantes kryptografisches Schlüsselmaterial sollten angemessene Aufbewahrungsmöglichkeiten und organisatorische Prozesse vorhanden sein.

Control 9.7: Sichere Betriebsumgebung

Die Betriebsumgebung sollte Herstellervorgaben oder Best-Practice-Ansätzen gemäß für den Produktivbetrieb eingerichtet und gehärtet sein.

Control 9.8: Go-Live-Test

Vor der Freischaltung von Applikationen sollten diese einem Go-Live-Penetrationstest unterzogen werden. Dieser Test sollte für alle neuen Releases ebenso durchgeführt werden.


Galileo Computing - Zum Seitenanfang

6.4.10 Security ResponseZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Nach dem Ausrollen von Software ist der Umgang mit Sicherheitslücken elementarer Bestandteil des sicheren Entwicklungsprozesses. Bewertung, Beseitigung und Kommunikation von Sicherheitslücken müssen im Vorfeld definiert sein, um im Schadensfall unverzüglich und angemessen reagieren zu können.

Control 10.1: Response-Policy

Es sollte eine Response-Policy existieren, die den Umgang mit nach dem Release bekannt gewordenen Sicherheitslücken und die Kommunikation mit Kunden regelt.

Control 10.2: Umgang mit Sicherheitslücken

Bekannt gewordene Sicherheitslücken sollten je nach Schwere entweder umgehend über ein Emergency-Update oder in den regulären Wartungsprozess eingebunden werden. Maßgeblich für beide Varianten ist die Aufnahme als Security-Bug in ein Bugtracking-System.

Control 10.3: Ursachen von Sicherheitslücken

Bei jeder bekannt gewordenen Sicherheitslücke sollte ermittelt werden, welche Stelle des Entwicklungsprozesses dafür verantwortlich ist. Das Ergebnis der Untersuchung muss in den PDCA-Zyklus einfließen. Der Security-Advisor ist in diesen Prozess einzubeziehen.

Control 10.4: Erkennen von Sicherheitslücken

Rollen, die für das Annehmen von Bug-Reports zuständig sind, müssen ausreichend geschult sein, um Sicherheitslücken in Fehlermeldungen erkennen und entsprechend klassifizieren zu können.


Galileo Computing - Zum Seitenanfang

6.4.11 SicherheitsmetrikenZur nächsten ÜberschriftZur vorigen Überschrift

Objective: Die Definition von Metriken zum Messen der Effizienz von Sicherheitsmaßnahmen ermöglicht die Überprüfung der Prozessreife und eine Bewertung der Maßnahmen durch das Management.

Control 11.1: Definieren von Messgrößen

Es sollten Messgrößen definiert werden, mit denen sich die Wirksamkeit von Sicherheitsmaßnahmen im Entwicklungszyklus messen lässt.

Control 11.2: Kontinuierliche Auswertung

Die Auswertung von Messgrößen sollte regelmäßig geschehen, um eine kontinuierliche Überwachung des Prozesses zu gewährleisten.

Control 11.3: Identifizieren von Stakeholdern

Für alle erfassten Messgrößen sollte ein Stakeholder identifiziert werden, der für die Auswertung und das Ableiten von Maßnahmen verantwortlich ist.

Control 11.4: Eigenschaften von Messgrößen

Messgrößen sollten die folgenden Eigenschaften aufweisen: Zweckdienlich zur Verbesserung der Sicherheit im Entwicklungsprozess, objektiv, eindeutig, angemessen, einfach zugänglich für den jeweiligen Stakeholder.


Galileo Computing - Zum Seitenanfang

6.4.12 Abschließende BemerkungZur vorigen Überschrift

Bei allen Maßnahmen und Aktionen, die im Rahmen der Etablierung eines sicheren Software-Entwicklungsprozesses durchgeführt werden, bleibt das Ergebnis, die Software, immer nur eine Annäherung an ein sicheres Produkt. Software ist zu komplex, um fehlerfrei sein zu können, und ein optimal auf Sicherheit getrimmter Entwicklungsprozess wird eine Menge Sicherheitslücken vermeiden, aber keine Garantie für absolut sichere Software sein.

Interessanterweise gibt es Software, die als sicher gilt. Qmail ist ein gutes Beispiel dafür. Qmail ist ein MTA, ein Mail Transfer Agent, für Unix-Systeme und wurde von seinem Programmierer Dan Bernstein als Ersatz für das durch immer neue Sicherheitslücken geplagte Urviech Sendmail konzipiert. 1997 hat Dan Bernstein einen Preis von 500 USD für denjenigen ausgelobt, der eine Sicherheitslücke in Qmail nachweisen kann. Das ist bis heute niemandem gelungen.

Die Begründung, warum aus seiner Sicht Qmail so sicher ist, gibt Dan Bernstein in der Qmail Security Guarantee [31](http://cr.yp.to/qmail/guarantee.html). Die Kurzzusammenfassung lautet wie folgt:

  1. Programme und Dateien niemals als Adressen behandeln
  2. So wenig wie möglich mit setuid-Programmen arbeiten
  3. So wenig wie möglich als root arbeiten
  4. Funktionen in eigene, sich nicht vertrauende Programme auslagern
  5. Nicht parsen
  6. Design und Code einfach (übersichtlich) halten (Keep it simple, stupid!)
  7. Bugfreien Code schreiben
  8. Auch wenn diese sieben Argumente für die Sicherheit von Qmail nicht den Anschein eines sicheren Entwicklungsprozesses erwecken, sind sie jedoch alle in verschiedenen Controls des oben beschriebenen Anforderungskatalogs enthalten. Und da schließt sich der Kreis: Ein einzelner, fähiger und engagierter Programmierer kann auch ohne einen Prozess sichere Software schreiben. Das funktioniert auch in einem Team gleichartig engagierter und fähiger Programmierer. Allerdings ist das Ergebnis nur so lange gut, wie alle Beteiligten ihren Elan behalten, ihr Wissen auf dem neuesten Stand bleibt und sie sich an alle selbst gesteckten Vorgaben bezüglich Design und Implementierung halten. Um diese Voraussetzung dauerhaft zu schaffen, ist ein entsprechend gearteter Entwicklungsprozess notwendig.


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.







<< zurück
  Zum Katalog
Zum Katalog: Apps entwickeln für iPhone und iPad





Apps entwickeln für iPhone und iPad
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Objective-C 2.0 & Cocoa





 Objective-C 2.0
 Cocoa


Zum Katalog: Mac OS X Lion






 Mac OS X Lion


Zum Katalog: Mac OS X und UNIX






 Mac OS X
 und UNIX


Zum Katalog: Android 3






 Android 3


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: CSS






 CSS


Zum Katalog: jQuery






 jQuery


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de