req_id

Feedback zur Arbeitsgruppe

8.1.6

Diese Anforderung sollte als etwas umsetzbarer betrachtet werden (z.B. sollten Sicherungen nur für einen bestimmten Zeitraum aufbewahrt, auf Diebstahl/Beschädigung überwacht werden und Sicherungen sollten regelmäßig geprüft werden, um sicherzustellen, dass sie wieder in die Produktion verschoben werden können. Die momentane Annahme ist zu weit gefasst und Sie benötigen weitere Definitionen.

5.1.4

Duplikat anderer Testläufe. Dies ist ein Test mit hohem Aufwand und geringem Wert. Empfohlen zum Entfernen.

7.3.3

Duplikat anderer Testläufe. Dies ist ein Test mit hohem Aufwand und geringem Wert. Empfohlen zum Entfernen.

1.2.2

aufgrund einer anderen Abdeckung wie 4.1.1 entfernen

2.2.4

Anfragen entfernen, da sie von 4.3.1 abgedeckt ist

(4.3.1 Überprüfen, ob Verwaltungsschnittstellen eine geeignete Multi-Faktor-Authentifizierung verwenden,

eine nicht autorisierte Nutzung verhindern.) Diese behebt die Identitätswechselresistenz gegen Phishing auf Admin-Oberflächen und anderen internen Zugriffspfaden.

2.2.5

Entfernen, da mTLS von den meisten CSPs nicht unterstützt wird und der Großteil der für CASA getesteten Entwickler die passwortbasierte Authentifizierung verwendet

2.4.3

Der geschriebene Standard ist nicht spezifisch genug, um durchsetzbar zu sein

2.4.5

In V5 des ASVS entfernte Anforderung und die empfohlenen Hash-Algorithmen in Version 2.4.1 können diese Anforderung nicht erfüllen

2.7.5

Tests sind nicht möglich, da sie möglicherweise eine Analyse von OOB-Anbietern erfordern. Das Risiko ist hier jedoch niedrig, da der Authentifizierungscode nur von kurzer Dauer ist.

2.8.2

Anforderung ist nur für benutzerdefinierte MFA-Lösungen relevant, die auch von 6.4.2 und 6.4.1 abgedeckt werden.

2.8.5

Entfernen Sie die Anforderung, da sie von 2.7.6 abgedeckt ist. Logging-Fehlgeschlagene Versuche werden von der Logging-Anforderung des ASVS abgedeckt.

2.8.6

Ein physisches OTP auf Anwendungsebene ist kein häufiger Anwendungsfall. Diese Anforderung ist für Administratorschnittstellen erforderlich. req 4.3.1 (Prüfe, ob administrative Schnittstellen eine geeignete Multi-Faktor-Authentifizierung verwenden, um eine nicht autorisierte Verwendung zu verhindern.) MFA für Admin-Oberflächen und dieses Risiko werden abgedeckt.

2.9.1

Diese Anforderung gilt für physische Geräte gemäß ASVS (Kryptografische Sicherheitsschlüssel sind Smartcards oder FIDO-Schlüssel, bei denen der Nutzer eine Steckdose einstecken oder koppeln muss)

kryptografisches Gerät auf den Computer, um die Authentifizierung abzuschließen. Die Prüfer senden eine Challenge-Nonce an die

für kryptografische Geräte oder Software und für die Berechnung von Antworten auf Basis einer sicheren

gespeicherter Schlüssel. Diese Anforderung wird durch CASA nicht abgedeckt, weil das Risiko der physischen Geräteauthentifizierung für MFA (physisch oder Software) durch 4.3.1 abgedeckt wird.

2.9.3

Diese Anforderung gilt für physische Geräte gemäß ASVS (Kryptografische Sicherheitsschlüssel sind Smartcards oder FIDO-Schlüssel, bei denen der Nutzer eine Steckdose einstecken oder koppeln muss)

kryptografisches Gerät auf den Computer, um die Authentifizierung abzuschließen. Die Prüfer senden eine Challenge-Nonce an die

für kryptografische Geräte oder Software und für die Berechnung von Antworten auf Basis einer sicheren

gespeicherter Schlüssel. Diese Anforderung wird durch CASA nicht abgedeckt, weil das Risiko der physischen Geräteauthentifizierung für MFA (physisch oder Software) durch 4.3.1 abgedeckt wird.

2.10.1

Anforderung ist ein Widerspruch von 2.10.2

2.10.3

Durch 2.4.1 abgedeckt (prüfen, ob eine der folgenden Passwort-Hash-Funktionen verwendet wird, wenn das Nutzerpasswort für die Anwendung gespeichert wird: argon2id, scrypt, bcrypt oder PBKDF2), die das Risiko von Offline-Angriffen und Passwortspeicherung abdeckt

2.10.4

Abgedeckt durch 6.4.2. Überprüfen, ob Schlüsselmaterial nicht für die Anwendung verfügbar ist. Stattdessen wird ein isoliertes Sicherheitsmodul wie ein Vault für kryptografische Vorgänge verwendet.

3.2.3

Gedeckt durch 3.4.1, 3.4.2 und 3.4.3

3.5.1

Nutzer können Tokens über den OAuth-Anbieter widerrufen

4.3.3

MFA ist durch die MFA für Administratorschnittstellen und privilegierten Zugriff abgedeckt

5.1.3

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

5.1.4

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

5.3.2

Der Teil dieser Anforderung, der angibt, dass jedes Unicode-Zeichen gültig ist, kann das Testen erschweren. Nicht jede Anwendung enthält ein Textformular, das groß genug für jedes Unicode-Zeichen ist. Außerdem werden bestimmte Betriebssysteme und Hacking-Tools nicht für den gesamten Unicode-Bereich unterstützt. Daher können Sie dies nicht testen, selbst wenn der Server dies unterstützt. Zweifelloser Sicherheitswert insgesamt. war ursprünglich in der Betaphase enthalten, wurde aber aufgrund von Testproblemen entfernt.

6.2.5

abgedeckt durch 6.2.4 und 6.2.3

6.2.6

abgedeckt durch 6.2.4 und 6.2.3

6.3.1

abgedeckt durch 6.2.4 und 6.2.3

6.3.3

die von anderen Zufallszahlen generiert werden.

7.1.2

Durch 7.1.1 abgedeckt

7.1.3

Durch 7.1.1 abgedeckt

7.3.1

Durch 7.1.1 abgedeckt

7.3.3

Durch 7.1.1 abgedeckt

8.1.3

Es ist schwierig, zu beschreiben, was ein akzeptabler oder erforderlicher Parameter ist. Der Test kann nicht getestet werden. Was ist erforderlich? Wie wird ermittelt, ob eine Ausnahme gültig ist? Wird für CASA nicht berücksichtigt

8.3.3

Dies ist keine testbare Anforderung, die für die Datenschutzerklärung und die Nutzungsbedingungen und nicht für die Anwendungssicherheit relevant ist. Dies ist eine Überprüfung auf Einhaltung von Rechten und Compliance und ist nicht Gegenstand des CASA

8.3.6

Die Steuerung ist systemspezifisch (Windows/Linux-Variante) und gerätespezifisch und in den meisten Fällen nicht die Anwendungssteuerung.

8.3.8

abgedeckt durch 1.8.1, 1.8.2 und 1.1.4

9,2.5

durch 8.3.5 und Logging-Richtlinienüberprüfungen der Anwendung abgedeckt.

10.1

Wird von der Architektur überprüft und ist eine empfohlene Best Practice. Anforderung kann nicht getestet werden

10.2.3

Dies ist nicht innerhalb eines angemessenen Zeitraums möglich. Etwas seltsamen Code sollte dokumentiert und geprüft werden. Wenn Sie die spezifische Aufgabe jedoch festlegen, um sicherzustellen, dass Backdoors nicht vorhanden sind, ist eine gründliche Überprüfung von Code erforderlich. Außerdem wird nicht garantiert, dass Backdoors nicht vorhanden sind.

Schwieriger Test auf gut konzipierte schädliche Funktionen

10.2.4

Keine Möglichkeit zum Testen. Dies ist nicht innerhalb eines angemessenen Zeitraums möglich. Etwas seltsamen Code sollte dokumentiert und geprüft werden. Wenn Sie die spezifische Aufgabe jedoch festlegen, um sicherzustellen, dass Backdoors nicht vorhanden sind, ist eine gründliche Überprüfung von Code erforderlich. Außerdem wird nicht garantiert, dass Backdoors nicht vorhanden sind.

Schwieriger Test auf gut konzipierte schädliche Funktionen

10.2

Keine Möglichkeit zum Testen. Dies ist nicht innerhalb eines angemessenen Zeitraums möglich. Etwas seltsamen Code sollte dokumentiert und geprüft werden. Wenn Sie die spezifische Aufgabe jedoch festlegen, um sicherzustellen, dass Backdoors nicht vorhanden sind, ist eine gründliche Überprüfung von Code erforderlich. Außerdem wird nicht garantiert, dass Backdoors nicht vorhanden sind.

Schwieriger Test auf gut konzipierte schädliche Funktionen

13.1

Gedeckt durch 5.2.6 und 5.3.9

12.3.1

Pfaddurchlaufrisiko, das von anderen vorhandenen Anforderungen aus Kapitel 5 (Validierung, Bereinigung und Codierung) des ASVS und der CASA abgedeckt ist

12.3

Gedeckt durch 5.2.6 und 5.3.9

12.3.6

abgedeckt durch 10.3.2 12.4.1 und 12.4.2

12.5.1

abgedeckt durch 10.3.2 und 12.4.2

12.5.2

abgedeckt durch 10.3.2 12.4.1 und 12.4.2

13.1.5

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

13.2.2

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

13.2.3

Abgedeckt durch 4.2.2

13.2.5

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

13.3.1

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

14.4.1

Durch 5.3.1 abgedeckt

14.4.2

Diese Anforderung wird von anderen Anforderungen für die Eingabevalidierung abgedeckt. Wenn keine Validierung zu einer tatsächlichen Sicherheitslücke in der Geschäftslogik führt, kann dies ein geringerer Schweregrad sein. Wenn eine Telefonnummer nicht korrekt validiert wird, wird sie nur auf der Informationsseite angezeigt. Dies hat keine direkten Auswirkungen auf die Sicherheit.

14.4.3

abgedeckt durch 5.2.7 und 5.3.3

14.4.5

abgedeckt durch 6.2.1 und 9.2.1

14.4.7

Durch 12.4.1 abgedeckt

14.5.3

Durch 14.5.2 abgedeckt

2.1

Durch 2.1.1 abgedeckt

2.1.6

Durch 2.1.1 abgedeckt

2.2.3

Nicht relevant für Casa, da das Risiko durch andere Anti-Automatisierungskontrollen abgedeckt ist

2.5.6

durch anderen Passwortschutz abgedeckt

3.1.1

Geringes Risiko der Gefährdung und durch andere Kontrollen des ASV abgedeckt

3.2.1

Geringes Risiko der Gefährdung und durch andere Kontrollen des ASV abgedeckt

3.4.4

Geringes Risiko der Gefährdung und durch andere Kontrollen des ASV abgedeckt

3.4.5

Geringes Risiko der Gefährdung und durch andere Kontrollen des ASV abgedeckt

4.2.1

unter 13.1.4

5.2.8

durch andere Eingabevalidierungs- und Desinfizierungsprüfungen abgedeckt

5,3,5

durch andere Eingabevalidierungs- und Desinfizierungsprüfungen abgedeckt

7.4.1

durch Logging-Prüfungen abgedeckt

8.2.3

Durch 8.1.1 abgedeckt

9.1.1

abgedeckt durch 6.2.1 und 9.2.1

1.2.3

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.4.4

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.5.2

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.5.3

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.5.4

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.9.1

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.11.3

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.14.1

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.14.2

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.14.3

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.14.4

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.14.5

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

1.14.6

abgedeckt durch 1.1.4, 1.8.4 und 1.8.2

6.1.2

Abgedeckt durch 6.1.1

6.1.3

Abgedeckt durch 6.1.1

2.10.2

Abgedeckt durch 2.5.4

2.2.1

Abgedeckt durch 11.1.4

2.7.3

Abgedeckt durch 2.7.2

2.7.4

Abgedeckt durch 2.7.2

5.1.2

Durch die Anti-Automatisierungssteuerung abgedeckt

6.2.2

genehmigte kryptografische Algorithmen nicht definiert

8.2.1

Abgedeckt durch 8.1.1

9.1.2

Abgedeckt durch 9.2.1

9.1.3

Abgedeckt durch 9.2.1

5.5.1

Abgedeckt durch 1.8.2

14.2.1

Abgedeckt durch 1.14.6

3.3.4

Dies gilt nicht für Anwendungen, die zustandslose AuthN/Z verwenden. Stimme der Empfehlung der NCC Group zum Entfernen zu. Dies sollte von 3.3.3 abgedeckt sein.

req_id

Beschreibung

1.1.4

Prüfen Sie die Dokumentation und eine Begründung für alle Vertrauensgrenzen, Komponenten und bedeutenden Datenflüsse der Anwendung.

1.8.1

Prüfen, ob alle sensiblen Daten identifiziert und in Schutzniveaus klassifiziert wurden

1.8.2

Achten Sie darauf, dass für alle Schutzniveaus bestimmte Sicherheitsanforderungen gelten, z. B. Verschlüsselungs-, Integritäts-, Aufbewahrungs-, Datenschutz- und andere Vertraulichkeitsanforderungen. Diese müssen

in der Architektur angewendet.

2.1.1

Achte darauf, dass die Passwörter der Nutzer mindestens 12 Zeichen lang sind

2.5.4

Achten Sie darauf, dass keine gemeinsamen oder Standardkonten vorhanden sind (z.B. „root“,

„admin“ oder „sa“).

4.2.1

Achten Sie darauf, dass sensible Daten und APIs vor Angriffen durch ungesicherte Direct Object Reference (IDOR) geschützt sind, die auf das Erstellen, Lesen, Aktualisieren und Löschen von Datensätzen abzielen, z. B. das Erstellen oder Aktualisieren von Datensätzen einer anderen Person, das Aufrufen aller Datensätze oder das Löschen aller Datensätze.

1.14.6

Prüfen, ob die Anwendung nicht unterstützte, unsichere oder verworfene Funktionen verwendet

clientseitige Technologien wie NSAPI-Plug-ins, Flash, Shockwave, ActiveX

Silverlight, NACL oder clientseitige Java-Applets.