Przejdź do głównej zawartości

8.26 Wymagania bezpieczeństwa aplikacji

W skrócie: przed budową lub zakupem aplikacji organizacja ustala, jakie wymagania bezpieczeństwa ma ona spełniać, i dokumentuje je jak każde inne wymaganie.

Cel: zapewnienie, że wszystkie wymagania bezpieczeństwa informacji są zidentyfikowane i uwzględnione przy wytwarzaniu lub pozyskiwaniu aplikacji.

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#System_and_network_security (bezpieczeństwo systemów i sieci), #Application_security (bezpieczeństwo aplikacji)
Domeny bezpieczeństwa#Protection (ochrona), #Defence (obrona)

Znaczenie atrybutów opisuje 4.2 Tematy i atrybuty.

Wytyczne​

  • Wymagania bezpieczeństwa aplikacji identyfikuje się, określa i zatwierdza na podstawie oceny ryzyka, z udziałem specjalistów bezpieczeństwa.
  • Ogólne wymagania mogą obejmować: poziom zaufania do tożsamości (uwierzytelnianie), rodzaj i klasyfikację przetwarzanych informacji, potrzeby rozdzielenia dostępu i poziomy dostępu, odporność na złośliwe ataki i niezamierzone zakłócenia (np. przepełnienie bufora, wstrzyknięcia SQL), wymagania prawne w miejscu przetwarzania transakcji, prywatność, ochronę danych wrażliwych, ochronę informacji w trakcie przetwarzania, w tranzycie i w spoczynku, szyfrowanie komunikacji, kontrolę danych wejściowych, automatyczne obliczenia, ograniczenia długości pól, rejestrowanie i monitorowanie, obsługę błędów.
  • Usługi transakcyjne wymagają dodatkowo: poziomu zaufania do tożsamości stron, ochrony przed nieuprawnioną zmianą transakcji, zapewnienia niezaprzeczalności, kompletności i poprawności transakcji, poufności i integralności danych zamówień i płatności.
  • Zamówienia i płatności elektroniczne wymagają m.in. ochrony informacji o płatnościach, weryfikacji danych płatniczych, właściwego przechowywania szczegółów transakcji poza środowiskiem dostępnym publicznie.
  • Wymagania określa się w specyfikacji, niezależnie od tego, czy aplikacja jest wytwarzana, czy kupowana. Przy zakupie gotowego produktu sprawdza się, czy spełnia wymagania, a jeśli nie — ocenia ryzyko.

W praktyce​

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

  • OWASP ASVS jako katalog wymagań bezpieczeństwa z poziomami dopasowanymi do ryzyka aplikacji.
  • Wymagania bezpieczeństwa jako elementy backlogu z kryteriami akceptacji, a nie osobny dokument, którego nikt nie czyta.
  • Dla płatności kartowych — PCI DSS; dla usług elektronicznych z podpisem — rozporządzenie eIDAS.

Powiązania​