Przejdź do głównej zawartości

8.29 Testy bezpieczeństwa w wytwarzaniu i odbiorze

W skrócie: nowe i zmienione systemy przechodzą testy bezpieczeństwa, zanim trafią na produkcję — według planu i z jasnymi kryteriami odbioru.

Cel: sprawdzenie, czy wymagania bezpieczeństwa informacji są spełnione, gdy aplikacje lub kod trafiają do środowiska produkcyjnego.

Atrybuty​

Typ atrybutuWartości
Typ zabezpieczenia#Preventive (prewencyjne)
Właściwości bezpieczeństwa informacji#Confidentiality (poufność), #Integrity (integralność), #Availability (dostępność)
Koncepcje cyberbezpieczeństwa#Identify (identyfikacja)
Zdolności operacyjne#System_and_network_security (bezpieczeństwo systemów i sieci), #Application_security (bezpieczeństwo aplikacji), #Information_security_assurance (zapewnienie bezpieczeństwa informacji)
Domeny bezpieczeństwa#Protection (ochrona)

Znaczenie atrybutów opisuje 4.2 Tematy i atrybuty.

Wytyczne​

  • Nowe systemy, aktualizacje i nowe wersje są gruntownie testowane i weryfikowane w procesie wytwarzania.
  • Testy bezpieczeństwa są częścią testów systemu lub komponentu. Przeprowadza się je względem wymagań — funkcjonalnych i niefunkcjonalnych.
  • Testy obejmują: funkcje bezpieczeństwa (uwierzytelnianie, ograniczenie dostępu, kryptografia), bezpieczne programowanie (8.28), bezpieczne konfiguracje (8.9, 8.20, 8.22), w tym systemów operacyjnych, zapór i innych komponentów.
  • Plan testów obejmuje harmonogram działań, dane wejściowe i oczekiwane wyniki w różnych warunkach, kryteria oceny wyników oraz decyzje o dalszych krokach.
  • Organizacja może korzystać z narzędzi automatycznych: analizy kodu, skanerów podatności. Weryfikuje poprawki podatności.
  • Testy wykonuje się w środowisku jak najbardziej zbliżonym do produkcyjnego, by system nie wprowadził podatności do środowiska organizacji.
  • Przy wytwarzaniu zleconym i zakupie komponentów stosuje się proces odbioru — z umową określającą wymagania i dowodami testów.
  • Program testów akceptacyjnych obejmuje wymagania bezpieczeństwa. Przy zakupie produktów można uwzględnić certyfikację, np. Common Criteria.

W praktyce​

Przykłady i narzędzia poniżej to praktyka branżowa, nie treść normy.

  • DAST (np. OWASP ZAP, Burp Suite) na środowisku testowym w potoku CI, uzupełniony testem penetracyjnym przed dużymi wydaniami.
  • Kryterium akceptacji: brak otwartych podatności krytycznych i wysokich, z udokumentowanymi wyjątkami.
  • Testy konfiguracji infrastruktury jako kodu (np. Checkov, tfsec) przed wdrożeniem.

Powiązania​