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

Difference between revisions of "Germany/Projekte/Top 10 fuer Entwickler-2013/Nächste Schritte für Software-Entwickler"

From OWASP
Jump to: navigation, search
m
m
Line 83: Line 83:
 
   
 
   
 
='''Anwendungs-Sicherheits-Architektur'''=   
 
='''Anwendungs-Sicherheits-Architektur'''=   
Tbd: weitere Infos hier, oder auf einer eigenen Seite (2)
+
Um eine Webanwendung möglichst sicher zu gestalten ist eine geeignete Sicherheitsarchitektur zu konzipieren. Hierbei spielen insbesondere die folgenden Aspekte eine zentrale Rolle:
 +
* 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?
  
 
='''Standardisierte Sicherheitskontrollen'''=   
 
='''Standardisierte Sicherheitskontrollen'''=   
Line 89: Line 102:
 
Security Gates helfen damit, ein Mindestmaß an Sicherheit in einem Projekt umzusetzen.
 
Security Gates helfen damit, ein Mindestmaß an Sicherheit in einem Projekt umzusetzen.
  
{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstLeft|title=Anforderungen an die Anwendungssicherheit (1)|year=2013|language=de}}  
+
{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstLeft|title=Konzeption und Planung|year=2013|language=de}}  
====Tbd====
+
Am Ende der Konzeptions- und Planungsphase sollten folgende Dokumente erstellt worden sein, die vom Auftraggeber auf ihre Vollständigkeit zu prüfen sind:
 +
* Liste der verwendeten Guidelines und Good Practices für das Softwaredesign
 +
* Objektmodell mit Datentypen, Datenklassifizierungen und Datenflüssen
 +
* Access Control Matrix bzw. Rollen und Berechtigungskonzepte
 +
* Abuse Cases
 +
* Bedrohungsmodellierung (Liste mit Zugangspunkten zur Applikation, Bedrohungsmodell mit Vertrauensgrenzen (Trust Boundaries), Liste identifizierter und bewerteter Bedrohungen, Liste mit begründeten Gegenmaßnahmen)
 +
* Liste aller Sicherheitsanforderungen
 +
* Detaillierte Testplanung
 +
* Planung von Quality Gates
 +
* Planung von Security Pushes
 +
* Software Security Metriken1
 +
* Sicherheitsarchitektur
 +
 
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=right|title=Anforderungen an die Anwendungssicherheit (2)|year=2013|language=de}}  
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=right|title=Anforderungen an die Anwendungssicherheit (2)|year=2013|language=de}}  
 
====Tbd====
 
====Tbd====

Revision as of 08:28, 1 July 2013

← Top_10_fuer_Entwickler/A10_Ungeprüfte Um- und Weiterleitungen
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top 10 fuer Entwickler/Nächste Schritte für Projektleiter und Anwendungsverantwortliche →

TEST-TEST TEST -- Seite in Bearbeitung (BAUSTELLE!!) Text noch von 2010 TEST-TEST TEST

Starten Sie jetzt mit Ihrem Anwendungssicherheits-Programm!

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ügbar

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


Anforderungen an die Anwendungssicherheit

Anwendungs-Sicherheits-Architektur

Standardisierte Sicherheitskontrollen
  • Die Entwicklung starker und anwendbarer Sicherheitskontrollen ist recht schwierig. Standardisierte Sicherheitskontrollen für Entwickler vereinfachen die Entwicklung sicherer Anwendungen. Das OWASP empfiehlt dazu das OWASP Enterprise Security API (ESAPI) Project - ein Modell, dass APIs zur Entwicklung sicherer Anwendungen zur Verfügung stellt. ESAPI unterstützt Implementierungen in Java, .NET, PHP, Classic ASP, Python, sowie Cold Fusion.

Sicherer Entwicklungszyklus (Secure Development Lifecycle SDLC)
  • Um den Prozess zur sicheren Anwendungserstellung in einer Organisation zu verbessern, empfiehlt OWASP das OWASP Software Assurance Maturity Model (SAMM). Das Modell hilft bei der Formulierung und Umsetzung einer Software-Sicherheitsstrategie, die spezifische Risiken der eigenen Organisation berücksichtigt.

Anwendungs-Sicherheits-Ausbildung


Es stehen zahlreiche weitere OWASP Ressourcen zur Verfügung. Besuchen Sie die OWASP Projects Seite, die eine Liste aller OWASP Projekte, organisiert nach dem Qualitätsstatus der einzelnen Veröffentlichungen (Veröffentlicht, Beta oder Alpha) enthält. Viele OWASP Ressourcen sind in unserem Wiki verfügbar und können auch in Papierformat bestellt werden.

mögliche Erweiterung:

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.

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.

Die Grundwerte beziehen sich nicht ausschließlich auf Daten, sondern sollten ebenfalls auf Datenflüsse, Kommunikationskanäle oder ganze IT-Systeme umgelegt werden.

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.

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.

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:

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

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:

  • Liste der verwendeten Guidelines und Good Practices für das Softwaredesign
  • Objektmodell mit Datentypen, Datenklassifizierungen und Datenflüssen
  • Access Control Matrix bzw. Rollen und Berechtigungskonzepte
  • Abuse Cases
  • Bedrohungsmodellierung (Liste mit Zugangspunkten zur Applikation, Bedrohungsmodell mit Vertrauensgrenzen (Trust Boundaries), Liste identifizierter und bewerteter Bedrohungen, Liste mit begründeten Gegenmaßnahmen)
  • Liste aller Sicherheitsanforderungen
  • Detaillierte Testplanung
  • Planung von Quality Gates
  • Planung von Security Pushes
  • Software Security Metriken1
  • Sicherheitsarchitektur
Anforderungen an die Anwendungssicherheit (2)

Tbd

Anforderungen an die Anwendungssicherheit (3)

Tbd

Referenzen

OWASP

Andere

Tbd: weitere Infos hier, oder auf einer eigenen Seite (4)

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.

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.

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.


← Top_10_fuer_Entwickler/A10_Ungeprüfte Um- und Weiterleitungen
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top 10 fuer Entwickler/Nächste Schritte für Projektleiter und Anwendungsverantwortliche →

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png