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 "OWASP Secure Software Contract Annex German"

From OWASP
Jump to: navigation, search
(Main)
 
(21 intermediate revisions by the same user not shown)
Line 19: Line 19:
 
Diese ergänzende Vertragsvereinbarung soll Softwareentwicklern und ihren Kunden helfen wichtige Vertragslaufzeiten und Vertragsbedingungen bezüglich der Sicherheit von Software, die entwickelt oder geliefert werden soll, zu verhandeln und festzuhalten.  
 
Diese ergänzende Vertragsvereinbarung soll Softwareentwicklern und ihren Kunden helfen wichtige Vertragslaufzeiten und Vertragsbedingungen bezüglich der Sicherheit von Software, die entwickelt oder geliefert werden soll, zu verhandeln und festzuhalten.  
  
Grund für dieses Projekt ist, daß die meisten Verträge keine Vereinbarungen zu diesem Thema enthalten, während die Parteien oftmals jedoch gravierend unterschiedliche Ansichten darüber haben, was tatsächlich vereinbart wurde.
+
Grund für dieses Projekt ist, dass die meisten Verträge keine Vereinbarungen zu diesem Thema enthalten, während die Parteien oftmals jedoch gravierend unterschiedliche Ansichten darüber haben, was tatsächlich vereinbart wurde.
  
Wir glauben, der beste Weg sicherzustellen, daß beiderseits eine sachgerechte Entscheidung über das weitere Vorgehen getroffen wird, ist diese Vertragsbedingungen klar und deutlich auszusprechen.
+
Wir glauben, der beste Weg sicherzustellen, dass beiderseits eine sachgerechte Entscheidung über das weitere Vorgehen getroffen wird, ist diese Vertragsbedingungen klar und deutlich auszusprechen.
  
  "Die Sicherheit von kommerzieller Software wird sich verbeßern, wenn der Markt bessere Sicherheit fordert.
+
  "Die Sicherheit von kommerzieller Software wird sich verbessern, wenn der Markt bessere Sicherheit fordert.
 
  Jede Angebotsanfrage für Software sollte an die Anbieter wenigstens die Frage enthalten, wie sie ihre Produkte
 
  Jede Angebotsanfrage für Software sollte an die Anbieter wenigstens die Frage enthalten, wie sie ihre Produkte
  auf Schwachstellen hin überprüfen. Diese Maßnahme wird ein erster Schritt sein Anbieter von Software
+
  auf Schwachstellen hin überprüfen. Diese Massnahme wird ein erster Schritt sein Anbieter von Software
  'von der Stange' und ausgegliederten Entwicklern davon zu überzeugen, daß Unternehmen Sicherheit wertschätzen."
+
  'von der Stange' und ausgegliederten Entwicklern davon zu überzeugen, dass Unternehmen Sicherheit wertschätzen."
 
       -- John Pescatore, Forschungsdirektor bei Gartner
 
       -- John Pescatore, Forschungsdirektor bei Gartner
  
Wir halten Kunden und Entwickler an, dieses Dokument als ein Rahmenkonzept für die Diskußion von Erwartungen und Verhandlung von Haftungsfragen zu nutzen. Diese ergänzenden Vertragsbedingungen sind dafür vorgesehen, einem Vertrag über die Entwicklung von Software beigefügt zu werden. Diese Bedingungen sind verhandlungsfähig, d.h. sie können und sollten von Kunden und Entwicklern erörtert werden.
+
Wir halten Kunden und Entwickler an, dieses Dokument als ein Rahmenkonzept für die Diskussion von Erwartungen und Verhandlung von Haftungsfragen zu nutzen. Diese ergänzenden Vertragsbedingungen sind dafür vorgesehen, einem Vertrag über die Entwicklung von Software beigefügt zu werden. Diese Bedingungen sind verhandlungsfähig, d.h. sie können und sollten von Kunden und Entwicklern erörtert werden.
  
 
==ÜBER DAS PROJEKT==
 
==ÜBER DAS PROJEKT==
  
Dieses Dokument wurde von der Open Web Application Security Project Stiftung (kurz: OWASP) erstellt. Die Stiftung ist eine gemeinnützige Organisation, die sich der Entwicklung freier und öffentlich zugänglicher Werkzeuge sowie der Dokumentation hinsichtlich sicherer Software gewidmet hat. Um den einfachen Gebrauch dieses Dokuments bei privaten Vertragßchlüßen zu erleichtern, wird es unter der CC Share Alike 3.0 license zur Verfügung gestellt. Sie können es anpaßen und verwenden, wie es Ihren Bedürfnißen entspricht. Ergänzende Details zu diesem Projekt können sie unter  http://www.owasp.com/index.php/OWASP_Legal_Project aufrufen. Wir begrüßen Rückmeldungen sowohl seitens Softwareherstellern sowie - verbrauchern als auch seitens der Rechtskreise.  
+
Dieses Dokument wurde von der Open Web Application Security Project Stiftung (kurz: OWASP) erstellt. Die Stiftung ist eine gemeinnützige Organisation, die sich der Entwicklung freier und öffentlich zugänglicher Werkzeuge sowie der Dokumentation hinsichtlich sicherer Software gewidmet hat. Um den einfachen Gebrauch dieses Dokuments bei privaten Vertragsschlüssen zu erleichtern, wird es unter der CC Share Alike 3.0 license zur Verfügung gestellt. Sie können es anpassen und verwenden, wie es Ihren Bedürfnissen entspricht. Ergänzende Details zu diesem Projekt können sie unter  http://www.owasp.com/index.php/OWASP_Legal_Project aufrufen. Wir begrüßen Rückmeldungen sowohl seitens Softwareherstellern sowie Verbrauchern als auch seitens der Rechtskreise.  
  
OWASP möchte sich an dieser Stelle ausdrücklich vielmals für die umfaßende Unterstützung durch Aspect Security während der Recherche und Vorbereitung für dieses Dokuments bedanken.
+
Das ursprüngliche, englischsprachige Projekt wurde von Jeff Williams mit Unterstützung von Aspect Security erstellt.
  
 +
Die hier vorliegende deutsche Version wurde von Mareike Zeisel von der LMU München übersetzt. Betreut wurde sie hierbei von Herrn Thomas Hofer, Akademischer Direktor des [http://www.jura.uni-muenchen.de/fakultaet/riz Rechtsinformatikzentrum der LMU München].
 +
Die OWASP-Projektleitung und technische Betreuung hat [https://www.owasp.org/index.php/User:Ralf_Reinhardt Ralf Reinhardt] übernommen. Er wird dabei durch Arbeitszeitfreistellung von der [http://www.sicsec.de sic(!)sec GmbH, Information Security Services] unterstützt.
  
 +
Aktueller Stand: Es liegt eine reine Übersetzung vor.
  
 +
Geplant  für die nächste Studienarbeit, bzw. Workshop am Rechtsinformatikzentrum: Juristische Würdigung und falls erforderlich Anpassung an deutsche Rechtsnormen.
  
== FOO ==
+
==EINWÄNDE==
 +
Die folgenden Seiten behandeln oft eingeführte Einwände gegen die Nutzung dieser Formulierungen in Zusammenhang mit Softwareentwicklungsverträgen
 +
 
 +
===ABER NICHT ALLE BESTIMMUNGEN TREFFEN AUF UNS ZU...===
 +
Dieses Dokument sollte als Ausgangspunkt Ihres Vertrages angesehen werden. Möglicherweise gefallen Ihnen nicht alle Maßnahmen oder Sie wollen Ihrem Vertragspartner mehr vorschlagen. Vielleicht wollen Sie Haftungsfragen anders regeln. Dieses Dokument beabsichtigt nicht exakt die Bedürfnisse jedes einzelnen Softwarekunden und Softwareentwicklers aufzugreifen. Es beabsichtigt vielmehr ein Rahmenkonzept bereitzustellen, an Hand dessen die Schlüsselthemen diskutiert werden können, die maßgeblich sind, um sicherzustellen, dass am Ende eine sichere Software herauskommt. Nach Ihrem Gespräch über die Softwaresicherheit und dem Treffen einer Vereinbarung, sollten Sie diese auf sich maß schneidern.
 +
 
 +
===ABER WER SOLL FÜR DIESE MASSNAHMEN ZAHLEN...===
 +
Bei diesem Vertrag geht es NICHT darum, den Softwareentwickler mehr zu belasten. Es stellt sich nicht die Frage, ob Sicherheit mit Kosten einhergeht - natürlich, lautet die Antwort. Die bessere Frage lautet eher, welche Maßnahmen beide Parteien ergreifen sollten, um diese Kosten zu senken und zu welchem Zeitpunkt.
 +
 
 +
Diese ergänzenden Vertragsbedingungen schweigen bewusst darüber, wer die Kosten dieser Maßnahmen tragen sollte. Während viele dieser Maßnahmen bereits greifen sollten, was auch von vielen Kunden erwartet wird, werden sie nicht regelmäßig von der Industrie angewandt. Die Frage danach, wer (und wie viel) zahlt, sollte Gegenstand der Verhandlung sein.
 +
 
 +
Kosten für Sicherheitsmaßnahmen zu berechnen, ist sehr schwierig. Einerseits gibt es Kosten, die auf der Ausführung von Sicherheitsmaßnahmen beruhen und andererseits entstehen erhebliche Kosten erst, wenn man Sicherheitsmaßnahmen unterlässt. Wir sind davon überzeugt, der kostengünstigste Weg, Software zu entwickeln, ist, die Wahrscheinlichkeit zu senken, dass Sicherheitslücken entstehen und die Zeit zwischen der Entstehung der Sicherheitslücke und ihrer Behebung zu minimieren.
 +
 
 +
Eine wichtige Unterscheidung, die bei der Kostenberechnung gemacht werden muss, ist jene zwischen der Herstellung eines Sicherheitsmechanismus und den Kontrollmaßnahmen für die Richtigkeit und Effektivität dieser Mechanismen selbst. Zu versuchen, am Ende der Laufzeit noch Vorrichtungen einzubauen, kann schwerwiegende Gestaltungsfragen aufwerfen und wird die Kosten in die Höhe schnellen lassen. Diese Vereinbarung ermutigt, bereits in einem frühen Planungsstadium Entscheidungen bezüglich solcher Mechanismen zu fällen, mit dem Ziel Kosten zu minimieren. Gleichermaßen treibt es die Kosten in die Höhe, wenn man bis kurz vor Bereitstellung der Software an den Kunden mit Kontrollmaßnahmen wie dem Codereview oder dem Penetrationstest wartet. Wir glauben, der beste Weg Sicherheit zu erreichen, ist, sich während der gesamten Laufzeit um Sicherheit zu bemühen.
 +
 
 +
===ABER DAS ANFORDERUNGSNIVEAU IST ZU LASCH===
 +
Diese Vereinbarung geht davon aus, dass die Software, die entwickelt wird, für ein großes Unternehmen oder eine staatliche Behörde ziemlich wichtig ist. Wir haben diese Vereinbarung auf ein Anforderungsniveau gestützt, das von den meisten Softwareentwicklungsorganisationen erreicht werden kann und das die häufigsten Risiken genau bestimmt und behandelt.
 +
 
 +
Jedoch ist es möglich, dass man das Anforderungsniveau für Software, die in entscheidenden Anwendungen eingesetzt werden wird, anheben möchte. Dies trifft z.B. auf Software aus dem Bereich Medizin-, Finanz- oder Verteidigungswesen zu. Man könnte möglicherweise zusätzliche Überprüfungen, Dokumentationen und Versuche anfertigen und durchführen. Man möchte möglicherweise die zum zum Auffinden, Diagnostizieren und Beseitigen von Schwachstellen notwendigen Verfahren verbessern. Bei weniger sensiblen Anwendungen, könnte man solche Maßnahmen verringern oder entfernen wollen.
 +
 
 +
===ABER SO VIEL KÖNNEN WIR NICHT RISKIEREN===
 +
Dieses Vertragswerk soll Diskussionen darüber, wer das Risiko für Schwachstellen in der Softwaresicherheit auf sich nehmen muss, erleichtern. Am einen Ende der Bandbreite könnte der Kunde alle Risiken tragen während der Entwickler Codes mit einer Menge Schwachstellen liefern könnte. Am anderen Ende könnte der Entwickler alle Risiken auf sich nehmen und die Verantwortung für einen perfekt abgelieferten Code übernehmen. Beide Extreme sind nicht handhabbar.
 +
 
 +
Gegenwärtig, in diesem Vertragswerk, trägt der Entwickler die Risiken von Problemen, die in den Bestimmungen erfasst worden sind oder vernünftigerweise von Probeläufen abgedeckt werden sollten. Dennoch muss die Korrektur "neuartiger" Sicherheitsprobleme vom Kunden bezahlt werden. Wir denken, das ist ein zweckmäßiger Ausgleich, denn der Entwickler kann sein Risiko beschränken und ermutigt den Kunden die Sicherheitsanforderungen bereits im Vorfeld korrekt umzusetzen. Viele andere Lösungen für dieses Problem sind möglich. Bitte teilen Sie uns Ihre alternativen Vorschläge mit, damit wir sie in zukünftige Versionen dieses Dokuments einarbeiten können.
 +
 
 +
Bitte nehmen Sie zur Kenntnis, dass diese Diskussion nur die Risiken, verbunden mit dem Schließen der Sicherheitslücken im Code, abdeckt. Diese Diskussion behandelt ausdrücklich nicht die Kosten, die mit der Entdeckung irgendeines Sicherheitsvorfalls, basierend auf der Ausnutzung solcher Schwachstellen, entstehen. Wir sind an den besten Geschäftsabläufen/ Best Practices auf diesem Gebiet interessiert.
 +
 
 +
===ABER WIE KÖNNEN WIR DEN CODE EINES DRITTEN ABSICHERN...===
 +
Fast alle Softwareprojekte verwenden in beträchtlichem Umfang Code Dritter, solche wie libraries und frameworks. Dieser Code ist unter dem Aspekt Sicherheit genauso wichtig wie der speziell für Ihr Projekt entwickelte Code des Kunden. Wir glauben, dass die Verantwortung zur Sicherstellung der Sicherheit des Codes am besten vom Entwickler getragen wird, obwohl er möglicherweise nicht in vollem Umfang diese Sicherheit gewährleisten kann. Jedoch muss Sicherheit ein Teil der Build-or-Buy-Entscheidung sein. Das scheint der beste Weg zu sein, den Sicherheitsaspekt zu fördern.
 +
 
 +
Dem Entwickler ist es selbstverständlich möglich, die Verantwortung bis zum Anbieter der Software des Dritten durch zureichen. Der Entwickler kann die Software des Dritten sogar selbst analysieren oder Sicherheitsexperten engagieren, um sie analysieren zu lassen.
 +
 
 +
===ABER WARUM SOLL ICH MIR ALL DIESE MÜHE MACHEN...===
 +
Schlussendlich glauben wir, dass es keine Alternative dazu gibt, Sicherheit zu einem Thema in den Softwarevertragsverhandlungen zu machen. Momentan sind wir der Meinung, dass im Rahmen von Softwareentwicklungsverträgen, die die Auslieferung von Software zum Ziel haben, ernsthafte Missverständnisse über die Code-Sicherheit auftreten. Das kann nur in teuren Rechtsstreits und Entscheidungen enden, die von Personen mit lediglich wenig Erfahrungen mit oder Verständnis für Software getroffen werden. Eine ausführliche Auseinandersetzung mit diesem Thema können Sie hier nachlesen: [[Secure software contracting hypothetical case study]]
 +
 
 +
Aus dem Durcharbeiten dieses Vertrages kann man viel Nutzen ziehen. An erster Stelle werden die Erwartungen zwischen den beteiligten Parteien klar herausgestellt. In einigen Fällen kann dadurch Klagewellen vorgebeugt werden, sobald komplizierte Sicherheitsprobleme in der Software zum Vorschein kommen. Außerdem sind das dieselben Maßnahmen, die aus vielen Gründen im Bereich der Rechtssicherheit und Regelüberwachung gefordert werden.
 +
 
 +
===ABER ES IST VIEL ZU MÜHSELIG ALL DAS ZU DOKUMENTIEREN...===
 +
OWASP animiert nicht zum Dokumentieren um des Dokumentierens Willen. Dieses Vertragswerk wurde darauf ausgerichtet, Qualität zu fördern, nicht Quantität.  Wir glauben,  eine kurze Risikobewertung, ein paar Seiten mit Anforderungen, ein kurzes Dokument mit dem Sicherheitsentwurf, ein Testplan und einige Testergebnisse, würden - bei einigen bestimmten Projekten - einem solchen Vertrag Genüge tun.
 +
 
 +
Das Ziel dieses Dokuments ist, zu jedem Zeitpunkt der Laufzeit einfach sicherzustellen, dass dem Punkt Sicherheit die nötige Aufmerksamkeit gewidmet wurde. Als zusätzlicher Nutzen erweist sich, dass diese Dokumentation zusammengefasst als "Zertifikatspaket" dienen kann. Dieses beweist wesentlich, warum darauf vertraut werden kann, dass die Software arbeitet, wie sie es vorgibt.
 +
 
 +
==VERTRAGSANHANG==
 +
 
 +
===1. Einleitung===
 +
 
 +
Dieser Anhang wurde erstellt für ______________________ ("Vereinbarung") zwischen Kunde und Entwickler. Der Kunde und der Entwickler erklären sich bereit, die Sicherheit der Software in Übereinstimmung mit den folgenden Bestimmungen zu maximieren.
 +
 
 +
===2. Philosophie===
 +
 
 +
Dieser Anhang soll die sicherheitsbezogenen Rechte und Pflichten aller Beteiligten an einem Softwareentwicklungsverhältnis klären.
 +
 
 +
;(a) Sicherheitsentscheidungen werden auf Grundlage von Risikoerwägungen getroffen: Entscheidungen über die Sicherheit werden gemeinsam von Kunde und Entwickler, gestützt  auf ein festes Verständnis der damit verbundenen Risiken, gefällt.
 +
 
 +
;(b) Sicherheitsmaßnahmen werden ausgeglichen: Sicherheitsleistungen werden annähernd gleichmäßig auf die gesamte Laufzeit der  Softwareentwicklung verteilt.
 +
 
 +
;(c) Sicherheitsmaßnahmen werden eingebunden: Alle hier behandelten Maßnahmen und Dokumentationen können und sollen während der  Laufzeit der Softwareentwicklung seitens des Entwicklers einbezogen und nicht getrennt  vom Rest des Projekts bearbeitet werden. Keine Bestimmung dieses Anhangs impliziert  einen bestimmten Softwareentwicklungsprozess.
 +
 
 +
;(d) Schwachstellen werden erwartet: Jede Software hat Bugs (Programmfehler) und einige von diesen werden  Sicherheitsprobleme verursachen. Sowohl Kunde als auch Entwickler werden bemüht sein,  Schwachstellen so früh als möglich während der Laufzeit zu identifizieren.
 +
 
 +
;(e) Sicherheitsinformationen werden vollständig offengelegt: Alle sicherheitsrelevanten Informationen werden zwischen dem Kunden und dem  Entwickler unmittelbar und vollständig freigegeben.
 +
 
 +
;(f) Ausschließlich nützliche Sicherheitsdokumentation ist erforderlich: Sicherheitsdokumentation muss nicht umfangreich sein, um eindeutig das  Sicherheitsdesign, Risikoanalysen oder Probleme zu beschreiben.
 +
 
 +
===3. Maßnahmen zur Lebensdauer===
 +
 
 +
;(a) Risikoverständnis: Entwickler und Kunde erklären sich bereit, zusammenzuarbeiten, um die Risiken angesichts  der Anwendung (application) zu verstehen und zu dokumentieren. Dieser Aufwand soll die  Hauptrisiken für das Daten (assets) und die Funktionen, bereitgestellt durch die  Anwendung (application), identifizieren. Jeder der in der Liste der Anforderungen  aufgelisteten Punkte sollte in Betracht gezogen werden.
 +
 
 +
;(b) Anforderungen: Basierend auf den Risiken kommen Entwickler und Kunde darüber ein,  zusammenzuarbeiten, um detaillierte Sicherheitsvorschriften als Teil des Leistungsumfangs  der zu entwicklenden Software zu entwerfen. Jeder im Teil über die Sicherheitsvorschriften  aufgelistete Punkt dieses Anhangs sollte diskutiert und sowohl vom Entwickler wie vom  Kunden beurteilt werden. Diesen Anforderungen kann durch Kundensoftware, Drittsoftware  oder das Programm entsprochen werden.
 +
 
 +
;(c) Entwurf: Entwickler stimmt zu, Unterlagen bereitzustellen, die klar und deutlich den Plan zur Erreichung jeder einzelnen Sicherheitsanforderung erklären. In den meisten Fällen wird  diese Dokumentation Sicherheitsmechanismen beschreiben, wobei die Mechanismen sich in  die Struktur und alle relevanten Entwurfsmuster einfügen, um ihren ordnungsgemäßen  Gebrauch zu gewährleisten. Der Entwurf sollte zweifellos festlegen, ob der Support von  eigener Software, Drittanbietersoftware oder dem Betreiber zur Verfügung gestellt wird.
 +
 
 +
;(d) Umsetzung: Entwickler verpflichtet sich, eine Reihe von sicheren Codierungsrichtlinien bereitzustellen  und zu befolgen sowie eine Reihe gemeinsamer Programmierschnittstellen zur  Sicherheitskontrolle zu verwenden (wie z.B. die [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API (ESAPI)]). In Richtlinien wird festgelegt, wie Codes formatiert,  strukturiert und kommentiert werden sollen. Gemeinsame Programmierschnittstellen zur  Sicherheitskontrolle werden festlegen, wie Sicherheitskontrollen abgerufen werden und  ablaufen müssen. Jeglicher sicherheitsrelevanter Code muss gründlich kommentiert werden.  Spezifische Leitlinien für die Vermeidung von häufigen Sicherheitslücken sollen darin  enthalten sein. Außerdem wird der gesamte Code von mindestens einem anderen Entwickler  mit den Sicherheitsanforderungen verglichen und an Hand der Codierungsleitlinien  überprüft, bevor er als bereit für den Unit-Test erachtet wird.
 +
 
 +
;(e) Sicherheitsanalyse und Prüfung: Entwickler wird die Analyse der Anwendungssicherheit und die Überprüfung (auch "Verifizierung" genannt) nach den Prüfanforderungen eines vereinbarten Standards (wie z.B. dem  [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)]) durchführen. Der Entwickler  muss Erkenntnisse aus der Überprüfung nach den standardmäßigen Anforderungen an  Berichte dokumentieren. Entwickler soll die Erkenntnisse aus der überprüfung dem Kunden  zur Verfügung stellen.
 +
 
 +
;(f) Sichere Bereitstellung: Entwickler verpflichtet sich, sichere Konfigurationsrichtlinien zur Verfügung zu stellen, die  alle sicherheitsrelevanten Konfigurationsoptionen und deren Auswirkungen auf  die  allgemeine Sicherheit der Software vollständig beschreiben. Die Richtlinie enthält eine  vollständige Beschreibung der Abhängigkeiten von der Trägerplattform, einschließlich  Betriebssystem, Webserver und Anwendungsserver, und wie sie für die Sicherheit  konfiguriert werden sollten. Die Standardkonfiguration der Software sollte sicher sein.
 +
 
 +
===4. Themenbereich Sicherheitsanforderungen===
 +
 
 +
Die folgenden Themenbereiche müssen beim übereinkommen über das Risiko und der Definition der Anforderungen an Maßnahmen berücksichtigt werden. Diese Bemühungen sollten eine Reihe spezifischer, maßgeschneiderter und überprüfbarer Anforderungen hervorbringen. Sowohl Entwickler als auch Kunde sollten in diesen Prozess einbezogen werden und müssen ein finales Anforderungenwerk vereinbaren.
 +
 
 +
;(a) Eingabeüberprüfung und Encoding: Die Anforderungen sollen die Regeln festlegen, nach denen jegliche Eingabe in die Anwendung, ob von seiten der Benutzer, Dateisysteme, Datenbanken, Verzeichnisse oder externer Systeme, in eine vorschriftsmäßige Form gebracht, validiert oder kodiert werden kann. Standardmäßig soll jede Eingabe ungültig sein, wenn sie keiner detaillierten Spezifikation entspricht, die festlegt, was erlaubt ist. Darüber hinaus sollen die Anforderungen angeben, welche Maßnahmen ergriffen werden sollen, wenn ungültige Eingaben gemacht werden. Im Besonderen soll die Anwendung nicht anfällig für Injektionen, überlauffunktionen, Beschädigungen oder andere unlautere Angriffe bei der Eingabe sein.
 +
 
 +
;(b) Authentifizierung und Session Management: Die Anforderungen sollen angeben, wie Anmeldeinformationen und Sitzungs-IDs während  ihrer gesamten Lebensdauer geschützt werden. Anforderungen für alle damit verknüpften  Funktionen, einschließlich vergessener Passwörter, dem ändern von Kennwörtern, sich  Merken von Passwörtern, der Abmeldung und mehrerer Logins, sind aufzustellen.
 +
 
 +
;(c) Zugangskontrolle: Die Anforderungen umfassen eine detaillierte Beschreibung aller in der Anwendung  verwendeten Rollen (Gruppen, Berechtigungen, Autorisierungen). Die Anforderungen sollen  auch alle Vermögenswerte und Funktionen bezeichnen, die die Anwendung bietet. Die  Anforderungen werden vollständig die genauen Zugriffsrechte auf jeden Vermögenswert und  Funktion für jede Rolle festlegen.
 +
 
 +
;(d) Fehlerbehandlung: Die Anforderungen sollen ausführlich beschreiben, wie während der Verarbeitung  auftauchende Fehler behandelt werden. Einige Anwendungen sollten im Falle eines Fehlers  Ergebnisse nach größten Bemühungen bieten, während andere die Verarbeitung sofort  beenden sollten.
 +
 
 +
;(e) Protokollierung: Die Anforderungen sollen angeben, welche Ereignisse sicherheitsrelevant sind und  protokolliert werden müssen, wie beispielsweise aufgedeckte Angriffe, fehlgeschlagene  Anmeldeversuche, und Versuche, seine Autorisierung zu überschreiten. Die Anforderungen  sollen auch festlegen, welche Information mit jedem Ereignis zu protokollieren ist,  einschließlich Datum und Uhrzeit, Ereignisbeschreibung, Anwendungsdetails und andere  Informationen, die bei forensischen Bemühungen nützlich sind.
 +
 
 +
;(f) Anbindungen an externe Systeme: Die Anforderungen sollen beschreiben, wie die Authentifizierung und die Verschlüsselung  für alle externen Systeme, wie Datenbanken, Verzeichnisse und Web-Services, gehandhabt  werden. Alle Anmeldeinformationen, die für die Kommunikation mit externen Systemen  erforderlich sind, müssen außerhalb des Codes in einer Konfigurationsdatei in  verschlüsselter Form gespeichert werden.
 +
 
 +
;(g) Verschlüsselung: Die Anforderungen sollen angeben, welche Daten verschlüsselt werden müssen, wie die  Verschlüsselung vorzunehmen ist, und wie alle Zertifikate und andere  Anmeldeinformationen behandelt werden müssen. Die Anwendung soll einen  Standardalgorithmus nutzen, der in eine weit verbreitete und getestete  Verschlüsselungsbibliothek implementiert wurde.
 +
 
 +
;(h) Verfügbarkeit: Die Anforderungen sollen angeben, wie vor Angriffen durch Dienstverweigerung geschützt  wird. Alle wahrscheinlichen Angriffe auf die Anwendung müssen in Betracht gezogen  werden, einschließlich Authentifizierungsperre, Anschlussüberlastung und andere Angriffe  durch Ressourcenüberlastung.
 +
 
 +
;(I) Sichere Konfigurierung: Die Anforderungen sollen festlegen, dass die Standardwerte für alle sicherheitsrelevanten  Konfigurationsoptionen sicher sind. Für Prüfungszwecke sollte die Software in der Lage  sein,  einen leicht lesbaren Bericht auszugeben, der alle sicherheitsrelevanten  Konfigurationsdetails enthält.
 +
 
 +
;(j) Besondere Schwachstellen: Die Anforderungen umfassen eine Reihe spezifischer Schwachstellen, die nicht in der  Software gefunden werden sollen. Falls nicht anders angegeben, wird die Software keine der  in der aktuellen Version des "OWASP Top Ten Most Critical Web Application  Vulnerabilities" beschriebenen Mängel enthalten.
 +
 
 +
===5. Personal und Organisation===
 +
 
 +
;(a) Sicherheitsarchitekt: Entwickler wird die Verantwortung für die Sicherheit auf eine einzige leitende technische  Ressource übertragen, bekannt als der projekteigene Sicherheitsarchitekt. Der Sicherheitsarchitekt wird die Sicherheit jedes Liefergegenstandes zertifizieren.
 +
 
 +
;(b) Sicherheitstraining: Es liegt in der Verantwortung des Entwicklers zu gewährleisten, dass alle Mitglieder des  Entwicklerteams in sicheren Programmiertechniken geschult wurden.
 +
 
 +
;(c) Vertrauenswürdige Entwickler: Entwickler verpflichtet sich, angemessene Hintergrundrecherchen zu allen Mitgliedern im  Entwicklerteam anzustellen.
 +
 
 +
===6. Entwicklungsumgebung===
 +
 
 +
;(a) Sichere Programmierung: Der Entwickler muss offenlegen, welche Werkzeuge in der Entwicklungsumgebung verwendet  werden, um eine sichere Programmierung zu fördern.
 +
 
 +
;(b) Konfigurationsmanagement: Der Entwickler soll mit einem Quellcodeverwaltungssystem arbeiten, das die Team- Mitglieder authentifiziert und protokolliert. Insbesondere mit allen änderungen an der Grundsoftware sowie  den dazugehörigen Konfigurationen. Das System soll außerdem  Dateien bilden.
 +
 
 +
;(c) Verteilung: Der Entwickler hat einen Build-Prozess zu verwenden, der zuverlässig eine vollständige  Distribution aus dem Quellcode erstellt. Dieser Prozess muss eine Methode zur überprüfung  der Integrität der dem Kunden gelieferten Software vorsehen.
 +
 
 +
===7. Programmbibliotheken, Frameworks und Produkte===
 +
 
 +
;(a) Offenlegung: Entwickler soll jede Drittanbietersoftware, die in der Software verwendet wird,  einschließlich, Programmbibliotheken, Frameworks, Komponenten und andere Produkte,  egal ob kommerziell, frei, open-source oder closed-source, offenlegen.
 +
 
 +
;(b) Evaluation: Entwickler muss alle zumutbaren Anstrengungen unternehmen, um sicherzustellen, dass  Software von Drittanbietern alle Bedingungen dieses Vertrages erfüllt und genauso sicher  wie der kundenspezifisch entwickelte Code ist, der nach dieser Vereinbarung entwickelt  wurde.
 +
 
 +
===8. Sicherheitsüberprüfung===
 +
 
 +
;(a) Recht auf überprüfung: Kunde hat das Recht, die Software jederzeit innerhalb von 60 Tagen ab Lieferung auf  Sicherheitslücken überprüfen zu lassen. Entwickler verpflichtet sich das  Review-Team  durch die Bereitstellung von Quellcode und den Zugang zu Testumgebungen  angemessen zu unterstützen.
 +
 
 +
;(b) Prüfbericht: Sicherheitsüberprüfungen werden alle Aspekte der gelieferten Software abdecken,  einschließlich benutzerdefinierter Codes, Komponenten, Produkte und  Systemkonfiguration.
 +
 
 +
;(c) Prüfungsumfang: Die überprüfung soll wenigstens alle Sicherheitsanforderungen abdecken und nach anderen  üblichen Schwachstellen suchen. Die überprüfung kann eine Kombination von  Schwachstellen-Scans, Penetrationstests, statischen Analysen des Quellcodes und Experten- Codereview umfassen.
 +
 
 +
;(d) Entdeckte Fehler: Aufgedeckte Sicherheitsprobleme werden sowohl dem Kunden als auch dem Entwickler  gemeldet. Alle Probleme werden aufgespürt und beseitigt, wie im Abschnitt dieses  Vertragsanhangs über Sicherheitsproblemmanagement vorgesehen.
 +
 
 +
===9. Sicherheitsproblemmanagement===
 +
 
 +
;(a) Identifizierung: Entwickler wird alle Sicherheitsprobleme während der gesamten Lebensdauer verfolgen,  egal ob es sich um Probleme mit den Anforderungen, der Gestaltung, der Implementierung,  den Tests, der Bereitstellung oder dem Betrieb handelt. Das mit jeder Sicherheitslücke  verbundene Risiko wird ausgewertet, dokumentiert und dem Kunden so früh als möglich  nach der Entdeckung berichtet.
 +
 
 +
;(b) Schutz: Entwickler wird in geeigneter Weise Informationen bezüglich Sicherheitsfragen und die  dazugehörigen Unterlagen schützen, um die Wahrscheinlichkeit zu begrenzen, dass  Schwachstellen in der Betriebskundensoftware enthüllt werden.
 +
 
 +
;(c) Wiederherstellung: Sicherheitsprobleme, die vor der Lieferung identifiziert werden, sollen vom Entwickler behoben werden. Sicherheitsprobleme, die nach der Lieferung entdeckt werden, sollen in der gleichen Weise wie dieser Vertrag es für andere Bugs und Probleme festlegt, behandelt werden.
 +
 
 +
===10. Garantie===
 +
 
 +
;(a) Garantie: Entwickler wird ein "Zertifizierungspaket" anbieten, bestehend aus der  Sicherheitsdokumentation, die im Verlauf des gesamten Entwicklungsprozesses erstellt  wurde. Das Paket sollte nachweisen, dass die Sicherheitsanforderungen, die Gestaltung, die  Implementierung und die Testergebnisse ordnungsgemäß umgesetzt und erfasst und alle  Sicherheitsprobleme in geeigneter Weise gelöst wurden.
 +
 
 +
;(b) Selbstzertifizierung: Der Sicherheitsarchitekt wird bescheinigen, dass die Software die Sicherheitsanforderungen  erfüllt, alle Sicherheitsmaßnahmen durchgeführt worden sind, und alle aufgefundenen  Sicherheitsprobleme dokumentiert und gelöst wurden. Ausnahmen vom Zertifizierungsstatus  sollen in vollem Umfang bei Lieferung dokumentiert werden.
 +
 
 +
;(c) Kein schädlicher Code: Entwickler garantiert, dass die Software keinen Code enthält, der eine Anforderung an die  Software nicht unterstützt und die Sicherheit der Anwendung schwächt, einschließlich  Computerviren, Würmern, Zeitbomben, Hintertüren, Trojaner, Easter eggs, und allen  anderen Formen von bösartigem Code.
 +
 
 +
===11. Sicherheitsabnahme und Erhaltung===
 +
 
 +
;(a) Abnahme: Die Software darf nicht als abgenommen angesehen werden, bis das Zertifizierungspaket  vollständig vorliegt und alle Sicherheitsprobleme behoben wurden.
 +
 
 +
;(b) Untersuchung von Sicherheitsproblemen: Falls nach der Abnahme Sicherheitsprobleme entdeckt werden oder der begründete Verdacht  besteht, soll der Entwickler dem Auftraggeber bei der Durchführung einer Untersuchung  behilflich sein, um die Art des Problems festzustellen. Das Problem soll als "neuartig"  angesehen werden, falls es nicht durch die Sicherheitsanforderungen abgedeckt wird und  außerhalb des  angemessenen Umfangs der Sicherheitsüberprüfung liegt.
 +
 
 +
;(c) Neuartige Sicherheitsprobleme: Entwickler und Kunde vereinbaren, die für die Behebung neuartiger Sicherheitsprobleme anzustrengenden Bemühungen gründlich zu betrachten und nach Treu und Glauben zu verhandeln, um eine Vereinbarung über die Durchführung der erforderlichen Arbeiten zu ihrer Bewältigung zu erreichen.
 +
 
 +
;(d) Andere Sicherheitsprobleme: Entwickler hat sämtliche wirtschaftlich vernünftige Anstrengungen, im Einklang stehend mit fehlerfreien Softwareenticklungsverfahren, zu ergreifen, und dabei die Schwere des Risikos zu berücksichtigen, um so schnell wie möglich alle Sicherheitsprobleme zu beheben, die nicht  als neuartig betrachtet werden.
  
 
== What is OWASP Security Principles Project? ==
 
== What is OWASP Security Principles Project? ==
Line 49: Line 211:
 
</span>
 
</span>
  
The end goal is to identify, cite, and document the fundamental principles of information security. Once this is well organised, I think it would be great to publish this through the [http://scriptogr.am/dennis-groves/post/owasp-press OWASP Press]. Of course, it will always remain freely available, and any money collected will go directly into the project to absorb costs with any remaining funds going to the OWASP Foundation.
+
//TODO
 
 
This document should serve as a guide to technical architects and designers outlining the fundamental principles of security.
 
  
 
== Presentation ==
 
== Presentation ==
  
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
+
[https://www.owasp.org/index.php/German_OWASP_Day_2015 German OWASP Day 2015] [https://www.owasp.org/images/b/b6/OWASP_Secure_Software_Contract_Annex_auf_Deutsch_-_Ralf_Reinhardt.pdf]
<span style="color:#ff0000">
 
This is where you can link to slide presentations related to your project.  
 
</span>
 
 
 
 
 
AppSec USA 2013 [https://github.com/OWASP/Security-Principles/tree/master/Presentations/AppSec%20NYC%202013]
 
  
 
== Project Leader ==
 
== Project Leader ==
  
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 +
<!--
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
A project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.
+
A project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project's progress to the OWASP Foundation, and he/she is ultimately responsible for the project's deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.
 
</span>
 
</span>
 +
-->
 +
* Thomas Hofer, Akademischer Direktor des Rechtsinformatikzentrum der LMU München
 +
* [https://www.owasp.org/index.php/User:Ralf_Reinhardt Ralf Reinhardt]
 +
* Translation initially done by Mareike Zeisel
  
* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves]
+
<!--
 
 
 
 
 
== Related Projects ==
 
== Related Projects ==
 
+
-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 +
<!--
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
 
This is where you can link to other OWASP Projects that are similar to yours.  
 
This is where you can link to other OWASP Projects that are similar to yours.  
 
</span>
 
</span>
 
 
* [[OWASP_CISO_Survey]]
 
* [[OWASP_CISO_Survey]]
 
+
-->
 +
<!--
 
== Openhub ==
 
== Openhub ==
 
 
* [https://www.openhub.net/orgs/OWASP OWASP Project Openhub]
 
* [https://www.openhub.net/orgs/OWASP OWASP Project Openhub]
 +
-->
  
 
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE -->
 
<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE -->
Line 90: Line 248:
  
 
== Quick Download ==
 
== Quick Download ==
 
+
//TODO
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 +
<!--
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
 
This is where you can link to your repository.
 
This is where you can link to your repository.
Line 101: Line 260:
 
* [https://github.com/OWASP/Security-Principles/zipball/master .zip file.]
 
* [https://github.com/OWASP/Security-Principles/zipball/master .zip file.]
 
* [https://github.com/OWASP/Security-Principles/tarball/master .tgz file.]
 
* [https://github.com/OWASP/Security-Principles/tarball/master .tgz file.]
 
+
-->
 
== News and Events ==
 
== News and Events ==
 
+
//TODO
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 +
<!--
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
 
This is where you can link to press your project has been a part of. Appropriate press includes: Project Leader interviews, articles written about your project, and videos about your project.  
 
This is where you can link to press your project has been a part of. Appropriate press includes: Project Leader interviews, articles written about your project, and videos about your project.  
 
</span>
 
</span>
 
+
-->
 +
<!--
 
* [20 Nov 2013] News 2
 
* [20 Nov 2013] News 2
 
* [30 Sep 2013] News 1
 
* [30 Sep 2013] News 1
 
+
-->
 
== In Print ==
 
== In Print ==
 
+
//TODO
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 +
<!--
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
 
This is where you place links to where your project product can be downloaded or purchased, in the case of a book.  
 
This is where you place links to where your project product can be downloaded or purchased, in the case of a book.  
Line 120: Line 282:
  
 
This project can be purchased as a print on demand book from Lulu.com
 
This project can be purchased as a print on demand book from Lulu.com
 
+
-->
 
==Classifications==
 
==Classifications==
 +
//TODO
  
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
Line 178: Line 341:
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
A project roadmap is the envisioned plan for the project. The purpose of the roadmap is to help others understand where the project is going. It gives the community a chance to understand the context and the vision for the goal of the project. Additionally, if a project becomes inactive, or if the project is abandoned, a roadmap can help ensure a project can be adopted and continued under new leadership.
+
A project roadmap is the envisioned plan for the project. The purpose of the roadmap is to help others understand where the project is going. It gives the community a chance to understand the context and the vision for the goal of the project. Additionally, if a project becomes inactive, or if the project is abandoned, a roadmap can help ensure a project can be adopted and continued under new leadership.
</span> 
+
</span>  
  
 
<span style="color:#ff0000">
 
<span style="color:#ff0000">
Roadmaps vary in detail from a broad outline to a fully detailed project charter. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Some details that leaders may consider placing in the roadmap include: envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc. You are required to have at least 4 milestones for every year the project is active.  
+
Roadmaps vary in detail from a broad outline to a fully detailed project charter. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Some details that leaders may consider placing in the roadmap include: envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc. You are required to have at least 4 milestones for every year the project is active.  
 
</span>
 
</span>
  

Latest revision as of 16:42, 11 December 2015

OWASP Project Header.jpg

OWASP Secure Software Contract Annex (Deutsche Übersetzung)

OWASP Ergänzende Vertragsbedingungen zur Entwicklung sicherer Software

 WARNUNG: DIESES DOKUMENT IST AUSSCHLIESSLICH ALS ORIENTIERUNGSHILFE ANZUSEHEN.
 OWASP EMPFIEHLT IHNEN DRINGEND EINEN SPEZIALISIERTEN RECHTSANWALT ZUR AUSARBEITUNG
 EINES SOFTWARELIZENZVERTRAGES HERANZUZIEHEN.

EINLEITUNG

Diese ergänzende Vertragsvereinbarung soll Softwareentwicklern und ihren Kunden helfen wichtige Vertragslaufzeiten und Vertragsbedingungen bezüglich der Sicherheit von Software, die entwickelt oder geliefert werden soll, zu verhandeln und festzuhalten.

Grund für dieses Projekt ist, dass die meisten Verträge keine Vereinbarungen zu diesem Thema enthalten, während die Parteien oftmals jedoch gravierend unterschiedliche Ansichten darüber haben, was tatsächlich vereinbart wurde.

Wir glauben, der beste Weg sicherzustellen, dass beiderseits eine sachgerechte Entscheidung über das weitere Vorgehen getroffen wird, ist diese Vertragsbedingungen klar und deutlich auszusprechen.

"Die Sicherheit von kommerzieller Software wird sich verbessern, wenn der Markt bessere Sicherheit fordert.
Jede Angebotsanfrage für Software sollte an die Anbieter wenigstens die Frage enthalten, wie sie ihre Produkte
auf Schwachstellen hin überprüfen. Diese Massnahme wird ein erster Schritt sein Anbieter von Software
'von der Stange' und ausgegliederten Entwicklern davon zu überzeugen, dass Unternehmen Sicherheit wertschätzen."
      -- John Pescatore, Forschungsdirektor bei Gartner

Wir halten Kunden und Entwickler an, dieses Dokument als ein Rahmenkonzept für die Diskussion von Erwartungen und Verhandlung von Haftungsfragen zu nutzen. Diese ergänzenden Vertragsbedingungen sind dafür vorgesehen, einem Vertrag über die Entwicklung von Software beigefügt zu werden. Diese Bedingungen sind verhandlungsfähig, d.h. sie können und sollten von Kunden und Entwicklern erörtert werden.

ÜBER DAS PROJEKT

Dieses Dokument wurde von der Open Web Application Security Project Stiftung (kurz: OWASP) erstellt. Die Stiftung ist eine gemeinnützige Organisation, die sich der Entwicklung freier und öffentlich zugänglicher Werkzeuge sowie der Dokumentation hinsichtlich sicherer Software gewidmet hat. Um den einfachen Gebrauch dieses Dokuments bei privaten Vertragsschlüssen zu erleichtern, wird es unter der CC Share Alike 3.0 license zur Verfügung gestellt. Sie können es anpassen und verwenden, wie es Ihren Bedürfnissen entspricht. Ergänzende Details zu diesem Projekt können sie unter http://www.owasp.com/index.php/OWASP_Legal_Project aufrufen. Wir begrüßen Rückmeldungen sowohl seitens Softwareherstellern sowie Verbrauchern als auch seitens der Rechtskreise.

Das ursprüngliche, englischsprachige Projekt wurde von Jeff Williams mit Unterstützung von Aspect Security erstellt.

Die hier vorliegende deutsche Version wurde von Mareike Zeisel von der LMU München übersetzt. Betreut wurde sie hierbei von Herrn Thomas Hofer, Akademischer Direktor des Rechtsinformatikzentrum der LMU München. Die OWASP-Projektleitung und technische Betreuung hat Ralf Reinhardt übernommen. Er wird dabei durch Arbeitszeitfreistellung von der sic(!)sec GmbH, Information Security Services unterstützt.

Aktueller Stand: Es liegt eine reine Übersetzung vor.

Geplant für die nächste Studienarbeit, bzw. Workshop am Rechtsinformatikzentrum: Juristische Würdigung und falls erforderlich Anpassung an deutsche Rechtsnormen.

EINWÄNDE

Die folgenden Seiten behandeln oft eingeführte Einwände gegen die Nutzung dieser Formulierungen in Zusammenhang mit Softwareentwicklungsverträgen

ABER NICHT ALLE BESTIMMUNGEN TREFFEN AUF UNS ZU...

Dieses Dokument sollte als Ausgangspunkt Ihres Vertrages angesehen werden. Möglicherweise gefallen Ihnen nicht alle Maßnahmen oder Sie wollen Ihrem Vertragspartner mehr vorschlagen. Vielleicht wollen Sie Haftungsfragen anders regeln. Dieses Dokument beabsichtigt nicht exakt die Bedürfnisse jedes einzelnen Softwarekunden und Softwareentwicklers aufzugreifen. Es beabsichtigt vielmehr ein Rahmenkonzept bereitzustellen, an Hand dessen die Schlüsselthemen diskutiert werden können, die maßgeblich sind, um sicherzustellen, dass am Ende eine sichere Software herauskommt. Nach Ihrem Gespräch über die Softwaresicherheit und dem Treffen einer Vereinbarung, sollten Sie diese auf sich maß schneidern.

ABER WER SOLL FÜR DIESE MASSNAHMEN ZAHLEN...

Bei diesem Vertrag geht es NICHT darum, den Softwareentwickler mehr zu belasten. Es stellt sich nicht die Frage, ob Sicherheit mit Kosten einhergeht - natürlich, lautet die Antwort. Die bessere Frage lautet eher, welche Maßnahmen beide Parteien ergreifen sollten, um diese Kosten zu senken und zu welchem Zeitpunkt.

Diese ergänzenden Vertragsbedingungen schweigen bewusst darüber, wer die Kosten dieser Maßnahmen tragen sollte. Während viele dieser Maßnahmen bereits greifen sollten, was auch von vielen Kunden erwartet wird, werden sie nicht regelmäßig von der Industrie angewandt. Die Frage danach, wer (und wie viel) zahlt, sollte Gegenstand der Verhandlung sein.

Kosten für Sicherheitsmaßnahmen zu berechnen, ist sehr schwierig. Einerseits gibt es Kosten, die auf der Ausführung von Sicherheitsmaßnahmen beruhen und andererseits entstehen erhebliche Kosten erst, wenn man Sicherheitsmaßnahmen unterlässt. Wir sind davon überzeugt, der kostengünstigste Weg, Software zu entwickeln, ist, die Wahrscheinlichkeit zu senken, dass Sicherheitslücken entstehen und die Zeit zwischen der Entstehung der Sicherheitslücke und ihrer Behebung zu minimieren.

Eine wichtige Unterscheidung, die bei der Kostenberechnung gemacht werden muss, ist jene zwischen der Herstellung eines Sicherheitsmechanismus und den Kontrollmaßnahmen für die Richtigkeit und Effektivität dieser Mechanismen selbst. Zu versuchen, am Ende der Laufzeit noch Vorrichtungen einzubauen, kann schwerwiegende Gestaltungsfragen aufwerfen und wird die Kosten in die Höhe schnellen lassen. Diese Vereinbarung ermutigt, bereits in einem frühen Planungsstadium Entscheidungen bezüglich solcher Mechanismen zu fällen, mit dem Ziel Kosten zu minimieren. Gleichermaßen treibt es die Kosten in die Höhe, wenn man bis kurz vor Bereitstellung der Software an den Kunden mit Kontrollmaßnahmen wie dem Codereview oder dem Penetrationstest wartet. Wir glauben, der beste Weg Sicherheit zu erreichen, ist, sich während der gesamten Laufzeit um Sicherheit zu bemühen.

ABER DAS ANFORDERUNGSNIVEAU IST ZU LASCH

Diese Vereinbarung geht davon aus, dass die Software, die entwickelt wird, für ein großes Unternehmen oder eine staatliche Behörde ziemlich wichtig ist. Wir haben diese Vereinbarung auf ein Anforderungsniveau gestützt, das von den meisten Softwareentwicklungsorganisationen erreicht werden kann und das die häufigsten Risiken genau bestimmt und behandelt.

Jedoch ist es möglich, dass man das Anforderungsniveau für Software, die in entscheidenden Anwendungen eingesetzt werden wird, anheben möchte. Dies trifft z.B. auf Software aus dem Bereich Medizin-, Finanz- oder Verteidigungswesen zu. Man könnte möglicherweise zusätzliche Überprüfungen, Dokumentationen und Versuche anfertigen und durchführen. Man möchte möglicherweise die zum zum Auffinden, Diagnostizieren und Beseitigen von Schwachstellen notwendigen Verfahren verbessern. Bei weniger sensiblen Anwendungen, könnte man solche Maßnahmen verringern oder entfernen wollen.

ABER SO VIEL KÖNNEN WIR NICHT RISKIEREN

Dieses Vertragswerk soll Diskussionen darüber, wer das Risiko für Schwachstellen in der Softwaresicherheit auf sich nehmen muss, erleichtern. Am einen Ende der Bandbreite könnte der Kunde alle Risiken tragen während der Entwickler Codes mit einer Menge Schwachstellen liefern könnte. Am anderen Ende könnte der Entwickler alle Risiken auf sich nehmen und die Verantwortung für einen perfekt abgelieferten Code übernehmen. Beide Extreme sind nicht handhabbar.

Gegenwärtig, in diesem Vertragswerk, trägt der Entwickler die Risiken von Problemen, die in den Bestimmungen erfasst worden sind oder vernünftigerweise von Probeläufen abgedeckt werden sollten. Dennoch muss die Korrektur "neuartiger" Sicherheitsprobleme vom Kunden bezahlt werden. Wir denken, das ist ein zweckmäßiger Ausgleich, denn der Entwickler kann sein Risiko beschränken und ermutigt den Kunden die Sicherheitsanforderungen bereits im Vorfeld korrekt umzusetzen. Viele andere Lösungen für dieses Problem sind möglich. Bitte teilen Sie uns Ihre alternativen Vorschläge mit, damit wir sie in zukünftige Versionen dieses Dokuments einarbeiten können.

Bitte nehmen Sie zur Kenntnis, dass diese Diskussion nur die Risiken, verbunden mit dem Schließen der Sicherheitslücken im Code, abdeckt. Diese Diskussion behandelt ausdrücklich nicht die Kosten, die mit der Entdeckung irgendeines Sicherheitsvorfalls, basierend auf der Ausnutzung solcher Schwachstellen, entstehen. Wir sind an den besten Geschäftsabläufen/ Best Practices auf diesem Gebiet interessiert.

ABER WIE KÖNNEN WIR DEN CODE EINES DRITTEN ABSICHERN...

Fast alle Softwareprojekte verwenden in beträchtlichem Umfang Code Dritter, solche wie libraries und frameworks. Dieser Code ist unter dem Aspekt Sicherheit genauso wichtig wie der speziell für Ihr Projekt entwickelte Code des Kunden. Wir glauben, dass die Verantwortung zur Sicherstellung der Sicherheit des Codes am besten vom Entwickler getragen wird, obwohl er möglicherweise nicht in vollem Umfang diese Sicherheit gewährleisten kann. Jedoch muss Sicherheit ein Teil der Build-or-Buy-Entscheidung sein. Das scheint der beste Weg zu sein, den Sicherheitsaspekt zu fördern.

Dem Entwickler ist es selbstverständlich möglich, die Verantwortung bis zum Anbieter der Software des Dritten durch zureichen. Der Entwickler kann die Software des Dritten sogar selbst analysieren oder Sicherheitsexperten engagieren, um sie analysieren zu lassen.

ABER WARUM SOLL ICH MIR ALL DIESE MÜHE MACHEN...

Schlussendlich glauben wir, dass es keine Alternative dazu gibt, Sicherheit zu einem Thema in den Softwarevertragsverhandlungen zu machen. Momentan sind wir der Meinung, dass im Rahmen von Softwareentwicklungsverträgen, die die Auslieferung von Software zum Ziel haben, ernsthafte Missverständnisse über die Code-Sicherheit auftreten. Das kann nur in teuren Rechtsstreits und Entscheidungen enden, die von Personen mit lediglich wenig Erfahrungen mit oder Verständnis für Software getroffen werden. Eine ausführliche Auseinandersetzung mit diesem Thema können Sie hier nachlesen: Secure software contracting hypothetical case study

Aus dem Durcharbeiten dieses Vertrages kann man viel Nutzen ziehen. An erster Stelle werden die Erwartungen zwischen den beteiligten Parteien klar herausgestellt. In einigen Fällen kann dadurch Klagewellen vorgebeugt werden, sobald komplizierte Sicherheitsprobleme in der Software zum Vorschein kommen. Außerdem sind das dieselben Maßnahmen, die aus vielen Gründen im Bereich der Rechtssicherheit und Regelüberwachung gefordert werden.

ABER ES IST VIEL ZU MÜHSELIG ALL DAS ZU DOKUMENTIEREN...

OWASP animiert nicht zum Dokumentieren um des Dokumentierens Willen. Dieses Vertragswerk wurde darauf ausgerichtet, Qualität zu fördern, nicht Quantität. Wir glauben, eine kurze Risikobewertung, ein paar Seiten mit Anforderungen, ein kurzes Dokument mit dem Sicherheitsentwurf, ein Testplan und einige Testergebnisse, würden - bei einigen bestimmten Projekten - einem solchen Vertrag Genüge tun.

Das Ziel dieses Dokuments ist, zu jedem Zeitpunkt der Laufzeit einfach sicherzustellen, dass dem Punkt Sicherheit die nötige Aufmerksamkeit gewidmet wurde. Als zusätzlicher Nutzen erweist sich, dass diese Dokumentation zusammengefasst als "Zertifikatspaket" dienen kann. Dieses beweist wesentlich, warum darauf vertraut werden kann, dass die Software arbeitet, wie sie es vorgibt.

VERTRAGSANHANG

1. Einleitung

Dieser Anhang wurde erstellt für ______________________ ("Vereinbarung") zwischen Kunde und Entwickler. Der Kunde und der Entwickler erklären sich bereit, die Sicherheit der Software in Übereinstimmung mit den folgenden Bestimmungen zu maximieren.

2. Philosophie

Dieser Anhang soll die sicherheitsbezogenen Rechte und Pflichten aller Beteiligten an einem Softwareentwicklungsverhältnis klären.

(a) Sicherheitsentscheidungen werden auf Grundlage von Risikoerwägungen getroffen
Entscheidungen über die Sicherheit werden gemeinsam von Kunde und Entwickler, gestützt auf ein festes Verständnis der damit verbundenen Risiken, gefällt.
(b) Sicherheitsmaßnahmen werden ausgeglichen
Sicherheitsleistungen werden annähernd gleichmäßig auf die gesamte Laufzeit der Softwareentwicklung verteilt.
(c) Sicherheitsmaßnahmen werden eingebunden
Alle hier behandelten Maßnahmen und Dokumentationen können und sollen während der Laufzeit der Softwareentwicklung seitens des Entwicklers einbezogen und nicht getrennt vom Rest des Projekts bearbeitet werden. Keine Bestimmung dieses Anhangs impliziert einen bestimmten Softwareentwicklungsprozess.
(d) Schwachstellen werden erwartet
Jede Software hat Bugs (Programmfehler) und einige von diesen werden Sicherheitsprobleme verursachen. Sowohl Kunde als auch Entwickler werden bemüht sein, Schwachstellen so früh als möglich während der Laufzeit zu identifizieren.
(e) Sicherheitsinformationen werden vollständig offengelegt
Alle sicherheitsrelevanten Informationen werden zwischen dem Kunden und dem Entwickler unmittelbar und vollständig freigegeben.
(f) Ausschließlich nützliche Sicherheitsdokumentation ist erforderlich
Sicherheitsdokumentation muss nicht umfangreich sein, um eindeutig das Sicherheitsdesign, Risikoanalysen oder Probleme zu beschreiben.

3. Maßnahmen zur Lebensdauer

(a) Risikoverständnis
Entwickler und Kunde erklären sich bereit, zusammenzuarbeiten, um die Risiken angesichts der Anwendung (application) zu verstehen und zu dokumentieren. Dieser Aufwand soll die Hauptrisiken für das Daten (assets) und die Funktionen, bereitgestellt durch die Anwendung (application), identifizieren. Jeder der in der Liste der Anforderungen aufgelisteten Punkte sollte in Betracht gezogen werden.
(b) Anforderungen
Basierend auf den Risiken kommen Entwickler und Kunde darüber ein, zusammenzuarbeiten, um detaillierte Sicherheitsvorschriften als Teil des Leistungsumfangs der zu entwicklenden Software zu entwerfen. Jeder im Teil über die Sicherheitsvorschriften aufgelistete Punkt dieses Anhangs sollte diskutiert und sowohl vom Entwickler wie vom Kunden beurteilt werden. Diesen Anforderungen kann durch Kundensoftware, Drittsoftware oder das Programm entsprochen werden.
(c) Entwurf
Entwickler stimmt zu, Unterlagen bereitzustellen, die klar und deutlich den Plan zur Erreichung jeder einzelnen Sicherheitsanforderung erklären. In den meisten Fällen wird diese Dokumentation Sicherheitsmechanismen beschreiben, wobei die Mechanismen sich in die Struktur und alle relevanten Entwurfsmuster einfügen, um ihren ordnungsgemäßen Gebrauch zu gewährleisten. Der Entwurf sollte zweifellos festlegen, ob der Support von eigener Software, Drittanbietersoftware oder dem Betreiber zur Verfügung gestellt wird.
(d) Umsetzung
Entwickler verpflichtet sich, eine Reihe von sicheren Codierungsrichtlinien bereitzustellen und zu befolgen sowie eine Reihe gemeinsamer Programmierschnittstellen zur Sicherheitskontrolle zu verwenden (wie z.B. die OWASP Enterprise Security API (ESAPI)). In Richtlinien wird festgelegt, wie Codes formatiert, strukturiert und kommentiert werden sollen. Gemeinsame Programmierschnittstellen zur Sicherheitskontrolle werden festlegen, wie Sicherheitskontrollen abgerufen werden und ablaufen müssen. Jeglicher sicherheitsrelevanter Code muss gründlich kommentiert werden. Spezifische Leitlinien für die Vermeidung von häufigen Sicherheitslücken sollen darin enthalten sein. Außerdem wird der gesamte Code von mindestens einem anderen Entwickler mit den Sicherheitsanforderungen verglichen und an Hand der Codierungsleitlinien überprüft, bevor er als bereit für den Unit-Test erachtet wird.
(e) Sicherheitsanalyse und Prüfung
Entwickler wird die Analyse der Anwendungssicherheit und die Überprüfung (auch "Verifizierung" genannt) nach den Prüfanforderungen eines vereinbarten Standards (wie z.B. dem OWASP Application Security Verification Standard (ASVS)) durchführen. Der Entwickler muss Erkenntnisse aus der Überprüfung nach den standardmäßigen Anforderungen an Berichte dokumentieren. Entwickler soll die Erkenntnisse aus der überprüfung dem Kunden zur Verfügung stellen.
(f) Sichere Bereitstellung
Entwickler verpflichtet sich, sichere Konfigurationsrichtlinien zur Verfügung zu stellen, die alle sicherheitsrelevanten Konfigurationsoptionen und deren Auswirkungen auf die allgemeine Sicherheit der Software vollständig beschreiben. Die Richtlinie enthält eine vollständige Beschreibung der Abhängigkeiten von der Trägerplattform, einschließlich Betriebssystem, Webserver und Anwendungsserver, und wie sie für die Sicherheit konfiguriert werden sollten. Die Standardkonfiguration der Software sollte sicher sein.

4. Themenbereich Sicherheitsanforderungen

Die folgenden Themenbereiche müssen beim übereinkommen über das Risiko und der Definition der Anforderungen an Maßnahmen berücksichtigt werden. Diese Bemühungen sollten eine Reihe spezifischer, maßgeschneiderter und überprüfbarer Anforderungen hervorbringen. Sowohl Entwickler als auch Kunde sollten in diesen Prozess einbezogen werden und müssen ein finales Anforderungenwerk vereinbaren.

(a) Eingabeüberprüfung und Encoding
Die Anforderungen sollen die Regeln festlegen, nach denen jegliche Eingabe in die Anwendung, ob von seiten der Benutzer, Dateisysteme, Datenbanken, Verzeichnisse oder externer Systeme, in eine vorschriftsmäßige Form gebracht, validiert oder kodiert werden kann. Standardmäßig soll jede Eingabe ungültig sein, wenn sie keiner detaillierten Spezifikation entspricht, die festlegt, was erlaubt ist. Darüber hinaus sollen die Anforderungen angeben, welche Maßnahmen ergriffen werden sollen, wenn ungültige Eingaben gemacht werden. Im Besonderen soll die Anwendung nicht anfällig für Injektionen, überlauffunktionen, Beschädigungen oder andere unlautere Angriffe bei der Eingabe sein.
(b) Authentifizierung und Session Management
Die Anforderungen sollen angeben, wie Anmeldeinformationen und Sitzungs-IDs während ihrer gesamten Lebensdauer geschützt werden. Anforderungen für alle damit verknüpften Funktionen, einschließlich vergessener Passwörter, dem ändern von Kennwörtern, sich Merken von Passwörtern, der Abmeldung und mehrerer Logins, sind aufzustellen.
(c) Zugangskontrolle
Die Anforderungen umfassen eine detaillierte Beschreibung aller in der Anwendung verwendeten Rollen (Gruppen, Berechtigungen, Autorisierungen). Die Anforderungen sollen auch alle Vermögenswerte und Funktionen bezeichnen, die die Anwendung bietet. Die Anforderungen werden vollständig die genauen Zugriffsrechte auf jeden Vermögenswert und Funktion für jede Rolle festlegen.
(d) Fehlerbehandlung
Die Anforderungen sollen ausführlich beschreiben, wie während der Verarbeitung auftauchende Fehler behandelt werden. Einige Anwendungen sollten im Falle eines Fehlers Ergebnisse nach größten Bemühungen bieten, während andere die Verarbeitung sofort beenden sollten.
(e) Protokollierung
Die Anforderungen sollen angeben, welche Ereignisse sicherheitsrelevant sind und protokolliert werden müssen, wie beispielsweise aufgedeckte Angriffe, fehlgeschlagene Anmeldeversuche, und Versuche, seine Autorisierung zu überschreiten. Die Anforderungen sollen auch festlegen, welche Information mit jedem Ereignis zu protokollieren ist, einschließlich Datum und Uhrzeit, Ereignisbeschreibung, Anwendungsdetails und andere Informationen, die bei forensischen Bemühungen nützlich sind.
(f) Anbindungen an externe Systeme
Die Anforderungen sollen beschreiben, wie die Authentifizierung und die Verschlüsselung für alle externen Systeme, wie Datenbanken, Verzeichnisse und Web-Services, gehandhabt werden. Alle Anmeldeinformationen, die für die Kommunikation mit externen Systemen erforderlich sind, müssen außerhalb des Codes in einer Konfigurationsdatei in verschlüsselter Form gespeichert werden.
(g) Verschlüsselung
Die Anforderungen sollen angeben, welche Daten verschlüsselt werden müssen, wie die Verschlüsselung vorzunehmen ist, und wie alle Zertifikate und andere Anmeldeinformationen behandelt werden müssen. Die Anwendung soll einen Standardalgorithmus nutzen, der in eine weit verbreitete und getestete Verschlüsselungsbibliothek implementiert wurde.
(h) Verfügbarkeit
Die Anforderungen sollen angeben, wie vor Angriffen durch Dienstverweigerung geschützt wird. Alle wahrscheinlichen Angriffe auf die Anwendung müssen in Betracht gezogen werden, einschließlich Authentifizierungsperre, Anschlussüberlastung und andere Angriffe durch Ressourcenüberlastung.
(I) Sichere Konfigurierung
Die Anforderungen sollen festlegen, dass die Standardwerte für alle sicherheitsrelevanten Konfigurationsoptionen sicher sind. Für Prüfungszwecke sollte die Software in der Lage sein, einen leicht lesbaren Bericht auszugeben, der alle sicherheitsrelevanten Konfigurationsdetails enthält.
(j) Besondere Schwachstellen
Die Anforderungen umfassen eine Reihe spezifischer Schwachstellen, die nicht in der Software gefunden werden sollen. Falls nicht anders angegeben, wird die Software keine der in der aktuellen Version des "OWASP Top Ten Most Critical Web Application Vulnerabilities" beschriebenen Mängel enthalten.

5. Personal und Organisation

(a) Sicherheitsarchitekt
Entwickler wird die Verantwortung für die Sicherheit auf eine einzige leitende technische Ressource übertragen, bekannt als der projekteigene Sicherheitsarchitekt. Der Sicherheitsarchitekt wird die Sicherheit jedes Liefergegenstandes zertifizieren.
(b) Sicherheitstraining
Es liegt in der Verantwortung des Entwicklers zu gewährleisten, dass alle Mitglieder des Entwicklerteams in sicheren Programmiertechniken geschult wurden.
(c) Vertrauenswürdige Entwickler
Entwickler verpflichtet sich, angemessene Hintergrundrecherchen zu allen Mitgliedern im Entwicklerteam anzustellen.

6. Entwicklungsumgebung

(a) Sichere Programmierung
Der Entwickler muss offenlegen, welche Werkzeuge in der Entwicklungsumgebung verwendet werden, um eine sichere Programmierung zu fördern.
(b) Konfigurationsmanagement
Der Entwickler soll mit einem Quellcodeverwaltungssystem arbeiten, das die Team- Mitglieder authentifiziert und protokolliert. Insbesondere mit allen änderungen an der Grundsoftware sowie den dazugehörigen Konfigurationen. Das System soll außerdem Dateien bilden.
(c) Verteilung
Der Entwickler hat einen Build-Prozess zu verwenden, der zuverlässig eine vollständige Distribution aus dem Quellcode erstellt. Dieser Prozess muss eine Methode zur überprüfung der Integrität der dem Kunden gelieferten Software vorsehen.

7. Programmbibliotheken, Frameworks und Produkte

(a) Offenlegung
Entwickler soll jede Drittanbietersoftware, die in der Software verwendet wird, einschließlich, Programmbibliotheken, Frameworks, Komponenten und andere Produkte, egal ob kommerziell, frei, open-source oder closed-source, offenlegen.
(b) Evaluation
Entwickler muss alle zumutbaren Anstrengungen unternehmen, um sicherzustellen, dass Software von Drittanbietern alle Bedingungen dieses Vertrages erfüllt und genauso sicher wie der kundenspezifisch entwickelte Code ist, der nach dieser Vereinbarung entwickelt wurde.

8. Sicherheitsüberprüfung

(a) Recht auf überprüfung
Kunde hat das Recht, die Software jederzeit innerhalb von 60 Tagen ab Lieferung auf Sicherheitslücken überprüfen zu lassen. Entwickler verpflichtet sich das Review-Team durch die Bereitstellung von Quellcode und den Zugang zu Testumgebungen angemessen zu unterstützen.
(b) Prüfbericht
Sicherheitsüberprüfungen werden alle Aspekte der gelieferten Software abdecken, einschließlich benutzerdefinierter Codes, Komponenten, Produkte und Systemkonfiguration.
(c) Prüfungsumfang
Die überprüfung soll wenigstens alle Sicherheitsanforderungen abdecken und nach anderen üblichen Schwachstellen suchen. Die überprüfung kann eine Kombination von Schwachstellen-Scans, Penetrationstests, statischen Analysen des Quellcodes und Experten- Codereview umfassen.
(d) Entdeckte Fehler
Aufgedeckte Sicherheitsprobleme werden sowohl dem Kunden als auch dem Entwickler gemeldet. Alle Probleme werden aufgespürt und beseitigt, wie im Abschnitt dieses Vertragsanhangs über Sicherheitsproblemmanagement vorgesehen.

9. Sicherheitsproblemmanagement

(a) Identifizierung
Entwickler wird alle Sicherheitsprobleme während der gesamten Lebensdauer verfolgen, egal ob es sich um Probleme mit den Anforderungen, der Gestaltung, der Implementierung, den Tests, der Bereitstellung oder dem Betrieb handelt. Das mit jeder Sicherheitslücke verbundene Risiko wird ausgewertet, dokumentiert und dem Kunden so früh als möglich nach der Entdeckung berichtet.
(b) Schutz
Entwickler wird in geeigneter Weise Informationen bezüglich Sicherheitsfragen und die dazugehörigen Unterlagen schützen, um die Wahrscheinlichkeit zu begrenzen, dass Schwachstellen in der Betriebskundensoftware enthüllt werden.
(c) Wiederherstellung
Sicherheitsprobleme, die vor der Lieferung identifiziert werden, sollen vom Entwickler behoben werden. Sicherheitsprobleme, die nach der Lieferung entdeckt werden, sollen in der gleichen Weise wie dieser Vertrag es für andere Bugs und Probleme festlegt, behandelt werden.

10. Garantie

(a) Garantie
Entwickler wird ein "Zertifizierungspaket" anbieten, bestehend aus der Sicherheitsdokumentation, die im Verlauf des gesamten Entwicklungsprozesses erstellt wurde. Das Paket sollte nachweisen, dass die Sicherheitsanforderungen, die Gestaltung, die Implementierung und die Testergebnisse ordnungsgemäß umgesetzt und erfasst und alle Sicherheitsprobleme in geeigneter Weise gelöst wurden.
(b) Selbstzertifizierung
Der Sicherheitsarchitekt wird bescheinigen, dass die Software die Sicherheitsanforderungen erfüllt, alle Sicherheitsmaßnahmen durchgeführt worden sind, und alle aufgefundenen Sicherheitsprobleme dokumentiert und gelöst wurden. Ausnahmen vom Zertifizierungsstatus sollen in vollem Umfang bei Lieferung dokumentiert werden.
(c) Kein schädlicher Code
Entwickler garantiert, dass die Software keinen Code enthält, der eine Anforderung an die Software nicht unterstützt und die Sicherheit der Anwendung schwächt, einschließlich Computerviren, Würmern, Zeitbomben, Hintertüren, Trojaner, Easter eggs, und allen anderen Formen von bösartigem Code.

11. Sicherheitsabnahme und Erhaltung

(a) Abnahme
Die Software darf nicht als abgenommen angesehen werden, bis das Zertifizierungspaket vollständig vorliegt und alle Sicherheitsprobleme behoben wurden.
(b) Untersuchung von Sicherheitsproblemen
Falls nach der Abnahme Sicherheitsprobleme entdeckt werden oder der begründete Verdacht besteht, soll der Entwickler dem Auftraggeber bei der Durchführung einer Untersuchung behilflich sein, um die Art des Problems festzustellen. Das Problem soll als "neuartig" angesehen werden, falls es nicht durch die Sicherheitsanforderungen abgedeckt wird und außerhalb des angemessenen Umfangs der Sicherheitsüberprüfung liegt.
(c) Neuartige Sicherheitsprobleme
Entwickler und Kunde vereinbaren, die für die Behebung neuartiger Sicherheitsprobleme anzustrengenden Bemühungen gründlich zu betrachten und nach Treu und Glauben zu verhandeln, um eine Vereinbarung über die Durchführung der erforderlichen Arbeiten zu ihrer Bewältigung zu erreichen.
(d) Andere Sicherheitsprobleme
Entwickler hat sämtliche wirtschaftlich vernünftige Anstrengungen, im Einklang stehend mit fehlerfreien Softwareenticklungsverfahren, zu ergreifen, und dabei die Schwere des Risikos zu berücksichtigen, um so schnell wie möglich alle Sicherheitsprobleme zu beheben, die nicht als neuartig betrachtet werden.

What is OWASP Security Principles Project?

Here you should add a short description of what your project actually does. What is the primary goal of your project, and why is it important?

//TODO

Presentation

German OWASP Day 2015 [1]

Project Leader

  • Thomas Hofer, Akademischer Direktor des Rechtsinformatikzentrum der LMU München
  • Ralf Reinhardt
  • Translation initially done by Mareike Zeisel


Quick Download

//TODO

News and Events

//TODO

In Print

//TODO

Classifications

//TODO

Here is where you can let the community know what project stage your project is currently in, whether the project is a builder, breaker, or defender project, and what type of project you are running.

New projects.png Owasp-builders-small.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files DOC.jpg

Many projects have "Frequently Asked Questions" documents or pages. However, the point of such a document is not the questions. The point of a document like this are the answers. The document contains the answers that people would otherwise find themselves giving over and over again. The idea is that rather than laboriously compose and post the same answers repeatedly, people can refer to this page with pre-prepared answers. Use this space to communicate your projects 'Frequent Answers.'


How can I participate in your project?

All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

If I am not a programmer can I participate in your project?

Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

Contributors

The success of OWASP is due to a community of enthusiasts and contributors that work to make our projects great. This is also true for the success of your project. Be sure to give credit where credit is due, no matter how small! This should be a brief list of the most amazing people involved in your project. Be sure to provide a link to a complete list of all the amazing people in your project's community as well.

The OWASP Security Principles project is developed by a worldwide team of volunteers. A live update of project contributors is found here.

The first contributors to the project were:

A project roadmap is the envisioned plan for the project. The purpose of the roadmap is to help others understand where the project is going. It gives the community a chance to understand the context and the vision for the goal of the project. Additionally, if a project becomes inactive, or if the project is abandoned, a roadmap can help ensure a project can be adopted and continued under new leadership.

Roadmaps vary in detail from a broad outline to a fully detailed project charter. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Some details that leaders may consider placing in the roadmap include: envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc. You are required to have at least 4 milestones for every year the project is active.

As of October 2013, the priorities are:

  • Finish the referencing for each principle.
  • Update the Project Template.
  • Use the OWASP Press to develop a book.
  • Finish and publish the book on Lulu.

Involvement in the development and promotion of the OWASP Security Principles Project is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:

  • Helping find references to some of the principles.
  • Project administration support.
  • Wiki editing support.
  • Writing support for the book.
PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: N/A
Purpose: N/A
License: N/A
who is working on this project?
Project Leader(s): N/A
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: N/A
Project Roadmap: Not Yet Created
Key Contacts
  • Contact the GPC to contribute to this project
  • Contact the GPC to review or sponsor this project
current release
pending
last reviewed release
pending


other releases