req_id

Feedback der Arbeitsgruppe

8.1.6

Wir würden uns wünschen, dass diese Anforderung konkreter formuliert wird, z.B. „Sicherungen sollten nur für einen bestimmten Zeitraum aufbewahrt werden“, „Sicherungen sollten auf Diebstahl/Beschädigung überwacht werden“ oder „Sicherungen sollten regelmäßig geprüft werden, um sicherzustellen, dass sie wieder in die Produktion verschoben werden können“. Die aktuelle Annahme ist zu allgemein und muss genauer definiert werden.

5.1.4

Duplikat anderer Testläufe. Dieser Testlauf ist mit hohem Aufwand verbunden und hat einen geringen Wert. Wir empfehlen, sie zu entfernen.

7.3.3

Duplikat anderer Testläufe. Dieser Testlauf ist mit hohem Aufwand verbunden und hat einen geringen Wert. Wir empfehlen, sie zu entfernen.

1.2.2

Entfernen aufgrund der Abdeckung in anderen Anforderungen wie 4.1.1

2.2.4

Entferne die Anforderung, da sie von 4.3.1 abgedeckt wird.

(4.3.1 Überprüfen, ob für administrative Schnittstellen eine geeignete Multi-Faktor-Authentifizierung verwendet wird, um

unbefugte Nutzung verhindern), die die Widerstandsfähigkeit gegen Identitätsdiebstahl durch Phishing in Administratorschnittstellen und anderen internen Zugriffspfaden abdeckt

2.2.5

Entfernen, da mTLS von den meisten CSPs nicht unterstützt wird und die Mehrheit der Entwickler, die CASA testen, die passwortbasierte Authentifizierung verwenden.

2.4.3

Der Standard ist in seiner aktuellen Form nicht spezifisch genug, um durchgesetzt zu werden.

2.4.5

Anforderung in V5 des ASVS entfernt und die empfohlenen Hashing-Algorithmen in 2.4.1 können diese Anforderung nicht erfüllen

2.7.5

Ein Test ist nicht möglich, da möglicherweise eine Analyse von OOB-Drittanbietern erforderlich ist. Das Risiko ist hier gering, da der Authentifizierungscode nur kurz gültig ist.

2.8.2

Die Anforderung bezieht sich nur auf benutzerdefinierte MFA-Lösungen, die auch von 6.4.2 und 6.4.1 abgedeckt werden.

2.8.5

Anforderung entfernen, da sie zusätzlich von 2.7.6 abgedeckt wird. Das Protokollieren fehlgeschlagener Versuche wird von der Protokollierungsanforderung des ASVS abgedeckt.

2.8.6

Physische Einmalpasswörter auf Anwendungsebene sind kein häufiger Anwendungsfall. Diese Anforderung ist für Administratorschnittstellen erforderlich. Anforderung 4.3.1 (Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.) deckt jedoch die MFA für Administratorschnittstellen ab und damit auch dieses Risiko.

2.9.1

Diese Anforderung bezieht sich auf physische Geräte gemäß ASVS (kryptografische Sicherheitsschlüssel sind Smartcards oder FIDO-Schlüssel, die der Nutzer einstecken oder koppeln muss,

kryptografisches Gerät mit dem Computer verbunden sein, um die Authentifizierung abzuschließen. Prüfer senden eine Challenge-Nonce an die

kryptografische Geräte oder Software und das Gerät oder die Software berechnen eine Antwort auf der Grundlage einer sicher

gespeicherten kryptografischen Schlüssel) fällt diese Anforderung nicht in den Geltungsbereich von CASA, da das Risiko der Authentifizierung physischer Geräte durch 4.3.1 für den Zweck der MFA (physisch oder Software) abgedeckt wird.

2.9.3

Diese Anforderung bezieht sich auf physische Geräte gemäß ASVS (kryptografische Sicherheitsschlüssel sind Smartcards oder FIDO-Schlüssel, die der Nutzer einstecken oder koppeln muss,

kryptografisches Gerät mit dem Computer verbunden sein, um die Authentifizierung abzuschließen. Prüfer senden eine Challenge-Nonce an die

kryptografische Geräte oder Software und das Gerät oder die Software berechnen eine Antwort auf der Grundlage einer sicher

gespeicherten kryptografischen Schlüssel) fällt diese Anforderung nicht in den Geltungsbereich von CASA, da das Risiko der Authentifizierung physischer Geräte durch 4.3.1 für den Zweck der MFA (physisch oder Software) abgedeckt wird.

2.10.1

Die Anforderung widerspricht 2.10.2.

2.10.3

Abgedeckt durch 2.4.1 (Verify that one of the following password hashing functions is used when storing the user's password for the application: argon2id, scrypt, bcrypt or PBKDF2) which covers the risk of offline attacks and password storage.

2.10.4

Gedeckt durch 6.4.2: Prüfen Sie, ob das Schlüsselmaterial nicht für die Anwendung verfügbar ist, sondern stattdessen ein isoliertes Sicherheitsmodul wie einen Tresor für kryptografische Vorgänge verwendet.

3.2.3

Abgedeckt 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

Für die Anfrage ist die Multi-Faktor-Authentifizierung für Administratorschnittstellen und privilegierten Zugriff erforderlich.

5.1.3

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

5.1.4

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

5.3.2

Der Teil dieser Anforderung, der besagt, dass jedes Unicode-Zeichen gültig ist, kann das Testen erschweren. Nicht jede Anwendung enthält ein Textfeld, das groß genug ist, um alle Unicode-Zeichen aufzunehmen. Außerdem werden bestimmte Betriebssysteme und Hacking-Tools für den gesamten Unicode-Bereich nicht unterstützt, sodass Sie dies auch dann nicht testen können, wenn der Server es unterstützt. Insgesamt fragwürdiger Sicherheitswert. War ursprünglich in der Betaversion enthalten, wurde aber aufgrund von Problemen beim Testen entfernt.

6.2.5

durch 6.2.4 und 6.2.3 abgedeckt

6.2.6

durch 6.2.4 und 6.2.3 abgedeckt

6.3.1

durch 6.2.4 und 6.2.3 abgedeckt

6.3.3

die von anderen Anforderungen zur Generierung von Zufallszahlen abgedeckt werden.

7.1.2

von 7.1.1 abgedeckt

7.1.3

von 7.1.1 abgedeckt

7.3.1

von 7.1.1 abgedeckt

7.3.3

von 7.1.1 abgedeckt

8.1.3

Es ist schwierig zu beschreiben, was ein akzeptabler oder notwendiger Parameter ist. Kein testbarer Fall. Was ist notwendig? Wie stellen wir fest, ob eine Ausnahme gültig ist? Nicht im Umfang von CASA enthalten

8.3.3

Keine testbare Anforderung, die sich auf die Datenschutzerklärung und die Nutzungsbedingungen bezieht und nicht auf die Anwendungssicherheit. Dies ist eine rechtliche Prüfung und eine Compliance-Prüfung, die nicht im Rahmen von CASA erfolgt.

8.3.6

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

8.3.8

von 1.8.1, 1.8.2 und 1.1.4 abgedeckt

9.2.5

von 8.3.5 abgedeckt und Protokollierungsrichtlinienprüfungen der Anwendung.

10.1.1

Wird durch die Architekturprüfung abgedeckt und ist eine empfohlene Best Practice. Anforderung kann nicht getestet werden

10.2.3

Nicht in einem angemessenen Zeitraum möglich. Jeder ungewöhnliche Code sollte dokumentiert und überprüft werden. Um jedoch sicherzustellen, dass keine Hintertüren vorhanden sind, ist eine detaillierte Codeüberprüfung Zeile für Zeile erforderlich. Auch dann kann nicht garantiert werden, dass keine Hintertüren vorhanden sind.

Gut konzipierte schädliche Funktionen sind schwer zu testen.

10.2.4

Keine Möglichkeit zum Testen. Nicht in einem angemessenen Zeitraum möglich. Jeder ungewöhnliche Code sollte dokumentiert und überprüft werden. Die Festlegung der spezifischen Aufgabe, um sicherzustellen, dass keine Hintertüren vorhanden sind, würde jedoch eine detaillierte Codeüberprüfung Zeile für Zeile erfordern und garantiert nicht, dass keine Hintertüren vorhanden sind.

Gut konzipierte schädliche Funktionen sind schwer zu testen.

10.2.5

Keine Möglichkeit zum Testen. Nicht in einem angemessenen Zeitraum möglich. Jeder ungewöhnliche Code sollte dokumentiert und überprüft werden. Die Festlegung der spezifischen Aufgabe, um sicherzustellen, dass keine Hintertüren vorhanden sind, würde jedoch eine detaillierte Codeüberprüfung Zeile für Zeile erfordern und garantiert nicht, dass keine Hintertüren vorhanden sind.

Gut konzipierte schädliche Funktionen sind schwer zu testen.

13.1.1

Gedeckt durch 5.2.6 und 5.3.9

12.3.1

Das Risiko von Path Traversal wird durch andere bestehende Anforderungen aus Kapitel 5 (Validierung, Bereinigung und Codierung) des ASVS und CASA abgedeckt.

12.3.3

Gedeckt durch 5.2.6 und 5.3.9

12.3.6

durch 10.3.2, 12.4.1 und 12.4.2 abgedeckt

12.5.1

von 10.3.2 und 12.4.2 abgedeckt

12.5.2

durch 10.3.2, 12.4.1 und 12.4.2 abgedeckt

13.1.5

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

13.2.2

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

13.2.3

Von 4.2.2 abgedeckt

13.2.5

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

13.3.1

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

14.4.1

von 5.3.1 abgedeckt

14.4.2

Diese Anforderung wird von anderen Anforderungen zur Eingabevalidierung abgedeckt. Wenn durch die fehlende Validierung keine tatsächliche Sicherheitslücke in der Geschäftslogik entsteht, kann die Schwere niedriger sein. Wenn die Telefonnummer beispielsweise nicht richtig validiert wird, führt das nur zu einer falschen Anzeige der Telefonnummer auf der Infoseite, was keine direkten Sicherheitsrisiken birgt.

14.4.3

durch 5.2.7 und 5.3.3 abgedeckt

14.4.5

durch 6.2.1 und 9.2.1 abgedeckt

14.4.7

durch 12.4.1 abgedeckt

14.5.3

von 14.5.2 abgedeckt

2.1.5

von 2.1.1 abgedeckt

2.1.6

von 2.1.1 abgedeckt

2.2.3

Nicht relevant für CASA, da das Risiko durch andere Maßnahmen zur Verhinderung von Automatisierung abgedeckt wird

2.5.6

durch anderen Passwortschutz abgedeckt

3.1.1

Geringes Risiko der Offenlegung und durch andere ASVS-Kontrollen abgedeckt

3.2.1

Geringes Risiko der Offenlegung und durch andere ASVS-Kontrollen abgedeckt

3.4.4

Geringes Risiko der Offenlegung und durch andere ASVS-Kontrollen abgedeckt

3.4.5

Geringes Risiko der Offenlegung und durch andere ASVS-Kontrollen abgedeckt

4.2.1

von 13.1.4 abgedeckt

5.2.8

durch andere Prüfungen zur Eingabevalidierung und ‑bereinigung abgedeckt

5.3.5

durch andere Prüfungen zur Eingabevalidierung und ‑bereinigung abgedeckt

7.4.1

durch Logging-Prüfungen abgedeckt

8.2.3

von 8.1.1 abgedeckt

9.1.1

durch 6.2.1 und 9.2.1 abgedeckt

1.2.3

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.4.4

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.5.2

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.5.3

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.5.4

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.9.1

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.11.3

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.14.1

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.14.2

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.14.3

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.14.4

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.14.5

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

1.14.6

von 1.1.4, 1.8.4 und 1.8.2 abgedeckt

6.1.2

Abgedeckt durch 6.1.1

6.1.3

Abgedeckt durch 6.1.1

2.10.2

Von 2.5.4 abgedeckt

2.2.1

Von 11.1.4 abgedeckt

2.7.3

Von 2.7.2 abgedeckt

2.7.4

Von 2.7.2 abgedeckt

5.1.2

Von der Anti-Automatisierungssteuerung abgedeckt

6.2.2

Genehmigte kryptografische Algorithmen nicht definiert

8.2.1

Von 8.1.1 abgedeckt

9.1.2

Von 9.2.1 abgedeckt

9.1.3

Von 9.2.1 abgedeckt

5.5.1

Von 1.8.2 abgedeckt

14.2.1

Von 1.14.6 abgedeckt

3.3.4

Dies gilt nicht für Anwendungen, die zustandslose Authentifizierung und Autorisierung verwenden. Wir stimmen der Empfehlung der NCC Group zu, die Erweiterung zu entfernen. Dies sollte durch 3.3.3 abgedeckt sein.

req_id

Beschreibung

1.1.4

Dokumentation und Begründung aller Vertrauensgrenzen, Komponenten und wichtigen Datenflüsse der Anwendung prüfen.

1.8.1

Prüfen, ob alle vertraulichen Daten identifiziert und in Schutzstufen klassifiziert wurden

1.8.2

Prüfen Sie, ob für alle Schutzstufen eine Reihe von Schutzanforderungen vorhanden ist, z. B. Verschlüsselungsanforderungen, Integritätsanforderungen, Aufbewahrungs-, Datenschutz- und andere Vertraulichkeitsanforderungen, und ob diese

in der Architektur angewendet.

2.1.1

Prüfen Sie, ob die von Nutzern festgelegten Passwörter mindestens 12 Zeichen lang sind.

2.5.4

Prüfen Sie, ob keine freigegebenen oder Standardkonten vorhanden sind, z. B. „root“.

„admin“ oder „sa“).

4.2.1

Prüfen Sie, ob vertrauliche Daten und APIs vor IDOR-Angriffen (Insecure Direct Object Reference) geschützt sind, die auf das Erstellen, Lesen, Aktualisieren und Löschen von Datensätzen abzielen, z. B. das Erstellen oder Aktualisieren des Datensatzes einer anderen Person, das Anzeigen aller Datensätze oder das Löschen aller Datensätze.

1.14.6

Prüfen Sie, ob die Anwendung nicht unterstützte, unsichere oder

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

Silverlight, NACL oder clientseitige Java-Applets.