Sicherheitsüberprüfung

The goal of security review in the OpenStack community is to identify weaknesses in design or implementation of OpenStack projects. While rare, these weaknesses could potentially have catastrophic effects on the security of an OpenStack deployment, and therefore work should be undertaken to minimize the likelihood of these defects in released projects. Over the course of a security review, the following should be known and documented:

  • Alle Einstiegspunkte in ein System

  • Welche Vermögenswerte sind gefährdet

  • Wo Daten bestehen bleiben

  • Wie Daten zwischen Komponenten des Systems reisen

  • Datenformate und Transformationen

  • Externe Abhängigkeiten des Projekts

  • Ein vereinbarter Satz von Erkenntnissen und/oder Mängeln

  • Wie das Projekt mit externen Abhängigkeiten interagiert

A common reason to perform a security review on an OpenStack deliverable repository is to assist with Vulnerability Management Team (VMT) oversight. The OpenStack VMT lists overseen repositories where the report reception and disclosure of vulnerabilities is managed by the VMT. While not a strict requirement, some form of security review, audit or threat analysis helps everyone more easily pinpoint areas where a system is more prone to vulnerabilities and solve them before they become a problem for users.

The OpenStack VMT suggests that an architectural review of the recommended deployment for a project is an appropriate form of security review, balancing the need for review with the resource requirements for a project of the scale of OpenStack. Security architecture review is also often referred to as threat analysis, security analysis or threat modeling. In the context of OpenStack security review, these terms are synonymous for an architectural security review which may identify defects in the design of a project or reference architecture, and may lead to further investigative work to verify parts of the implementation.

Security review is expected to be the normal route for new projects and for cases where third parties have not performed security reviews or are unable to share their results. Information for projects that require a security review will be available in the upcoming security review process.

In cases where a security review has already been performed by a third party, or where a project prefers to use a third party to perform their review, information on how to take the output of that third party review and submit it for validation will be available in the upcoming third party security review process.

In beiden Fällen sind die Anforderungen an Dokumentations-Artefakte ähnlich - das Projekt muss ein Architektur-Diagramm für eine Best-Practice-Bereitstellung bieten. Schwachstellen-Scans und statische Analysen-Scans sind keine ausreichenden Beweise für eine Überprüfung durch Dritte, obwohl sie im Rahmen des Entwicklungszyklus für alle Teams dringend empfohlen werden.