req_id

Opinie grupy roboczej

8.1.6

Warto rozważyć, czy to wymaganie nie powinno być bardziej konkretne (np. kopie zapasowe powinny być przechowywane tylko przez określony czas, kopie zapasowe powinny być monitorowane pod kątem kradzieży lub uszkodzenia, kopie zapasowe powinny być regularnie kontrolowane, aby potwierdzić możliwość ich przeniesienia z powrotem do środowiska produkcyjnego). Obecne założenie jest zbyt ogólne i wymaga doprecyzowania.

5.1.4

Duplikat innych elementów testowania. To test o dużym nakładzie pracy i małej wartości. Zalecamy usunięcie.

7.3.3

Duplikat innych elementów testowania. To test o dużym nakładzie pracy i małej wartości. Zalecamy usunięcie.

1.2.2

usunięcie z powodu pokrycia w innych wymaganiach, np. 4.1.1

2.2.4

Usuń Req, ponieważ jest on objęty punktem 4.3.1.

(4.3.1 Sprawdź, czy interfejsy administracyjne korzystają z odpowiedniego uwierzytelniania wielopoziomowego, aby

zapobiegać nieautoryzowanemu użyciu), która obejmuje odporność na podszywanie się pod inne osoby w celu wyłudzania informacji w interfejsach administracyjnych i innych wewnętrznych ścieżkach dostępu.

2.2.5

Usuń, ponieważ mTLS nie jest obsługiwany przez większość dostawców usług w chmurze, a większość deweloperów testujących CASA będzie korzystać z uwierzytelniania opartego na haśle.

2.4.3

Standard w obecnej formie nie jest wystarczająco precyzyjny, aby można było go egzekwować.

2.4.5

Wymaganie usunięte w wersji 5 ASVS, a zalecane algorytmy haszowania w sekcji 2.4.1 nie spełniają tego wymagania

2.7.5

Testowanie jest niewykonalne, ponieważ może wymagać analizy dostawców uwierzytelniania poza pasmem. Ryzyko jest tu niskie, ponieważ kod uwierzytelniania ma krótki okres ważności.

2.8.2

Wymaganie to dotyczy tylko niestandardowych rozwiązań MFA, które są również objęte sekcjami 6.4.2 i 6.4.1.

2.8.5

Usuń wymaganie, ponieważ jest ono dodatkowo objęte punktem 2.7.6. Rejestrowanie nieudanych prób jest objęte wymaganiem dotyczącym logowania w ASVS.

2.8.6

Fizyczny kod OTP na poziomie aplikacji nie jest typowym przypadkiem użycia. To żądanie jest potrzebne w przypadku interfejsów administracyjnych. Wymaganie 4.3.1 (Sprawdzanie, czy interfejsy administracyjne korzystają z odpowiedniego uwierzytelniania wielopoziomowego, aby zapobiegać nieautoryzowanemu użyciu) obejmuje uwierzytelnianie wielopoziomowe w przypadku interfejsów administracyjnych i zmniejsza to ryzyko.

2.9.1

Wymaganie to obejmuje urządzenia fizyczne zgodnie z ASVS (kryptograficzne klucze bezpieczeństwa to karty inteligentne lub klucze FIDO, które użytkownik musi podłączyć lub sparować z urządzeniem).

urządzenie kryptograficzne do komputera, aby dokończyć uwierzytelnianie. Weryfikatorzy wysyłają do

urządzenia lub oprogramowania kryptograficznego, a urządzenie lub oprogramowanie oblicza odpowiedź na podstawie bezpiecznie

przechowywany klucz kryptograficzny), co wyklucza to wymaganie z zakresu CASA, ponieważ ryzyko związane z uwierzytelnianiem na urządzeniach fizycznych jest objęte punktem 4.3.1 na potrzeby uwierzytelniania wieloskładnikowego (fizycznego lub programowego).

2.9.3

Wymaganie to obejmuje urządzenia fizyczne zgodnie z ASVS (kryptograficzne klucze bezpieczeństwa to karty inteligentne lub klucze FIDO, które użytkownik musi podłączyć lub sparować z urządzeniem).

urządzenie kryptograficzne do komputera, aby dokończyć uwierzytelnianie. Weryfikatorzy wysyłają do

urządzenia lub oprogramowania kryptograficznego, a urządzenie lub oprogramowanie oblicza odpowiedź na podstawie bezpiecznie

przechowywany klucz kryptograficzny), co wyklucza to wymaganie z zakresu CASA, ponieważ ryzyko związane z uwierzytelnianiem na urządzeniach fizycznych jest objęte punktem 4.3.1 na potrzeby uwierzytelniania wieloskładnikowego (fizycznego lub programowego).

2.10.1

Wymaganie jest sprzeczne z punktem 2.10.2

2.10.3

Wymaganie 2.4.1 (Sprawdź, czy podczas przechowywania hasła użytkownika w aplikacji używana jest jedna z tych funkcji skracania haseł: argon2id, scrypt, bcrypt lub PBKDF2), które obejmuje ryzyko ataków offline i przechowywania haseł.

2.10.4

Wymaganie 6.4.2 Sprawdź, czy materiał klucza nie jest udostępniany aplikacji, ale zamiast tego używa odizolowanego modułu zabezpieczeń, takiego jak magazyn, do operacji kryptograficznych.

3.2.3

Objęte sekcjami 3.4.1, 3.4.2 i 3.4.3

3.5.1

Użytkownik może unieważnić tokeny za pomocą dostawcy OAuth

4.3.3

Wymaganie jest objęte uwierzytelnianiem dwuskładnikowym w przypadku interfejsów administracyjnych i dostępu uprzywilejowanego.

5.1.3

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

5.1.4

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

5.3.2

Część tego wymagania, która określa, że każdy znak Unicode jest prawidłowy, może utrudniać testowanie. Nie każda aplikacja będzie zawierać pole tekstowe wystarczająco duże, aby zmieścić wszystkie znaki Unicode. Brak też obsługi niektórych systemów operacyjnych i narzędzi hakerskich w całej przestrzeni Unicode, co uniemożliwia testowanie, nawet jeśli serwer je obsługuje. Ogólnie wątpliwa wartość zabezpieczeń. Pierwotnie była dostępna w wersji beta, ale została usunięta z powodu problemów podczas testowania.

6.2.5

objęte postanowieniami punktów 6.2.4 i 6.2.3.

6.2.6

objęte postanowieniami punktów 6.2.4 i 6.2.3.

6.3.1

objęte postanowieniami punktów 6.2.4 i 6.2.3.

6.3.3

objęte innymi wymaganiami dotyczącymi generowania liczb losowych.

7.1.2

objęte punktem 7.1.1

7.1.3

objęte punktem 7.1.1

7.3.1

objęte punktem 7.1.1

7.3.3

objęte punktem 7.1.1

8.1.3

Trudno jest opisać, który parametr jest dopuszczalny lub niezbędny. Nie można przetestować tego przypadku. Co jest niezbędne? Jak określimy, czy wyjątek jest ważny? Uznawane za wykraczające poza zakres CASA

8.3.3

Nie jest to wymaganie podlegające testowaniu. Dotyczy polityki prywatności i warunków korzystania z usług, a nie bezpieczeństwa aplikacji. Jest to weryfikacja pod kątem zgodności z przepisami prawa, która nie jest objęta oceną bezpieczeństwa CASA.

8.3.6

Sterowanie jest specyficzne dla systemu (wariant Windows/Linux) i urządzenia, a w większości przypadków nie dotyczy aplikacji.

8.3.8

objęte sekcjami 1.8.1, 1.8.2 i 1.1.4

9.2.5

objęte punktem 8.3.5 i zasadami rejestrowania dzienników aplikacji.

10.1.1

Objęte przeglądem architektury i zalecane jako sprawdzona metoda. Wymaganie nie podlega testowaniu

10.2.3

Nie można tego zrobić w rozsądnym czasie. Wszelkie nietypowe kody powinny być udokumentowane i sprawdzone. Jednak ustawienie konkretnego zadania, które zapewni, że nie ma w nich tylnych drzwi, wymagałoby szczegółowego sprawdzenia kodu wiersz po wierszu i nie gwarantuje, że tylne drzwi nie występują.

Trudno jest testować dobrze zaprojektowane złośliwe funkcje.

10.2.4

Nie ma możliwości przetestowania. Nie można tego zrobić w rozsądnym czasie. Każdy dziwny kod powinien być udokumentowany i sprawdzony. Jednak ustawienie konkretnego zadania, które zapewni, że nie ma w nim tylnych drzwi, wymaga szczegółowego sprawdzenia kodu wiersz po wierszu i nie gwarantuje, że tylne drzwi nie występują.

Trudno jest testować dobrze zaprojektowane złośliwe funkcje.

10.2.5

Nie ma możliwości przetestowania. Nie można tego zrobić w rozsądnym czasie. Każdy dziwny kod powinien być udokumentowany i sprawdzony. Jednak ustawienie konkretnego zadania, które zapewni, że nie ma w nim tylnych drzwi, wymaga szczegółowego sprawdzenia kodu wiersz po wierszu i nie gwarantuje, że tylne drzwi nie występują.

Trudno jest testować dobrze zaprojektowane złośliwe funkcje.

13.1.1

Objęte sekcjami 5.2.6 i 5.3.9

12.3.1

ryzyko związane z przechodzeniem ścieżek, które jest objęte innymi wymaganiami z rozdziału 5 (Weryfikacja, oczyszczanie i kodowanie) standardu ASVS i CASA;

12.3.3

Objęte sekcjami 5.2.6 i 5.3.9

12.3.6

objęte sekcjami 10.3.2, 12.4.1 i 12.4.2.

12.5.1

objęte sekcjami 10.3.2 i 12.4.2

12.5.2

objęte sekcjami 10.3.2, 12.4.1 i 12.4.2.

13.1.5

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

13.2.2

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

13.2.3

Objęte sekcją 4.2.2

13.2.5

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

13.3.1

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

14.4.1

objęte sekcją 5.3.1

14.4.2

Ten wymóg jest objęty innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie powoduje rzeczywistej luki w logice biznesowej, może to być problem o mniejszym stopniu ważności. Przykład: nieprawidłowe sprawdzanie poprawności numeru telefonu powoduje tylko nieprawidłowe wyświetlanie numeru telefonu na stronie informacji, co nie ma bezpośrednich konsekwencji dla bezpieczeństwa.

14.4.3

objęte sekcjami 5.2.7 i 5.3.3.

14.4.5

objęte sekcjami 6.2.1 i 9.2.1.

14.4.7

objęte sekcją 12.4.1,

14.5.3

objęte sekcją 14.5.2

2.1.5

objęte sekcją 2.1.1

2.1.6

objęte sekcją 2.1.1

2.2.3

Nie ma znaczenia w przypadku casa, ponieważ ryzyko jest objęte innymi mechanizmami ochrony przed automatyzacją.

2.5.6

chronione przez inne zabezpieczenie hasłem.

3.1.1

Niskie ryzyko narażenia i objęte innymi kontrolami ASVS

3.2.1

Niskie ryzyko narażenia i objęte innymi kontrolami ASVS

3.4.4

Niskie ryzyko narażenia i objęte innymi kontrolami ASVS

3.4.5

Niskie ryzyko narażenia i objęte innymi kontrolami ASVS

4.2.1

objęte punktem 13.1.4,

5.2.8

objęte innymi kontrolami weryfikacji i oczyszczania danych wejściowych.

5.3.5

objęte innymi kontrolami weryfikacji i oczyszczania danych wejściowych.

7.4.1

objęte kontrolami logowania,

8.2.3

objęte sekcją 8.1.1

9.1.1

objęte sekcjami 6.2.1 i 9.2.1.

1.2.3

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.4.4

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.5.2

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.5.3

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.5.4

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.9.1

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.11.3

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.14.1

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.14.2

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.14.3

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.14.4

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.14.5

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

1.14.6

objęte punktami 1.1.4, 1.8.4 i 1.8.2.

6.1.2

Objęte sekcją 6.1.1

6.1.3

Objęte sekcją 6.1.1

2.10.2

Objęte sekcją 2.5.4

2.2.1

Objęte wersją 11.1.4

2.7.3

Objęte sekcją 2.7.2

2.7.4

Objęte sekcją 2.7.2

5.1.2

Objęte ochroną przed automatyzacją

6.2.2

niezdefiniowane zatwierdzone algorytmy kryptograficzne,

8.2.1

Objęte sekcją 8.1.1

9.1.2

Objęte sekcją 9.2.1

9.1.3

Objęte sekcją 9.2.1

5.5.1

Objęte sekcją 1.8.2

14.2.1

Objęte sekcją 1.14.6

3.3.4

Nie dotyczy to aplikacji korzystających z bezstanowej autoryzacji i uwierzytelniania. Zgadzam się z rekomendacją NCC Group dotyczącą usunięcia. Powinno to być objęte sekcją 3.3.3

req_id

Opis

1.1.4

Sprawdź dokumentację i uzasadnienie wszystkich granic zaufania, komponentów i istotnych przepływów danych aplikacji.

1.8.1

Sprawdzanie, czy wszystkie dane wrażliwe są zidentyfikowane i sklasyfikowane na poziomach ochrony.

1.8.2

Sprawdź, czy wszystkie poziomy ochrony mają powiązany zestaw wymagań dotyczących ochrony, takich jak wymagania dotyczące szyfrowania, wymagania dotyczące integralności, przechowywania, prywatności i inne wymagania dotyczące poufności, oraz czy są one

zastosowane w architekturze.

2.1.1

Sprawdź, czy hasła ustawione przez użytkowników mają co najmniej 12 znaków.

2.5.4

Sprawdź, czy nie ma kont współdzielonych ani domyślnych (np. „root”,

„admin” lub „sa”).

4.2.1

Sprawdź, czy dane wrażliwe i interfejsy API są chronione przed atakami typu IDOR (Insecure Direct Object Reference), które mają na celu tworzenie, odczytywanie, aktualizowanie i usuwanie rekordów, np. tworzenie lub aktualizowanie rekordów innych osób, wyświetlanie rekordów wszystkich osób lub usuwanie wszystkich rekordów.

1.14.6

Sprawdź, czy aplikacja nie korzysta z nieobsługiwanych, niezabezpieczonych ani przestarzałych

technologie po stronie klienta, takie jak wtyczki NSAPI, Flash, Shockwave, ActiveX,

Silverlight, NACL lub aplety Java po stronie klienta.