8.29 Testowanie bezpieczeństwa w cyklu rozwoju

Treść sekcji 8.29 Testowanie bezpieczeństwa w cyklu rozwoju.# 8.29 Testowanie bezpieczeństwa w rozwoju i akceptacji

Rodzaj kontroli: Informacja
Właściwości bezpieczeństwa: Prewencyjne, Poufność, Integralność, Dostępność
Koncepcje cyberbezpieczeństwa: Ochrona, Bezpieczeństwo aplikacji, Zapewnienie bezpieczeństwa informacji, Bezpieczeństwo systemów i sieci
Obszary operacyjne: Ochrona

Kontrola

Procesy testowania bezpieczeństwa powinny być zdefiniowane i wdrożone w cyklu życia rozwoju.

Cel

Weryfikacja, czy wymagania bezpieczeństwa informacji zostały spełnione, kiedy aplikacje lub kod są wdrażane do środowiska produkcyjnego.

Wytyczne

Nowe systemy informacyjne, aktualizacje i nowe wersje powinny być dokładnie testowane i weryfikowane podczas procesów rozwoju. Testowanie bezpieczeństwa powinno być integralną częścią testów systemów lub komponentów.

Testowanie bezpieczeństwa powinno być przeprowadzone w oparciu o zestaw wymagań, które mogą być wyrażone jako funkcjonalne lub niefunkcjonalne. Testowanie bezpieczeństwa powinno obejmować testowanie: a) funkcji bezpieczeństwa (np. uwierzytelnianie użytkowników (patrz 8.5), ograniczenia dostępu (patrz 8.3) oraz użycie kryptografii (patrz 8.24));
b) bezpiecznego kodowania (patrz 8.28);
c) bezpiecznych konfiguracji (patrz 8.9, 8.20 i 8.22), w tym systemów operacyjnych, zapór ogniowych i innych komponentów bezpieczeństwa.

Plany testów powinny być ustalane na podstawie zestawu kryteriów. Zakres testowania powinien być proporcjonalny do ważności, charakteru systemu i potencjalnego wpływu zmiany wprowadzanej. Plan testów powinien zawierać:
a) szczegółowy harmonogram działań i testów;
b) dane wejściowe i oczekiwane wyniki w różnych warunkach;
c) kryteria oceny wyników;
d) decyzję o dalszych działaniach, jeśli to konieczne.

Organizacja może skorzystać z narzędzi automatycznych, takich jak narzędzia do analizy kodu lub skanery podatności, i powinna zweryfikować usunięcie defektów związanych z bezpieczeństwem.

W przypadku rozwoju wewnętrznego, testy te powinny być początkowo przeprowadzone przez zespół deweloperski. Następnie powinno być przeprowadzone niezależne testowanie akceptacyjne, aby upewnić się, że system działa zgodnie z oczekiwaniami i tylko zgodnie z oczekiwaniami (patrz 5.8). Należy rozważyć: a) przeprowadzenie przeglądów kodu jako element testowania pod kątem wad bezpieczeństwa, w tym nieoczekiwanych danych wejściowych i warunków;
b) przeprowadzenie skanowania podatności w celu identyfikacji niebezpiecznych konfiguracji i podatności systemu;
c) przeprowadzenie testów penetracyjnych w celu identyfikacji niebezpiecznego kodu i projektów.

W przypadku zleconego rozwoju i zakupu komponentów, należy postępować zgodnie z procesem zakupu. Umowy z dostawcą powinny uwzględniać zidentyfikowane wymagania bezpieczeństwa (patrz 5.20). Produkty i usługi powinny być oceniane na podstawie tych kryteriów przed zakupem.

Testowanie powinno być przeprowadzane w środowisku testowym, które jak najdokładniej odwzorowuje docelowe środowisko produkcyjne, aby upewnić się, że system nie wprowadza podatności do środowiska organizacji i że testy są wiarygodne (patrz 8.31).

Inne informacje

Można utworzyć wiele środowisk testowych, które mogą być wykorzystywane do różnych rodzajów testów (np. testy funkcjonalne i wydajnościowe). Te różne środowiska mogą być wirtualne, z indywidualnymi konfiguracjami symulującymi różnorodne środowiska operacyjne.

Testowanie i monitorowanie środowisk testowych, narzędzi i technologii również należy wziąć pod uwagę, aby zapewnić skuteczne testowanie. Te same zasady stosują się do monitorowania systemów monitorujących w środowiskach rozwoju, testów i produkcji. W zależności od wrażliwości systemów i danych należy ocenić, jak wiele warstw meta-testowania będzie przydatnych.