Appendix C: BSI Grundschutz Mapping (German)

Das IT-Grundschutz-Kompendium 2020 enthält nun auch mit Modul “Software Entwicklung” im Bereich “Konzepte und Vorgehensweisen” Anforderungen an die Softwarentwicklung. Anforderungen aus diesem Bereich sind mit CON.8 referenziert und in drei Stufen (“Basis”, “Standard” und “Erweitert”) eingeteilt. Da dies bisher nur in deutsch verfügbar ist, erfolgt diese Betrachtung auch in deutsch.

Insgesamt werden durch TSS-WEB alle sicherheitsrelevanten Basis- und Standard-Anforderungen abgedeckt.

Anforderung aus IT Grundschutz Kompendium 2020

Level

Relevante Anforderung aus TSS-WEB

CON.8.A1 Definition von Rollen und Verantwortlichkeiten [Leiter Organisation] (B)

  1. Für den Software-Entwicklungsprozess MUSS ein Gesamtverantwortlicher benannt werden.

  2. Außerdem MÜSSEN die Rollen und Verantwortlichkeiten für alle Aktivitäten im Rahmen der Software-Entwicklung festgelegt werden.

  3. Für jedes Entwicklungsprojekt MUSS ein Sicherheitsverantwortlicher benannt werden.

Basis

  1. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  2. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  3. Nein Aktuell nicht direkt abgedeckt, in der Praxis wäre dies der Produktverantwortliche (Accountable) und die Entwickler bzw. Security Architekt / Officer (Responsible)

CON.8.A2 Auswahl eines Vorgehensmodells (B)

  1. Es MUSS ein geeignetes Vorgehensmodell zur Software-Entwicklung festgelegt werden.

  2. Anhand des gewählten Vorgehensmodells MUSS ein Ablaufplan für die Software-Entwicklung erstellt werden.

  3. Die Sicherheitsanforderungen MÜSSEN dokumentiert werden.

  4. Das Personal SOLLTE in der Methodik des gewählten Vorgehensmodells geschult sein.

Basis

  1. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  2. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  3. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  4. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

 

CON.8.A3 Auswahl einer Entwicklungsumgebung (B)

  1. Es MUSS eine Liste der erforderlichen und optionalen Auswahlkriterien für eine Entwicklungsumgebung vom Leiter Entwicklung erstellt werden.

  2. Die Entwicklungsumgebung MUSS anhand der vorgegebenen Kriterien ausgewählt werden.

Basis

  1. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  2. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  3. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

 

CON.8.A4 Einhaltung einer sicheren Vorgehensweise [Entwickler] (B)

  1. Das ausgewählte Vorgehensmodell zur Software-Entwicklung, einschließlich der festgelegten Sicherheitsanforderungen, MUSS eingehalten werden.

  2. Der entwickelte oder geänderte Quellcode MUSS auf Fehler gesichtet werden.

  3. Externe Komponenten MÜSSEN auf Schwachstellen und potentielle Konflikte überprüft werden.

Basis

  1. Nur bedingt eine Sicherheitsanforderung, de Anforderungen in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process gehen auf Sicherheitsaspekte in dem Softwarentwicklungsprozess beschrieben.

  2. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  3. Ja Siehe Anf. “Secure of 3rd party dependencies” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process

CON.8.A5 Sicheres Systemdesign (B)

  1. Grundsätzlich MÜSSEN alle Eingabedaten vor der Weiterverarbeitung geprüft und validiert werden.

  2. Bei Client-Server-Anwendungen MÜSSEN die Daten grundsätzlich auf dem Server validiert werden.

  3. Die Standardeinstellungen der Software MÜSSEN derart konfiguriert sein, dass ein sicherer Betrieb der Software ermöglicht wird.

  4. Bei Fehlern oder Ausfall von Komponenten des Systems DÜRFEN KEINE schützenswerten Informationen preisgegeben werden.

  5. Der Betrieb der Software MUSS mit möglichst geringen Benutzerprivilegien möglich sein.

Basis

  1. Ja Siehe Anf. 1 inhttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/262199/8.2+Input+Validation

  2. Ja Siehe Anf. 2 in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/262199/8.2+Input+Validation

  3. Ja Siehe Anf. 9 in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/327729/8.1+General+Design+Principles

  4. Ja Siehe Anf. 1 in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/1179658

  5. Ja Siehe Anf. “System hardening” inhttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98305/3.+Secure+Operation

CON.8.A6 Verwendung von Bibliotheken aus vertrauenswürdigen Quellen (B)

  1. Wird im Rahmen des Entwicklungs- und Implementierungsprozesses auf externe Bibliotheken zurückgegriffen, MÜSSEN diese aus vertrauenswürdigen Quellen bezogen werden.

  2. Bevor sie verwendet werden, MUSS außerdem die Integrität der Bibliotheken geeignet sichergestellt werden.

Basis

  1. Ja Siehe Anf. “Secure of 3rd party dependencies” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process

  2. Unklar welche Form der Integrität hier gemeint ist:

    1. Manipulation durch Dritte: Durch HTTPS und 1. abgedeckt, zusätzliche Signaturprüfung etc. kein Stand der Technik und sicherlich keine Basis-Anforderung

    2. Inkonsistenz: Durch moderne Software implizit abgedeckt und auch keine Sicherheitsanforderung.

CON.8.A7 Anwendung von Testverfahren [Tester] (B)

  1. Vor der Freigabe neuer oder geänderter Softwareversionen MÜSSEN angemessene Tests durchgeführt werden, bei denen die Funktionalität und Sicherheit der Software auf dem Zielsystem geprüft wird.

  2. Alle kritischen Grenzwerte MÜSSEN getestet werden.

  3. Code Reviews und eine automatische statische Code-Analyse MÜSSEN durchgeführt werden.

  4. Verwendete externe Bibliotheken MÜSSEN ebenfalls getestet werden

  5. Außerdem MUSS getestet werden, ob die Systemvoraussetzungen für die vorgesehene Software ausreichend dimensioniert sind.

Basis

  1. Ja Siehe Anf. “Security Gates” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process

  2. Ja Siehe Anf. “Remediation of Security findings” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process

  3. Ja Siehe Anf. "Utilize automated security testing tools" und "Custom security tests & developer tests" in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98368/6.+Security+Tests

  4. Siehe Anf. “Secure of 3rd party dependencies” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process

  5. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

CON.8.A8 Bereitstellung von Patches, Updates und Änderungen [Entwickler] (B)

  1. Es MUSS sichergestellt sein, dass sicherheitskritische Patches und Updates zeitnah durch die Entwickler bereitgestellt und durch den IT-Betrieb eingespielt werden. Dies betrifft auch verwendete externe Bibliotheken.

  2. Für die Installations-, Update- oder Patchdateien MÜSSEN vom Entwickler digitale Signaturen bereitgestellt wer-den.

Basis

  1. Ja Siehe Anforderungen in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/294913/2.+Remediation+of+Vulnerabilities+in+Production

  2. Nein Nicht abgedeckt, da Code Signing aus unserer Sicht keine generell sinnvolle Anforderung darstellt.

CON.8.A9 Berücksichtigung von Compliance-Anforderungen [Entwickler] (B)

  1. Alle Compliance-Anforderungen, die institutionsweiten Sicherheitsrichtlinien, die rechtlichen Anforderungen und die spezifischen Sicherheitsanforderungen MÜSSEN bei der Software-Entwicklung ermittelt und berücksichtigt werden.

Basis

Nein Nicht abgedeckt, da unternehmensspezifisch.

CON.8.A10 Versionsverwaltung des Quellcodes [Entwickler] (B)

  1. Das Entwicklungsprojekt (Quellcode des Projektes) MUSS über eine geeignete Versionsverwaltung verwaltet wer-den.

  2. Der Leiter Entwicklung MUSS den Zugriff auf die Versionsverwaltung regeln und festlegen, wann Änderungen am Quellcode durch die Entwickler als eigene Version in der Versionsverwaltung gespeichert werden sollen.

  3. Es MUSS sichergestellt sein, dass durch die Versionsverwaltung alle Änderungen am Quellcode nachvollzogen und rückgängig gemacht werden können.

  4. Die Versionsverwaltung MUSS in dem Datensicherungskonzept berücksichtigt werden und DARF NICHT ohne Datensicherung erfolgen.

Basis

  1. Ja Siehe Anf. “Protection of source and program code” https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Secure+Development+Environment

  2. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

  3. Nein Unnötige Anforderung, das dies eine grundlegende Eigenschaft eines Versionisierungssystem darstellt.

  4. Nein Nicht abgedeckt, da keine Sicherheitsanforderung

CON.8.A11 Erstellung einer Richtlinie für die Software-Entwicklung (S)

  1. Es SOLLTE eine Richtlinie für die Software-Entwicklung erstellt und aktuell gehalten werden.

  2. Die Richtlinie SOLLTE neben Namenskonventionen auch Vorgaben zu Elementen beinhalten, die verwendet bzw. nicht verwendet wer-den dürfen.

  3. Die relevanten Anforderungen aus diesem Baustein SOLLTEN in die Richtlinie aufgenommen werden.

  4. Die Richtlinie SOLLTE für die Entwickler verbindlich sein.

Standard

Nein Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.

Eine Richtlinie für sichere Softwareentwicklung oder alternativ die Berücksichtigung von Sicherheit in der bestehenden Richtlinie für Softwareentwicklung würden Sinn machen. Das ist der Gedanke von TSS-WEB.

CON.8.A12 Ausführliche Dokumentation (S)

  1. Es SOLLTEN ausreichende Projekt-, Funktions- und Schnittstellendokumentationen erstellt und aktuell gehalten werden.

  2. Benutzern und Administratoren SOLLTEN geeignete Hilfen zur korrekten Nutzung bzw. Administration der Software zur Verfügung gestellt werden.

  3. Die Software-Entwicklung SOLLTE so dokumentiert sein, dass ein Fachexperte mithilfe der Dokumentation den Programm-Code nachvollziehen und weiterentwickeln kann.

Standard

Nein Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.

In Anf. “Security documentation” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Processsind Anforderungen an die Dokumentation von Sicherheitsaspekten gestellt.

CON.8.A13 Beschaffung von Werkzeugen (S)

  1. Werkzeuge für die Software-Entwicklung SOLLTEN nach standardisierten und dokumentierten Vorgehensweisen beschafft werden.

Standard

Nein Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.

CON.8.A14 Schulung des Projektteams zur Informationssicherheit (S)

  1. Die Entwickler und die übrigen Mitglieder des Projektteams SOLLTEN zu generellen Informationssicherheitsaspekten und zu den jeweils speziell für sie relevanten Aspekten geschult sein.

Standard

Nein Implizit abdeckt durch Rollenbeschreibungen in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/327717/1.+Introduction .

CON.8.A15 Sicherer Einsatz der Test- und Entwicklungsumgebungen [Entwickler] (S)

  1. Die Test- und Entwicklungsumgebungen SOLLTEN getrennt von der Produktionsumgebung betrieben werden.

  2. Informationen, die für den Produktivbetrieb nicht relevant sind, SOLLTEN möglichst entfernt werden, bevor die Programmpakete in die Produktionsumgebung überführt werden.

  3. Testdaten SOLLTEN sorgfältig ausgewählt und geschützt werden.

  4. Verteilte Arbeitsplätze der Software-Entwicklung SOLLTEN über eine sichere Verbindung miteinander kommunizieren. Der Zugriff auf die Entwicklungsdaten SOLLTE kontrolliert sein.

Standard

  1. Ja Siehe Anf. zu “Environment separation” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98305/3.+Secure+Operation

  2. Ja Siehe Anf. zu “System hardening” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98305/3.+Secure+Operation (“Exposed development artifacts (e.g. SVN files)”)

  3. Ja Siehe Anf. zu “General requirements” in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98368/6.+Security+Tests (“Data used on development and test systems MUST be either synthetic or anonymized production data…”)

  4. JaSiehe Anf. “Securing access to the dev environment” inhttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Secure+Development+Environment. Wichtiger ist jedoch der sichere Zugriff auf sensiblen Programmcode von remote.

CON.8.A16 Geeignete Steuerung der Software-Entwicklung (S)

  1. Bei einer Software-Entwicklung SOLLTE ein geeignetes Steuerungs- und Projektmanagementmodell auf Basis des ausgewählten Vorgehensmodells verwendet werden und in die Richtlinie zur Software-Entwicklung integriert wer-den.

  2. Dabei SOLLTEN insbesondere die benötigten Qualifikationen beim Personal und die Abdeckung aller relevanten Phasen während des Lebenszyklus der Software berücksichtigt werden.

  3. Außerdem SOLLTE ein geeignetes Entwicklungsmodell und Risikomanagement sowie geeignete Qualitätsziele festgelegt werden.

  4. Werden Teile der Software-Entwicklung extern durchgeführt, SOLLTE dies geeignet in die internen Steuerungs- und Sicherheitsprozesse eingebunden werden.

Standard

  1. Nein Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.

  2. Nein Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.

  3. Unklar, ob hier mit Risikomanagement Projektrisiken oder Sicherheitsrisiken gemeint sind. Letzteres ist durch verschiedene Anforderungen in https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338/5.+Security+within+Software+Development+Process enthalten.

  4. Nein Nicht explizit abgedeckt.

CON.8.A17 Auswahl vertrauenswürdiger Entwicklungswerkzeuge (H)

  1. Zur Entwicklung der Software SOLLTEN nur Werkzeuge mit nachgewiesenen Sicherheitseigenschaften verwendet werden.

  2. Es SOLLTE sichergestellt sein, dass die Werkzeuge nicht manipuliert werden können.

  3. An die Hersteller von Hardware oder Software SOLLTEN hinreichende Anforderungen zur Sicherheit ihrer Werkzeuge gestellt werden.

Erweitert

  1. Unklar was hiermit konkret gemeint ist.

  2. Unklar was hiermit konkret gemeint und was hier in der Praxis geschehen soll. Manipuliert durch den Entwickler oder durch Dritte?

  3. Unklar wer diese Anforderung stellen soll und was für Anforderungen dies in der Praxis betreffen soll.

CON.8.A18 Regelmäßige Sicherheitsaudits für die Entwicklungsumgebung (H)

  1. Es SOLLTEN regelmäßige Sicherheitsaudits der Software-Entwicklungsumgebung und der Software-Testumgebung durchgeführt werden.

Erweitert

Nein Nicht explizit abgedeckt. Zudem unklar, was ein solches Sicherheitsaudit umfassen soll (die korrekte Integration von Security Tools wie SAST etc., die Verwendung aktueller Versionen oder die Verwendung nicht-manipulierter Werkzeuge?).

CON.8.A19 Regelmäßige Integritätsprüfung der Entwicklungsumgebung [IT-Betrieb] (H)

  1. Die Integrität der Entwicklungsumgebung SOLLTE regelmäßig mit kryptographischen Mechanismen entsprechend dem Stand der Technik geprüft werden.

  2. Die Prüfsummendateien und das Prüfprogramm selbst SOLLTEN ausreichend vor Manipulationen geschützt sein.

  3. Wichtige Hinweise auf einen Integritätsverlust SOLLTEN nicht in einer Fülle irrelevanter Warnmeldungen (false positives) untergehen.

Erweitert

Nein Unklar wie dies bei moderner Softwareentwicklung geschehen soll. Nur wenn Entwicklern nicht veränderbare Entwicklungsumgebungen inkl. Module verwenden, wäre ein solcher Test denkbar.