Akredytacja systemu o klauzuli zastrzeżone
← Powrót do przewodnika: Akredytacja systemu niejawnego
Systemy przetwarzające informacje o klauzuli „zastrzeżone” idą inną drogą niż pozostałe. Droga jest krótsza, ale bywa myląca: skrócenie dotyczy procedury, a nie wymagań.
Kto udziela akredytacji
Art. 48 ust. 9 ustawy o ochronie informacji niejawnych stanowi, że akredytacji bezpieczeństwa teleinformatycznego dla systemu przeznaczonego do przetwarzania informacji niejawnych o klauzuli „zastrzeżone” udziela kierownik jednostki organizacyjnej.
Robi to przez zatwierdzenie dokumentacji bezpieczeństwa systemu.
Dla porównania: dla klauzuli „poufne” i wyższej akredytacji udziela ABW albo SKW, a potwierdzeniem jest świadectwo akredytacji wydane przez służbę.
Co to zmienia, a czego nie zmienia
Zmienia się organ i tryb. Nie ma wniosku do służby, nie ma sześciomiesięcznego postępowania, nie ma świadectwa wydanego z zewnątrz.
Nie zmienia się dokumentacja. System nadal potrzebuje SWB i PBE, a ich zawartość określa art. 49 tak samo jak dla klauzul wyższych. SWB nadal musi zawierać wyniki szacowania ryzyka, powstaje na etapie projektowania i podlega modyfikacji przed zmianami w systemie.
Nie zmienia się odpowiedzialność. Za ochronę informacji niejawnych w jednostce odpowiada kierownik, co wynika z art. 14 ust. 1 ustawy. Przy klauzuli „zastrzeżone” ta odpowiedzialność jest widoczna wprost: to on podpisuje dokument, który dopuszcza system do pracy.
Pułapka pierwsza: to nie jest formalność
Zatwierdzenie dokumentacji przez kierownika bywa traktowane jak podpisanie pisma przygotowanego przez informatyka. Tymczasem jest to decyzja o dopuszczeniu systemu do przetwarzania informacji niejawnych, podejmowana na własną odpowiedzialność, bez zewnętrznej weryfikacji.
Brak oceny przez służbę oznacza, że nikt z zewnątrz nie wychwyci błędu przed uruchomieniem. Wychwyci go dopiero kontrola albo incydent.
Pułapka druga: klauzula ma tendencję do wzrostu
System zaprojektowany „na zastrzeżone” bywa po jakimś czasie używany do przetwarzania pojedynczych dokumentów o klauzuli „poufne”, bo akurat było wygodnie.
To zmienia wszystko: organ akredytujący, tryb, wymagania. System bez akredytacji ABW albo SKW nie może przetwarzać informacji o klauzuli „poufne” i wyższej, niezależnie od tego, jak dobrze jest zabezpieczony.
Warto ustalić to na wejściu i zapisać w SWB wprost: jaka jest najwyższa dopuszczalna klauzula w tym systemie.
Pułapka trzecia: brak zewnętrznego terminu usypia
Przy klauzulach wyższych rytm wymusza służba: sześć miesięcy postępowania, trzydzieści dni na zalecenia, termin ważności świadectwa. Przy „zastrzeżonych” żaden z tych terminów nie działa z zewnątrz.
Efekt bywa taki, że dokumentacja zatwierdzona przy uruchomieniu systemu zostaje w tej wersji przez lata, mimo że system zmienił się kilkanaście razy. Tymczasem art. 49 ust. 4 wiąże każdą zmianę z ponownym szacowaniem ryzyka niezależnie od klauzuli.
Co zrobić, żeby to działało
Zapisz w SWB najwyższą dopuszczalną klauzulę i traktuj ją jak granicę systemu, a nie sugestię.
Ustal własny rytm przeglądów. Skoro nie ma terminu z zewnątrz, jednostka musi go sobie nadać. Przegląd raz w roku i po każdej istotnej zmianie jest rozsądnym minimum.
Wpisz aktualizację dokumentacji do procedury zmian. Wtedy obowiązek z art. 49 ust. 4 uruchamia się sam, a nie z czyjejś pamięci.
Nie pisz dokumentacji sam dla siebie. Skoro nikt z zewnątrz jej nie oceni przed uruchomieniem, warto, żeby przeczytał ją ktoś, kto systemu nie budował.
Podsumowanie
Uproszczona ścieżka dla klauzuli „zastrzeżone” skraca procedurę, ale przenosi całą odpowiedzialność do wewnątrz jednostki. Dokumentacja jest ta sama, obowiązek aktualizacji ten sam, a jedyna różnica polega na tym, że nikt z zewnątrz nie sprawdzi jej przed uruchomieniem systemu.
Uruchamiacie system o klauzuli zastrzeżone albo chcecie sprawdzić dokumentację przed zatwierdzeniem? Napiszcie do nas.
