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

Inhaltsverzeichnis
Geleitwort
Vorwort
1 Hello iPhone
2 Grundlagen
3 Views und Viewcontroller
4 Alles unter Kontrolle
5 Daten, Tabellen und Controller
6 Models, Layer, Animationen
7 Programmieren, aber sicher
8 Datenserialisierung und Internetzugriff
9 Jahrmarkt der Nützlichkeiten
A Sicherer Entwicklungszyklus
Stichwort

Download:
- ZIP, ca. 49,9 MB
Buch bestellen
Ihre Meinung?

Spacer
Apps programmieren für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das umfassende Handbuch
Buch: Apps programmieren für iPhone und iPad

Apps programmieren für iPhone und iPad
Galileo Computing
1000 S., geb., mit DVD
39,90 Euro, ISBN 978-3-8362-1915-0
Pfeil Sicherer Entwicklungszyklus
Pfeil A.1 Awareness
Pfeil A.2 Umgebung
Pfeil A.3 Training
Pfeil A.4 Dokumentation
Pfeil A.5 Requirements
Pfeil A.6 Design
Pfeil A.7 Implementierung
Pfeil A.8 Security-Testing
Pfeil A.9 Deployment
Pfeil A.10 Security Response
Pfeil A.11 Sicherheitsmetriken
Pfeil A.12 Abschließende Bemerkung

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 – 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.


Galileo Computing - Zum Seitenanfang

A.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 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.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Zum Katalog: Apps programmieren für iPhone und iPad

Apps programmieren für iPhone und iPad
Jetzt bestellen


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

 Buchempfehlungen
Zum Katalog: Einstieg in Objective-C 2.0 und Cocoa





 Einstieg in
 Objective-C 2.0
 und Cocoa


Zum Katalog: Apps entwickeln für iPhone und iPad - Videotraining






 Apps entwickeln für
 iPhone und iPad -
 Videotraining


Zum Katalog: Apps mit HTML5 und CSS3






 Apps mit HTML5
 und CSS3


Zum Katalog: iPhone- und iPad-Apps entwickeln






 iPhone- und
 iPad-Apps entwickeln


Zum Katalog: Android 4






 Android 4


Zum Katalog: Android-Apps entwickeln - Videotraining






 Android-Apps
 entwickeln -
 Videotraining


Zum Katalog: Windows Store Apps mit XAML und C#






 Windows Store Apps
 mit XAML und C#


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





Copyright © Galileo Press 2013
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