This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Germany/Projekte/Top 10 fuer Entwickler-2013/Nächste Schritte für Software-Entwickler
| ← A10-Ungeprüfte Um- und Weiterleitungen | Nächste Schritte für Projektleiter und Anwendungsverantwortliche → |
|
Etablierung und Nutzung umfassender Sicherheitsmaßnahmen
Unabhängig davon, ob man ein Neuling im Bereich der Webanwendungssicherheit ist, oder schon mit den erläuterten Gefahren vertraut ist – die Entwicklung einer neuen, sicheren Webanwendung, oder das Absichern einer bereits existierenden, kann sehr schwierig sein. Für die Betreuung eines großen Anwendungsportfolios mag das abschreckend wirken. Viele OWASP Ressourcen sind frei verfügbarUm Organisationen und Entwicklern dabei zu helfen, ihre Anwendungssicherheitsrisiken kostengünstig zu reduzieren, stellt die OWASP zahlreiche frei zugängliche Ressourcen zur Verbesserung der Anwendungssicherheit zur Verfügung. Im Folgenden werden einige dieser OWASP Ressourcen vorgestellt, die Organisationen helfen können, sichere Webanwendungen zu erstellen. Auf der nächsten Seite stellen wir einige OWASP Ressourcen vor, die Organisationen dabei helfen können Ihre Anwendungs-sicherheit zu überprüfen.
| |||||||||||
mögliche Erweiterung:
Comment: Hier werden zusätzliche Hinweise zusammengestellt. Z.B. auf Basis der BSI-Leitfäden zur Entwicklung sicherer Webanwendungen
- Anforderungen an die Anwendungssicherheit
- Anwendungs-Sicherheits-Architektur
- Standardisierte Sicherheitskontrollen
- Sicherer Entwicklungszyklus SDLC
- Anwendungs-Sicherheits-Ausbildung
Zunächst sind die durch die Anwendung zu verarbeitenden Daten zu definieren und deren Schutzbedarf festzulegen. Das Ziel der Schutzbedarfserhebung ist es zu ermitteln, in welchem Ausmaß die Webapplikation in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit geschützt werden muss, um in späteren Phasen daraus die Sicherheitsanforderungen, Maßnahmen sowie Audit-Pläne ableiten zu können. Die Grundwerte stellen jene Faktoren dar, die von Angriffen bedroht werden. In der Informationssicherheit sind drei fundamentale Grundwerte vorhanden: Vertraulichkeit, Integrität und Verfügbarkeit.</span>
Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Das Belauschen, eine Weitergabe oder Veröffentlichung von vertraulichen Informationen ist daher nicht erwünscht. Die Integrität von Daten gewährleistet deren Vollständigkeit und Unversehrtheit über einen bestimmten Zeitraum und ermöglicht die Aufdeckung einer Manipulation. Verfügbarkeit kann sich auf IT-Systeme oder Daten beziehen und fordert, dass sie zu definierten Zeiten, im Einklang mit der Vertraulichkeit und der Integrität, von Anwendern stets wie vorgesehen genutzt werden können.</span>
Die Grundwerte beziehen sich nicht ausschließlich auf Daten, sondern sollten ebenfalls auf Datenflüsse, Kommunikationskanäle oder ganze IT-Systeme umgelegt werden.</span>
Webanwendungen besitzen unterschiedliche Schutzbedürfnisse. Da diese in der Praxis meist nicht quantifizierbar sind, werden sie in drei Kategorien eingeteilt: „Normal“, „Hoch“ und „Sehr hoch“. Diese Definition entspricht den Begriffen des IT-Grundschutzes des BSI. Unter einem normalen Schutzbedarf sind Schadensauswirkungen begrenzt und überschaubar, während unter einem hohen bzw. sehr hohen Schutzbedarf die Schadensauswirkungen beträchtlich bzw. existenziell bedrohlich sein können. Diese Kategorien dienen als Entscheidungsgrundlage, welche Sicherheitsanforderungen für die jeweilige Webanwendung getroffen werden sollten.</span>
Um die Zuordnung zu einer der Kategorien zu erleichtern, können verschiedene Schadenszenarien betrachtet werden (z.B. ein Verstoß gegen Gesetze oder Vorschriften). Die Schadensszenarien fassen Schäden zusammen, die beim Eintreten einen Verlust eines Schutzzieles bedeuten. Die Webanwendung muss mindestens hinsichtlich der folgenden Schadensszenarien bewertet werden. Darüber hinaus – wenn notwendig – können weitere Schadensszenarien definiert oder es müssen die individuellen Gegebenheiten berücksichtigt werden. </span>
|
Anforderungen an die Anwendungssicherheit (1)
Tbd |
Anforderungen an die Anwendungssicherheit (2)
Tbd |
|
Anforderungen an die Anwendungssicherheit (3)
Tbd |
Referenzen
OWASP Andere |
Um eine Webanwendung möglichst sicher zu gestalten ist eine geeignete Sicherheitsarchitektur zu konzipieren. Hierbei spielen insbesondere die folgenden Aspekte eine zentrale Rolle:</span>
- Werden Designprinzipen angewendet?
- z.B. Seperation of Concerns: Ist jede Aufgabe einer und nur einer logischen Komponente zugeordnet?
- Wurden alle notwendigen Angriffsvektoren ermittelt und behandelt?
- Ist die Architektur vollständig in Bezug auf funktionale und nicht funktionale Sicherheitsanforderungen?
- Ist die Architekturbeschreibung auf dem aktuellen Stand und entspricht der vorliegenden Code-Basis?
- Wurden die wesentlichen Designentscheidungen durch Dokumentation explizit gemacht?
- Sind alle wesentlichen Entscheidungen nachvollziehbar?
- Qualität und Ausführlichkeit der Dokumentation
- Sind fachliche und technologische Aspekte getrennt adressiert?
- Ist die Anwendung über eine logische Komponentenbildung auf verschiedensten Ebenen strukturiert?
- Erfolgen der Datenfluss, der Steuerungsfluss und die Fehlerbehandlung durchgehend konsistent nach demselben Schema (zumindest innerhalb von Komponenten derselben Architektur-Ebene)?
- Wie gut erlaubt die Architektur die Erweiterbarkeit der Anwendung während der Wartung?
- Sind vorhandene Schnittstellen definiert und hinreichend dokumentiert?
Um die Sicherheit und damit auch die Qualität der Software zu erhöhen, ist es notwendig, während des gesamten Entwicklungszeitraums sicherheitsspezifische Tests durchzuführen. Je früher dabei Schwachstellen identifiziert werden, desto geringer fallen die zur Behebung notwendigen Kosten aus. Eine häufig verwendete Methodik ist die Verwendung von Security Gates. Security Gates stellen eine Form der innerhalb der Qualitätssicherung häufig verwendeten Quality Gates dar. Dabei handelt es sich um Meilensteine im Projekt, die nur unter Einhaltung definierter Sicherheits- bzw. Qualitätskriterien passiert werden dürfen. Security Gates werden häufig mit den Ergebnissen obligatorischer Sicherheitstests verknüpft. So ließe sich bestimmen, dass eine Anwendung vor dem Produktivgang einen Penetrationstest durchlaufen muss und durch diesen keine gravierenden Mängel identifiziert werden dürfen. Security Gates helfen damit, ein Mindestmaß an Sicherheit in einem Projekt umzusetzen. </span>
|
Konzeption und Planung
Am Ende der Konzeptions- und Planungsphase sollten folgende Dokumente erstellt worden sein, die vom Auftraggeber auf ihre Vollständigkeit zu prüfen sind:
|
Implementierungsphase
Während bzw. am Ende der Implementierungsphase sollten folgende Punkte geprüft werden:
|
|
Testphase
Erste Softwaretests finden bereits während der Entwicklungsphase statt. Speziell beim Einsatz agiler Entwicklungsmethoden sollte es zu jedem Ende eines Sprints möglich sein, die Ergebnisse der Testverfahren zu prüfen. Dabei muss sichergestellt werden, dass gefundene Schwachstellen und deren Behebung dokumentiert und nachvollziehbar sind.
Hierbei ist zwischen den folgenden Testarten zu unterscheiden:
|
Referenzen
OWASP Andere |
Software sicher zu entwickeln ist eine komplexe Herausforderung. Umso wichtiger ist daher eine strukturierte Herangehensweise, welche die notwendigen Aktivitäten sowie die Bewertungskriterien definiert und damit eine nachhaltige Berücksichtigung von Softwaresicherheit im Rahmen der Softwareentwicklung gewährleistet. Folglich werden in diesem Kapitel allgemeine Anforderungen definiert, die eine Organisation sowohl bei der Konzeption und Implementierung als auch bei der Verifikation von Sicherheit unterstützen.</span>
Mit fortschreitender Entwicklung steigen die Kosten für die Behebung von Fehlern gleichsam sprunghaft und deren Erkennungsrate geht zurück. Je eher eine Schwachstelle gefunden und behoben wird, desto weniger Kosten entstehen. Auch das Sicherheitsniveau einer Anwendung wird grundlegend in frühen Phasen deren Entwicklung bestimmt. Spätere Änderungen sind vergleichbar mit dem Versuch, einen Fehler im Rohbau eines Hauses im Nachhinein zu korrigieren.</span>
Da sicherheitsrelevante Entscheidungen im gesamten Lebenszyklus einer Webanwendung getroffen werden, leitet sich hieraus die Notwendigkeit ab, diese auch in jeder einzelnen Entwicklungsphase entsprechend zu berücksichtigen. Dies wird erreicht, indem über dem existierenden Vorgehensmodell zur Entwicklung ein Secure Development Lifecycle (SDL) definiert wird, der entsprechende Aktivitäten zur Erstellung bzw. Analyse der Sicherheit jeder einzelnen Phase, also eine Art sicheren Entwicklungsprozess, definiert.</span>
Natürlich sind Entwicklungsprozesse häufig sehr stark organisationsspezifisch ausgeprägt. Der SDL muss diese spezifische Art und Weise, wie eine Organisation Software entwickelt, gleichsam berücksichtigen, um zu funktionieren. Davon ist natürlich nicht nur dessen Einführung betroffen. Der Versuch von heute auf morgen einen vollumfänglichen Sicherheitsprozess einzuführen wird wahrscheinlich damit scheitern. Denn damit ist häufig auch die Umstellung eben dieser Art und Weise verbunden, mit der eine Organisation Software entwickelt und das geschieht in der Regel nicht von heute auf morgen.</span>
|
Reifegrade
Organisationen entwickeln auf teilweise sehr unterschiedliche Weise Software und auch in Bezug auf Sicherheit findet man große Unterschiede. Dies betrifft sowohl das aktuell erreichte Sicherheitsniveau als auch die angestrebten Sicherheitsziele. Diese Heterogenität zwischen den Organisationen muss berücksichtigt werden, wenn die Einführung von Sicherheitsaktivitäten (auch als „Sicherheitsinitiative“ bezeichnet) geplant und angegangen wird. Das Verständnis von Reifegraden ist dabei elementar. Solche Reifegrade beispielsweise von BSIMM und Open SAMM einbezogen. Der Gedanke ist dabei einfach: Jede Aktivität einer Phase des Entwicklungsprozesses besitzt einen bestimmten Reifegrad. Sowohl hinsichtlich des aktuellen Implementierungsgrades (Ist-Zustandes) als auch hinsichtlich gewünschter oder theoretisch denkbarer Ausprägungen (Soll-Zustand). Der Reifegrad einer Aktivität resultiert aus der Gesamtheit der Teilaktivitäten, die in dieser Aktivität durchgeführt werden. Nicht jedes Unternehmen besitzt die höchsten Sicherheitsanforderungen, und genau dies wird durch die Reifegrade berücksichtigt. Gleichwohl bieten Reifegrade auch die Möglichkeit, einen Secure Development Lifecycle (SDL) zu bewerten und Unzulänglichkeiten aufzudecken. Häufig haben Unternehmen etwa einen sehr hohen Reifegrad beim Security Testing, berücksichtigen den Bereich der konzeptionellen Sicherheit dagegen kaum. Bezieht man den Reifegrad auf den SDL, wird dabei die Gesamtheit der umgesetzten Aktivitäten (und deren Reifegrade) betrachtet. Reifegrade spielen auch bei der strukturierten Planung und Einführung von Aktivitäten in der Organisation eine entscheidende Rolle. Für die visuelle Darstellung der Reifegrade und insbesondere für die Darstellung deren gewünschter Entwicklung können Scorecards herangezogen werden. |
Scorecards
Zur Unterstützung der Umsetzung der sicheren Softwareentwicklung (insbesondere zur Anhebung des Reifegrades) können Scorecards herangezogen werden. Jede Phase des Entwicklungsprozesses wird mit einem Reifegrad anhand der umgesetzten Aktivitäten bewertet und in der Scorecard eingetragen. Zusätzlich wird in der Scorecard zu jeder Phase des Entwicklungsprozesses der angestrebte Ziel-Reifegrad eingetragen. Scorecards dienen in erster Linie der anschaulichen Darstellung des derzeitigen Reifegrades sowie des angestrebten Reifegrades. Sie können aber auch zur Gap Analyse (Gegenüberstellung des SOLL- und IST-Zustandes) sowie zu laufenden Messungen herangezogen werden. Der Unterschied zwischen IST und SOLL kann mit Unterstützung einer Roadmap geplant und nach erfolgreicher Umsetzung verringert werden. |
|
Roadmap
Jede Vorgehensweise muss für eine erfolgreiche und nachvollziehbare Umsetzung geplant werden. Die Planung für die Einführung von Sicherheit in der Softwareentwicklung kann mit Hilfe einer Roadmap erfolgen. Roadmaps definieren, wie der Reifegrad einer Phase iterativ angehoben werden kann. Hierbei werden bestimmte Aktivitäten in bestimmten Iterationen definiert und umgesetzt. Je nach Organisation kann die Anzahl der Iterationen variieren. Hier ein Beispiel für Iterationen, die häufig verwendet werden:
|
Referenzen
OWASP Andere |
Unter dem Begriff Awareness versteht man die Bewusstseinsbildung hinsichtlich Sicherheitsthemen. Alle an der Entwicklung einer Anwendung beteiligten Mitarbeiter müssen mit dem Thema Sicherheit konfrontiert werden. Das betrifft sowohl Entwickler als auch Projektmanager, Qualitätstester, Administratoren usw.</span>
Es muss sichergestellt werden, dass von jedem Mitarbeiter die Folgen von Sicherheitsmängeln sowie geltenden Anforderungen verstanden werden. Auch das Thema Datenschutz sollte in diesem Rahmen in ausreichendem Maße adressiert werden. Diese Bewusstseinsbildung erfolgt zumeist durch Schulungen.</span>
Diese Schulungen können sowohl von externen als auch interne Experten durchgeführt werden. Eine solche Veranstaltung kann abhängig von den spezifischen Erfordernissen entweder als mehrtägiger Workshop oder als computergestützter modularer Kurs aufgebaut werden. Der Inhalt sollte sowohl konzeptuelle als auch technische Informationen beinhalten. Die Ausgestaltung kann und sollte dabei unterschiedliche Zielgruppen angemessen adressieren. Einem Projektmanager muss in der Regel nicht das gleiche technische Verständnis vermittelt werden, wie dies etwa bei Entwicklern der Fall ist, insbesondere wenn diese mit der konkreten Implementierung von sicherheitsrelevanten Funktionen betraut worden sind. Ein grundlegendes Awareness-Training sollte für alle an der Entwicklung einer Webanwendung beteiligten Personen verpflichtend sein und periodisch durchgeführt werden. Neue Mitarbeiter sollen ein entsprechendes Training unmittelbar nach Firmeneintritt erhalten.</span>
| ← A10-Ungeprüfte Um- und Weiterleitungen | Nächste Schritte für Projektleiter und Anwendungsverantwortliche → |
