Szczególne Wymagania Bezpieczeństwa: struktura dokumentu

← Powrót do przewodnika: Dokumentacja SWB i PBE

SWB jest dokumentem, od którego zaczyna się każdy system przetwarzający informacje niejawne. Nie ma jednego obowiązującego wzoru, jest za to ustawowo określona zawartość i logika, której trzymają się wszystkie sensowne wersje tego dokumentu.

Co mówi przepis

Art. 49 ust. 1 ustawy z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych wymienia, co dokument powinien zawierać w szczególności:

wyniki procesu szacowania ryzyka dla bezpieczeństwa informacji niejawnych przetwarzanych w systemie teleinformatycznym oraz określać przyjęte w ramach zarządzania ryzykiem sposoby osiągania i utrzymywania odpowiedniego poziomu bezpieczeństwa systemu, a także opisywać aspekty jego budowy, zasady działania i eksploatacji, które mają związek z bezpieczeństwem systemu lub wpływają na jego bezpieczeństwo

Zwrot „w szczególności” jest tu istotny w obie strony. Nakłada minimum, poniżej którego dokument jest niekompletny, ale nie zamyka listy: przy systemie o wyższej klauzuli albo nietypowej architekturze służba może oczekiwać więcej.

Układ, który się broni

Poniższa struktura nie jest narzucona przepisem. Wynika z kolejności, w jakiej czyta się dokument przy ocenie: najpierw czym jest system, potem co mu grozi, potem jak się przed tym broni.

1. Identyfikacja systemu i jednostki

Nazwa systemu, jednostka organizacyjna, klauzula przetwarzanych informacji, podstawa prawna przetwarzania. Ta część bywa traktowana jak metryczka, a rozstrzyga o jednej rzeczy: jaka jest najwyższa klauzula, bo od niej zależy tryb akredytacji i to, czy prowadzi ją ABW albo SKW.

2. Granice systemu

Najczęściej pomijana i najczęściej kosztowna część. Trzeba jednoznacznie napisać, co należy do systemu, a co jest jego otoczeniem: które stanowiska, które nośniki, które pomieszczenia, które urządzenia peryferyjne.

Granica przebiega też przez ludzi. Osoba, która ma dostęp do stanowiska, jest wewnątrz systemu, choćby formalnie pracowała w innej komórce.

Dopóki granica nie jest opisana, nie da się rzetelnie oszacować ryzyka, bo nie wiadomo, czego dotyczy.

3. Wyniki szacowania ryzyka

Nie opis metody, tylko wyniki. Zidentyfikowane zagrożenia, podatności, oszacowany poziom ryzyka i decyzja, co z nim zrobiono.

Dokument, który w tym miejscu mówi „przeprowadzono analizę ryzyka zgodnie z przyjętą metodyką” i przechodzi dalej, nie spełnia wymogu z art. 49 ust. 1. Ustawa żąda wyników.

4. Sposoby osiągania i utrzymywania poziomu bezpieczeństwa

Środki organizacyjne, fizyczne i techniczne. Kluczowe jest powiązanie ich z ryzykiem: ustawa wiąże te sposoby wprost z zarządzaniem ryzykiem, więc każdy środek powinien dać się przypisać do ryzyka, które ogranicza.

Praktyczny sprawdzian: jeśli przy dowolnym zabezpieczeniu nie da się wskazać ryzyka z części trzeciej, to albo brakuje ryzyka, albo zabezpieczenie jest tam z rozpędu.

5. Aspekty budowy systemu

Architektura, konfiguracja, mechanizmy uwierzytelniania i rozliczalności, sposób separacji od innych sieci. Tylko w zakresie, w jakim wiąże się to z bezpieczeństwem: ustawa nie każe opisywać systemu w całości.

6. Zasady działania i eksploatacji

Reguły, które PBE zamieni potem na konkretne czynności. To jest miejsce na zasadę wiedzy koniecznej, reguły nadawania uprawnień, zasady postępowania z nośnikami.

7. Role i odpowiedzialność

Kierownik jednostki, pełnomocnik ochrony, inspektor bezpieczeństwa teleinformatycznego, administrator systemu, użytkownicy. Podział wynikający z art. 14 i art. 15 ustawy powinien być tu przełożony na konkretne stanowiska w konkretnej jednostce.

Kiedy powstaje

Art. 49 ust. 2 nie pozostawia w tej sprawie wyboru. SWB opracowuje się na etapie projektowania, konsultuje z ABW albo SKW, uzupełnia na etapie wdrażania i modyfikuje na etapie eksploatacji, przed wprowadzeniem zmian w systemie.

Konsekwencja jest praktyczna, nie formalna. Dokument pisany po zbudowaniu systemu przestaje być projektem bezpieczeństwa i staje się protokołem stanu zastanego. Jeżeli w tym stanie coś jest nie tak, poprawka kosztuje już nie decyzji projektowej, tylko przebudowy.

Dokument żyje razem z systemem

Art. 49 ust. 4 wiąże każdą zmianę w systemie z ponownym szacowaniem ryzyka. SWB nie jest więc dokumentem, który się pisze i odkłada do segregatora na pięć lat.

Wymiana serwera, dołożenie stanowiska, nowa wersja oprogramowania zabezpieczającego, zmiana pomieszczenia: każda z tych sytuacji uruchamia ten sam mechanizm, czyli spojrzenie na ryzyko i aktualizację dokumentu.

Rozjazd między SWB a stanem faktycznym jest jedną z najczęstszych uwag pokontrolnych i jednocześnie najłatwiejszą do uniknięcia, jeśli aktualizacja jest wpisana w procedurę zmiany, a nie zostawiona dobrej pamięci.

Podsumowanie

SWB odpowiada na pytanie, czym jest system, co mu grozi i jak jednostka zamierza to opanować. Minimalną zawartość wyznacza art. 49 ust. 1, ale o jakości dokumentu decydują dwie rzeczy spoza katalogu: jasno wytyczona granica systemu i widoczne powiązanie każdego zabezpieczenia z konkretnym ryzykiem.

Przygotowujecie SWB albo dokument wrócił z uwagami? Napiszcie do nas, bezpłatnie ocenimy zakres prac.