Aktualizacje CASA

Aktualizacja: 29 marca 2023 r.

Aby zapewnić zgodność z trendami branżowymi i sprawdzonymi metodami, grupa robocza obrony aplikacji (ADA) w I kwartale 2023 roku przeprowadziła sesje sprawdzania, aby zaktualizować, uprościć i ujednolicić procedury testowania CASA. Na podstawie tych sesji roboczych wymagania i proces CASA zostały zaktualizowane w ten sposób:

  • Wymagania dotyczące CASA zostały zaktualizowane z 134 na 73 (szczegóły poniżej).

  • Aby przeprowadzić ocenę CASA, aplikacja musi uzyskać lub usunąć wszystkie 73 wymagania CASA, niezależnie od oceny CWE.

  • Zaktualizowane opisy poziomów, tak aby uwzględnić moduł prowadzony na poziomie 2.

  • Dla każdego poziomu dodano informacje o bezpieczeństwie.

  • Mała aktualizacja, która upraszcza sam proces skanowania poziomu 2.

Aktualizacja wymagań CASA

  • Aktualną listę wymagań znajdziesz tutaj.

  • Te wymagania zostały usunięte


identyfikator_żądania

Opinia na temat grupy roboczej

8.1.6

Uznałoby to wymaganie za bardziej przydatne (np. kopie zapasowe powinny być przechowywane tylko przez X czas, kopie zapasowe powinny być monitorowane pod kątem kradzieży/uszkodzeń, należy regularnie sprawdzać kopie zapasowe, aby potwierdzić ich możliwość przeniesienia do środowiska produkcyjnego). Obecne założenie jest zbyt ogólne i wymagałoby szerszego zdefiniowania.

5,1,4

Duplikat innych przypadków testowych. To bardzo skomplikowany test o małej wartości. Zalecamy usunięcie.

7,3,3

Duplikat innych przypadków testowych. To bardzo skomplikowany test o małej wartości. Zalecamy usunięcie.

1,2,2

usuń ze względu na inne wymogi, takie jak 4.1.1

2,2,4

Usunięcie żądania Req w zakresie 4.3.1

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

zapobieganie nieautoryzowanemu użyciu). Wykrywa ono odporność na próby podszywania się pod inne osoby w interfejsach administracyjnych i innych ścieżkach dostępu wewnętrznego.

2,2,5

Usuwanie jest niedozwolone, ponieważ większość CSP nie obsługuje mTLS

2,4,3

Standard w obecnej formie nie jest wystarczająco szczegółowy i wykonalny

2,4,5

Ten wymóg nie jest wymagany w wersji 5 ASVS, a zalecane algorytmy szyfrowania w wersji 2.4.1 nie mogą spełniać tego wymogu

2,7,5

Testowanie jest niemożliwe, ponieważ może wymagać analizy zewnętrznych dostawców OOB. W tym przypadku istnieje niewielkie ryzyko, że kod uwierzytelniania jest krótki.

2,8,2

wymagania dotyczą tylko niestandardowych rozwiązań MFA, również w wersjach 6.4.2 i 6.4.1

2,8,5

Usuń wymaganie, ponieważ jest ono objęte punktem 2.7.6, a dodatkowo nieudane próby logowania są objęte wymaganiami logowania w ASVS

2,8,6

Hasło fizyczne na poziomie aplikacji nie jest typowym przypadkiem. Ten wymóg jest wymagany w interfejsach administratora. Wymóg zastosowania wersji 4.3.1.

2,9,1

Ten wymóg dotyczy urządzeń fizycznych zgodnie z zasadami ASVS (klucze kryptograficzne to karty inteligentne lub klucze FIDO, gdzie użytkownik musi podłączyć lub sparować

urządzenia kryptograficznego na komputer w celu przeprowadzenia uwierzytelniania. Weryfikatorzy wysyłają wyzwanie zabezpieczające do

urządzeń lub oprogramowania kryptograficznego, a urządzenie lub oprogramowanie oblicza odpowiedź na podstawie bezpiecznego

przechowywanego klucza kryptograficznego). z powodu braku uwierzytelniania CASA zgodnie z wymaganiami MFA (fizycznymi lub fizycznymi), które są związane z ryzykiem uwierzytelniania urządzeń fizycznych, nie jest uwzględniony ten warunek 4.3.1.

2,9,3

Ten wymóg dotyczy urządzeń fizycznych zgodnie z zasadami ASVS (klucze kryptograficzne to karty inteligentne lub klucze FIDO, gdzie użytkownik musi podłączyć lub sparować

urządzenia kryptograficznego na komputer w celu przeprowadzenia uwierzytelniania. Weryfikatorzy wysyłają wyzwanie zabezpieczające do

urządzeń lub oprogramowania kryptograficznego, a urządzenie lub oprogramowanie oblicza odpowiedź na podstawie bezpiecznego

przechowywanego klucza kryptograficznego). z powodu braku uwierzytelniania CASA zgodnie z wymaganiami MFA (fizycznymi lub fizycznymi), które są związane z ryzykiem uwierzytelniania urządzeń fizycznych, nie jest uwzględniony ten warunek 4.3.1.

2.10.1

Wymaganie jest sprzeczne z zawartością 2.10.2

2,10,3

Objęty systemem 2.4.1 (sprawdź, czy podczas przechowywania hasła użytkownika do aplikacji używana jest jedna z tych funkcji haszowania: argon2id, scrypt, bcrypt lub PBKDF2), co obejmuje ryzyko ataków offline i przechowywania hasła.

2,10,4

Objęty systemem 6.4.2. Sprawdź, czy materiał klucza nie jest dostępny dla aplikacji, ale używa odizolowanego modułu zabezpieczeń, np. Vault do operacji kryptograficznych.

3,2,3

Obsługiwane przez 3.4.1, 3.4.2 i 3.4.3

3,5,1

Użytkownik może unieważniać tokeny przez dostawcę OAuth

4,3,3

Wymagania są objęte MFA dla interfejsów administracyjnych i uprzywilejowanego dostępu

5,1,3

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

5,1,4

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

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 ma taki format, że mieści się w nim każdy znak Unicode. Brak obsługi niektórych systemów operacyjnych i narzędzi do łamania zabezpieczeń w całej przestrzeni Unicode. Dlatego nie możesz przetestować tej funkcji, nawet jeśli serwer ją obsługuje. Wątpliwej wartości bezpieczeństwa. Pierwotnie była w wersji beta, ale została usunięta z powodu problemów podczas testów.

6,2,5

z zastosowaniem systemów 6.2.4 i 6.2.3

6.2.6

z zastosowaniem systemów 6.2.4 i 6.2.3

6.3.1

z zastosowaniem systemów 6.2.4 i 6.2.3

6.3.3

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

7,1,2

obsługiwane przez 7.1.1

7,1,3

obsługiwane przez 7.1.1

7,3,1

obsługiwane przez 7.1.1

7,3,3

obsługiwane przez 7.1.1

8.1.3

Trudno jest opisać, który parametr jest akceptowany lub wymagany. Przypadka, którego nie można przetestować. Co uznaje się za konieczne? Jak ustalimy, czy wyjątek jest prawidłowy? Uznaje się poza zakresem dla CASA

8.3.3

Wymagana możliwość testowania, związana z polityką prywatności i warunkami korzystania z usługi, a nie bezpieczeństwem aplikacji. Ma to na celu sprawdzenie zgodności z przepisami i regulacja zgodności z przepisami ustawy CASA

8.3.6

Element sterujący odnosi się do systemu (wariantu systemu Windows lub Linux), a także do urządzenia i w większości przypadków nie jest kontrolowany przez aplikację.

8.3.8

z uwzględnieniem ustawień 1.8.1, 1.8.2 i 1.1.4

9,2,5

i są objęte 8.3.5 i weryfikacją zasad aplikacji.

10.1.1

Jest ona objęta weryfikacją architektury i jest zalecaną sprawdzoną metodą. Tego wymogu nie można przetestować

10.2.3

Nie jest to możliwe w rozsądnym czasie. Każdy dziwny kod powinien być udokumentowany i zweryfikowany, jednak ustawienie konkretnego zadania, by mieć pewność, że nie mają dostępu do zaległości, wymaga szczegółowej weryfikacji kodu i nie gwarantuje, że takie tajemnice nie są dostępne.

Trudne do przetestowania pod kątem dobrze zaprojektowanych złośliwych funkcji

10,2,4

Brak możliwości testowania. Nie można tego zrobić w rozsądnym czasie. Każdy dziwny kod powinien być udokumentowany i zweryfikowany, jednak ustawienie konkretnego zadania, by mieć pewność, że nie mają dostępu do zaległości, wymaga szczegółowej weryfikacji kodu i nie gwarantuje, że takie tajemnice nie są dostępne.

Trudne do przetestowania pod kątem dobrze zaprojektowanych złośliwych funkcji

10,2,5

Brak możliwości testowania. Nie można tego zrobić w rozsądnym czasie. Każdy dziwny kod powinien być udokumentowany i zweryfikowany, jednak ustawienie konkretnego zadania, by mieć pewność, że nie mają dostępu do zaległości, wymaga szczegółowej weryfikacji kodu i nie gwarantuje, że takie tajemnice nie są dostępne.

Trudne do przetestowania pod kątem dobrze zaprojektowanych złośliwych funkcji

13,1.1

Obsługiwane przez 5.2.6 i 5.3.9

12.3.1

ryzyko związane z przemierzaniem ścieżki objęte innymi wymaganiami określonymi w rozdziale 5 (weryfikacja, sanityzacja i kodowanie) rekordów ASVS i CASA;

12,3,3

Obsługiwane przez 5.2.6 i 5.3.9

12,3.6

z uwzględnieniem ustawień 10.3.2 12.4.1 i 12.4.2

12,5,1

z uwzględnieniem ustawień 10.3.2 i 12.4.2

12,5,2

z uwzględnieniem ustawień 10.3.2 12.4.1 i 12.4.2

13,1,5

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

13.2.2

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

13,2,3

Obsługiwane przez 4.2.2

13,2,5

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

13,3,1

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

14,4.1

obsługiwany przez 5.3.1

14,4.2

To wymaganie jest objęte innymi wymaganiami dotyczącymi weryfikacji danych wejściowych. Jeśli brak weryfikacji nie wprowadza rzeczywistej luki w logice biznesowej, może być ona niższa. Na przykład niepoprawna weryfikacja numeru telefonu powoduje, że wyświetla się on nieprawidłowo na stronie z informacjami, co nie ma bezpośredniego wpływu na bezpieczeństwo.

14,4.3

z zastosowaniem systemów 5.2.7 i 5.3.3

14,4,5

6.2.1 i 9.2.1

14,4,7

obsługiwany przez 12.4.1

14,5,3

obsługiwane przez 14.5.2

2.1.5

obsługiwany przez 2.1.1

2.1.6

obsługiwany przez 2.1.1

2,2,3

Nie dotyczy Casa, ponieważ ryzyko jest regulowane przez inne środki antyautomatyzacyjne

2,5,6

Chronione hasłem

3.1.1

Małe ryzyko narażenia na kontakt i inne zabezpieczenia ASVS

3.2.1

Małe ryzyko narażenia na kontakt i inne zabezpieczenia ASVS

3,4,4

Małe ryzyko narażenia na kontakt i inne zabezpieczenia ASVS

3,4,5

Małe ryzyko narażenia na kontakt i inne zabezpieczenia ASVS

4.2.1

obsługiwane przez 13.1.4

5,2,8

objęte innymi mechanizmami weryfikacji oraz dezynfekcji

5,3,5

objęte innymi mechanizmami weryfikacji oraz dezynfekcji

7,4,1

objęte weryfikacją

8.2.3

obsługiwany przez 8.1.1

9.1.1

6.2.1 i 9.2.1

1,2,3

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,4,4

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,5,2

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,5,3

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,5,4

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,9,1

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,11,3

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,14,1

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,14,2

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,14,3

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,14,4

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,14,5

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

1,14,6

z uwzględnieniem ustawień 1.1.4, 1.8.4 i 1.8.2

6.1.2

Obsługiwane przez 6.1.1

6.1.3

Obsługiwane przez 6.1.1

2,10,2

Objęte przez 2.5.4

2,2,1

Objęte przez 11.1.4

2,7,3

Obsługiwane przez 2.7.2

2,7,4

Obsługiwane przez 2.7.2

5,1,2

Ochrona antyautomatyzacyjna

6.2.2

nie określono zatwierdzonych algorytmów kryptograficznych

8.2.1

Obsługiwane przez 8.1.1

9.1.2

Obsługiwane przez 9.2.1

9,1,3

Obsługiwane przez 9.2.1

5,5,1

Objęte przez 1.8.2

14.2.1

Objęte przez 1.14.6

3,3,4

Nie dotyczy to aplikacji korzystających z stanowych zasad AuthN/Z. Zaakceptuj rekomendacje NCC Group, aby je usunąć. Powinno to zająć 3.3.3



  • Dodaliśmy te wymagania:


identyfikator_żądania

Opis

1,1,4

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

1,8.1

Sprawdź, czy wszystkie dane wrażliwe są rozpoznawane i klasyfikowane na poziomie ochrony

1,8.2

Sprawdź, czy wszystkie poziomy ochrony mają powiązany zestaw wymagań w zakresie zabezpieczeń, takich jak wymagania dotyczące szyfrowania, wymagania dotyczące integralności, przechowywania, prywatności i inne wymagania dotyczące poufności, a także

stosowane w architekturze.

2.1.1

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

2,5,4

Upewnij się, że nie ma kont udostępnionych ani domyślnych (np. „root”,

„admin” lub „sa”).

4.2.1

Sprawdź, czy dane wrażliwe i interfejsy API są chronione przed atakami niezabezpieczonej bezpośredniej identyfikacji obiektów (IDOR), które polegają na kierowaniu na odczytywanie, odczytywanie, aktualizowanie i usuwanie rekordów, takich jak tworzenie lub aktualizowanie czyichś rekordów, wyświetlanie wszystkich rekordów lub usuwanie wszystkich rekordów.

1,14,6

Sprawdź, czy aplikacja nie korzysta z nieobsługiwanych, niezabezpieczonych lub wycofanych danych

technologie działające po stronie klienta, np. wtyczki NSAPI, Flash, Shockwave, ActiveX,

Silverlight, NACL lub apletów Java po stronie klienta.