├── CHANGELOG.md ├── Dockerfile ├── README.md ├── asvs.py ├── de ├── 0x00-Header.md ├── 0x01-Frontispiece.md ├── 0x02-Preface.md ├── 0x03-Using-CSVS.md ├── 0x10-V01-Organizational.md ├── 0x11-V02-Infrastructure.md ├── 0x12-V03-Containers.md ├── 0x13-V04-Orchestration-Management.md ├── 0x14-V05-Image-Distribution.md ├── 0x15-V06-Secrets-and-Keys.md ├── 0x16-V07-Network.md ├── 0x17-V08-Storage.md ├── 0x18-V09-Logging-Monitoring.md ├── 0x19-V10-Integration.md ├── 0x20-V11-Disaster-Recovery.md ├── 0x21-V12-Testing.md ├── 0x90-Appendix-A_Glossary.md └── 0x91-Appendix-B_References.md ├── en ├── 0x00-Header.md ├── 0x01-Frontispiece.md ├── 0x02-Preface.md ├── 0x03-Using-CSVS.md ├── 0x10-V01-Organizational.md ├── 0x11-V02-Infrastructure.md ├── 0x12-V03-Containers.md ├── 0x13-V04-Orchestration-Management.md ├── 0x14-V05-Image-Distribution.md ├── 0x15-V06-Secrets-and-Keys.md ├── 0x16-V07-Network.md ├── 0x17-V08-Storage.md ├── 0x18-V09-Logging-Monitoring.md ├── 0x19-V10-Integration.md ├── 0x20-V11-Disaster-Recovery.md ├── 0x21-V12-Testing.md ├── 0x90-Appendix-A_Glossary.md └── 0x91-Appendix-B_References.md ├── export.py ├── generate-csv.py ├── generate_document.sh ├── generate_document_with_docker.sh ├── images ├── csvs-levels.png ├── license.png ├── logo.png └── redguard-logo.png └── templates └── reference.docx /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | 3 | All notable changes to this project will be documented in this file. For changes that don't change the actual content of the project (e.g. fixing typos) no new version is released but an existing release is updated. 4 | 5 | Please note that the _Added_, _Changed_, and _Remove_ sections for each release reference the requirement IDs out of the parent version before the moves in section _Moved_ have been applied. 6 | 7 | ## [v1.0] - 2019-02-26 8 | 9 | ### Added 10 | 11 | - This CHANGELOG file to hopefully serve as an evolving example of a 12 | standardized open source project CHANGELOG. 13 | - Control objective for _Secrets and Keys_. 14 | - Add extensive .gitignore file. 15 | - Add _1.6_. 16 | - Add _3.13_. 17 | - Add _6.10_. 18 | 19 | ### Changed 20 | 21 | - Adapt readme file for v1.0. 22 | - Rename section _Overall-Security_ to _Secrets and Keys_. 23 | - Make _1.3_ more clear. 24 | - Make _1.4_ more clear. 25 | - Make _1.5_ more clear. 26 | - Merged _2.1_ and _2.2_ into _2.1_ 27 | - Make _2.4_ more clear. 28 | - Add AppArmor to _2.7_. 29 | - Include logging to _2.11_. 30 | - Expand the scope for _2.12_. 31 | - Add examples to _2.13_. 32 | - Make clear, that _3.4_ requires a specific seccomp-profile. 33 | - Only require _3.6_ for level 3. 34 | - Only require _3.7_ for level 3 as DCT is only required for that level in _6.2_. 35 | - Only require _3.10_ for level 2 and 3. 36 | - Extend _3.12_. 37 | - Provide example in _3.13_. 38 | - Only require _4.4_ for level 3. 39 | - Only require _5.1_ for level 3. 40 | - Make _5.5_ more clear and restrictive. 41 | - Make _7.2_ more clear. 42 | - Extend _7.6_ with examples. 43 | - Extend _10.5_ with examples and only require it for level 2 and 3. 44 | - Only require _10.6_ for level 3. 45 | - Fix typos. 46 | 47 | ### Moved 48 | 49 | - _2.3_ is now _2.2_. 50 | - _2.4_ is now _2.3_. 51 | - _2.5_ is now _2.4_. 52 | - _2.6_ is now _2.5_. 53 | - _2.7_ is now _2.6_. 54 | - _2.8_ is now _2.7_. 55 | - _2.9_ is now _2.8_. 56 | - _2.10_ is now _2.9_. 57 | - _2.11_ is now _2.10_. 58 | - _2.12_ is now _2.11_. 59 | - _2.13_ is now _2.12_. 60 | - _2.14_ is now _2.13_. 61 | - _2.15_ is now _2.14_. 62 | - _2.16_ is now _2.15_. 63 | - _3.13_ is now _3.14_. 64 | - _3.14_ is now _3.15_. 65 | - _6.14_ is now _2.14_. 66 | - _6.1_ is now _2.15_. 67 | - _6.6_ is now _2.16_. 68 | - _4.7_ is now _4.6_. 69 | - _4.9_ is now _4.7_. 70 | - _4.10_ is now _4.8_. 71 | - _4.11_ is now _4.9_. 72 | - _4.12_ is now _4.10_. 73 | - _6.2_ is now _6.1_. 74 | - _6.4_ is now _6.2_. 75 | - _6.7_ is now _6.3_. 76 | - _6.8_ is now _6.4_. 77 | - _6.9_ is now _6.5_. 78 | - _6.10_ is now _6.6_. 79 | - _6.11_ is now _6.7_. 80 | - _6.12_ is now _6.8_. 81 | - _6.13_ is now _6.9_. 82 | - _6.3_ is now _10.6_. 83 | - _6.5_ is now _12.11_. 84 | - _7.5_ is now _7.4_. 85 | - _7.6_ is now _7.5_. 86 | - _7.7_ is now _7.6_. 87 | - _7.8_ is now _7.7_. 88 | - _7.9_ is now _7.8_. 89 | - _7.10_ is now _7.9_. 90 | - _7.11_ is now _7.10_. 91 | - _7.12_ is now _7.11_. 92 | - _7.13_ is now _7.12_. 93 | 94 | ### Removed 95 | 96 | - Specific sizing definitions in _2.5_. 97 | - _4.6_ as it is not really a security concern and was unclear. 98 | - _4.8_ as it is not really a security concern. 99 | - _7.4_ as it is not really a security concern. 100 | - Unneeded Microsoft Word and .DS_Store meta files. 101 | 102 | ## [v0.1] - 2018-09-25 103 | 104 | ### Added 105 | 106 | - Initial DRAFT version for the whole CSVS. 107 | -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | FROM alpine 2 | RUN apk update && apk upgrade && apk add \ 3 | bash \ 4 | wget 5 | WORKDIR /app/ 6 | ARG pandoc_version=2.5 7 | RUN wget https://github.com/jgm/pandoc/releases/download/${pandoc_version}/pandoc-${pandoc_version}-linux.tar.gz -O pandoc.tar.gz && \ 8 | tar -xvzf pandoc.tar.gz && \ 9 | rm pandoc.tar.gz && \ 10 | mv pandoc-${pandoc_version}/bin/pandoc /usr/bin/pandoc && \ 11 | rm -r pandoc-${pandoc_version} 12 | CMD ["./generate_document.sh"] 13 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Container Security Verification Standard 2 | 3 | Welcome to the Container Security Verification Standard (CSVS) version 1.0. The CSVS is a community-effort to establish a framework of security requirements and controls that focus on normalizing the functional and non-functional security controls required when designing, developing and testing container-based solutions with a focus on Docker. 4 | 5 | ## Download 6 | 7 | * [Word document](https://github.com/OWASP/Container-Security-Verification-Standard/releases/download/v1.0/container_security_verification_standard_v1.0_en.docx) 8 | * [PDF document](https://github.com/OWASP/Container-Security-Verification-Standard/releases/download/v1.0/container_security_verification_standard_v1.0_en.pdf) 9 | * [Source code](https://github.com/OWASP/Container-Security-Verification-Standard) 10 | 11 | ## Contributing 12 | 13 | We're always looking for people who are willing to review and extend the CSVS. If you feel like you could be one of them, please either just create a pull request with your changes or open an issue if you need any help. 14 | 15 | ## FAQ 16 | 17 | 1. **The document looks similar to the OWASP Application Security Verification Standard. How is it related?** 18 | We love the work done by the OWASP ASVS project team and indeed the overall structure and e.g. the scripts to export the CSVS to different formats is coming from the ASVS. 19 | 2. **Topic XYZ is missing. Why?** 20 | Either it didn't cross our minds yet or we thought it is already covered in one of the requirements in the CSVS. Anyway, please let us know by [opening an issue](https://github.com/OWASP/Container-Security-Verification-Standard/issues/new) or even fork the CSVS and send us a pull request with your proposed changes. 21 | 3. **There are already other documents that cover container security like the [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker/) or [NIST Application Container Security Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf). Why do we need the CSVS?** 22 | Existing documents often contain more than 100 pages or are using a lot of running text. We think there should be a clear standard that allows you to go through and actually verify your level of security related to container solutions. 23 | 4. **Is there any referencing from the CSVS to other standards and vice-versa?** 24 | Unfortunately not yet, but we made sure to cover at least the [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker/) and [NIST Application Container Security Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf). 25 | -------------------------------------------------------------------------------- /asvs.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | ''' ASVS document parser and converter class. 4 | 5 | Based upon code written for MASVS By Bernhard Mueller 6 | 7 | Copyright (c) 2017 OWASP Foundation 8 | 9 | Permission is hereby granted, free of charge, to any person obtaining a copy 10 | of this software and associated documentation files (the "Software"), to deal 11 | in the Software without restriction, including without limitation the rights 12 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 13 | copies of the Software, and to permit persons to whom the Software is 14 | furnished to do so, subject to the following conditions: 15 | 16 | The above copyright notice and this permission notice shall be included in all 17 | copies or substantial portions of the Software. 18 | 19 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 20 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 21 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 22 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 23 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 24 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 25 | SOFTWARE. 26 | 27 | ''' 28 | 29 | import os 30 | import re 31 | import json 32 | from xml.sax.saxutils import escape 33 | import csv 34 | 35 | try: 36 | from StringIO import StringIO 37 | except ImportError: 38 | from io import StringIO 39 | 40 | 41 | class ASVS: 42 | ''' Creates requirements list out of markdown files. ''' 43 | requirements = [] 44 | 45 | def __init__(self): 46 | for file in os.listdir("en"): 47 | 48 | if re.match("0x\d{2}-V", file): 49 | for line in open(os.path.join("en", file)): 50 | regex = re.compile('\\*\\*(\d\.\d+)\\*\\*\s\|\s{0,1}(.*?)\s{0,1}\|') 51 | m = re.search(regex, line) 52 | if m: 53 | req = {} 54 | req['id'] = m.group(1) 55 | req['text'] = m.group(2) 56 | req['file'] = file 57 | 58 | self.requirements.append(req) 59 | 60 | def to_json(self): 61 | ''' Returns a JSON-formatted string ''' 62 | return json.dumps(self.requirements) 63 | 64 | def to_xml(self): 65 | ''' Returns XML ''' 66 | xml = '' 67 | 68 | for r in self.requirements: 69 | 70 | xml += "" + escape(r['text']) + "\n" 71 | 72 | return xml 73 | 74 | def to_csv(self): 75 | ''' Returns CSV ''' 76 | si = StringIO() 77 | 78 | writer = csv.DictWriter(si, ['id', 'text']) 79 | writer.writeheader() 80 | writer.writerows(self.requirements) 81 | 82 | return si.getvalue() 83 | -------------------------------------------------------------------------------- /de/0x00-Header.md: -------------------------------------------------------------------------------- 1 | # Container Security Verification Standard 2 | 3 | ![logo](../images/logo.png) 4 | 5 | Version 1.0 6 | 7 | Datum: [date] 8 | -------------------------------------------------------------------------------- /de/0x01-Frontispiece.md: -------------------------------------------------------------------------------- 1 | # Vorwort 2 | 3 | ## Über den Standard 4 | 5 | Der Container Security Verification Standard ist eine Liste von Sicherheitsanforderungen oder -tests, die von Architekten, Entwicklern, Testern, Sicherheitsfachleuten und sogar Verbrauchern verwendet werden können, um zu definieren, was ein sicherer Container und eine entsprechende Infrastruktur sind. 6 | 7 | ## Copyright und Lizenz 8 | 9 | ![license](../images/license.png) 10 | 11 | Copyright © 2019 OWASP Foundation. Dieses Dokument steht unter der Creative Commons Attribution ShareAlike 4.0 Lizenz. Für jede Wiederverwendung oder Weitergabe müssen Sie anderen die Lizenzbestimmungen für dieses Werk mitteilen. 12 | 13 | Der zum Erstellen des CSVS-Dokuments und der CSVS-Struktur verwendete Code basiert auf dem OWASP ASVS Projekt. 14 | 15 | ## Mitarbeit 16 | 17 | Wenn Sie innerhalb des Standards Probleme finden, die behoben werden sollten: 18 | 19 | * Aufbau des Standards. 20 | * Fehlende Kontrollen. 21 | * Ineffektive oder veraltete Kontrollen. 22 | * Unklare Formulierungen, Rechtschreibung, Grammatikprobleme. 23 | * Formatierungsprobleme. 24 | * Übersetzungsprobleme - Wenn der Wortlaut einer Anforderung in Ihrer Sprache schwer verständlich ist, lassen Sie es uns bitte wissen. Wenn es nicht auf Spanisch oder Thailändisch funktioniert, funktioniert es wahrscheinlich auch nicht auf Englisch. 25 | * Übersetzungsangebote - lassen Sie es uns bitte wissen, damit wir Sie mit Leuten verbinden können, die eventuell bereits an Ihrer Sprache arbeiten. 26 | 27 | Bitte melden Sie Probleme unter https://github.com/OWASP/Container-Security-Verification-Standard/issues 28 | 29 | | Lead Authors | Contributors & Reviewers | Übersetzer | 30 | | --- | --- | --- | 31 | | Sven Vetsch | Alexander Hermann, Dominik Nufer, Dominique Meier, Patrick Schmid, Daniel Tschabold | Stephan Kaps (Deutsch) | 32 | 33 |


34 | 35 | Ein spezieller Dank für das Sponsoring des Projekts geht an: 36 | 37 | [![logo](../images/redguard-logo.png)](https://www.redguard.ch/) 38 | -------------------------------------------------------------------------------- /de/0x02-Preface.md: -------------------------------------------------------------------------------- 1 | # Übersicht 2 | 3 | Willkommen beim Container Security Verification Standard (CSVS), Version 1.0. Bei CSVS handelt es sich um ein Gemeinschaftsprojekt zur Definition einer Reihe von Sicherheitsanforderungen, die sich auf die Normalisierung der funktionalen und nicht funktionalen Sicherheitskontrollen konzentrieren, die beim Definieren, Entwickeln und Testen containergestützter Lösungen (mit Schwerpunkt auf Docker) erforderlich sind. 4 | 5 | Wir gehen davon aus, dass die Inhalte des CSVS wahrscheinlich nie zu 100% von allen Seiten einheitlich akzeptiert werden. Die Risikoanalyse ist in gewissem Maße immer subjektiv, was eine Herausforderung darstellt, wenn versucht wird, Anforderungen zu verallgemeinern. Wir freuen uns immer über Ihr Feedback und über andere Ansichten bezüglich der im CSVS enthaltenen Anforderungen. 6 | -------------------------------------------------------------------------------- /de/0x03-Using-CSVS.md: -------------------------------------------------------------------------------- 1 | # Verwendung des CSVS 2 | 3 | Der CSVS hat zwei Hauptziele: 4 | 5 | * Unterstützung von Organisationen bei der Entwicklung und Wartung sicherer Container und Containerinfrastrukturen. 6 | * Schaffen eines einheitliches Verständnisses zwischen Sicherheitsdienstleistern, Anbietern von Sicherheitstools und Anwendern. 7 | 8 | ## Sicherheitsüberprüfungsstufen für Container 9 | 10 | Der CSVS definiert drei Sicherheitsüberprüfungsstufen, wobei mit jeder Stufe die Sicherheitsanforderungen erhöht werden. 11 | 12 | * CSVS Level 1 ist grundsätzlich für alle Containerprojekte gedacht. 13 | * CSVS Level 2 ist für Containerprojekte gedacht, die mit vertraulichen Daten oder Geschäftslogik in Kontakt kommen und entsprechend zusätzlichen Schutz erfordern. 14 | * CSVS Level 3 ist für die kritischsten Containerprojekte gedacht, die hoch sensitive Transaktionen durchführen, vertrauliche persönliche oder medizinische Daten enthalten, oder für alle Container, die grundsätzlich ein Höchstmaß an Vertrauen erfordern. 15 | 16 | Jede Stufe enthält eine Liste von Sicherheitsanforderungen. Jede dieser Anforderungen kann auch sicherheitsspezifischen Features und Funktionen zugeordnet werden, die in die Container oder die zugrunde liegende Infrastruktur integriert werden müssen. 17 | 18 | ![csvs-levels](../images/csvs-levels.png) 19 | 20 | Bild 1 - Container Security Verification Standard Sicherheitsüberprüfungsstufen 21 | 22 | ## Verwendung des Standards 23 | 24 | Eine der besten Möglichkeiten, den Container Security Verification Standard zu verwenden, besteht darin, ihn als Vorlage zu verwenden, um eine Sicherheitscheckliste zu erstellen, die für Ihr Projekt, Ihre Plattform oder Ihre Organisation spezifisch angepasst wird. Das Anpassen des CSVS an Ihre Anwendungsfälle erhöht den Fokus auf die Sicherheitsanforderungen, die für Ihre Projekte und Umgebungen am relevantesten sind. 25 | 26 | ### Level 1: Opportunistisch 27 | 28 | Eine container-basierte Infrastruktur oder Lösung erreicht CSVS Level 1 (oder _Opportunistisch_), wenn sie bekannte Sicherheitsbedrohungen, die leicht zu entdecken und leicht zu missbrauchen sind, angemessen abwehrt. 29 | 30 | Stufe 1 eignet sich in der Regel für Anwendungen, bei denen ein geringes Vertrauen in die korrekte Verwendung von Sicherheitskontrollen einschließlich der Verfügbarkeit erforderlich ist, oder um eine schnelle Analyse einer Flotte von Unternehmensanwendungen durchzuführen oder die Erstellung einer priorisierten Liste von Sicherheitsanforderungen als Teil eines mehrphasigen Vorgehens zu unterstützen. Wir betrachten Level 1 als das für alle Containerprojekte erforderliche Minimum. Wenn die von Ihrer containergestützten Lösung verarbeiteten Daten eine hohe sensitivität aufweisen, sollte eine höhere Prüfungsstufe gewählt werden. 31 | 32 | ### Level 2: Standard 33 | 34 | Eine containergestützte Infrastruktur / Lösung erreicht CSVS Level 2 (oder Standard), wenn sie die meisten Risiken, die heute mit containergestützten Lösungen verbunden sind, angemessen abwehrt. 35 | 36 | Stufe 2 stellt sicher, dass Sicherheitskontrollen vorhanden sind, effektiv / getestet sind und in der übergreifend verwendet werden. Stufe 2 ist in der Regel für containergestützte Projekte geeignet, die wichtige und vertrauliche Transaktionen abwickeln, einschließlich solcher, die vertrauliche Informationen verarbeiten, geschäftskritische oder vertrauliche Funktionen implementieren oder andere vertrauliche Daten verarbeiten. 37 | 38 | ### Level 3: Fortgeschritten 39 | 40 | CSVS Level 3 ist die höchste Überprüfungsstufe innerhalb des CSVS. Diese Ebene ist in der Regel für containergestützte Lösungen reserviert, für die ein sehr hohes Maß an Sicherheit erfordern wie beispielsweise in Bereichen wie Militär, Gesundheit oder innerhalb kritischer Infrastrukturen. 41 | 42 | Unternehmen benötigen möglicherweise CSVS Level 3 für Lösungen, die wichtige Funktionen ausführen, bei denen ein Ausfall die Betriebsabläufe des Unternehmens oder sogar dessen Überlebensfähigkeit erheblich gefährden kann. Eine container-basierte Lösung erreicht CSVS Level 3 (oder Fortgeschritten), wenn sie sich angemessen gegen fortgeschrittene Gegner verteidigt und außerdem Prinzipien eines guten Sicherheitsdesigns aufweist. 43 | 44 | Eine Anwendung auf CSVS Level 3 erfordert eine gründlichere Analyse, Architektur, Codierung und Prüfung als alle anderen Prüfungsstufen innerhalb des Standards. Eine sichere Containerinfrastruktur ist auf sinnvolle Weise modularisiert (um beispielsweise Ausfallsicherheit und Skalierbarkeit zu gewährleisten) und jedes Modul (getrennt durch Netzwerkverbindung und / oder physische Instanz) übernimmt seine eigenen Sicherheitsaufgaben (mehrschichtige Sicherheit), die ordnungsgemäß dokumentiert und getestet werden muss. Zu den Anforderungen gehören Kontrollen zur Gewährleistung der Vertraulichkeit (z. B. Verschlüsselung), Integrität (z. B. Transaktionen, Eingabevalidierung), Verfügbarkeit (z. B. ordnungsgemäße Verteilung der Last), Authentifizierung (auch zwischen Systemen), Autorisierung und Überwachung (Protokollierung). 45 | 46 | ## CSVS in der Praxis anwenden 47 | 48 | Je nach Branche oder spezifischen Informations- und Technologie-Assets, unterscheidet sich die Bedrohungen einzelner Unternehmen. Auch branchenspezifische Compliance-Anforderungen können einen Einfluss auf die Sicherheitsanforderungen einer Unternehmung haben. Obwohl es für jede Branche eindeutige Kriterien und unterschiedliche Bedrohungen gibt, ist es in allen Branchensegmenten ein gemeinsames Thema, dass opportunistische Angreifer nach Schwachstellen suchen, die leicht auszunutzen sind. Aus diesem Grund wird CSVS Level 1 für alle containergestützten Projekte unabhängig von der Branche empfohlen. 49 | 50 | Unternehmen werden dazu aufgefordert, sich eingehender mit ihren spezifischen Risikoeigenschaften zu befassen, die auf der Art ihres Geschäfts beruhen. Am anderen Ende des Spektrums befindet sich CSVS Level 3, das für Fälle reserviert ist, die die Sicherheit von Menschenleben gefährden könnten oder bei denen ein erfolgreicher Angriff die Organisation ernsthaft und nachhaltig beeinträchtigen könnte. 51 | 52 | ## Anwendungsfälle 53 | 54 | ### Als ausführliche Anleitung zur Sicherheitsarchitektur 55 | 56 | Eine der gebräuchlichsten Anwendungen für den Container Security Verification Standard ist die Verwendung als Ressource für Sicherheitsarchitekten. In den beiden wichtigsten Sicherheitsarchitektur-Frameworks, SABSA und TOGAF, fehlen zahlreiche Informationen, die für die Prüfung der Sicherheitsarchitektur für Anwendungen und Container erforderlich sind. Mit dem CSVS können diese Lücken geschlossen werden, indem Sicherheitsarchitekten die Möglichkeit erhalten, häufig auftretende Probleme besser zu vorzubeugen. 57 | 58 | ### Als Ersatz für handelsübliche Checklisten 59 | 60 | Viele Organisationen können vom CSVS profitieren, indem sie eine der drei Ebenen als internen Minimalstandard wählen, statt selbst komplett neue Grundlagen zu definieren und erarbeiten. Der CSVS kann natürlich auch auf die jeweiligen Anforderungen einer Branche oder eines einzelnen Unternehmens angepasst werden. Wenn ein eigener interner Standard basierend auf dem CSVS definiert wird, empfehlen wird, das Mapping auf den CSVS zu erhalten, um die zukünfige Pflege bei neuen Versionen zu vereinfachen. 61 | 62 | ### Für Sicherheitstrainings 63 | 64 | Der CSVS kann auch zum Definieren von Merkmalen einer sicheren Containerinfrastruktur verwendet werden. Bei vielen Sicherheitskursen handelt es sich lediglich um Ethical Hacking Kurse mit wenig Inhalten für den eigentlichen Betrieb. Sicherheitstrainings können den CSVS mit seinem starken Fokus auf proaktiven Sicherheitsanforderungen nutzen, um Good und Best Practices zu schulen. 65 | -------------------------------------------------------------------------------- /de/0x10-V01-Organizational.md: -------------------------------------------------------------------------------- 1 | # V1: Organisatorisch 2 | 3 | ## Sicherheitsziele 4 | 5 | Idealerweise wird Sicherheit in allen Phasen der Entwicklung berücksichtigt. In der Realität spielt die Sicherheit jedoch im Entwicklungsprozess oft erst sehr spät eine Rolle. Neben den technischen Vorgaben, erfordert der Container Security Verification Standard (CSVS) die einhaltung von Prozessen, welche sicherstellen, dass die Sicherheit bei der Planung der Architektur der Lösung explizit berücksichtigt wurde und die Funktionen und Sicherheitsrollen aller Komponenten bekannt sind. 6 | 7 | In der Kategorie "V1" sind Anforderungen an Prozesse, Architektur und Design der Containerlösung aufgeführt. Daher kann diese Kategorie nicht auf technische Testfälle abgebildet werden, sondern muss auf Prozessebene angegangen werden. Darüber hinaus sollte beachtet werden, dass diese Kategorie nicht vollständig, da jede Organisation unterschiedlich strukturiert ist und jedes Setup unterschiedliche organisatorische und prozessuale Anforderungen hat. Der CSVS versucht nur, einige grundlegende Aspekte in dieser Kategorie abzudecken. Es wird dringend empfohlen, die Anforderungen entsprechend um Ihren spezifischen Anforderungen zu erweitern. 8 | 9 | ## Sicherheitsvorgaben 10 | 11 | Bitte beachten Sie, dass die Anforderungen in diesem Abschnitt nicht vollständig sind, da sich viele organisatorische Sicherheitsvorgaben nicht nur auf Containerinfrastrukturen beschränken allerdings einen indirekten Einfluss auf diese haben können. 12 | 13 | | # | Beschreibung | L1 | L2 | L3 | Seit | 14 | | --- | --- | --- | --- | -- | -- | 15 | | **1.1** | Stellen Sie sicher, dass die technischen Mitarbeiter (insbesondere die mit DevOps-Aktivitäten beauftragten Mitarbeiter und Architekten) regelmäßig zu Sicherheitsaspekten der von ihnen verwendeten Technologien geschult werden. | ✓ | ✓ | ✓ | 1.0 | 16 | | **1.2** | Stellen Sie sicher, dass die Manager regelmäßig zu Sicherheitsaspekten der in ihren Projekten verwendeten Technologien geschult werden. | | | ✓ | 1.0 | 17 | | **1.3** | Stellen Sie sicher, dass alle verarbeiteten Daten gemäß vorhandenen internen Datenklassifizierungsvorgaben klassifiziert sind. | ✓ | ✓ | ✓ | 1.0 | 18 | | **1.4** | Stellen Sie sicher, dass jeder Dienst / jede Anwendung (kann aus mehreren Containern bestehen) über ein Sicherheitskonzept verfügt, das Informationen zu den Sicherheitsanforderungen des Dienstes / der Anwendung und zu deren Maßnahmen enthält. | | ✓ | ✓ | 1.0 | 19 | | **1.5** | Stellen Sie sicher, dass identifizierte Sicherheitsrisiken und Sicherheitslücken zeitnah beseitigt werden (oder eine Ausnahme gewährt wird) und nach einem vordefinierten Risiko- und Schwachstellen-Managementprozess zentral verwaltet werden. | | ✓ | ✓ | 1.0 | 20 | | **1.6** | Stellen Sie sicher, dass die Rollen und Verantwortlichkeiten für die Containerinfrastruktur definiert sind. Dies beinhaltet z.B. wer Verbindungen genehmigt oder über die zulässigen Basis-Images entscheidet. | | ✓ | ✓ | 1.0 | 21 | -------------------------------------------------------------------------------- /de/0x11-V02-Infrastructure.md: -------------------------------------------------------------------------------- 1 | # V2: Infrastruktur 2 | 3 | ## Sicherheitsziele 4 | 5 | Die zugrunde liegende Infrastruktur kann für verschiedene Konfigurationen sehr unterschiedlich sein, Sie ist jedoch die Grundlage für alles und muss daher den oberen Schichten die Möglichkeit bieten, das geforderte Sicherheitsniveau zu erreichen. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Stellen Sie sicher, dass die Infrastruktur ausreichende Ressourcen bereitstellt. 10 | * Härten Sie die Basisinfrastruktur einschließlich der Containerplattform. 11 | 12 | ## Sicherheitsvorgaben 13 | 14 | | # | Beschreibung | L1 | L2 | L3 | Seit | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **2.1** | Stellen Sie sicher, dass die Gesamtarchitektur und das Gesamtdesign einschließlich der Vernetzung innerhalb und außerhalb der Containerlösung definiert sind. | ✓ | ✓ | ✓ | 1.0 | 17 | | **2.2** | Stellen Sie sicher, dass die Infrastruktur einschließlich aller Komponenten (Knoten, Netzwerke, Container usw.) dokumentiert ist (idealerweise vollständig automatisiert). | ✓ | ✓ | ✓ | 1.0 | 18 | | **2.3** | Stellen Sie sicher, dass alle verwendeten Komponenten unterstützt / gewartet werden und miteinander kompatibel sind (Betriebssystem, Docker Engine, UCP, DTR, ...). | ✓ | ✓ | ✓ | 1.0 | 19 | | **2.4** | Stellen Sie sicher, dass allen Knoten ausreichende Ressourcen zugewiesen sind, damit sie stabil laufen. | ✓ | ✓ | ✓ | 1.0 | 20 | | **2.5** | Stellen Sie sicher, dass die für Container verfügbaren Ressourcen begrenzt sind (ulimit). | | ✓ | ✓ | 1.0 | 21 | | **2.6** | Stellen Sie sicher, dass SELinux oder AppArmor aktiviert ist und auf allen Knoten sowie für Dockerd ausgeführt wird. | | | ✓ | 1.0 | 22 | | **2.7** | Stellen Sie sicher, dass Updates für die Knoten und die Docker Engine, die auf ihnen ausgeführt werden, in regelmäßigen Abständen angewendet werden. Das Anwenden von Updates erfolgt im Idealfall vollautomatisch. | ✓ | ✓ | ✓ | 1.0 | 23 | | **2.8** | Stellen Sie sicher, dass Aktualisierungen mithilfe einer kanarischen Bereitstellungs- / Freigabestrategie bereitgestellt werden, die Rollbacks ermöglicht. | | ✓ | ✓ | 1.0 | 24 | | **2.9** | Stellen Sie sicher, dass _dockerd_ mit aktiviertem _live restore_ konfiguriert ist. | | ✓ | ✓ | 1.0 | 25 | | **2.10** | Stellen Sie sicher, dass die Berechtigungen für die Konfiguration von _dockerd_ auf Benutzer beschränkt sind, die tatsächlich Zugriff darauf benötigen und ordnungsgemäß protokolliert sind. | ✓ | ✓ | ✓ | 1.0 | 26 | | **2.11** | Stellen Sie sicher, dass alle Knoten regelmäßigen automatisierten Sicherheitsüberprüfungen unterzogen werden, die sich auf das gesamte Betriebssystem und nicht nur auf containerbezogene Elemente beziehen. | | ✓ | ✓ | 1.0 | 27 | | **2.12** | Stellen Sie sicher, dass container-spezifische Betriebssysteme (z. B. Container Linux, RancherOS, RedHat Project Atomic und VMware Photon) auf allen Knoten anstelle von Allzweck-Betriebssystemen verwendet werden. | | | ✓ | 1.0 | 28 | | **2.13** | Stellen Sie sicher, dass alle Knoten auf der Grundlage gängiger Best Practices gehärtet sind. | ✓ | ✓ | ✓ | 1.0 | 29 | | **2.14** | Stellen Sie sicher, dass, sofern nicht anders angegeben, die Standardwerte für die Docker-Konfiguration verwendet werden. | ✓ | ✓ | ✓ | 1.0 | 30 | | **2.15** | Stellen Sie sicher, dass der direkte Zugriff auf Knoten (z. B. über SSH oder RDP) so weit wie möglich eingeschränkt ist. | ✓ | ✓ | ✓ | 1.0 | 31 | -------------------------------------------------------------------------------- /de/0x12-V03-Containers.md: -------------------------------------------------------------------------------- 1 | # V3: Container 2 | 3 | ## Sicherheitsziele 4 | 5 | Die Hauptkomponente von container-basierten Lösungen sind die Container selbst. Sie enthalten nicht nur Dienste und Anwendungslogik, sondern interagieren auch mit anderen Systemen und Containern, um Daten auszutauschen, die häufig vertraulich sind und genauen Schutz erfordern. 6 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden high-level Anforderungen erfüllt: 7 | 8 | * Stellen Sie sicher, dass die Container mit den geringstmöglichen Berechtigungen ausgeführt werden. 9 | * Härten Sie die Services im Container und minimieren Sie die Angriffsfläche. 10 | * Nutzen Sie die Sicherheitsfunktionen der verwendeten Containertechnologie. 11 | 12 | ## Sicherheitsvorgaben 13 | 14 | | # | Beschreibung | L1 | L2 | L3 | Seit | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **3.1** | Stellen Sie sicher, dass der Root-Benutzer nur während der Initialisierung verwendet wird und die Berechtigungen nach Abschluss gelöscht werden. | | ✓ | ✓ | 1.0 | 17 | | **3.2** | Stellen Sie sicher, dass der Benutzer-Namespace aktiviert ist. | | ✓ | ✓ | 1.0 | 18 | | **3.3** | Stellen Sie sicher, dass in jedem Container-Image ein neuer Benutzer erstellt wird, mit dem dann alle Vorgänge im Container ausgeführt werden. | | | ✓ | 1.0 | 19 | | **3.4** | Stellen Sie sicher, dass für jeden Container ein bestimmtes (nicht standardmäßiges) _seccomp_-Profil angewendet wird, das auf den Anforderungen des Containers basiert. | | | ✓ | 1.0 | 20 | | **3.5** | Stellen Sie sicher, dass Containern während ihrer Laufzeit keine zusätzlichen Berechtigungen gewährt werden (`--no-new-privileges` flag). | ✓ | ✓ | ✓ | 1.0 | 21 | | **3.6** | Stellen Sie sicher, dass alle Basisimages explizit angegeben sind, und verwenden Sie deren Hash anstelle von Name und Tag. | | | ✓ | 1.0 | 22 | | **3.7** | Stellen Sie sicher, dass die Signatur jedes Images vor der produktiven Verwendung überprüft wird.| | | ✓ | 1.0 | 23 | | **3.8** | Stellen Sie sicher, dass nur die erforderlichen Softwarepakete in den Images installiert sind. | ✓ | ✓ | ✓ | 1.0 | 24 | | **3.9** | Stellen Sie sicher, dass das Root-Dateisystem im schreibgeschützten Modus bereitgestellt ist. | | ✓ | ✓ | 1.0 | 25 | | **3.10** | Stellen Sie sicher, dass ein Container nach dem aktiven Zugriff (z. B. zur Fehlerbehebung) gelöscht und durch eine neue Instanz (Container) des Images ersetzt wurde. | | ✓ | ✓ | 1.0 | 26 | | **3.11** | Stellen Sie sicher, dass Dockerfiles anstelle der ADD-Direktive die COPY-Direktive verwenden, es sei denn, die Quelle ist voll vertrauenswürdig. | ✓ | ✓ | ✓ | 1.0 | 27 | | **3.12** | Stellen Sie sicher, dass Remoteverwaltungsdienste wie SSH oder RDP deaktiviert sind oder gar nicht erst in Containern installiert sind. | ✓ | ✓ | ✓ | 1.0 | 28 | | **3.13** | Stellen Sie sicher, dass offen gelegte Dienste wie _etcd_ entweder nur für vollständig vertrauenswürdige Systeme verfügbar sind oder eine Authentifizierung erfordern. | ✓ | ✓ | ✓ | 1.0 | 29 | | **3.14** | Stellen Sie sicher, dass die Anzahl der zulässigen Prozesse in einem Container genau definiert und auf diesen Wert begrenzt ist, indem Sie "--pids-limit" verwenden. | | | ✓ | 1.0 | 30 | | **3.15** | Stellen Sie sicher, dass der Docker-Socket nicht in einem Container gemountet ist, es sei denn, er wird zur Überwachung oder Verwaltung verwendet. Wenn der Zugriff auf den Docker-Socket erforderlich ist, Stellen Sie sicher, ob der schreibgeschützte Zugriff ausreicht, und begrenzen Sie den Zugriff auf den Container entsprechend. | ✓ | ✓ | ✓ | 1.0 | 31 | -------------------------------------------------------------------------------- /de/0x13-V04-Orchestration-Management.md: -------------------------------------------------------------------------------- 1 | # V4: Orchestration Management 2 | 3 | ## Sicherheitsziele 4 | 5 | Sollten Ihre container-basierten Lösungen über eine bestimmte Anzahl von Knoten und Containern hinauswachsen, wird ein Orchestrator benötigt. Der Orchestrator unterstützt Sie beim Verwalten und Administrieren der Lösung und überwacht was passiert. Da der Orchestrator ein so mächtiges zentrales Element in einer Containerinfrastruktur ist, wirkt sich die Sicherheitsstufe des Orchestrators direkt auf alle anderen Aspekte Ihrer Infrastruktur aus. 6 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 7 | 8 | * Verfügbarkeit für den Orchestrator ist garantiert. 9 | * Der Orchestrator ist gehärtet. 10 | * Die Interaktion mit dem Orchestrator ist größtenteils automatisiert, um menschliche Fehler zu vermeiden. 11 | 12 | ## Sicherheitsvorgaben 13 | 14 | | # | Beschreibung | L1 | L2 | L3 | Seit | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **4.1** | Stellen Sie sicher, dass die Manager-Knoten redundant eingerichtet und für die Unterstützung hoher Verfügbarkeit bereit sind. | ✓ | ✓ | ✓ | 1.0 | 17 | | **4.2** | Stellen Sie sicher, dass eine ungerade Anzahl von Manager-Knoten mit mindestens drei Knoten bereitgestellt wird. | ✓ | ✓ | ✓ | 1.0 | 18 | | **4.3** | Stellen Sie sicher, dass die Manager auf mehrere Rechenzentren und Verfügbarkeitszonen verteilt sind. | | ✓ | ✓ | 1.0 | 19 | | **4.4** | Stellen Sie sicher, dass die Manager-Knoten mit aktiviertem _auto-lock_ ausgeführt werden. | | | ✓ | 1.0 | 20 | | **4.5** | Stellen Sie sicher, dass der Orchestrator die aktiven Container regelmäßig neu verteilt. | ✓ | ✓ | ✓ | 1.0 | 21 | | **4.6** | Stellen Sie sicher, dass Manager-Knoten keine Worker-Aufgaben und -Container übernehmen. | ✓ | ✓ | ✓ | 1.0 | 22 | | **4.7** | Stellen Sie sicher, dass vordefinierte Bezeichnungen verwendet werden, um alle Ressourcen ordnungsgemäß zu identifizieren und zu verwalten. | | ✓ | ✓ | 1.0 | 23 | | **4.8** | Stellen Sie sicher, dass nicht mehr benötigte Container gelöscht werden. | | ✓ | ✓ | 1.0 | 24 | | **4.9** | Stellen Sie sicher, dass nur Container mit derselben Datenklassifizierungsebene auf demselben Knoten ausgeführt werden. | | | ✓ | 1.0 | 25 | | **4.10** | Stellen Sie sicher, dass nur Container mit demselben Expositionsgrad (z. B. mit Blick auf das Internet) auf demselben Knoten ausgeführt werden. | | | ✓ | 1.0 | 26 | -------------------------------------------------------------------------------- /de/0x14-V05-Image-Distribution.md: -------------------------------------------------------------------------------- 1 | # V5: Image Verteilung 2 | 3 | ## Sicherheitsziele 4 | 5 | Damit Container ausgeführt werden können, müssen zunächst Images erstellt werden. Images definieren, was in einem Container ausgeführt wird und beispielsweise welche Version eines Softwarepakets verwendet wird. Als Basis für eine möglicherweise große Menge von Containern ist die Sicherheit jedes Images für den sicheren Betrieb einer Umgebung von entscheidender Bedeutung. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Images sind gehärtet. 10 | * In Images werden keine sensiblen Daten gespeichert. 11 | * Images werden auf gefährdete Komponenten überprüft. 12 | 13 | ## Sicherheitsvorgaben 14 | 15 | | # | Beschreibung | L1 | L2 | L3 | Seit | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **5.1** | Stellen Sie sicher, dass eine ungerade Anzahl von Image-Registries (z. B. DTR) mit mindestens drei Registries verwendet wird. | | | ✓ | 1.0 | 18 | | **5.2** | Stellen Sie sicher, dass die Speicherbereinigung in den Image-Registries aktiviert ist und regelmäßig ausgeführt wird. | ✓ | ✓ | ✓ | 1.0 | 19 | | **5.3** | Stellen Sie sicher, dass alle Images regelmäßigen automatischen Sicherheitsscans unterzogen werden. | | ✓ | ✓ | 1.0 | 20 | | **5.4** | Stellen Sie sicher, dass Container immer auf der Grundlage des neuesten entsprechenden Images und nicht der lokalen Caches erstellt werden. | ✓ | ✓ | ✓ | 1.0 | 21 | | **5.5** | Stellen Sie sicher, dass alle Images Tags verwenden, während nur Produktion / Master das Standard-Tag _latest_ verwenden dürfen. | | ✓ | ✓ | 1.0 | 22 | -------------------------------------------------------------------------------- /de/0x15-V06-Secrets-and-Keys.md: -------------------------------------------------------------------------------- 1 | # V6: Secrets und Kryptografische Schlüssel 2 | 3 | ## Sicherheitsziele 4 | 5 | Produktionssysteme verwenden normalerweise Geheimnisse und kryptografische Schlüssel. Diese können zu Konfigurationszwecken verwendet werden und enthalten Benutzernamen und Kennwörter oder ermöglichen den Schutz von Informationen durch kryptografische Mittel. In diesem Abschnitt wird festgelegt, wie mit diesen vertraulichen Informationen umgegangen werden soll. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Schützen Sie sensible Informationen. 10 | * ÜberStellen Sie sicher den sicheren Umgang mit kryptografischem Material. 11 | * Rotieren Sie kryptografische Schlüssel regelmäßig. 12 | 13 | ## Sicherheitsvorgaben 14 | 15 | | # | Beschreibung | L1 | L2 | L3 | Seit | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **6.1** | Stellen Sie sicher, dass ein RBAC-Modell zum Verwalten der Zugriffssteuerung verwendet wird. | | ✓ | ✓ | 1.0 | 18 | | **6.2** | Stellen Sie sicher, dass Docker Content Trust aktiviert und erzwungen ist. | | | ✓ | 1.0 | 19 | | **6.3** | Vertrauliche Informationen dürfen niemals Teil einer Dockerfile- oder Docker-Compose-Datei sein. Stellen Sie insbesondere sicher, dass z.B. Docker Secrets für den Umgang mit vertraulichen Informationen wie API-Schlüsseln und Kennwörtern verwendet werden. | ✓ | ✓ | ✓ | 1.0 | 20 | | **6.4** | Stellen Sie sicher, dass die Orchestrierungsverbindungsschlüssel in regelmäßigen Abständen rotiert werden. | | ✓ | ✓ | 1.0 | 21 | | **6.5** | Stellen Sie sicher, dass die Auto-Lock-Schlüssel in regelmäßigen Abständen rotiert werden, wenn die Auto-Lock-Funktion aktiviert ist. | | ✓ | ✓ | 1.0 | 22 | | **6.6** | Stellen Sie sicher, dass die Knotenzertifikate in regelmäßigen Abständen rotiert werden. | | ✓ | ✓ | 1.0 | 23 | | **6.7** | Stellen Sie sicher, dass CA-Zertifikate in regelmäßigen Abständen rotiert werden. | | ✓ | ✓ | 1.0 | 24 | | **6.8** | Stellen Sie sicher, dass Ihre eigene Zertifizierungsstelle zum Generieren und Überprüfen von Zertifikaten für die gegenseitige TLS-Authentifizierung der Kommunikation zwischen Clustern verwendet wird. | | ✓ | ✓ | 1.0 | 25 | | **6.9** | Stellen Sie sicher, dass die verwendeten SSL / TLS-Zertifikate (z. B. für UCP und DTR) validiert sind. | ✓ | ✓ | ✓ | 1.0 | 26 | | **6.10** | Stellen Sie sicher, dass Geheimnisse (z. B. kryptografische Schlüssel und Kennwörter) sicher mit einer Secret Management Lösung verwendet werden, anstatt z.B. unter Verwendung von Umgebungsvariablen einem Container bereitgestellt werden. | | ✓ | ✓ | 1.0 | 27 | -------------------------------------------------------------------------------- /de/0x16-V07-Network.md: -------------------------------------------------------------------------------- 1 | # V7: Netzwerk 2 | 3 | ## Sicherheitsziele 4 | 5 | Fast alle modernen Anwendungen und Dienste sind nicht monolithisch, sondern bestehen aus mehreren Komponenten, die über Netzwerkverbindungen miteinander interagieren. Das Sichern von Netzwerken ist eine eigene Sicherheitsdisziplin, es gibt jedoch einige Aspekte, die sich auf Containertechnologien auswirken können, und wo sie die Sicherheit bei der Verwendung von Netzwerken verbessern können. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Wählen Sie einen guten Netzwerktreiber und konfigurieren Sie ihn richtig. 10 | * Deaktivieren Sie nicht benötigte Funktionen und wenden Sie Einschränkungen an. 11 | * Verschlüsselung erzwingen, wenn Daten über Netzwerke übertragen werden. 12 | 13 | ## Sicherheitsvorgaben 14 | 15 | | # | Beschreibung | L1 | L2 | L3 | Seit | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **7.1** | Stellen Sie sicher, dass ein produktionsbereiter Netzwerktreiber verwendet wird. | ✓ | ✓ | ✓ | 1.0 | 18 | | **7.2** | Stellen Sie sicher, dass die Lastenausgleichsfunktionen aktiviert sind (z. B. mithilfe von DNS Round Robin oder virtuellen IPs (VIP)). | | ✓ | ✓ | 1.0 | 19 | | **7.3** | Stellen Sie sicher, dass der Docker Userland-Proxy (der standardmäßig aktiviert ist) deaktiviert ist. | | ✓ | ✓ | 1.0 | 20 | | **7.4** | Stellen Sie sicher, dass die Standardbrücke (_docker0_) nicht verwendet wird. | ✓ | ✓ | ✓ | 1.0 | 21 | | **7.5** | Stellen Sie sicher, dass _dockerd_ so konfiguriert ist, dass standardmäßig keine Netzwerkkommunikation zwischen verschiedenen Containern möglich ist. Dies kann erfolgen, indem entweder die _docker0_-Bridge nicht verwendet wird oder _--icc_ auf false gesetzt wird. | | ✓ | ✓ | 1.0 | 22 | | **7.6** | Stellen Sie sicher, dass _dockerd_ die Berechtigung hat, _iptables_-Regeln zu ändern. | ✓ | ✓ | ✓ | 1.0 | 23 | | **7.7** | Stellen Sie sicher, dass veröffentlichte Ports einer konkreten Netzwerkschnittstelle eines Knotens zugewiesen sind. | ✓ | ✓ | ✓ | 1.0 | 24 | | **7.8** | Stellen Sie sicher, dass Management- und Daten- / Anwendungsverkehr durch verschiedene Netzwerkschnittstellen getrennt sind. | | | ✓ | 1.0 | 25 | | **7.9** | Stellen Sie sicher, dass jeder Anwendung (einem oder mehreren Diensten) mindestens ein separates, isoliertes Overlay-Netzwerk zugewiesen ist, um die Segmentierung der Schicht 3 sicherzustellen. | | ✓ | ✓ | 1.0 | 26 | | **7.10** | Stellen Sie sicher, dass die Verschlüsselung zwischen Containern oder Knoten im Overlay-Netzwerk aktiviert ist. | | ✓ | ✓ | 1.0 | 27 | | **7.11** | Stellen Sie sicher, dass sich die verwendeten Subnetze nicht mit anderen Subnetzen (z. B. Overlay-Netzwerken) überschneiden. | ✓ | ✓ | ✓ | 1.0 | 28 | | **7.12** | Stellen Sie sicher, dass veröffentlichte Ports auf ein notwendiges Minimum beschränkt sind. | ✓ | ✓ | ✓ | 1.0 | 29 | -------------------------------------------------------------------------------- /de/0x17-V08-Storage.md: -------------------------------------------------------------------------------- 1 | # V8: Datenspeicher 2 | 3 | ## Sicherheitsziele 4 | 5 | Da Container nur vorübergehend existieren, ist es wichtig, ein zuverlässiges und sicheres Speicher-Backend für persistente Daten bereitzustellen. Nicht nur die Verfügbarkeit gespeicherter Daten ist von entscheidender Bedeutung, sondern auch die Integrität und die Maßnahmen zur Zugriffskontrolle. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Wählen Sie einen guten Speichertreiber und konfigurieren Sie ihn richtig. 10 | * Vergewissern Sie sich, dass die Daten nicht lokal auf den Knoten gespeichert sind, um die Persistenz zu gewährleisten. 11 | 12 | ## Sicherheitsvorgaben 13 | 14 | | # | Beschreibung | L1 | L2 | L3 | Seit | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **8.1** | Stellen Sie sicher, dass ein produktionsreifes Speicher-Backend verwendet wird. | ✓ | ✓ | ✓ | 1.0 | 17 | | **8.2** | Stellen Sie sicher, dass das Image-Seicher-Backend redundant ist und sich in einer gesicherten Netzwerkzone befindet. | ✓ | ✓ | ✓ | 1.0 | 18 | | **8.3** | Stellen Sie sicher, dass ein geeigneter und getesteter Datenspeichertreiber verwendet wird, um die Replikation und Verfügbarkeit von Anwendungsdaten sicherzustellen. | ✓ | ✓ | ✓ | 1.0 | 19 | | **8.4** | Stellen Sie sicher, dass persistente Daten niemals direkt in einem Container gespeichert werden, sondern stattdessen auf einem entsprechenden Docker-Volume oder Bereitstellungspunkt. | ✓ | ✓ | ✓ | 1.0 | 20 | | **8.5** | Stellen Sie sicher, dass persistente Daten regelmäßig nach einem geeigneten, genau definierten Sicherungskonzept gesichert und die Wiederherstellung getestet werden. | ✓ | ✓ | ✓ | 1.0 | 21 | -------------------------------------------------------------------------------- /de/0x18-V09-Logging-Monitoring.md: -------------------------------------------------------------------------------- 1 | # V9: Logging & Monitoring 2 | 3 | ## Sicherheitsziele 4 | 5 | Die Sicherung von Containern und Infrastruktur ist eine Sache, aber es ist nicht weniger wichtig, dass Sie wissen, wann etwas schief geht. Durch Protokollierung und Überwachung erhalten Sie Einblicke in den aktuellen Stand Ihrer Lösung und können entsprechend reagieren. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Haben Sie eine zentrale Protokollierungs- und Überwachungsinstanz. 10 | * Überwachen Sie alle Ihre Komponenten. 11 | 12 | ## Sicherheitsvorgaben 13 | 14 | | # | Beschreibung | L1 | L2 | L3 | Seit | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **9.1** | Stellen Sie sicher, dass das zugrunde liegende System, Docker Engine sowie Container und deren Prozesse protokolliert werden. | | ✓ | ✓ | 1.0 | 17 | | **9.2** | Stellen Sie sicher, dass die verwendeten Ressourcen auf Knoten- und Containerebene überwacht werden. | | ✓ | ✓ | 1.0 | 18 | | **9.3** | Stellen Sie sicher, dass das Speicher-Backend überwacht wird. | | ✓ | ✓ | 1.0 | 19 | | **9.4** | Stellen Sie sicher, dass die Integritätsprüfungsfunktion von Docker für alle Container verwendet und deren Status überwacht wird. | | ✓ | ✓ | 1.0 | 20 | | **9.5** | Stellen Sie sicher, dass alle Protokolle an einen zentralen Ort übertragen und dort gespeichert werden. | | ✓ | ✓ | 1.0 | 21 | | **9.6** | Stellen Sie sicher, dass in Produktionsumgebungen die Protokollebene von _dockerd_ auf _info_ festgelegt ist. | ✓ | ✓ | ✓ | 1.0 | 22 | -------------------------------------------------------------------------------- /de/0x19-V10-Integration.md: -------------------------------------------------------------------------------- 1 | # V10: Integration 2 | 3 | ## Sicherheitsziele 4 | 5 | Container-basierte Lösungen sind normalerweise nicht eigenständig, sondern lassen sich in eine Vielzahl unterschiedlicher Systeme integrieren. Solche Systeme können IAM-Lösungen, CI / CD-Pipelines oder vorhandene Netzwerkumgebungen sein. Jede Interaktion stellt auch eine potenzielle Bedrohung für eine container-basierte Lösung dar und umgekehrt. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Integration in bestehende Sicherheitsinfrastruktur. 10 | * Platzieren Sie Informationen in einem zentralen Inventar- und Änderungsmanagementsystem. 11 | * Nutzung der vorhandenen Netzwerkinfrastruktur. 12 | 13 | ## Sicherheitsvorgaben 14 | 15 | | # | Beschreibung | L1 | L2 | L3 | Seit | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **10.1** | Stellen Sie sicher, dass die Orchestrierungslösung (z. B. UCP) und die Registry (z. B. DTR) in die vorhandene Infrastruktur (SSO, DCT usw.) integriert sind. | | ✓ | ✓ | 1.0 | 18 | | **10.2** | Stellen Sie sicher, dass die CI / CD-Tools und -Systeme mit der Docker-Infrastruktur verbunden sind, damit Änderungen an Knoten, Images oder dem Netzwerk vollständig automatisiert getestet und bereitgestellt werden können. | | ✓ | ✓ | 1.0 | 19 | | **10.3** | Stellen Sie sicher, dass zusätzliche Knoten automatisch eingerichtet werden können (z. B. Puppet, Chef, Ansible, Salt, Terraform) und wie vorhandene Knoten konfiguriert werden. | | ✓ | ✓ | 1.0 | 20 | | **10.4** | Stellen Sie sicher, dass ein zentrales Änderungsmanagementsystem implementiert ist und alle Änderungen an der Containerinfrastruktur und ihren Komponenten dort nachverfolgt werden. | | ✓ | ✓ | 1.0 | 21 | | **10.5** | Stellen Sie sicher, dass ein Such- und Registrierungsdienst wie consul, Zookeeper, Eureka, Etcd oder auch nur DNS intern und extern verwendet wird. | | ✓ | ✓ | 1.0 | 22 | | **10.6** | Stellen Sie sicher, dass Benutzer und Rollen einer vorhandenen zentralen IAM-Lösung zugeordnet sind. | | | ✓ | 1.0 | 23 | -------------------------------------------------------------------------------- /de/0x20-V11-Disaster-Recovery.md: -------------------------------------------------------------------------------- 1 | # V11: Disaster Recovery 2 | 3 | ## Sicherheitsziele 4 | 5 | Wenn etwas schief geht, ist es wichtig, dass das System so schnell wie möglich wieder verfügbar ist, ohne die Sicherheit zu beeinträchtigen. In dieser Kategorie werden Anforderungen beschrieben, mit denen Sie sicherstellen können, dass Ihre Notfallwiederherstellung wie erwartet funktioniert und die Ausfallzeiten kurz sind. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Backups werden regelmäßig erstellt. 10 | * Wiederherstellungsschritte sind automatisiert. 11 | * Selbstheilungskräfte werden eingesetzt. 12 | 13 | ## Sicherheitsvorgaben 14 | 15 | | # | Beschreibung | L1 | L2 | L3 | Seit | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **11.1** | Stellen Sie sicher, dass regelmäßige Sicherungen (UCP, DTR und Swarm) durchgeführt werden. Es muss mindestens eine wöchentliche Sicherung durchgeführt werden. | ✓ | ✓ | ✓ | 1.0 | 18 | | **11.2** | Stellen Sie sicher, dass die Wiederherstellung der Infrastruktur automatisiert, dokumentiert und regelmäßig getestet wird. | ✓ | ✓ | ✓ | 1.0 | 19 | | **11.3** | Stellen Sie sicher, dass Upgrades und Downgrades der Basisinfrastruktur sowie der Docker Engine automatisiert, dokumentiert und regelmäßig getestet werden. | | | ✓ | 1.0 | 20 | | **11.4** | Stellen Sie sicher, dass die Wiederherstellung einzelner Anwendungen / Dienste automatisiert, dokumentiert und regelmäßig getestet wird. | | ✓ | ✓ | 1.0 | 21 | | **11.5** | Stellen Sie sicher, dass für jeden Container eine "On-Failure" -Richtlinie zum Neustart aktiviert ist. | | ✓ | ✓ | 1.0 | 22 | -------------------------------------------------------------------------------- /de/0x21-V12-Testing.md: -------------------------------------------------------------------------------- 1 | # V12: Testing 2 | 3 | ## Sicherheitsziele 4 | 5 | Die Technologie entwickelt sich immer weiter und verändert sich ständig auf unerwartete Weise. Basierend darauf ist die Absicherung einer container-basierten Lösung nicht nur ein einmaliger Aufwand, sondern es sollten regelmäßig verschiedene Überprüfungen und Validierungen durchgeführt werden. 6 | 7 | Stellen Sie sicher, dass eine geprüfte Containerlösung regelmäßig die folgenden hohen Anforderungen erfüllt: 8 | 9 | * Wiederherstellung nach einem Fehler. 10 | * Stellen Sie sicher, dass die Sicherheitseinstellungen wirksam werden. 11 | * Dokumentation des aktuellen Zustands der container-basierten Lösung. 12 | 13 | ## Sicherheitsvorgaben 14 | 15 | Die folgenden Anforderungen sind anhand eines regelmäßigen Ausführungszyklus zu bewerten. Es wird empfohlen, den Zyklus auf drei Monate oder kürzer zu halten. 16 | 17 | | # | Beschreibung | L1 | L2 | L3 | Seit | 18 | | --- | --- | --- | --- | -- | -- | 19 | | **12.1** | Stellen Sie sicher, dass alle Benutzer- und Gruppenberechtigungen für Ressourcen den Spezifikationen und der Dokumentation entsprechen. | ✓ | ✓ | ✓ | 1.0 | 20 | | **12.2** | Vergewissern Sie sich, dass die Ressourcenbeschränkungen für die Anwendung / den Container wie definiert funktionieren. | | ✓ | ✓ | 1.0 | 21 | | **12.3** | Stellen Sie sicher, dass jeder Dienst vollständig automatisiert wiederhergestellt werden kann. | | ✓ | ✓ | 1.0 | 22 | | **12.4** | Stellen Sie sicher, dass Zertifikate und Schlüssel gemäß den Spezifikationen rotiert wurden. | | | ✓ | 1.0 | 23 | | **12.5** | Stellen Sie sicher, dass die Konfigurationen, Images und Netzwerke aller Dienste fortlaufend aktualisiert und heruntergestuft werden können. | | ✓ | ✓ | 1.0 | 24 | | **12.6** | Stellen Sie sicher, dass sowohl die Knoten als auch die Docker Engine auf dem neuesten Stand sind. | ✓ | ✓ | ✓ | 1.0 | 25 | | **12.7** | Stellen Sie sicher, dass die Lastausgleichsstrategien wie definiert funktionieren. | | ✓ | ✓ | 1.0 | 26 | | **12.8** | Stellen Sie sicher, dass die Container auf der Grundlage der definierten Strategie im gesamten Cluster verteilt sind. | | ✓ | ✓ | 1.0 | 27 | | **12.9** | Stellen Sie sicher, dass alle Dienste nach einem Ausfall von Knoten und einzelnen Containern wiederhergestellt werden können. | | ✓ | ✓ | 1.0 | 28 | | **12.10** | Stellen Sie sicher, dass bei einem Totalausfall für alle Dienste Sicherungen wiederhergestellt werden können. | ✓ | ✓ | ✓ | 1.0 | 29 | | **12.11** | Stellen Sie sicher, dass _Docker Security Bench_ regelmäßig ausgeführt und bestanden wird. | | ✓ | ✓ | 1.0 | 30 | -------------------------------------------------------------------------------- /de/0x90-Appendix-A_Glossary.md: -------------------------------------------------------------------------------- 1 | # Appendix A: Glossar 2 | 3 | * **API** – Application programming interface 4 | * **CA** – Certificate Authority 5 | * **CI/CD** – Continuous Integration und Continuous Delivery 6 | * **CLI** – Command Line Interface 7 | * **DCT** – Docker Content Trust 8 | * **DNS RR** – DNS Round Robin 9 | * **DTR** – Docker Trusted Registry 10 | * **IAM** - Identity und Access Management 11 | * **LDAP** – Lightweight Directory Access Protocol 12 | * **mTLS** – Mutual TLS (authentication) 13 | * **Node** – Ein physischer Host, auf dem die Container- / Docker-Engine ausgeführt wird. Könnte ein einzelner Host oder ein Host als Teil eines Clusters sein. 14 | * **RBAC** – Role-Based Access Control 15 | * **RDP** – Remote Desktop Protocol 16 | * **Service** – Ein Dienst, der in einem Container ausgeführt wird. 17 | * **SSH** – Secure Shell 18 | * **SSL** – Secure Sockets Layer 19 | * **SSO** – Single Sign-On 20 | * **TLS** – Transport Layer Security, der Nachfolger von Secure Sockets Layer (SSL) 21 | * **UCP** – Docker Universal Control Plane 22 | * **VIP** – Virtual IP 23 | -------------------------------------------------------------------------------- /de/0x91-Appendix-B_References.md: -------------------------------------------------------------------------------- 1 | # Appendix B: Referenzen 2 | 3 | Die folgenden Projekte sind für Benutzer / Anwender dieser Norm wahrscheinlich sehr hilfreich und waren auch bei ihrer Erstellung hilfreich: 4 | 5 | - OWASP Application Security Verification Standard - [https://www.owasp.org/index.php/ASVS](https://www.owasp.org/index.php/ASVS) 6 | - CIS Docker Benchmark - [https://www.cisecurity.org/benchmark/docker/](https://www.cisecurity.org/benchmark/docker/) 7 | - Docker Reference Architectures - [https://success.docker.com/architectures](https://success.docker.com/architectures) 8 | - Docker EE Best Practices and Design Considerations - [https://success.docker.com/article/docker-ee-best-practices](https://success.docker.com/article/docker-ee-best-practices) 9 | - NIST Application Container Security Guide - [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf) 10 | -------------------------------------------------------------------------------- /en/0x00-Header.md: -------------------------------------------------------------------------------- 1 | # Container Security Verification Standard 2 | 3 | ![logo](../images/logo.png) 4 | 5 | Version 1.0 6 | 7 | Date: [date] 8 | -------------------------------------------------------------------------------- /en/0x01-Frontispiece.md: -------------------------------------------------------------------------------- 1 | # Frontispiece 2 | 3 | ## About the Standard 4 | 5 | The Container Security Verification Standard is a list of security requirements or tests that can be used by architects, developers, testers, security professionals and even consumers to define what a secure container and corresponding infrastructure is. 6 | 7 | ## Copyright and License 8 | 9 | ![license](../images/license.png) 10 | 11 | Copyright © 2019 OWASP Foundation. This document is released under the Creative Commons Attribution ShareAlike 4.0 license. For any reuse or distribution, you must make clear to others the license terms of this work. 12 | 13 | The code used to build the CSVS document and structure is based on the OWASP ASVS project. 14 | 15 | ## Contribution 16 | 17 | If you find any issues within the standard that should be addressed: 18 | 19 | * Design of the standard. 20 | * Missing controls. 21 | * Ineffective or outdated controls. 22 | * Unclear wording, spelling, grammar issues. 23 | * Formatting issues. 24 | * Translation issues – if a control’s wording is such that trying express it in your language will be difficult or impossible, please let us know. If it doesn’t work in Spanish or Thai, it probably isn’t working in English either. 25 | * Offers of translation – please let us know so that we can direct you to folks already working on your language. 26 | 27 | Please log all issues at https://github.com/OWASP/Container-Security-Verification-Standard/issues 28 | 29 | ## Contributors 30 | 31 | | Lead Authors | Contributors & Reviewers | Translators | 32 | | --- | --- | --- | 33 | | Sven Vetsch | Alexander Hermann, Dominik Nufer, Dominique Meier, Patrick Schmid, Daniel Tschabold | Stephan Kaps (German) | 34 | 35 |


36 | 37 | Special thanks for sponsoring the project goes to: 38 | 39 | [![logo](../images/redguard-logo.png)](https://www.redguard.ch/) 40 | -------------------------------------------------------------------------------- /en/0x02-Preface.md: -------------------------------------------------------------------------------- 1 | # Preface 2 | 3 | Welcome to the Container Security Verification Standard (CSVS) version 1.0. The CSVS is a community-effort to establish a framework of security requirements and controls that focus on normalizing the functional and non-functional security controls required when designing, developing and testing container-based solutions with a focus on Docker. 4 | 5 | We expect that there will most likely never be 100% agreement on this standard. Risk analysis is always subjective to some extent, which creates a challenge when attempting to generalize in a one size fits all standard. We're always happy to hear your feedback and re-evaluate the requirements. 6 | -------------------------------------------------------------------------------- /en/0x03-Using-CSVS.md: -------------------------------------------------------------------------------- 1 | # Using the CSVS 2 | 3 | CSVS has two main goals: 4 | * Help organizations develop and maintain secure containers and container infrastructure. 5 | * Allow security services, security tool vendors, and consumers to align their requirements and offerings. 6 | 7 | ## Container Security Verification Levels 8 | The Container Security Verification Standard defines three security verification levels, with each level increasing in depth. 9 | 10 | * CSVS Level 1 is meant for all container projects. 11 | * CSVS Level 2 is meant for container projects that deal with sensitive data or business logic, which requires additional protection. 12 | * CSVS Level 3 is meant for the most critical container projects that perform high value transactions, contain sensitive personal or medical data, or any container that requires the highest level of trust. 13 | 14 | Each CSVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into the containers or their underlying infrastructure. 15 | 16 | ![csvs-levels](../images/csvs-levels.png) 17 | 18 | Figure 1 - Container Security Verification Standard levels 19 | 20 | ## How to use this standard 21 | 22 | One of the best ways to use the Container Security Verification Standard is to use it as blueprint to create a security checklist specific to your project, platform or organization. Tailoring the CSVS to your use cases will increase the focus on the security requirements that are most important to your projects and environments. 23 | 24 | ### Level 1: Opportunistic 25 | 26 | A container-based infrastructure/solution achieves CSVS Level 1 (or Opportunistic) if it adequately defends against well known security threats that are easy to discover and easy to abuse. 27 | 28 | Level 1 is typically appropriate for applications where low confidence in the correct use of security controls including availability is required, or to provide a quick analysis of a fleet of enterprise applications, or assisting in developing a prioritized list of security requirements as part of a multi-phase effort. We consider Level 1 the minimum required for all container projects. If data processed by your container-based solution has high value, you would rarely want to stop at a Level 1 review. 29 | 30 | ### Level 2: Standard 31 | 32 | A container-based infrastructure/solution achieves CSVS Level 2 (or Standard) if it adequately defends against most of the risks associated with container-based solutions today. 33 | 34 | Level 2 ensures that security controls are in place, effective/tested, and used within the whole solution. Level 2 is typically appropriate for container-based projects that handle significant and sensitive transactions, including those that process confident information, implement business-critical or sensitive functions, or process other sensitive assets. 35 | 36 | ### Level 3: Advanced 37 | 38 | CSVS Level 3 is the highest level of verification within the CSVS. This level is typically reserved for container-based solutions that require significant levels of security verification, such as those that may be found within areas of military, health and safety, critical infrastructure, etc. 39 | 40 | Organizations may require CSVS Level 3 for applications that perform critical functions, where failure could significantly impact the organization's operations, and even its survivability. A container-based solution achieves CSVS Level 3 (or Advanced) if it adequately defends against advanced adversaries and also demonstrates principles of good security design. 41 | 42 | An application at CSVS Level 3 requires more in depth analysis, architecture, coding, and testing than all the other levels. A secure container infrastructure is modularized in a meaningful way (to facilitate e.g. resilience, scalability, and most of all, layers of security), and each module (separated by network connection and/or physical instance) takes care of its own security responsibilities (defense in depth), that need to be properly documented and tested. Responsibilities include controls for ensuring confidentiality (e.g. encryption), integrity (e.g. transactions, input validation), availability (e.g. handling load gracefully), authentication (including between systems), non-repudiation, authorization, and auditing (logging). 43 | 44 | ## Applying CSVS in Practice 45 | 46 | Different threats have different motivations. Some industries have unique information and technology assets and domain specific regulatory compliance requirements. Although some unique criteria and some differences in threats exist for each industry, a common theme throughout all industry segments is that opportunistic attackers will look for any easily exploitable vulnerabilities, which is why CSVS Level 1 is recommended for all container-based projects regardless of industry. 47 | 48 | Organizations are strongly encouraged to look more deeply at their unique risk characteristics based on the nature of their business. At the other end of the spectrum is CSVS Level 3, which is reserved for those cases that might endanger human safety or when a full application breach could severely impact the organization. 49 | 50 | ## Use Cases 51 | 52 | ### As Detailed Security Architecture Guidance 53 | 54 | One of the more common uses for the Container Security Verification Standard is as a resource for security architects. The two major security architecture frameworks, SABSA and TOGAF, are missing a great deal of information that is necessary to complete application and container security architecture review. CSVS can be used to fill in those gaps by allowing security architects to choose better controls for common problems. 55 | 56 | ### As a Replacement for Off-the-shelf Checklists 57 | 58 | Many organizations can benefit from adopting the CSVS, by choosing one of the three levels, or by forking CSVS and changing what is required for each risk level in a domain specific way. We encourage this type of forking as long as traceability is maintained. 59 | 60 | ### For Security Trainings 61 | 62 | The CSVS can also be used to define characteristics of secure container infrastructure. Many security courses are simply ethical hacking courses with a light smear of operational tips. Security trainings can use the CSVS with its strong focus on the proactive controls to tech about best practices. 63 | -------------------------------------------------------------------------------- /en/0x10-V01-Organizational.md: -------------------------------------------------------------------------------- 1 | # V1: Organizational 2 | 3 | ## Control Objective 4 | 5 | In a perfect world, security would be considered throughout all phases of development. In reality however, security is often only a consideration at a late stage in the SDLC. Besides the technical controls, the CSVS requires processes to be in place that ensure that the security has been explicitly addressed when planning the architecture of the solution, and that the functional and security roles of all components are known. 6 | 7 | The category "V1" lists requirements pertaining to processes, architecture and design of the container solution. As such, this category can't be mapped to technical test cases but must be tackled on a process level. In addition, it should be noted, that this category is not and will never be complete as each organization is structured differently and each setup has different organizational and process requirements. The CSVS only tries to cover some basic aspects in this category and it's highly recommended to extend the requirements based on your needs. 8 | 9 | ## Security Verification Requirements 10 | 11 | Please note that the requirements in this section are non-exhaustive as many organizational security controls aren't solely focused on container infrastructures. 12 | 13 | | # | Description | L1 | L2 | L3 | Since | 14 | | --- | --- | --- | --- | -- | -- | 15 | | **1.1** | Verify that technical employees (especially the ones tasked with DevOps like activities and architects) receive regular training on security aspects of the technologies they use. | ✓ | ✓ | ✓ | 1.0 | 16 | | **1.2** | Verify that managers receive regular training on security aspects of the technologies used in their projects. | | | ✓ | 1.0 | 17 | | **1.3** | Verify that all handled data is classified based on internal data classification standards. | ✓ | ✓ | ✓ | 1.0 | 18 | | **1.4** | Verify that each service/application (can consist of multiple containers) has a security concept which provides information on the security needs of the service/application and how they are or will be addressed. | | ✓ | ✓ | 1.0 | 19 | | **1.5** | Verify that identified security risks and vulnerabilities are promptly eliminated (or an exception is granted) and centrally managed according to a predefined risk and vulnerability management process. | | ✓ | ✓ | 1.0 | 20 | | **1.6** | Verify the roles and responsibilities concerning the container infrastructure are defined. This includes e.g. who approves connectivity or decides on allowed base images. | | ✓ | ✓ | 1.0 | 21 | -------------------------------------------------------------------------------- /en/0x11-V02-Infrastructure.md: -------------------------------------------------------------------------------- 1 | # V2: Infrastructure 2 | 3 | ## Control Objective 4 | 5 | The underlying infrastructure can be very different for various setups but it's the basis of each and must therefore provide the possibility for the upper layers to achieve the demanded level of security. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Ensure that the infrastructure provides adequate resources. 10 | * Harden the base infrastructure including the container platform. 11 | 12 | ## Security Verification Requirements 13 | 14 | | # | Description | L1 | L2 | L3 | Since | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **2.1** | Verify that the overall architecture and design including networking inside and outside of the container solution is defined. | ✓ | ✓ | ✓ | 1.0 | 17 | | **2.2** | Verify that the infrastructure, including all components thereof (nodes, networks, containers, ...) are documented (ideally fully automated). | ✓ | ✓ | ✓ | 1.0 | 18 | | **2.3** | Verify that all of the used components are supported/maintained and compatible with each other (OS, Docker Engine, UCP, DTR, ...). | ✓ | ✓ | ✓ | 1.0 | 19 | | **2.4** | Verify that adequate resources are allocated to all nodes for them to run stable. | ✓ | ✓ | ✓ | 1.0 | 20 | | **2.5** | Verify that the resources available to containers are limited (ulimit). | | ✓ | ✓ | 1.0 | 21 | | **2.6** | Verify that SELinux or AppArmor is enabled and running on all nodes as well as for _dockerd_. | | | ✓ | 1.0 | 22 | | **2.7** | Verify that updates for both the nodes and the Docker Engine running on them are applied in regular intervals. Ideally, applying updates is fully automated. | ✓ | ✓ | ✓ | 1.0 | 23 | | **2.8** | Verify that updates are rolled out using a canary deployment/release strategy, which allows rollbacks. | | ✓ | ✓ | 1.0 | 24 | | **2.9** | Verify that _dockerd_ is configured with _live restore_ enabled. | | ✓ | ✓ | 1.0 | 25 | | **2.10** | Verify that permissions to the configuration of _dockerd_ is restricted to users that actually need access to it and are properly logged. | ✓ | ✓ | ✓ | 1.0 | 26 | | **2.11** | Verify that all nodes undergo regular automated security scans which cover the whole operating system and not just container related elements. | | ✓ | ✓ | 1.0 | 27 | | **2.12** | Verify that container-specific operating systems (e.g. Container Linux, RancherOS, RedHat Project Atomic, VMware Photon) are used on all nodes instead of general-purpose ones. | | | ✓ | 1.0 | 28 | | **2.13** | Verify that all nodes are hardened based on common best practices. | ✓ | ✓ | ✓ | 1.0 | 29 | | **2.14** | Verify that unless otherwise specified, the default Docker configuration values are used. | ✓ | ✓ | ✓ | 1.0 | 30 | | **2.15** | Verify that direct access to nodes (e.g. via SSH or RDP) is restricted as much as possible. | ✓ | ✓ | ✓ | 1.0 | 31 | -------------------------------------------------------------------------------- /en/0x12-V03-Containers.md: -------------------------------------------------------------------------------- 1 | # V3: Containers 2 | 3 | ## Control Objective 4 | 5 | The main component of container-based solutions are the containers themselves. Not only do they contain services and application logic but also interact with other systems and containers to exchange data that is often sensitive and demands accurate protection. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Ensure that the containers run with the least possible privileges. 10 | * Harden services inside the container and minimize the attack surface. 11 | * Leverage security features of the container technology in use. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **3.1** | Verify that the root user isn't used within containers except during initialization and privileges are dropped on completion. | | ✓ | ✓ | 1.0 | 18 | | **3.2** | Verify that user namespacing is enabled. | | ✓ | ✓ | 1.0 | 19 | | **3.3** | Verify that within each container image, a new user is created, which is then used to perform all operations within the container. | | | ✓ | 1.0 | 20 | | **3.4** | Verify that a specific (non-standard) _seccomp_-profile is applied to each container-based on the needs of the container. | | | ✓ | 1.0 | 21 | | **3.5** | Verify that containers cannot be granted any additional privileges during their runtime (`--no-new-privileges` flag). | ✓ | ✓ | ✓ | 1.0 | 22 | | **3.6** | Verify that all base images are explicitly specified, using their hash instead of name and tag. | | | ✓ | 1.0 | 23 | | **3.7** | Verify that the signature of each image is verified before productive usage. | | | ✓ | 1.0 | 24 | | **3.8** | Verify that only required software packages are installed in images. | ✓ | ✓ | ✓ | 1.0 | 25 | | **3.9** | Verify that the root file system is mounted in read-only mode. | | ✓ | ✓ | 1.0 | 26 | | **3.10** | Verify that after a container has been actively accessed (e.g., for troubleshooting), it's deleted and replaced by a new instance (container) of the image. | | ✓ | ✓ | 1.0 | 27 | | **3.11** | Verify that Dockerfiles use the `COPY` directive instead of the `ADD` directive unless the source is fully trusted. | ✓ | ✓ | ✓ | 1.0 | 28 | | **3.12** | Verify that remote management services such as SSH or RDP are disabled or not even installed within containers. | ✓ | ✓ | ✓ | 1.0 | 29 | | **3.13** | Verify that exposed services such as _etcd_ are either only available to fully trusted systems or require authentication. | ✓ | ✓ | ✓ | 1.0 | 30 | | **3.14** | Verify that the number of allowed processes within a container is precisely defined and limited to this value by using `--pids-limit`. | | | ✓ | 1.0 | 31 | | **3.15** | Verify that the Docker socket isn't mounted inside any container unless they are used for monitoring or administration. If access to the Docker socket is required, check if read-only access is sufficient and limit the access of the container accordingly. | ✓ | ✓ | ✓ | 1.0 | 32 | -------------------------------------------------------------------------------- /en/0x13-V04-Orchestration-Management.md: -------------------------------------------------------------------------------- 1 | # V4: Orchestration Management 2 | 3 | ## Control Objective 4 | 5 | As your container-based solutions outgrows a certain amount of nodes and containers an orchestrator is needed. The orchestrator helps managing and administrating the solution and keep track of what's going on. As the orchestrator is such a mighty central piece in a container infrastructure the security level of the orchestrator directly affects every other aspect of your infrastructure. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Uptime for the orchestrator is guaranteed. 10 | * The orchestrator is hardened. 11 | * Interaction with the orchestrator is mostly automated to avoid human errors. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **4.1** | Verify that manager nodes are set up redundant and ready to support high availability. | ✓ | ✓ | ✓ | 1.0 | 18 | | **4.2** | Verify that an odd number of manager nodes is deployed with a minimum of three nodes. | ✓ | ✓ | ✓ | 1.0 | 19 | | **4.3** | Verify that managers are distributed across multiple data centers and availability zones. | | ✓ | ✓ | 1.0 | 20 | | **4.4** | Verify that manager nodes run with _auto-lock_ enabled. | | | ✓ | 1.0 | 21 | | **4.5** | Verify that the orchestrator rebalances the active containers on a regular basis. | ✓ | ✓ | ✓ | 1.0 | 22 | | **4.6** | Verify that manager nodes don't take on worker tasks and containers. | ✓ | ✓ | ✓ | 1.0 | 23 | | **4.7** | Verify that predefined labels are used to properly identify and manage all resources. | | ✓ | ✓ | 1.0 | 24 | | **4.8** | Verify that containers that are no longer needed are deleted. | | ✓ | ✓ | 1.0 | 25 | | **4.9** | Verify that only containers with the same data classification level run on the same node. | | | ✓ | 1.0 | 26 | | **4.10** | Verify that only containers with the same level of exposure (e.g. Internet facing) run on the same node. | | | ✓ | 1.0 | 27 | -------------------------------------------------------------------------------- /en/0x14-V05-Image-Distribution.md: -------------------------------------------------------------------------------- 1 | # V5: Image Distribution 2 | 3 | ## Control Objective 4 | 5 | To have some running containers first you need images to be built. Images define what will be running inside of a container and for example which version of a software package will be used. As the base of potentially a huge amount of container, the security of each image is essential to ensure safe operation of an environment. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Images are hardened. 10 | * No sensitive data is stored inside of images. 11 | * Images are checked for vulnerable components. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **5.1** | Verify that an odd number of image registries (e.g., DTR) with a minimum of three registries is used. | | | ✓ | 1.0 | 18 | | **5.2** | Verify that garbage collection is enabled on the image registries and running on a regular basis. | ✓ | ✓ | ✓ | 1.0 | 19 | | **5.3** | Verify that all images undergo regular automated security scans. | | ✓ | ✓ | 1.0 | 20 | | **5.4** | Verify that containers are always created based on the most recent corresponding image and not local caches. | ✓ | ✓ | ✓ | 1.0 | 21 | | **5.5** | Verify that all images are using tags whereas only production/master is allowed to use the default _latest_ tag. | | ✓ | ✓ | 1.0 | 22 | -------------------------------------------------------------------------------- /en/0x15-V06-Secrets-and-Keys.md: -------------------------------------------------------------------------------- 1 | # V6: Secrets and Keys 2 | 3 | ## Control Objective 4 | 5 | Production systems are usually using some kind of secrets and cryptographic keys. Those can be used for configuration purposes and include usernames and passwords or to allow the protection of information by cryptographic means. This section defines how such sensitive information can should be handled. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Protect sensitive information. 10 | * Verify secure handling of cryptographic material. 11 | * Rotate cryptographic keys on a regular basis. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **6.1** | Verify that an RBAC model to manage access control is used. | | ✓ | ✓ | 1.0 | 18 | | **6.2** | Verify that Docker Content Trust is enabled and enforced. | | | ✓ | 1.0 | 19 | | **6.3** | Sensitive information may never be part of a Dockerfile or Docker-Compose file. In particular, verify that e.g. Docker secrets are used for handling sensitive information like API keys and passwords. | ✓ | ✓ | ✓ | 1.0 | 20 | | **6.4** | Verify that orchestration join keys are rotated in regular intervals. | | ✓ | ✓ | 1.0 | 21 | | **6.5** | Verify that auto-lock keys are rotated in regular intervals if auto-lock is enabled. | | ✓ | ✓ | 1.0 | 22 | | **6.6** | Verify that node certificates are rotated in regular intervals. | | ✓ | ✓ | 1.0 | 23 | | **6.7** | Verify that CA certificates are rotated in regular intervals. | | ✓ | ✓ | 1.0 | 24 | | **6.8** | Verify that your own CA is used for generating and verifying certificates used for mutual TLS authentication of inter-cluster communication. | | ✓ | ✓ | 1.0 | 25 | | **6.9** | Verify that the SSL/TLS certificates used (e.g. for UCP and DTR) are validated. | ✓ | ✓ | ✓ | 1.0 | 26 | | **6.10** | Verify that secrets (e.g. cryptographic keys and passwords) are used securely with a secret management solution instead of e.g. exposed to a container by using environment variables. | | ✓ | ✓ | 1.0 | 27 | -------------------------------------------------------------------------------- /en/0x16-V07-Network.md: -------------------------------------------------------------------------------- 1 | # V7: Network 2 | 3 | ## Control Objective 4 | 5 | Nearly all modern applications and services aren't monolithic but instead consist of multiple components interacting with each other through network connections. Securing networks is its own security discipline but there are some aspects that container technologies can affect and where they can improve security when using networks. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Choose a good network driver and configure it correctly. 10 | * Disable unneeded features and apply restrictions. 11 | * Enforce encryption when transferring data over networks. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **7.1** | Verify that a production ready networking driver is used. | ✓ | ✓ | ✓ | 1.0 | 18 | | **7.2** | Verify that load balancing features are activated (e.g. by using DNS Round Robin or virtual IPs (VIP)). | | ✓ | ✓ | 1.0 | 19 | | **7.3** | Verify that the Docker userland proxy (which is enabled by default) is disabled. | | ✓ | ✓ | 1.0 | 20 | | **7.4** | Verify that the default bridge (_docker0_) is not used. | ✓ | ✓ | ✓ | 1.0 | 21 | | **7.5** | Verify that _dockerd_ is configured in a way that network communication between different containers is not possible by default. This can be done either by not using the _docker0_ bridge or setting _--icc_ to false. | | ✓ | ✓ | 1.0 | 22 | | **7.6** | Verify that _dockerd_ is permitted to modify _iptables_ rules. | ✓ | ✓ | ✓ | 1.0 | 23 | | **7.7** | Verify that published ports are assigned to a specific network interface of a node. | ✓ | ✓ | ✓ | 1.0 | 24 | | **7.8** | Verify that management and data/application traffic is separated by different network interfaces. | | | ✓ | 1.0 | 25 | | **7.9** | Verify that each application (one or more services) is assigned at least one separate, isolated overlay network in order to ensure Layer 3 segmentation. | | ✓ | ✓ | 1.0 | 26 | | **7.10** | Verify that encryption between containers or nodes on the overlay network is enabled. | | ✓ | ✓ | 1.0 | 27 | | **7.11** | Verify that the used subnets do not overlap with other subnets (e.g. overlay networks). | ✓ | ✓ | ✓ | 1.0 | 28 | | **7.12** | Verify that published ports are limited to a necessary minimum. | ✓ | ✓ | ✓ | 1.0 | 29 | -------------------------------------------------------------------------------- /en/0x17-V08-Storage.md: -------------------------------------------------------------------------------- 1 | # V8: Storage 2 | 3 | ## Control Objective 4 | 5 | As containers are ephemeral it's important to provide a reliable and secure storage backend for persistent data. Not only is the availability of stored data essential but also its integrity and access control measures. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Choose a good storage driver and configure it correctly. 10 | * Make sure data is not locally stored on nodes for persistence. 11 | 12 | ## Security Verification Requirements 13 | 14 | | # | Description | L1 | L2 | L3 | Since | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **8.1** | Verify that a production ready storage backend is used. | ✓ | ✓ | ✓ | 1.0 | 17 | | **8.2** | Verify that the image storage backend is redundant and located in a secured network zone. | ✓ | ✓ | ✓ | 1.0 | 18 | | **8.3** | Verify that a suitable and tested data storage driver is used in order to ensure the replication and availability of application data. | ✓ | ✓ | ✓ | 1.0 | 19 | | **8.4** | Verify that persistent data is never stored directly inside a container, but on a corresponding docker volume or mount point instead. | ✓ | ✓ | ✓ | 1.0 | 20 | | **8.5** | Verify that persistent data is regularly backed up according to a suitable well defined backup concept and the restore is tested. | ✓ | ✓ | ✓ | 1.0 | 21 | -------------------------------------------------------------------------------- /en/0x18-V09-Logging-Monitoring.md: -------------------------------------------------------------------------------- 1 | # V9: Logging & Monitoring 2 | 3 | ## Control Objective 4 | 5 | Securing containers and infrastructure is one thing but making sure that you know when things go wrong is no less important. Logging and monitoring provide you insights in the current state of your solution and allow you to react accordingly. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Have a central logging and monitoring instance. 10 | * Monitor all your components. 11 | 12 | ## Security Verification Requirements 13 | 14 | | # | Description | L1 | L2 | L3 | Since | 15 | | --- | --- | --- | --- | -- | -- | 16 | | **9.1** | Verify that the underlying system, Docker Engine, as well as containers and their processes are logged. | | ✓ | ✓ | 1.0 | 17 | | **9.2** | Verify that the used resources at both node and container level are monitored. | | ✓ | ✓ | 1.0 | 18 | | **9.3** | Verify that the storage backend is monitored. | | ✓ | ✓ | 1.0 | 19 | | **9.4** | Verify that Docker's health checking functionality is used for all containers and their status is monitored. | | ✓ | ✓ | 1.0 | 20 | | **9.5** | Verify that all logs are transferred and stored to/in a central location. | | ✓ | ✓ | 1.0 | 21 | | **9.6** | Verify that in production environments, the log level of _dockerd_ is set to _info_. | ✓ | ✓ | ✓ | 1.0 | 22 | -------------------------------------------------------------------------------- /en/0x19-V10-Integration.md: -------------------------------------------------------------------------------- 1 | # V10: Integration 2 | 3 | ## Control Objective 4 | 5 | Container-based solutions are normally not self-contained but instead integrate with a variety of different systems. Such systems could be IAM solutions, CI/CD pipelines or existing network environments. Any interaction also poses a potential threat to a container-based solution and vice-versa. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Integrate into existing security infrastructure. 10 | * Place information in a central inventory and change management system. 11 | * Leverage existing networking infrastructure. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **10.1** | Verify that the orchestration solution (e.g. UCP) and registry (e.g. DTR) are integrated into the existing infrastructure (SSO, DCT,...). | | ✓ | ✓ | 1.0 | 18 | | **10.2** | Verify that the CI/CD tools and systems are connected to the Docker infrastructure to enable changes in nodes, images, or the network to be tested and rolled out fully automated. | | ✓ | ✓ | 1.0 | 19 | | **10.3** | Verify that additional nodes can be set up automatically (e.g., Puppet, Chef, Ansible, Salt, Terraform) and configured the same way as existing nodes. | | ✓ | ✓ | 1.0 | 20 | | **10.4** | Verify that a central change management system is implemented and all changes to the container infrastructure and its components are tracked there. | | ✓ | ✓ | 1.0 | 21 | | **10.5** | Verify that a discovery and registration service like consul, Zookeeper, Eureka, Etcd or even just DNS is used internally and externally. | | ✓ | ✓ | 1.0 | 22 | | **10.6** | Verify that users and roles are mapped to an existing central IAM solution. | | | ✓ | 1.0 | 23 | -------------------------------------------------------------------------------- /en/0x20-V11-Disaster-Recovery.md: -------------------------------------------------------------------------------- 1 | # V11: Disaster Recovery 2 | 3 | ## Control Objective 4 | 5 | When things go wrong it is important to get back on your feed as fast as possible without compromizing on security. This category describes requirements on how to verify that your disaster recovery works as expected and downtime is kept short. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements: 8 | 9 | * Backups are created on a regular basis. 10 | * Restoring steps are automated. 11 | * Self-healing capabilities are leveraged. 12 | 13 | ## Security Verification Requirements 14 | 15 | | # | Description | L1 | L2 | L3 | Since | 16 | | --- | --- | --- | --- | -- | -- | 17 | | **11.1** | Verify that regular backups (UCP, DTR, and Swarm) are performed. A weekly backup has to be performed at a minimum. | ✓ | ✓ | ✓ | 1.0 | 18 | | **11.2** | Verify that the restoration of the infrastructure is automated, documented and regularly tested. | ✓ | ✓ | ✓ | 1.0 | 19 | | **11.3** | Verify that upgrades and downgrades of the basic infrastructure as well as the Docker Engine is automated, documented and regularly tested. | | | ✓ | 1.0 | 20 | | **11.4** | Verify that the recovery of individual applications/services is automated, documented and regularly tested. | | ✓ | ✓ | 1.0 | 21 | | **11.5** | Verify that an `on-failure` restart policy is enabled for each container. | | ✓ | ✓ | 1.0 | 22 | -------------------------------------------------------------------------------- /en/0x21-V12-Testing.md: -------------------------------------------------------------------------------- 1 | # V12: Testing 2 | 3 | ## Control Objective 4 | 5 | Technology is always moving forward and steadily changing in unexpected ways. Based on this securing a container-based solution isn't just a one-time effort, but different checks and validations should be done on a regular basis. 6 | 7 | Ensure that a verified container solution satisfies the following high level requirements on a regular basis: 8 | 9 | * Recovery from failure. 10 | * Ensure that security settings are taking effect. 11 | * Documentation of the current state of the container-based solution. 12 | 13 | ## Security Verification Requirements 14 | 15 | The following requirements are to be evaluated based on a regular execution cycle. It is recommended to keep the cycle at three months or shorter. 16 | 17 | | # | Description | L1 | L2 | L3 | Since | 18 | | --- | --- | --- | --- | -- | -- | 19 | | **12.1** | Verify that all user and group permissions to resources are in line with the specifications and documentation. | ✓ | ✓ | ✓ | 1.0 | 20 | | **12.2** | Verify that application/container resource limitations work as defined. | | ✓ | ✓ | 1.0 | 21 | | **12.3** | Verify that each service can be successfully recreated in a fully automated way. | | ✓ | ✓ | 1.0 | 22 | | **12.4** | Verify that certificates and keys are rotated according to the specifications. | | | ✓ | 1.0 | 23 | | **12.5** | Verify that the configurations, images and networks of all services can be updated and downgraded on a rolling basis. | | ✓ | ✓ | 1.0 | 24 | | **12.6** | Verify that nodes as well as the Docker Engine are up to date. | ✓ | ✓ | ✓ | 1.0 | 25 | | **12.7** | Verify that the load-balancing strategies work as defined. | | ✓ | ✓ | 1.0 | 26 | | **12.8** | Verify that containers are balanced across the cluster based on the defined strategy. | | ✓ | ✓ | 1.0 | 27 | | **12.9** | Verify that all services can recover from failures of nodes and individual containers. | | ✓ | ✓ | 1.0 | 28 | | **12.10** | Verify that backups can be restored for all services in the event of a total failure. | ✓ | ✓ | ✓ | 1.0 | 29 | | **12.11** | Verify that _Docker Security Bench_ runs regularly and passes. | | ✓ | ✓ | 1.0 | 30 | -------------------------------------------------------------------------------- /en/0x90-Appendix-A_Glossary.md: -------------------------------------------------------------------------------- 1 | # Appendix A: Glossary 2 | 3 | * **API** – Application programming interface 4 | * **CA** – Certificate Authority 5 | * **CI/CD** – Continuous Integration and Continuous Delivery 6 | * **CLI** – Command Line Interface 7 | * **DCT** – Docker Content Trust 8 | * **DNS RR** – DNS Round Robin 9 | * **DTR** – Docker Trusted Registry 10 | * **IAM** - Identity and Access Management 11 | * **LDAP** – Lightweight Directory Access Protocol 12 | * **mTLS** – Mutual TLS (authentication) 13 | * **Node** – A physical host on which the container / Docker engine runs. Could be a single host or a host as part of a cluster. 14 | * **RBAC** – Role-Based Access Control 15 | * **RDP** – Remote Desktop Protocol 16 | * **Service** – A service which runs in a container. 17 | * **SSH** – Secure Shell 18 | * **SSL** – Secure Sockets Layer 19 | * **SSO** – Single Sign-On 20 | * **TLS** – Transport Layer Security, the successor to Secure Sockets Layer (SSL) 21 | * **UCP** – Docker Universal Control Plane 22 | * **VIP** – Virtual IP 23 | -------------------------------------------------------------------------------- /en/0x91-Appendix-B_References.md: -------------------------------------------------------------------------------- 1 | # Appendix B: References 2 | 3 | The following projects are most likely to be useful to users/adopters of this standard and were also helpful during its creation: 4 | 5 | - OWASP Application Security Verification Standard - [https://www.owasp.org/index.php/ASVS](https://www.owasp.org/index.php/ASVS) 6 | - CIS Docker Benchmark - [https://www.cisecurity.org/benchmark/docker/](https://www.cisecurity.org/benchmark/docker/) 7 | - Docker Reference Architectures - [https://success.docker.com/architectures](https://success.docker.com/architectures) 8 | - Docker EE Best Practices and Design Considerations - [https://success.docker.com/article/docker-ee-best-practices](https://success.docker.com/article/docker-ee-best-practices) 9 | - NIST Application Container Security Guide - [https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf) 10 | -------------------------------------------------------------------------------- /export.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python 2 | 3 | ''' Tool for converting the MASVS requirements to various formats. 4 | 5 | Usage: ./export.py [--format /dev/null 2>&1; 8 | } 9 | 10 | if ! command_exists pandoc; then 11 | echo "Error: Please install pandoc. Cannot continue" 12 | exit; 13 | fi 14 | 15 | if ! command_exists xelatex; then 16 | echo "Warning: Install xelatex to produce PDF output" 17 | fi 18 | 19 | echo "" 20 | 21 | generate_pdf() { 22 | if command_exists xelatex; then 23 | # pandoc -N --template ../templates/template.tex --variable mainfont="Merriweather" --variable sansfont="Roboto" --variable monofont="Menlo" --variable fontsize=10pt --variable version=1.17.2 --pdf-engine=xelatex --toc -fmarkdown-implicit_figures -o "../container_security_verification_standard$1.pdf" *.md 24 | echo " no PDF generated due to bugs" 25 | else 26 | echo " could not generate PDF, missing pdflatex" 27 | fi 28 | } 29 | 30 | generate_docx() { 31 | pandoc -s -f gfm --reference-doc=../templates/reference.docx --columns 10000 -t docx -o "../container_security_verification_standard_$1.docx" *.md 32 | } 33 | 34 | generate_html() { 35 | pandoc -s -f gfm -t html5 -o "../container_security_verification_standard_$1.html" *.md 36 | } 37 | 38 | generate() { 39 | echo -n "Generating CSVS ($1)..." 40 | if [ -d "$1" ]; 41 | then 42 | cd "$1" 43 | generate_docx $1 44 | generate_pdf $1 45 | generate_html $1 46 | cd .. 47 | echo " done." 48 | else 49 | echo " No CSVS found in directory $1" 50 | fi 51 | } 52 | 53 | # Arabic 54 | #generate "ar" 55 | 56 | # Brazil 57 | #generate "br" 58 | 59 | # Chinese 60 | #generate "cn" 61 | 62 | # Czech 63 | #generate "cz" 64 | 65 | # English 66 | generate "en" 67 | 68 | # French 69 | #generate "fr" 70 | 71 | # German 72 | generate "de" 73 | 74 | # Hebrew 75 | #generate "heb" 76 | 77 | # Italian 78 | #generate "it" 79 | 80 | # Japanese 81 | #generate "jp" 82 | 83 | # Korean 84 | #generate "kr" 85 | 86 | # Spanish 87 | # generate "es" 88 | 89 | # Ukraine 90 | #generate "ukr" 91 | 92 | echo 93 | echo "Generated Container Security Verification Standard" 94 | -------------------------------------------------------------------------------- /generate_document_with_docker.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | function command_exists () { 4 | command -v $1 >/dev/null 2>&1; 5 | } 6 | 7 | if ! command_exists docker; then 8 | echo "Docker isn't installed/available on this system..." 9 | exit; 10 | fi 11 | 12 | docker build -t owasp/csvs-pandoc . 13 | docker run -it --rm -v "$(pwd)":/app owasp/csvs-pandoc 14 | -------------------------------------------------------------------------------- /images/csvs-levels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Container-Security-Verification-Standard/57c0ee7fb6e0e2dc6f27c624da5d13b18d2a5a15/images/csvs-levels.png -------------------------------------------------------------------------------- /images/license.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Container-Security-Verification-Standard/57c0ee7fb6e0e2dc6f27c624da5d13b18d2a5a15/images/license.png -------------------------------------------------------------------------------- /images/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Container-Security-Verification-Standard/57c0ee7fb6e0e2dc6f27c624da5d13b18d2a5a15/images/logo.png -------------------------------------------------------------------------------- /images/redguard-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Container-Security-Verification-Standard/57c0ee7fb6e0e2dc6f27c624da5d13b18d2a5a15/images/redguard-logo.png -------------------------------------------------------------------------------- /templates/reference.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Container-Security-Verification-Standard/57c0ee7fb6e0e2dc6f27c624da5d13b18d2a5a15/templates/reference.docx --------------------------------------------------------------------------------