Anforderung aus IT Grundschutz Kompendium 2020 |
Level |
Relevante Anforderung aus TSS-WEB |
CON.8.A1 Definition von Rollen und Verantwortlichkeiten [Leiter =
Organisation] (B)
-
F=C3=BCr den Software-Entwicklungsprozess MUSS ein Gesamtverantwortl=
icher benannt werden.
-
Au=C3=9Ferdem M=C3=9CSSEN die Rollen und Verantwortlichkeiten f=C3=
=BCr alle Aktivit=C3=A4ten im Rahmen der Software-Entwicklung festgelegt we=
rden.
-
F=C3=BCr jedes Entwicklungsprojekt MUSS ein Sicherheitsverantwortlic=
her benannt werden.
|
Basis |
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Aktuell nicht direkt abgedeckt, in der Praxis w=C3=A4re dies der Produktve=
rantwortliche (Accountable) und die Entwickler bzw. Security Architekt / Of=
ficer (Responsible)
|
CON.8.A2 Auswahl eines Vorgehensmodells (B)
-
Es MUSS ein geeignetes Vorgehensmodell zur Software-Entwicklung fest=
gelegt werden.
-
Anhand des gew=C3=A4hlten Vorgehensmodells MUSS ein Ablaufplan f=C3=
=BCr die Software-Entwicklung erstellt werden.
-
Die Sicherheitsanforderungen M=C3=9CSSEN dokumentiert werden.=
p>
-
Das Personal SOLLTE in der Methodik des gew=C3=A4hlten Vorgehensmode=
lls geschult sein.
|
Basis |
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
|
CON.8.A3 Auswahl einer Entwicklungsumgebung (B)
-
Es MUSS eine Liste der erforderlichen und optionalen Auswahlkriterie=
n f=C3=BCr eine Entwicklungsumgebung vom Leiter Entwicklung erstellt werden=
.
-
Die Entwicklungsumgebung MUSS anhand der vorgegebenen Kriterien ausg=
ew=C3=A4hlt werden.
|
Basis |
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
|
CON.8.A4 Einhaltung einer sicheren Vorgehensweise [Entwickler] (=
B)
-
Das ausgew=C3=A4hlte Vorgehensmodell zur Software-Entwicklung, einsc=
hlie=C3=9Flich der festgelegten Sicherheitsanforderungen, MUSS eingehalten =
werden.
-
Der entwickelte oder ge=C3=A4nderte Quellcode MUSS auf Fehler gesich=
tet werden.
-
Externe Komponenten M=C3=9CSSEN auf Schwachstellen und potentielle K=
onflikte =C3=BCberpr=C3=BCft werden.
|
Basis |
-
Nur bedingt eine Sicherheitsanforderung, de Anforderungen in 5. Security within Software Development=
Process gehen auf Sicherheitsaspekte in dem Softwarentwicklungsprozess=
beschrieben.
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
JA S=
iehe Anf. =E2=80=9CSecure of 3rd party dependencies=E2=80=9D in 5. Security within Software Development=
Process
|
CON.8.A5 Sicheres Systemdesign (B)
-
Grunds=C3=A4tzlich M=C3=9CSSEN alle Eingabedaten vor der Weiterverar=
beitung gepr=C3=BCft und validiert werden.
-
Bei Client-Server-Anwendungen M=C3=9CSSEN die Daten grunds=C3=A4tzli=
ch auf dem Server validiert werden.
-
Die Standardeinstellungen der Software M=C3=9CSSEN derart konfigurie=
rt sein, dass ein sicherer Betrieb der Software erm=C3=B6glicht wird.<=
/p>
-
Bei Fehlern oder Ausfall von Komponenten des Systems D=C3=9CRFEN KEI=
NE sch=C3=BCtzenswerten Informationen preisgegeben werden.
-
Der Betrieb der Software MUSS mit m=C3=B6glichst geringen Benutzerpr=
ivilegien m=C3=B6glich sein.
|
Basis |
-
JA S=
iehe Anf. 1 in8.2 Input Validation
-
JA S=
iehe Anf. 2 in 8.2 Input Validation
-
JA S=
iehe Anf. 9 in 8.1 General Design Principles<=
/a>
-
JA S=
iehe Anf. 1 in 8.10 Error Handling & Logging
-
JA S=
iehe Anf. =E2=80=9CSystem hardening=E2=80=9D in3. Operat=
ional Requirements
|
CON.8.A6 Verwendung von Bibliotheken aus vertrauensw=C3=BCrdigen=
Quellen (B)
-
Wird im Rahmen des Entwicklungs- und Implementierungsprozesses auf e=
xterne Bibliotheken zur=C3=BCckgegriffen, M=C3=9CSSEN diese aus vertrauensw=
=C3=BCrdigen Quellen bezogen werden.
-
Bevor sie verwendet werden, MUSS au=C3=9Ferdem die Integrit=C3=A4t d=
er Bibliotheken geeignet sichergestellt werden.
|
Basis |
-
JA S=
iehe Anf. =E2=80=9CSecure of 3rd party dependencies=E2=80=9D in 5. Security within Software Development=
Process
-
Unklar welche Form der Integrit=C3=A4t hier gemeint ist:
-
Manipulation durch Dritte: Durch HTTPS und 1. abgedeckt, zus=C3=A4tzlich=
e Signaturpr=C3=BCfung etc. kein Stand der Technik und sicherlich keine Bas=
is-Anforderung
-
Inkonsistenz: Durch moderne Software implizit abgedeckt und auch keine S=
icherheitsanforderung.
|
CON.8.A7 Anwendung von Testverfahren [Tester] (B)
-
Vor der Freigabe neuer oder ge=C3=A4nderter Softwareversionen M=C3=
=9CSSEN angemessene Tests durchgef=C3=BChrt werden, bei denen die Funktiona=
lit=C3=A4t und Sicherheit der Software auf dem Zielsystem gepr=C3=BCft wird=
.
-
Alle kritischen Grenzwerte M=C3=9CSSEN getestet werden.
-
Code Reviews und eine automatische statische Code-Analyse M=C3=9CSSE=
N durchgef=C3=BChrt werden.
-
Verwendete externe Bibliotheken M=C3=9CSSEN ebenfalls getestet werde=
n
-
Au=C3=9Ferdem MUSS getestet werden, ob die Systemvoraussetzungen f=
=C3=BCr die vorgesehene Software ausreichend dimensioniert sind. =
li>
|
Basis |
-
JA S=
iehe Anf. =E2=80=9CSecurity Gates=E2=80=9D in 5. Security within Software Development Process =
li>
-
JA S=
iehe Anf. =E2=80=9CRemediation of Security findings=E2=80=9D in 5. Se=
curity within Software Development Process
-
JA S=
iehe Anf. "Utilize automated security testing tools" und "Custom security t=
ests & developer tests" in 6. Security Tests =
li>
-
Siehe Anf. =E2=80=9CSecure of 3rd party dependencies=E2=80=9D in 5. Security within Software Develop=
ment Process
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
|
CON.8.A8 Bereitstellung von Patches, Updates und =C3=84nderungen=
[Entwickler] (B)
-
Es MUSS sichergestellt sein, dass sicherheitskritische Patches und U=
pdates zeitnah durch die Entwickler bereitgestellt und durch den IT-Betrieb=
eingespielt werden. Dies betrifft auch verwendete externe Bibliotheken.
-
F=C3=BCr die Installations-, Update- oder Patchdateien M=C3=9CSSEN v=
om Entwickler digitale Signaturen bereitgestellt wer-den.
|
Basis |
-
JA S=
iehe Anforderungen in 2. Re=
mediation of Vulnerabilities in Production
-
NEIN=
Nicht abgedeckt, da Code Signing aus unserer Sicht keine generell sinnvoll=
e Anforderung darstellt.
|
CON.8.A9 Ber=C3=BCcksichtigung von Compliance-Anforderungen [Ent=
wickler] (B)
-
Alle Compliance-Anforderungen, die institutionsweiten Sicherheitsric=
htlinien, die rechtlichen Anforderungen und die spezifischen Sicherheitsanf=
orderungen M=C3=9CSSEN bei der Software-Entwicklung ermittelt und ber=C3=BC=
cksichtigt werden.
|
Basis |
NEIN=
Nicht abgedeckt, da unternehmensspezifisch. |
CON.8.A10 Versionsverwaltung des Quellcodes [Entwickler] (B)
-
Das Entwicklungsprojekt (Quellcode des Projektes) MUSS =C3=BCber ein=
e geeignete Versionsverwaltung verwaltet wer-den.
-
Der Leiter Entwicklung MUSS den Zugriff auf die Versionsverwaltung r=
egeln und festlegen, wann =C3=84nderungen am Quellcode durch die Entwickler=
als eigene Version in der Versionsverwaltung gespeichert werden sollen. =
em>
-
Es MUSS sichergestellt sein, dass durch die Versionsverwaltung alle =
=C3=84nderungen am Quellcode nachvollzogen und r=C3=BCckg=C3=A4ngig gemacht=
werden k=C3=B6nnen.
-
Die Versionsverwaltung MUSS in dem Datensicherungskonzept ber=C3=BCc=
ksichtigt werden und DARF NICHT ohne Datensicherung erfolgen.
|
Basis |
-
JA S=
iehe Anf. =E2=80=9CProtection of source and program code=E2=80=9D 4. Secure Development Environment
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
-
NEIN=
Unn=C3=B6tige Anforderung, das dies eine grundlegende Eigenschaft eines Ve=
rsionisierungssystem darstellt.
-
NEIN=
Nicht abgedeckt, da keine Sicherheitsanforderung
|
CON.8.A11 Erstellung einer Richtlinie f=C3=BCr die Software-Entw=
icklung (S)
-
Es SOLLTE eine Richtlinie f=C3=BCr die Software-Entwicklung erstellt=
und aktuell gehalten werden.
-
Die Richtlinie SOLLTE neben Namenskonventionen auch Vorgaben zu Elem=
enten beinhalten, die verwendet bzw. nicht verwendet wer-den d=C3=BCrfen.=
em>
-
Die relevanten Anforderungen aus diesem Baustein SOLLTEN in die Rich=
tlinie aufgenommen werden.
-
Die Richtlinie SOLLTE f=C3=BCr die Entwickler verbindlich sein.=
|
Standard |
NEIN=
Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.
Eine Richtlinie f=C3=BCr sichere Softwareentwicklung oder alternativ die=
Ber=C3=BCcksichtigung von Sicherheit in der bestehenden Richtlinie f=C3=BC=
r Softwareentwicklung w=C3=BCrden Sinn machen. Das ist der Gedanke von TSS-=
WEB. |
CON.8.A12 Ausf=C3=BChrliche Dokumentation (S)
-
Es SOLLTEN ausreichende Projekt-, Funktions- und Schnittstellendokum=
entationen erstellt und aktuell gehalten werden.
-
Benutzern und Administratoren SOLLTEN geeignete Hilfen zur korrekten=
Nutzung bzw. Administration der Software zur Verf=C3=BCgung gestellt werde=
n.
-
Die Software-Entwicklung SOLLTE so dokumentiert sein, dass ein Fache=
xperte mithilfe der Dokumentation den Programm-Code nachvollziehen und weit=
erentwickeln kann.
|
Standard |
NEIN=
Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.
In Anf. =E2=80=9CSecurity documentation=E2=80=9D in 5. Security within Software Development Process<=
/a>sind Anforderungen an die Dokumentation von Sicherheitsaspekten gestellt=
. |
CON.8.A13 Beschaffung von Werkzeugen (S)
-
Werkzeuge f=C3=BCr die Software-Entwicklung SOLLTEN nach standardisierte=
n und dokumentierten Vorgehensweisen beschafft werden.
|
Standard |
NEIN=
Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.
|
CON.8.A14 Schulung des Projektteams zur Informationssicherheit (=
S)
-
Die Entwickler und die =C3=BCbrigen Mitglieder des Projektteams SOLLTEN =
zu generellen Informationssicherheitsaspekten und zu den jeweils speziell f=
=C3=BCr sie relevanten Aspekten geschult sein.
|
Standard |
NEIN=
Implizit abdeckt durch Rollenbeschreibungen in 1. Introdu=
ction . |
CON.8.A15 Sicherer Einsatz der Test- und Entwicklungsumgebungen =
[Entwickler] (S)
-
Die Test- und Entwicklungsumgebungen SOLLTEN getrennt von der Produk=
tionsumgebung betrieben werden.
-
Informationen, die f=C3=BCr den Produktivbetrieb nicht relevant sind=
, SOLLTEN m=C3=B6glichst entfernt werden, bevor die Programmpakete in die P=
roduktionsumgebung =C3=BCberf=C3=BChrt werden.
-
Testdaten SOLLTEN sorgf=C3=A4ltig ausgew=C3=A4hlt und gesch=C3=BCtzt=
werden.
-
Verteilte Arbeitspl=C3=A4tze der Software-Entwicklung SOLLTEN =C3=BC=
ber eine sichere Verbindung miteinander kommunizieren. Der Zugriff auf die =
Entwicklungsdaten SOLLTE kontrolliert sein.
|
Standard |
-
JA S=
iehe Anf. zu =E2=80=9CEnvironment separation=E2=80=9D in 3. Operational Requirements
-
JA S=
iehe Anf. zu =E2=80=9CSystem hardening=E2=80=9D in 3. Op=
erational Requirements (=E2=80=9CExposed development artifacts (e.g. SV=
N files)=E2=80=9D)
-
JA S=
iehe Anf. zu =E2=80=9CGeneral requirements=E2=80=9D in 6. =
Security Tests (=E2=80=9CData used on development and test systems MUST=
be either synthetic or anonymized production data=E2=80=A6=E2=80=9D) =
li>
-
JASi=
ehe Anf. =E2=80=9CSecuring access to the dev environment=E2=80=9D in4. Secure Development Environment. Wichtiger =
ist jedoch der sichere Zugriff auf sensiblen Programmcode von remote. =
li>
|
CON.8.A16 Geeignete Steuerung der Software-Entwicklung (S)
-
Bei einer Software-Entwicklung SOLLTE ein geeignetes Steuerungs- und=
Projektmanagementmodell auf Basis des ausgew=C3=A4hlten Vorgehensmodells v=
erwendet werden und in die Richtlinie zur Software-Entwicklung integriert w=
er-den.
-
Dabei SOLLTEN insbesondere die ben=C3=B6tigten Qualifikationen beim =
Personal und die Abdeckung aller relevanten Phasen w=C3=A4hrend des Lebensz=
yklus der Software ber=C3=BCcksichtigt werden.
-
Au=C3=9Ferdem SOLLTE ein geeignetes Entwicklungsmodell und Risikoman=
agement sowie geeignete Qualit=C3=A4tsziele festgelegt werden.
-
Werden Teile der Software-Entwicklung extern durchgef=C3=BChrt, SOLL=
TE dies geeignet in die internen Steuerungs- und Sicherheitsprozesse eingeb=
unden werden.
|
Standard |
-
NEIN=
Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.
-
NEIN=
Nicht abgedeckt, da so wie hier beschrieben Sicherheitsanforderung.
-
Unklar, ob hier mit Risikomanagement Projektrisiken oder Sicherheitsrisi=
ken gemeint sind. Letzteres ist durch verschiedene Anforderungen in 5. Security within Software Develop=
ment Process enthalten.
-
NEIN=
Nicht explizit abgedeckt.
|
CON.8.A17 Auswahl vertrauensw=C3=BCrdiger Entwicklungswerkzeuge =
(H)
-
Zur Entwicklung der Software SOLLTEN nur Werkzeuge mit nachgewiesene=
n Sicherheitseigenschaften verwendet werden.
-
Es SOLLTE sichergestellt sein, dass die Werkzeuge nicht manipuliert =
werden k=C3=B6nnen.
-
An die Hersteller von Hardware oder Software SOLLTEN hinreichende An=
forderungen zur Sicherheit ihrer Werkzeuge gestellt werden.
|
Erweitert |
-
Unklar was hiermit konkret gemeint ist.
-
Unklar was hiermit konkret gemeint und was hier in der Praxis geschehen =
soll. Manipuliert durch den Entwickler oder durch Dritte?
-
Unklar wer diese Anforderung stellen soll und was f=C3=BCr Anforderungen=
dies in der Praxis betreffen soll.
|
CON.8.A18 Regelm=C3=A4=C3=9Fige Sicherheitsaudits f=C3=BCr die E=
ntwicklungsumgebung (H)
-
Es SOLLTEN regelm=C3=A4=C3=9Fige Sicherheitsaudits der Software-Entw=
icklungsumgebung und der Software-Testumgebung durchgef=C3=BChrt werden.
|
Erweitert |
NEIN=
Nicht explizit abgedeckt. Zudem unklar, was ein solches Sicherheitsaudit u=
mfassen soll (die korrekte Integration von Security Tools wie SAST etc., di=
e Verwendung aktueller Versionen oder die Verwendung nicht-manipulierter We=
rkzeuge?). |
CON.8.A19 Regelm=C3=A4=C3=9Fige Integrit=C3=A4tspr=C3=BCfung der=
Entwicklungsumgebung [IT-Betrieb] (H)
-
Die Integrit=C3=A4t der Entwicklungsumgebung SOLLTE regelm=C3=A4=C3=
=9Fig mit kryptographischen Mechanismen entsprechend dem Stand der Technik =
gepr=C3=BCft werden.
-
Die Pr=C3=BCfsummendateien und das Pr=C3=BCfprogramm selbst SOLLTEN =
ausreichend vor Manipulationen gesch=C3=BCtzt sein.
-
Wichtige Hinweise auf einen Integrit=C3=A4tsverlust SOLLTEN nicht in=
einer F=C3=BClle irrelevanter Warnmeldungen (false positives) untergehen.<=
/em>
|
Erweitert |
NEIN=
Unklar wie dies bei moderner Softwareentwicklung geschehen soll. Nur wenn =
Entwicklern nicht ver=C3=A4nderbare Entwicklungsumgebungen inkl. Module ver=
wenden, w=C3=A4re ein solcher Test denkbar. |