D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates

Transkript

1 D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates (Fraunhofer SIT) Prüfung: Sven Wohlgemuth (TU Darmstadt/CASED) Typ: [TECHNISCHER BERICHT] Projekt: Version: 1.0 Datum: 25. Juni 2013 Status: [FREIGABE] Klasse: [ÖFFENTLICHKEIT] Datei: D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates.docx Zusammenfassung In D08-QM Review-Konzept PersoApp wurden vier unterschiedliche Reviewtypen beschrieben, die im Verlauf von anzuwenden sind. Das vorliegende Dokument widmet sich der operativen Planung und Durchführung dieser unterschiedlichen Reviewtypen. Neben ausführlichen Beschreibungen liefert das Dokument Vorlagen und Checklisten, die zur Unterstützung der einzelnen Aktivitäten herangezogen werden können. Konsortialleitung: Prof. Dr. Ahmad-Reza Sadeghi und Dr. Sven Wohlgemuth System Security Lab, TU Darmstadt/CASED, Mornewegstr. 32, Darmstadt Tel.: Fax: Web:

2 Nutzungslizenz Die Nutzungslizenz dieses Dokumentes ist die Creative Commons Nutzungslizenz Attribution-ShareAlike 3.0 Unported 1. Mitglieder des Konsortiums 1. AGETO Service GmbH, Deutschland 2. Center for Advanced Security Research Darmstadt (CASED), Deutschland 3. Fraunhofer Institut für Sichere Informationstechnologie (SIT), Deutschland 4. Technische Universität (TU) Darmstadt, Deutschland Versionen Version Datum Beschreibung (Editor) Initiale Version (Fraunhofer SIT) Kapitel 5.2, 5.4 (Fraunhofer SIT) Kapitel 5 ergänzt (AGETO) Version zum Review durch TU Darmstadt (Fraunhofer SIT) Freigabe (Fraunhofer SIT) Autoren Autoren Philipp Holzinger (Fraunhofer SIT) Stefan Triller (Fraunhofer SIT) Beiträge Kapitel 5.5, Anhang A-E Kapitel 5.2, 5.3 Jens Kubieziel (AGETO) Kapitel 5.1, 5.2, Version Juni 2013 Seite 2/43

3 Inhaltsverzeichnis 1 Ziel und Zweck des Dokumentes Anwendungsbereich Abkürzungen und Begriffsdefinition Zuständigkeiten und Verantwortlichkeiten Operative Planung und Durchführung von Reviews und Release-Updates Der -Release-Zyklus Ablauf der Major-Release-Zyklen Ablauf des Einreichprozesses Verkürzter Release-Prozess Technisches Review Informelles Review Inspektion eines Major-Release-Update Management Review Interne und externe Anforderungen Mitgeltende Dokumente Anhang A Protokollvorlage für Reviewmeeting Anhang B Checkliste Management Review Anhang C Checkliste zur Sicherheitsarchitektur von Softwarereleases Security-relevant aspects of the software Outlining the software to develop Key properties High-level data flow diagram Historical information of security incidents Security incident history Quick assessment Creating security profiles for software components and other similar software projects Security profile for similar software projects Identify asset stakeholders Collect relevant assets Specify and rank security objectives for assets Version Juni 2013 Seite 3/43

4 1.7 List actors that interact with the software List intended role changes provided to the actors Classify processed data Identify technologies, platforms, and architectural paradigms Identify and prioritize threats Weaknesses identified using CWE Threats identified with STRIDE Attacker-motives assessment Threat prioritization Security architecture and design Outline Detailed data flow diagram Functional security design Security dependencies and trust relationships Secondary assets Security objectives for secondary assets Trusted actors and trusted environments Exposed entities Asset manifestations Generic data sinks Access path policy Security design tradeoffs Security priorities by role/task General considerations Security areas of concern Reference database filters Development action plan Secure programming guidance materials Secure coding plan Implementation constraints Component and platform versions Build action plan Release version build options Version Juni 2013 Seite 4/43

5 4.3.2 Build cleanup Secure default configuration Interactive security configuration Secure deployment requirements Testing action plan External testing requirements Security testing policy Entry points and exit points Attack success conditions Vulnerability rating model Documentation action plan Target operational environment(s) Components configuration constraints Security implications of configuration and deployment options User-dependent mechanism strength System administrator security tasks Anhang D Fragebogen zu externen Bibliotheken Anhang E Checkliste für die Programmierrichtlinie und Qualitätsmetriken Der Fragebogen aus Version Juni 2013 Seite 5/43

6 1 Ziel und Zweck des Dokumentes Die Entwicklung qualitativ hochwertiger Software bedarf der Anwendung bewährter Prozesse und Methoden, die die Erstellung und den Test von Komponenten begleiten. Um über den Projektverlauf eine planmäßige, nutzbringende, effiziente und erwartungsgemäße Anwendung von Methoden und Werkzeugen zu gewährleisten, bedarf es einer kontinuierlichen Begutachtung der Projektfortschritte und der Teilergebnisse. In D08-QM Review-Konzept PersoApp wurden vier unterschiedliche Reviewtypen beschrieben, die im Verlauf des PersoApp-Projekts anzuwenden sind. Das vorliegende Dokument widmet sich der operativen Planung und Durchführung dieser unterschiedlichen Reviewtypen. Neben ausführlichen Beschreibungen liefert das Dokument Vorlagen und Checklisten, die zur Unterstützung der einzelnen Aktivitäten herangezogen werden können. 2 Anwendungsbereich Die Festlegungen, die in diesem Dokument getroffen werden, sind über den gesamten Projektverlauf für jede Reviewdurchführung zu beachten. Zeitliche und organisatorische Einzelheiten werden im Folgenden für jeden Reviewtyp detailliert vorgestellt. Die Anwendung der beigefügten Vorlagen und Checklisten ist, sofern nicht anders angegeben, optional. Prozessbeschreibungen für die Durchführung von Code- und Dokumentations- Reviews zur kontinuierlichen Sicherstellung der Qualität sind dem mitgeltenden Dokument D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität zu entnehmen. Version Juni 2013 Seite 6/43

7 3 Abkürzungen und Begriffsdefinition Begriff Abkürzung Definition IEEE Std Hierdurch wird die aktuelle Ausgabe des IEEE Standard for Software Reviews and Audits referenziert. Das Dokument beschreibt die folgenden fünf grundlegenden Typen: Management Review Technisches Review Inspektion Walk-Through Audit Einzelne Festlegungen, die das vorliegende Dokument trifft, erfolgen in Anlehnung an diesen Standard. 4 Zuständigkeiten und Verantwortlichkeiten Die Einhaltung der im Folgenden getroffenen Festlegungen obliegt jedem Projektteilnehmer, der direkt oder indirekt an einem Review beteiligt ist. Unter einer direkten Beteiligung wird hier die aktive Teilnahme an einem Review verstanden. Als indirekt beteiligt gilt hier ein Projektteilnehmer, dessen Projektarbeit in irgendeiner Weise durch ein Review beeinflusst wird, beispielsweise etwa, weil ihm die Nachbesserung eines Reviewgegenstandes obliegt. 5 Operative Planung und Durchführung von Reviews und Release-Updates 5.1 Der -Release-Zyklus Innerhalb des Projektes sind sechs Pre- oder Major Releases vorgesehen. Diese bestehen aus einem Pre-Release zu einem frühen Zeitpunkt und weiteren Major-Releases im weiteren Verlauf. Der Releasezyklus zwischen den Major- Releases wurde auf sechs Monate festgelegt. Der Ausgangspunkt (T 0 ) für die Releasezyklen wird durch die Bereitstellung einer lauffähigen Basisversion markiert. Dieses Pre-Release ist unter den gängigen Betriebssystemen Microsoft Windows, Mac OS X und GNU/Linux 2 lauffähig. Es benötigt eine grafische Oberfläche, da die Steuerung der Software über die systemeigene Taskbar erfolgt. Das Kernentwicklungsteam ist für diese Aufgabe hauptsächlich zuständig. Der Abschluss erfolgt drei Monate nach Projektbeginn. Danach beginnen die 2 Getestet unter Ubuntu, Debian, Fedora, OpenSUSE und Gentoo. Version Juni 2013 Seite 7/43

8 Major-Release-Phasen. Diese sind in den untenstehenden Abschnitten genauer beschrieben Ablauf der Major-Release-Zyklen Jeder Major-Release-Zyklus unterteilt sich in zwei aufeinanderfolgende Phasen: 1. Entwicklungsphase 2. Testphase Die erste Phase (Entwicklungsphase) erstreckt sich über fünf Monate. Der Hauptzweck dieser Phase ist es, in Zusammenarbeit mit der Community Fehler in der Software zu identifizieren und diese anschließend zu beheben. Hierzu treten die Mitglieder aus der Community über die Kommunikationskanäle in Verbindung und melden Fehler. Diese Rückmeldung sollte idealerweise über das Bug-Tracking-System von erfolgen. Dort werden die Fehler eingetragen und der Entwickler hat die Möglichkeit, systematisch an Verbesserungen zu arbeiten sowie über einen definierten Kanal mit dem Einreicher eines Fehlers in Kontakt zu treten. Es wird empfohlen, dass Meldungen über Fehler bzw. Verbesserungen der Software, welche nicht über das Bug-Tracking-System eingereicht werden, durch den Entwickler selbst nachzutragen. Damit bleibt für alle interessierten Anwender wie Entwickler ein eindeutiger, zentraler Kanal, wo existierende und behobene Vorfälle registriert sind. Neben reinen Kommentaren besteht natürlich ebenso die Möglichkeit, Verbesserungen in Form von Patches einzureichen. Dies sind meist kleine Dateien, die Änderungen am Quellcode vorschlagen. Hier ist es ebenso sinnvoll, dass alle Patches im Bug-Tracking-System registriert sind. Entweder der Einreicher hängt die Patches direkt an den Eintrag im Bug-Tracking-System an oder es verbleibt in der Verantwortung des Entwicklers. Dieser kann einen Patch ebenso an den Eintrag anfügen. Alternativ besteht die Möglichkeit, auf eine Version im Versionskontrollsystem zu verweisen. Diese Version sollte jedoch nur den einen Patch enthalten. Eine dritte Klasse von möglichen Änderungen im Laufe der Entwicklungsphase sind so genannte Feature Requests. Dies sind Vorschläge für neue Funktionen innerhalb der Software oder auch für Änderungen im existierenden Ablauf des Programms. Feature Requests werden ebenso im Bug-Tracking-System aufgenommen und dort zentral gesteuert. In allen Fällen ist es wichtig und sinnvoll, der einreichenden Person eine zeitnahe Rückmeldung zu geben. Erfahrungsgemäß erhält dies die Motivation, weiterhin am Projekt mitzuarbeiten und ggf. später weitere Meldungen einzureichen. Fehlende Rückmeldungen hingegen können leicht zu Frustration und zu weniger konstruktiver Mitarbeit führen. Über die Projektwebseite wird Anwendern wie Entwicklern eine Möglichkeit zur Abgabe von Fehlermeldungen, Verbesserungen etc. zur Verfügung gestellt. Nachdem die oben vorgestellten Meldungen über die Software eingegangen sind, wird ein Prozess zur Bewertung bzw. Review der Meldungen initiiert. Der Einreichprozess selbst wird unten näher beschrieben. Version Juni 2013 Seite 8/43

9 Am Ende von Phase 1 steht ein so genannter Feature Freeze. Ab diesem Zeitpunkt werden keine Anfragen für neue Funktionalitäten (Features) angenommen. Der Feature Freeze ist gleichzeitig der Startpunkt von Phase 2, der Testphase. Die Phase 1 sollte sich über fünf Monate erstrecken, währenddessen die Phase 2 etwa einen Monat andauert. Im Dokument D09-QM-2 Release-Management von Software-Modulen und Dokumente der Open-Source ist der Testprozess dokumentiert. Innerhalb von Phase 2 werden weiterhin Patches akzeptiert. Diese dienen in der Regel der Behebung von Softwarefehlern und Sicherheitslücken. Damit leisten diese einen Beitrag zur Verbesserung der Qualität der Software. Dagegen werden keine neue Funktionalitäten (Features) akzeptiert. Die Entwicklung neuer Features wird für die nächste Entwicklungsphase zurückgestellt. Dies kann entweder über das Bug- Tracking-System geschehen. Alternativ kann der Entwickler im Vorfeld einen neuen Zweig innerhalb der Versionsverwaltungssoftware einrichten, wo Patches für neue Features eingepflegt werden. Der Einreicher eines Features ist ggf. von der späteren Aufnahme der Änderungen und dem Eintrag im Bug-Tracking-System zu informieren. Der Release Manager kann von der obigen Regel abweichen und trotzdem neue Features innerhalb des Feature Freeze implementieren. Dies kann sich bei sehr kleinen Neuerungen oder Spezialfällen anbieten. Innerhalb der Testphase kann eine Testversion der Community bereitgestellt werden. Dies ist kein offizielles Release, sondern dient externen Testpersonen, Neuerungen auszuprobieren und Fehler zu finden. Die Testphase wird durch ein Major Release abgeschlossen. Endanwendern wird empfohlen, die neu herausgegebene Version der PersoApp einzusetzen und darauf basierend Fehler zu melden. Diese Fehler werden innerhalb einer anschließenden Entwicklungsphase aufgenommen und es wird versucht, diese zu beheben. In der Regel erfolgt kein Backporting : Fehler, die in der aktuellen Variante der Software gefunden worden, werden nicht in alten Versionen behoben. Stattdessen sollten Endanwender immer das jeweils aktuellste Major Release einsetzen Ablauf des Einreichprozesses Die Software ist in ihrer internen Architektur in verschiedene Module zerlegt. Jedem Modul wird ein Entwickler zugeordnet. Dabei kann ein Entwickler mehrere Module betreuen. Wenn eine Meldung im Bug-Tracking-System eingeht, wird die Meldung dem Entwickler für das entsprechende Modul zugeordnet. Dieser muss entscheiden, ob dies wirklich seinem Aufgabengebiet obliegt. Gegebenenfalls erfolgt eine Neuzuordnung zu einem anderen Modul. Anschließend muss der verantwortliche Entwickler eine Bewertung vornehmen. Bei gemeldeten Fehlern in der Software ist zuerst zu prüfen, ob der Fehler nachvollziehbar ist. Gegebenenfalls muss der Entwickler mit dem Reporter des Fehlers Kontakt aufnehmen und weitere Informationen erfragen. Diese Kontaktaufnahme erfolgt über Version Juni 2013 Seite 9/43

10 das Bug-Tracking-System. Nachdem Erhalt aller wichtigen Informationen kann der verantwortliche Entwickler versuchen, den Fehler zu beheben bzw. andere versuchen, Lösungen zu finden. Im Allgemeinen kann nicht garantiert werden, dass alle innerhalb einer Entwicklungsphase gemeldeten Fehler auch in dieser Phase behoben werden. Die Behebung ist oft ein sehr zeit- und arbeitsaufwändiger Prozess. Fehler können auch nur unter bestimmten Konstellationen auftreten. Die Erfahrung mit anderen Projekten zeigt, dass gerade bei speziellen Fehlern die Lösung dieser Fehler lange Zeiträume (eine oder mehrere Jahre) beanspruchen kann. Im Falle von Patches, die von externer Seite eingereicht werden, wird ein Review- Prozess initiiert. Die Details des Prozesses sind im Dokument D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates definiert. Eingehende Feature Requests werden vom verantwortlichen Entwickler ebenfalls bewertet und auf Umsetzbarkeit geprüft. Die Ergebnisse dieser Prüfung sind im Bug- Tracking-System zu dokumentieren. Das neu zu entwickelnde Feature kann vom Entwickler selbst oder von Dritten implementiert werden. Gegebenenfalls wird die Implementierung wieder einem Review-Prozess unterworfen Verkürzter Release-Prozess In Ausnahmefällen kann der Bedarf nach einem Release entstehen, der außerhalb der oben definierten Zeiträume liegt. Dies ist insbesondere der Fall, wenn schwere Fehler oder kritische Sicherheitslücken in der Software gefunden wurden. Dies macht es notwendig, schnell zu reagieren und Endanwender nicht unnötig längere Zeit Unannehmlichkeiten oder Gefahren auszusetzen. Nachdem die entsprechende Meldung eingegangen ist, ist diese wieder vom verantwortlichen Entwickler zu prüfen und bewerten. Sollte der Entwickler ebenfalls zu der Einschätzung gelangen, dass es sich um einen schweren Fehler oder eine kritische Sicherheitslücke handelt, so ist die Meldung im Bug-Tracking-System entsprechend einzustufen. Aufgrund der Natur des gemeldeten Fehlers liegt in der Behebung hohe Priorität und der verantwortliche Entwickler muss entsprechend handeln. Dies bedeutet zum einen, dass schnellstmöglich versucht wird, den Fehler zu beheben. Andererseits kann es sinnvoll sein, die Community über den Fehler zu informieren. Bei Meldungen über Sicherheitslücken wird meist ein Zeitraum vorgegeben, in dem der Fehler behoben sein muss oder eine Lösung gefunden werden muss (Responsible Disclosure). Seitens des Entwicklers ist darauf zu achten, dass der Zeitraum eingehalten wird oder gegebenenfalls Kontakt zum Einreicher aufgenommen wird. Für schwere Fehler kann es sinnvoll sein, einen zweiten, nicht öffentlichen Kanal zur Einreichung zu etablieren. Denn das unmittelbare Wissen über diesen Fehler kann Systeme der Endanwender in unnötiger Weise in Gefahr bringen. Die Basis für die Behebung schwerer Fehler oder kritischer Sicherheitslücken ist das letzte Major Release. Ausgehend von dieser Version wird eine Korrektur entwickelt. Dieses Vorgehen vermindert die Komplexität. Denn innerhalb der Entwicklungsphase werden unter Umständen neue Features entwickelt oder experimentelle Änderungen Version Juni 2013 Seite 10/43

11 gemacht. In der Regel sind diese nicht vollständig ausgetestet. Damit würde die Gefahr neuer Fehler oder Schwachstellen entstehen. Hingegen wurde das letzte Major Release getestet und die Anzahl weiterer möglicher Fehler oder Schwachstellen ist minimal. Nachdem die Entwicklung der Korrektur beendet ist, wird ein Review- und Test- Prozess nach den Dokumenten D09-QM-2 Release-Management von Software- Modulen und Dokumente der Open-Source und D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates initiiert. Bei erfolgreicher Beendigung der obigen Prozesse wird die Software zum Download bereitgestellt. Spätestens an dieser Stelle ist darauf zu achten, dass die Endnutzer über das Release informiert werden. Diese Information sollte klar benennen, wo der Grund für den verkürzten Release-Prozess liegt und wo die möglichen Gefahren für den Endanwender liegen. Unter Umständen sollte die Downloadvariante der Vorversion der Software einen deutlichen Hinweis auf die aufgetretenen Probleme erhalten. Damit ist für zukünftige Nutzer klargestellt, dass die Benutzung dieses speziellen Release nicht angeraten wird. Von einer kompletten Entfernung der problematischen Vorversion ist abzuraten. Üblicherweise verteilt sich die Software im Laufe der Zeit an andere Stellen. Damit ist auch die problematische Version mit wenig Aufwand durch Dritte zu finden. Andererseits ist je nach dem spezifischen Vorgehen des Software-Entwicklers klar, wie sich diese Version zusammensetzt. Meist werden in der Versionsverwaltung Tags zur Markierungen spezieller Meilensteine benutzt. Auf diesem Wege könnte die Software-Version wiederhergestellt werden. Eine entsprechende Warnung zusammen mit der downloadbaren Version hat den Vorteil, dass dem Nutzer klar gemacht wird, dass dies ein Risiko darstellt. Bei den anderen Varianten ist dies nicht unbedingt der Fall. Nachdem die Software im Rahmen des verkürzten Release-Zyklus veröffentlicht wurde, beginnt eine neue Entwicklungsphase. Der verantwortliche Entwickler versucht, die Änderungen der vorigen Entwicklungsphase (Vor der verkürzten Release- Phase) neu in den Quellcode aufzunehmen. Dabei müssen unter Umständen Anpassungen der alten Änderungen vorgenommen werden. Je nach Schweregrad der Änderungen kann der Prozess im Bug-Tracking-System dokumentiert werden. Die weitere Entwicklung erfolgt schließlich nach den obigen Vorgaben mit der Entwicklungsund Testphase. 5.2 Technisches Review Für das Projekt wurden bereits im Vorfeld feste Termine für das Technische Review definiert. Demnach findet für die Major Releases in den Projektmonaten 13, 19, 25 und 31 jeweils ein (technischer) Review statt. Weiterhin kann ein Technischer Review jederzeit von den Projektteilnehmern initiiert und durchgeführt werden. Das Fraunhofer SIT hat zu diesem Technischen Review eine Sicherheits- Checkliste erstellt die als Anhang ( Checkliste zur Sicherheitsarchitektur von Softwarereleases ) zu diesem Dokument geliefert wird. Für die Einbindung externer Bib- Version Juni 2013 Seite 11/43

12 liotheken hat das Fraunhofer SIT den Anhang Fragebogen zu externen Bibliotheken erstellt. Wie im Dokument D08-QM Review-Konzept PersoApp festgelegt, ist die Grundlage für die Planung und Durchführung der Reviews der Standard IEEE Std In Anlehnung an dieses werden folgende Rollen für das Technische Review festgelegt: Entscheidungsträger Der Entscheidungsträger bewertet, ob die Reviewziele erreicht worden sind. Gegebenenfalls kann diese Rolle vom Initiator des Reviews eingenommen werden. Reviewleiter Der Reviewleiter plant und leitet das Reviewmeeting. Er unterstützt die Teilnehmer bei der Erreichung der Reviewziele und trägt die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Reviewdurchführung, um sie für andere Projektteilnehmer nachvollziehbar und verständlich zu machen. Hierfür kann die Vorlage aus Anhang A Protokollvorlage für Reviewmeeting verwendet werden. Im Gegensatz zum Technischen Review ist eine solche Dokumentation jedoch nicht verpflichtend zu erstellen, daher ist auch die Besetzung dieser Rolle optional. Technischer Gutachter Der technische Gutachter bringt seine fachliche Kompetenz zur Bewertung des Reviewgegenstandes ein und leistet daher einen wesentlichen Beitrag zur Erreichung der Reviewziele. Hierbei ist zu beachten, dass eine Rolle auch von mehreren Personen besetzt werden kann, und eine Person auch mehrere Rollen einnehmen kann. Die Durchführung des Reviews erfordert, dass der Reviewleiter im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. relevante Standards, Richtlinien, etc.) und den Reviewgegenstand (also z.b. das Dokument, den Quelltext, etc.) entsprechend verfügbar macht. Das Fraunhofer SIT hat zu diesem Technischen Review eine Sicherheits- Checkliste erstellt, die als Anhang ( Checkliste zur Sicherheitsarchitektur von Softwarereleases ) zu finden ist. Für die Einbindung externer Bibliotheken hat das Fraunhofer SIT den Anhang Fragebogen zu externen Bibliotheken erstellt. 5.3 Informelles Review Das Informelle Review, gemäß seiner allgemeinen Beschreibung in D08-QM Review-Konzept PersoApp, ist stark an der Vorgehensweise für die Durchführung eines Technischen Reviews angelehnt. Es ist nicht fest in den Entwicklungs-, Testund Release-Zyklus des -Projektes eingeplant und kann daher zu jeder Zeit von den Projektteilnehmern initiiert und durchgeführt werden. Version Juni 2013 Seite 12/43

13 Für die Durchführung gilt es mindestens ein, oder gegebenenfalls mehrere Reviewziele festzulegen. Dabei kann es sich beispielsweise um Folgendes handeln: Überprüfung der Konformität zu einer Richtlinie, einem Standard, etc. Sicherstellung der Benutzbarkeit einer Softwarekomponente Verständlichkeit, Vollständigkeit, etc. Des Weiteren gilt es die folgenden Rollen zu besetzen (angelehnt an IEEE Std ): Entscheidungsträger Der Entscheidungsträger bewertet, ob die Reviewziele erreicht worden sind. Gegebenenfalls kann diese Rolle vom Initiator des Reviews eingenommen werden. Reviewleiter Der Reviewleiter plant und leitet das Reviewmeeting. Er unterstützt die Teilnehmer bei der Erreichung der Reviewziele und trägt die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Reviewdurchführung, um sie für andere Projektteilnehmer nachvollziehbar und verständlich zu machen. Hierfür kann die Vorlage aus Anhang A Protokollvorlage für Reviewmeeting verwendet werden. Im Gegensatz zum Technischen Review ist eine solche Dokumentation jedoch nicht verpflichtend zu erstellen, daher ist auch die Besetzung dieser Rolle optional. Technischer Gutachter Der technische Gutachter bringt seine fachliche Kompetenz zur Bewertung des Reviewgegenstandes ein und leistet daher einen wesentlichen Beitrag zur Erreichung der Reviewziele. Hierbei ist zu beachten, dass eine Rolle auch von mehreren Personen besetzt werden kann, und eine Person auch mehrere Rollen einnehmen kann. Die Durchführung des Reviews erfordert, dass der Reviewleiter im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. relevante Standards, Richtlinien, etc.) und den Reviewgegenstand (also z.b. das Dokument, den Quelltext, etc.) entsprechend verfügbar macht. 5.4 Inspektion eines Major-Release-Update Der Bedarf für eine Inspektion der Major-Release-Updates wurde in der Projektplanung nicht separat definiert. Allerdings ergibt sich der Bedarf implizit aus den Anforderungen. Im Projekt sind fünf Major Releases geplant. Jedes Major- Release-Update sollte einer Inspektion unterzogen werden. Dies gilt auch dann, wenn es sich um einen verkürzten Releasezyklus wie im Dokument D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates handelt. Inspektionen außerhalb von Major-Release-Updates sind nicht zu empfehlen. Version Juni 2013 Seite 13/43

14 Gemäß des Standards IEEE Std sind folgende Rollen bei Inspektionen von Major-Release-Updates zu definieren: Leiter der Inspektion Der Leiter der Inspektion plant und leitet die Inspektion. Er identifiziert alle wichtigen Dokumente sowie die Module der Software, die für die Inspektion hilfreich sind. In seiner Verantwortung liegen ferner die Planung und Vorbereitung der Inspektionssitzung. Er trägt dazu bei, dass die Ziele der Inspektion erreicht werden. Schließlich trägt er die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Durchführung der Inspektion. Damit ist sie für andere Projektteilnehmer nachvollziehbar und verständlich. Für die Inspektion ist eine ausführliche Dokumentation sehr wichtig. Die gefundenen Anomalien und festgelegten Lösungsansätze müssen dokumentiert werden. Dies sichert, dass im Rahmen der eventuell durchzuführenden Prüfung alle Anomalien aus der ursprünglichen Inspektionssitzung beachtet werden. Lektor Die Aufgabe des Lektors ist es, die Teilnehmer der Inspektionssitzung durch die Software zu leiten. Er interpretiert die Arbeitsergebnisse und zeigt wichtige Aspekte für die Inspektion auf. Bei größerer Software ist es sinnvoll, den Arbeitsaufwand auf mehrere Lektoren zu verteilen. Diese bereiten jeweils nur ein oder wenige Module der Software auf. Entwickler Der Entwickler ist für die jeweilige Software oder das zu inspizierende Modul verantwortlich. In seiner Verantwortung liegt, dass die Software den Anforderungen aus dem Dokument D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates, um für die Inspektion bereit zu sein. Gegebenenfalls obliegt ihm die Aufgabe, Überarbeitungen, die während der Inspektion festgelegt wurden, durchzuführen. Technischer Gutachter Der technische Gutachter bietet seine Fachkompetenz an, um das Management bei der Bewertung des Gegenstands für die Inspektion zu unterstützen. Die Besetzung einer Rolle kann durch mehrere Personen erfolgen, auch kann eine Person mehrere Rollen zugleich einnehmen. Die Festlegung der Rollenbesetzung obliegt dem Leiter der Inspektion. Des Weiteren liegt es in seiner/ihrer Verantwortung, dass im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. Kennzahlen, Projektdokumentationen, etc.) und der Gegenstand der Inspektion entsprechend verfügbar gemacht wird. 5.5 Management Review Das Management Review wird von der Projektleitung initiiert und mindestens einmal jährlich durchgeführt. Darüber hinaus können bei Bedarf zu jedem Zeitpunkt im Version Juni 2013 Seite 14/43

15 Entwicklungs-, Test- und Release-Zyklus außerplanmäßige Management Reviews initiiert werden. In jedem Fall ist die Durchführung jedoch identisch. Zunächst gilt es auch hier ein, oder gegebenenfalls mehrere Reviewziele festzulegen. Dies sind beispielsweise: Bewertung des Projektfortschritts Bewertung der Ressourcenplanung Bewertung der Projektziele Zum anderen gilt es die folgenden Rollen zu besetzen (angelehnt an IEEE Std ): Entscheidungsträger Der Entscheidungsträger bewertet, ob die Reviewziele erreicht worden sind. Gegebenenfalls kann diese Rolle vom Reviewleiter, oder von der Projektleitung übernommen werden. Reviewleiter Der Reviewleiter plant und leitet das Reviewmeeting. Er unterstützt die Teilnehmer bei der Erreichung der Reviewziele und trägt die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Reviewdurchführung, um sie für andere Projektteilnehmer nachvollziehbar und verständlich zu machen. Hierfür kann die Vorlage aus Anhang A Protokollvorlage für Reviewmeeting verwendet werden. Im Gegensatz zum Informellen Review ist hier eine ausführliche Dokumentation obligatorisch, daher ist die Besetzung dieser Rolle nicht optional. Management Diese Rolle ist beispielsweise durch Projektleiter, Teilprojektleiter und Modulverantwortliche zu besetzen. Sie bringen ihre Fachkompetenz zur Bewertung des Reviewgegenstandes ein und leisten daher einen wesentlichen Beitrag zur Erreichung der Reviewziele. Technischer Gutachter Der technische Gutachter bietet seine Fachkompetenz an, um das Management bei der Bewertung des Reviewgegenstandes zu unterstützen. Die Besetzung einer Rolle kann durch mehrere Personen erfolgen, auch kann eine Person mehrere Rollen zugleich einnehmen. Die Festlegung der Rollenbesetzung obliegt dem Reviewleiter. Des Weiteren liegt es in seiner/ihrer Verantwortung, dass im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. Kennzahlen, Projektdokumentationen, etc.) und der Reviewgegenstand (also z.b. das Dokument, die Prozessbeschreibung, etc.) entsprechend verfügbar gemacht wird. Handlungsleitend und unterstützend für die Planung und Durchführung eines Management Reviews ist Anhang B Checkliste Management Review. Version Juni 2013 Seite 15/43

16 6 Interne und externe Anforderungen In diesem Kontext betreffen interne Anforderungen insbesondere die Einhaltung zeitlicher Festlegungen. Zum einen gilt es alle Aktivitäten zur Planung und Durchführung von Reviews in Übereinstimmung mit den Festlegungen in diesem Dokument zu erledigen. Zum anderen gilt es die Nachbesserungsarbeiten an Reviewgegenständen zeitnah abzuschließen und die Action Items im Rahmen der zeitlichen Vorgaben abzuarbeiten. Externe Anforderungen ergeben sich durch etwaige Standards, Richtlinien und andere Projektvorgaben, deren Einhaltung verbindlich ist, und somit im Zuge der Reviewdurchführung für eine Bewertung zu berücksichtigen sind. 7 Mitgeltende Dokumente D03-QM Entwurfs- und Entwicklungsprozess von sicheren Open-Source- Softwaremodulen der PersoApp D04-QM Programmierrichtlinien zur Erstellung von - Softwaremodulen D08-QM Review-Konzept D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität Version Juni 2013 Seite 16/43

17 Anhang A Protokollvorlage für Reviewmeeting Allgemeines Datum und Uhrzeit Ort Teilnehmer Reviewgegenstand Vorabinformationen Ziele Wesentliche Diskussionspunkte Inhalte und Ergebnisse Beschlüsse Action Items Bearbeiter Status (offen, erledigt) Enddatum Gutachter Funde Version Juni 2013 Seite 17/43

18 Anhang B Checkliste Management Review Nummer Prüfpunkt Status 1 Zielfestlegung getroffen 2 Verantwortliche Mitarbeiter festgelegt 3 Terminfestlegung getroffen 4 Einladungen versendet 5 Teilnahmebestätigungen eingeholt 6 Vorabinformationen versendet 7 Reviewgegenstand verfügbar gemacht 8 Reviewmeeting durchgeführt 9 Protokoll erstellt 10 Protokoll den Teilnehmern zur Verfügung gestellt 11 Funde an die Bearbeiter des Reviewgegenstandes kommuniziert 12 Bearbeitung aller Funde und Action Items abgeschlossen Version Juni 2013 Seite 18/43

19 Anhang C Checkliste zur Sicherheitsarchitektur von Softwarereleases Anmerkung: Die nachfolgende Checkliste ist sehr umfangreich. Gegebenenfalls sind einzelne Aktivitäten (temporär) im Kontext des -Projektes nicht anwendbar, In diesem Fall kann die betreffende Aktivität ausgelassen werden. 1 Security-relevant aspects of the software 1.1 Outlining the software to develop Key properties Fill the following table with key information about the software to develop Name Version and Release Application Domain Purpose e.g. CRM with social networking integration e.g. Manage customer information; Enable interaction with customers via popular social networking services; Keep track of interaction history over- Architecture view High-level data flow diagram Add high-level data flow diagrams to this section 1.2 Historical information of security incidents Security incident history If the software has previous versions, describe the security history of the software in the following table. Version Type of Incident Source URL/ID Notes e.g. 0.9 e.g. CWE-ID URL or ID of incident, e.g. CVE-ID If information is available elsewhere, replace table with a reference. Does this incident need to be considered specially or not at all for the software under development. and if so, why? Quick assessment If the software has previous versions, provide details about the software s security history by answering the following questionnaire. Are there unresolved vulnerabilities? Version Juni 2013 Seite 19/43

20 List vulnerabilities, impact, type of weakness and other noteworthy information Regarding the history of security incidents, are there peculiarities, like reoccurring vulnerabilities and types of weaknesses? List noteworthy observations of previous software versions Are the vulnerabilities caused by the software itself or by its integrated and open source components? Describe the source of the vulnerabilities Is the security documentation up-to-date and complete? Analyze the security documentation and describe the state of completeness and actuality Are there any special remarks from previous versions, that need to be investigated, e.g. special handling for an integrated or open source component or special configuration/deployment notes? Analyze previous versions of the threat model and other relevant documentation for special remarks and other hints 1.3 Creating security profiles for software components and other similar software projects For each software component create the following table and answer the questionnaire. ID Name Project URL ID for the component Project name of the component URL of the project s main website Version under investigation Date of investigation Investigated version Add when the investigation has been done Organizational measures: Does the project website contain a security section? Yes/No Add further comments if necessary Is there a list of known vulnerabilities and security advisories on the project website? Yes/No Add further comments if necessary Is there a contact point and process for reporting vulnerabilities? Yes/No Add further comments if necessary Does the project have an actively used bug tracking system? Yes/No Add further comments if necessary Vulnerability handling: Are there vulnerability reports present in public vulnerability databases or in the project bug tracking system? Yes/No Add further comments if necessary Version Juni 2013 Seite 20/43

21 If so, what was the impact of those vulnerabilities, e.g. CVSS score? List and comment the impact of the vulnerabilities (at least for the vulnerabilities for software version under investigation); Use standard metrics, such as CVSS, where available. Else describe impact in own words Are the vulnerabilities caused by the software itself or its components? Comment on the sources of the vulnerabilities; how many from components? How many from the core? Was the impact bigger/smaller/equal for vulnerabilities caused by source vs, components Are there peculiarities, like constantly reoccurring vulnerabilities and types of weaknesses? Describe any observation made during the investigation of the software Quickly evaluate how complicated the vulnerabilities were, e.g. simple errors that could have been prevented by secure coding practices or are they more complex? Evaluate why the vulnerabilities occurred in the first place; Where they caused by simple errors, false assumptions, unconsidered use of components, bad component selection? How is the quality of the vulnerability handling of the project? How long did it take to fix the vulnerability? Are vulnerabilities from public vulnerability databases also present in the projects bug tracking system? Have the fixes been adequately documented in either changelogs or the projects security documentation? Analyze and comment on the vulnerability handling of the software project Quality of code: Is the code well-structured? Yes/No Add further comments if necessary Is the code well-commented? Are all or most classes/files commented or just the core? Are the comments in general easily understandable or is expert knowledge needed? Yes/No Add further comments if necessary Are there many "TODO" or "FIXME" comments? Yes/No Add further comments if necessary, such as number of TODOs, and FIXMEs, number of files the comments occurred,other hints on possible project immaturity or incompleteness Are check-ins to the revision control system of the software well-commented and describe accurately what a check-in was about? Yes/No Add further comments if necessary Deployment: Is the default deployment of the software secure? Are there any default passwords, ports which need to be firewalled, etc.? Yes/No Add further comments if necessary Which user's rights are needed to run the software and is it possible to run the software in restricted (hardened) environments, e.g. chroot or jails in Unix/Linux? Yes/No Add further comments if necessary Version Juni 2013 Seite 21/43

22 Security documentation: Is there security documentation available for the end-user? Yes/No Add further comments if necessary Is the security documentation up-to-date and comprehensive? Yes/No Add further comments if necessary Is the documentation focusing solely on the software or does it, e.g., consider different usage environments of the software? Quickly analyze the security documentation of the software and comment on its completeness regarding usage environments, special configurations, etc Has the product undergone a security assessment and if so, are the results publicly available? Yes/No Add further comments if necessary If the product provides security features, is the security architecture welldocumented? Yes/No Add further comments if necessary If the product provides security features, are those features based on industry best practices and standards, e.g. use of well-known and tested cryptographic algorithms and implementations, support for enforcement of password policies if applicable? Yes/No Add further comments if necessary If a full security assessment of the component is available, replace the questionnaire with a reference to the full assessment. If the architect has doubts in the security level of the component, he should commission a full security assessment for the component to security expert Security profile for similar software projects Identify similar software projects. For each similar software, create the following table and answer the questionnaire. ID ID for the component Name Project name of the component Vendor Vendor name Project URL Add url to projects main site Version under investigation Investigated Version Date of investigation Add when the investigation has been done Are there vulnerability reports present in public vulnerability databases or in the project bug tracking system? Yes/No Add further comments if necessary If so, what was the impact of those vulnerabilities, e.g. CVSS score? List and comment the impact of the vulnerabilities (at least for the vulnerabilities for software version under investigation); Use standard metrics, such as CVSS, where available. Else describe impact in own words Are the vulnerabilities caused by the software itself or its components? Comment on the sources of the vulnerabilities; how many from components? How many from the core? Was the impact bigger/smaller/equal for vulnerabilities caused by source vs, components Version Juni 2013 Seite 22/43

23 Are there peculiarities, like constantly reoccurring vulnerabilities and types of weaknesses? Describe any observation made during the investigation of the software Are there common vulnerabilities to the software project under development? Compare the vulnerabilities of the software under development with those of the software under investigation; Are there similarities? Are there vulnerabilities caused by components that are also used in the software project under development? Analyze whether vulnerable components of the software under investigation are also used in the software under development; If so, are the vulnerabilities relevant for the software under development or is there some sort of mitigation? Are there solutions or mitigations to software and component vulnerabilities that are useful for the software project under development? If the software under investigation has or has had similar security problems as the software under development, analyze the solutioner s from the 3rd party and comment on quality and applicability for the software under development 1.4 Identify asset stakeholders In the following table, describe the asset stakeholder for the software to develop. ID Asset Stakeholder Optional comment or description S1 Add first asset stakeholder Add comment or description, if necessary S2 Add second asset stakeholder Add comment or description, if necessary S3 Add third asset stakeholder Add comment or description, if necessary SN Add further asset stakeholder Add comment or description, if necessary 1.5 Collect relevant assets Collect assets security measures shall protect and identify the related asset stakeholders. ID Asset Asset Stakeholders A1 Add first asset Add reference to stakeholder (e.g., S1 ) A2 Add second asset Add reference to stakeholder (e.g., S1, S2 ) A3 Add third asset Add reference to stakeholder AN Add further assets Add further references to stakeholders 1.6 Specify and rank security objectives for assets Create the following table for each security objective ID Short Name Security Objective O1: Add the considered security objective ( e.g., here Confidentiality of health records ) Version Juni 2013 Seite 23/43

24 Asset A1 Add the affected asset Stakeholder S1 Add the affected asset stakeholder Specification Provide more specific information on the security objective Ranking of security objective (condition under which a violation of the security objective would be considered negligible, marginal, critical, or catastrophic.) Negligible Marginal Critical Catastrophic Describe negligible impact scenarios Describe marginal impact scenarios Describe critical impact scenarios Describe catastrophic impact scenarios 1.7 List actors that interact with the software List all actors that interact with the software in the following table, describe them briefly, list their privileges and explain how an actor can become another actor through which mechanisms. ID Actor Description/Privileges AC1 Anonymous/Public (Note that for security considerations there always exist an anonymous/public actor ) Describe the actor and her privileges ACn Add further actors, each row one actor Describe the further actors and their privileges 1.8 List intended role changes provided to the actors List all possible changes in roles the software allows ID Source Actor Destination Actor Procedure RC1 Anonymous/Public (Note that for security considerations there always exist an anonymous/public actor ) Describe the destination actor the source actor can change to Describe how the procedure provided by the software allowing the change of roles RCn Add further change procedures the software shall provide, each row one pair source actor- destination actor and one procedure Add further destination actors Add further procedures 1.9 Classify processed data Identify and classify data the software will process once it is deployed. Also identify all representations of these data and create an access matrix for each data representation. The matrices should contain all actors that are identified in the previous step and marks indicating granted permissions. You can use the following tables as a starting point: Data class and representation ID: DC1 Add description of the data class and its representation considered in this table Actor Create Read Update Delete Version Juni 2013 Seite 24/43

25 Anonymous/Public Add x if privilege granted Add x if privilege granted Add x if privilege granted Add x if privilege granted Add further actors Add x if privilege granted Add x if privilege granted Add x if privilege granted Add x if privilege granted ID Data type Addressed In-transit In-process DR1 Add data type Describe storage locations Describe transfer channels List modules where this data type is processed 1.10 Identify technologies, platforms, and architectural paradigms List technologies used by the software and explain briefly why they are used. ID Technology Why it is used TE1 Added first technology used by the software Describe briefly why the technology is used TEN Added further technologies used by the software Add further descriptions List platforms supported by the software and explain briefly why these platforms are supported. ID Platform Why it is supported P1 Added first platform supported by the software Describe briefly why the platform is supported PN Added further platforms supported by the software Add further descriptions List architectural paradigms, applied by the software. Explain briefly why particular paradigms have been applied. ID Architectural Paradigm Why it is used AR1 Added first architectural paradigm applied by the software Describe briefly why the paradigm has been applied ARN Added further architectural paradigms applied by the software Add further descriptions 2 Identify and prioritize threats 2.1 Weaknesses identified using CWE Collect the weaknesses identified with the CWE in the following table. Add y for yes, or n for no in the columns Verified?, Applicable?, Requires Actions?, and Mitigated? CWE- ID Add CW-ID, e.g. 259 Name Affected Component/Function Add weakness name, e.g., Use of Hardcoded Password Describe the possibly affected components, e.g,, Default.conf configuration file Affected Security Objectives Reference the affect security objective, e.g., O5 Verified? Applicable? Requires Action? y or n y or n y or n Mitigated? y or n Add further CWE- Add further weaknesses Describe the possibly affected components Reference the affect y or n y or n y or n y or n Version Juni 2013 Seite 25/43

26 IDs security objective 2.2 Threats identified with STRIDE DFD entities In the following table list the entities identified in the data flow diagram. The table contains some example, to show the IDs for different entity types. ID Entity Type Description DF0 Data Flow Entity Name and short description of its function DFN Data Flow Entity Name and short description of its function DS0 Data Storage Entity Name and short description of its function DSN Data Storage Entity Name and short description of its function P0 Process Entity Name and short description of its function PN Process Entity Name and short description of its function EE0 External Entity Entity Name and short description of its function EEN External Entity Entity Name and short description of its function Threats Collect the threats identified with the STRIDE methodology. ID T0 TN Threat Against DFD Entry ID, e.g. DF0 PN Type Description Mitigation Note Either Spoofing, Tampering, Information Disclosure, DoS, or Elevation of Privilege Shortly describe how an exploit might look like and which assets and stakeholders are involved Describe a mitigation if available Comment, if for example, a threat is not relevant or especially relevant 2.3 Attacker-motives assessment Asses for each adversary type the possible benefits of an attack and attack costs. On the basis of this information decide whether the adversary type is relevant for the software at hand. Type of adversary Attack benefits Can an attack on the software serve the adversaries motives? Attack costs How difficulty is an attack? How easy can an attacker get in contact with the system? Are there cheaper ways to achieve the same goal without attacking the software? Adversary class relevant? Decision and rationale Regular users Describe how an attacker from this adversary class could benefit from an attack. Describe the effort required to perform an attack and alternative ways of achieving the same goal. Decide whether attackers of this adversary class are likely to attack the software. Justify the Version Juni 2013 Seite 26/43