Przejdź do głównej zawartości

8.34 Ochrona systemów informacyjnych podczas testów audytowych

W skrócie: audyty i testy na systemach produkcyjnych są planowane i uzgadniane z kierownictwem, tak by nie zaszkodziły działaniu systemów ani poufności danych.

Cel: ograniczenie wpływu audytów i innych działań zapewniających na systemy eksploatowane i procesy biznesowe.

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#Protect (ochrona)
Zdolności operacyjne#Information_protection (ochrona informacji), #System_and_network_security (bezpieczeństwo systemów i sieci)
Domeny bezpieczeństwa#Governance_and_Ecosystem (ład i ekosystem), #Protection (ochrona)

Znaczenie atrybutów opisuje 4.2 Tematy i atrybuty.

Wytyczne​

  • Uwaga terminologiczna: chodzi o systemy eksploatowane (operational systems), czyli produkcyjne, a nie systemy operacyjne.
  • Wnioski o dostęp do systemów i danych na potrzeby audytu uzgadnia się z kierownictwem. Uzgadnia się i kontroluje zakres testów technicznych.
  • Testy audytowe ogranicza się do dostępu tylko do odczytu. Gdy to nie wystarcza, testy wykonuje doświadczony administrator z odpowiednimi uprawnieniami w imieniu audytora.
  • Przed udzieleniem dostępu sprawdza się wymagania bezpieczeństwa wobec urządzeń audytora (np. ochrona przed malware, aktualizacje).
  • Dostęp inny niż tylko do odczytu przyznaje się wyłącznie do odizolowanych kopii plików systemowych, które usuwa się po audycie albo chroni, jeśli dokumentacja audytowa wymaga ich zachowania.
  • Wnioski o specjalne przetwarzanie (np. uruchamianie narzędzi audytowych) identyfikuje się i uzgadnia.
  • Testy mogące wpłynąć na dostępność systemu prowadzi się poza godzinami pracy. Dostęp na potrzeby audytu i testów jest monitorowany i rejestrowany.
  • Audyty i oceny mogą też dotyczyć środowisk rozwojowych i testowych — trzeba wtedy chronić integralność kodu i informacje wrażliwe w tych środowiskach.

W praktyce​

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

  • Pisemne zasady testu penetracyjnego (rules of engagement): zakres, okna czasowe, kontakty awaryjne, zakazane techniki (np. DoS).
  • Tymczasowe konta audytorów z datą wygaśnięcia i nagrywaniem sesji.
  • Uprzedzenie zespołu SOC o planowanym teście — albo świadome pominięcie, gdy test sprawdza właśnie wykrywanie.

Powiązania​