|
Niniejszy
artykuł jest kontynuacją dwu poprzednich i, dla lepszego rozumienia sprawy,
winien być czytany jako kolejny, rozpatrzone bowiem do tej pory etapy 1-5
analizy funkcjonalnej bezpieczeństwa, zakończone wyborem dobrej idei (etap
5AF), stawiają przed nami dwa najtrudniejsze zagadnienia: dopracowanie (etap
6AF) oraz wdrożenie (etap 7AF) praktycznego rozwiązania problemu ochrony
informacji w naszej organizacji/firmie/korporacji. Oczywisty jest fakt, że to
rozwiązanie dotyczy tylko tego analizowanego systemu (czyli układu czasu,
miejsca i możliwości) w odniesieniu do przyjętych przez decydentów (świadomie
lub tylko intuicyjnie) warunków brzegowych
1.
Wstęp
Zaproponowana
w niniejszym cyklu metoda analizy funkcjonalnej (cz. I rys. 1. - algorytm AF) w
swoim założeniu ma doprowadzić do powstania praktycznie sprawdzalnego
rozwiązania, którego przyjęcie jest uzależnione przede wszystkim od możliwości
jego pełnego pomyślnego wdrożenia. Wdrożenia zakończonego nie tylko
zrealizowaniem, założonej na wstępie, analizy funkcji bezpieczeństwa
systemowego ochranianej informacji, ale również uzyskaniem maksimum użytecznych
bieżących danych, odnoszących się do funkcjonowania samego systemu
bezpieczeństwa oraz jego bliższego otoczenia systemowego (rozpoznanie i
identyfikacja: zagrożeń i ryzyka, wymuszeń ustawowych oraz środowiskowych
itp.). Wszystko to, w końcowym efekcie naszych przemyśleń i prac, ma pozwolić
nam na podejmowanie, wybranych z szerokiego spektrum, teoretycznie
możliwych/dopuszczalnych, tych celowych i najbardziej skutecznych, działań
doskonalących nasz własny system ochronny (SZBI/ISMS).
Na czym
polega trudność? Cóż, diabeł tkwi w szczegółach. Otóż owa trudność polega na
konieczności szerszego, aniżeli tylko na koszty i korzyści finansowe,
spojrzenia na istotę zagadnienia (o czym zbyt często zdają się nie wiedzieć lub
nad wyraz chętnie zapominają współcześni decydenci).
2.
Przypomnienie kilku prawd oczywistych
Pisząc
„przypomnienie", autor ma świadomość, że liczne grono P.T. Czytelników uzna
poniższe stwierdzenia za truizm, ale przecież „kropla drąży skałę"...[1]/ (jednakże pod warunkiem, że spada ona
odpowiednio często i zawsze w to samo miejsce), czyli warto i należy po raz
kolejny przypomnieć, że:
- informacja
jest aktywem organizacji/firmy/korporacji, dlatego chronimy zawsze jej:
▪ poufność,
▪
dokładność/integralność,
▪ dostępność
wg uprawnień („wiedza potrzebna"),
-
bezpieczeństwo jest podstawą biznesu, dlatego też najistotniejsze jest
zapewnienie go w warunkach użytkowania zasobów na podstawie:
▪
identyfikacji użytkownika,
▪
uwierzytelnienia użytkownika,
▪ autoryzacji
uprawnień użytkownika,
▪ metod
dostępu użytkownika,
-
bezpieczeństwo informacji jest koniecznością w biznesie, dlatego bardzo ważne
jest upewnienie się formalne co do:
▪
rozliczalności dostępu, użytkowania i sposobu korzystania z niej,
▪ świadomości
personelu odnośnie jej wartości i ochrony,
▪ poprawnego
administrowania bezpieczeństwem w całym spektrum,
- plan
bezpieczeństwa informacji jest budowany „tu i teraz", czyli dla określonych
warunków występujących w samej organizacji/firmie/korporacji jak też dla
zweryfikowanych oddziaływań na nią jej najbliższego otoczenia.
Wg D.L.
Pipkina [2]/ poprawna budowa planu bezpieczeństwa informacji
przechodzi przez pięć głównych faz. Są to:
1) inspekcja -
najważniejszym zadaniem w budowaniu planu bezpieczeństwa informacji jest
wskazanie:
▪ kluczowych
funkcji w przedsiębiorstwie,
▪ zasobów, jakich
one wymagają,
▪ czasu,
kiedy zasoby te są potrzebne,
▪ sposobu/metody
współpracy z innymi funkcjami.
Faza
inspekcji umożliwia oszacowanie zarówno potrzeb instytucji w dziedzinie
bezpieczeństwa, jak i jej aktualnego poziomu przygotowania do zadań ochronnych.
2) ochrona -
proaktywne zmniejszanie ryzyka obejmuje każdy proces, który został wprowadzony
w celu ochrony przed przerwaniem działalności firmy. Dotyczy to czynności
fizycznych samych procesów i, towarzyszących ich realizacji, przepływów danych
informacyjnych. Do procesów minimalizujących skutki materializacji ryzyka
należy:
▪ wskazywanie
i kwalifikowanie wtórnych źródeł,
▪ zakup
części zapasowych,
▪ rozszerzanie
kanałów dystrybucji produktów,
▪ tworzenie
kopii krytycznej dokumentacji,
▪ zewnętrzne
wykonywanie operacji (tam, gdzie to potrzebne - jako umowy outsourcingu lub
zlecenia doraźne).
W tej fazie
decyzje polegają na określeniu, co wymaga ochrony, jaki poziom ochrony jest
potrzebny oraz w jaki sposób najlepiej wdrożyć żądany poziom bezpieczeństwa. Cele
te są osiągane przez opracowanie szczegółowego projektu bezpieczeństwa.
3) wykrywanie
- reaktywne zmniejszanie ryzyka, które obejmuje każdy proces wprowadzony w celu
zminimalizowania strat, czyli:
▪ wykrywanie
rozmyślnych działań skierowanych przeciw bezpieczeństwu,
▪ badanie
atakującego,
▪ badanie
metod ataku,
▪ badanie
technologii, które zostały użyte do wykrycia zdarzenia.
W fazie tej
dochodzi się, jak wykrywać rozmyślne szkodliwe działania i ograniczać wielkość
strat poniesionych na skutek incydentów, mogących spowodować przerwanie
funkcjonowania firmy.
4) reakcja -
w planie awaryjnym określa się, jaka powinna być odpowiedź na incydent związany
z bezpieczeństwem. W tej fazie decyzje polegają na opracowaniu procesu
reagowania dla możliwych scenariuszy. Odpowiedź musi zostać zdefiniowana,
udokumentowana i przetestowana, zanim zdarzy się incydent, tak aby każdy
wiedział, co należy zrobić podczas kryzysu. Plan reagowania na incydenty jest
krytyczną częścią planu utrzymania ciągłości działania. Odpowiednie
przygotowanie jest tu kluczem do sukcesu.
5) refleksja -
z chwilą gdy incydent się kończy, instytucja musi wykonać szereg kroków, tak
aby mogła pozostawić to zdarzenie za sobą i pracować dalej. Proces wymagający
udoskonalenia będzie (a przynajmniej bez wątpienia powinien) należeć do tych,
które są zdefiniowane w planie ciągłości działania. Ponieważ wszystkie te
udoskonalenia podlegają ocenie, potrzebne jest więc bardzo szerokie spojrzenie,
pozwalające określić, czy są również inne obszary planu ciągłości działania, w
których zmiany przyniosą korzyści oraz czy zmiany te wpłyną na inne obszary
planu.
Każda
instytucja (organizacja/firma/korporacja) powinna regularnie przeglądać swoje
plany bezpieczeństwa informacji. W trakcie realizowania tego procesu wiele z
nich odkryje, że ich biznesplany nie odpowiadają potrzebom bezpieczeństwa
informacji, zwłaszcza w rozumieniu potrzeb całości. Instytucja musi wypracować ogólny
kierunek bezpieczeństwa, tak aby poszczególne zasady bezpieczeństwa można było
budować w skoordynowany sposób.
Wykładnią
takiego kierunku jest nie tyle sama Polityka Bezpieczeństwa Informacji, co jej
udział w ogólnej Polityce Bezpieczeństwa Operacyjnego firmy oraz zgodność z nią
pozostałych współdziałających (bezpieczeństwo fizyczne, personalne, ciągłość
działania) i zależnych (grupy informacji, systemy IT/ICT) polityk, co
uwidacznia schematycznie poniższy rysunek:
Rys. 1.
Współzależności polityk bezpieczeństwa deklarowanych do stosowania w firmie
Warto i
trzeba pamiętać o przedstawionych współzależnościach, pod względem przepływów
informacji mamy tutaj bowiem (swoiście rozumiany) „system naczyń połączonych",
w którym każda, nawet przypadkowa lub niezamierzona, „nieszczelność" jest
źródłem strat [3]/. Przedstawiona wielofazowość planowania
działań związanych z bezpieczeństwem nie jest zatem na chwilę obecną czymś
nowym, a jedynie propozycją pozwalającą „ogarnąć całość" tej rozległej (czasem
bardzo skomplikowanej) struktury.
3.
Budowa podstaw rozwiązania praktycznego
Stan
wyjściowy w naszych pracach, po zakończeniu dotychczasowych analiz (etap 5 AF -
cz. II), możemy zobrazować jako zestawienie ograniczeń co do ew. dalszych
działań, o których to decydują przede wszystkim wypracowane i przyjęte
wcześniej:
- wybrane
„dobre idee" do dalszego naszego postępowania (wynikające z przyjętego systemu
wartościowania);
- założone
cele końcowe (uwarunkowane stanem i sytuacją organizacji/firmy/korporacji).
Uzupełnieniem
są tutaj informacje dodatkowe, wynikające z przysposobionej wiedzy z zakresu
bliższego i dalszego otoczenia systemowego i dotyczące:
-
technicznych rozwiązań zadań standardowych (upublicznione lub spopularyzowane
wymogi jako element działania ustawowego, np. obligatoryjnie obowiązujących
norm obronnych);
- stanu
rzeczy (w odniesieniu do zapisów teoretycznych, wyników przeprowadzonych
eksperymentów, uruchomionych i aktualnie sprawdzanych eksploatacyjnie rozwiązań
prototypowych);
- sytuacji
prawnej i ekonomicznej organizacji/firmy/korporacji planującej logistykę
wdrożenia projektowanego/planowanego rozwiązania,
-
przeprowadzonej wcześniej (etap 3 AF) analizy stanu rzeczy w całej jego
rozciągłości (doświadczenia z przeszłości, przewidywania i oczekiwania co do
przyszłości).
Rys. 2.
Bliższe i dalsze uwarunkowania projektu planu bezpieczeństwa informacji
Oczywiste
jest przeniesienie do obszaru objętego przez każdą z nich, wymienionych
wcześniej, wielofazowych czynności przygotowawczych.
3.1.
Koncepcja planu ochrony informacji
Przedstawiony
schemat zależności systemowych planu bezpieczeństwa informacji jest obrazem
działania ukierunkowanego na informacje napływające z zewnątrz, dotyczące
bezpieczeństwa informacji „in corpore".
Budując plan
ochrony informacji w danej firmie/organizacji/korporacji, znajdujemy się w
sytuacji, kiedy to musimy (bazując na posiadanej własnej wiedzy) szczegółowo
odpowiedzieć na kilka zasadniczych pytań, będących podstawą wszelkich naszych
działań praktycznych, czyli określić:
- jaki zasób
informacyjny chronimy?
- jak jest on
podzielony (wg potrzeb, dostępności, zagrożeń)?
- jak i
dlaczego różnicujemy poziomy oraz działy/grupy informacyjne?
- jakie są
realne zagrożenia dla informacji (zasobu, grup lub pojedynczych informacji)?
- jakiego
typu mechanizmy i metody chcemy zastosować w ochronie informacji?
- jakie
przewidujemy metody - sposoby ew. naszego reaktywnego oddziaływania na
ujawnione niebezpieczeństwa dla zasobu informacji (incydenty, zagrożenia i
ataki oraz materializacja różnorodnych rodzajów ryzyk)?
- jakie są
możliwości zabezpieczenia/odtworzenia zasobu krytycznych informacji?
Odpowiedzi na
te pytania można (dla ułatwienia późniejszego wdrożenia) pogrupować i przypisać
jako zadania dla:
- zarządu i
najwyższego kierownictwa firmy/organizacji/korporacji,
- zespołu
sterującego wdrożeniem planu zapewnienia bezpieczeństwa informacji,
- pionu
zapewnienia bezpieczeństwa i ochrony,
- średniego
personelu kierowniczego,
- personelu
technicznego IT,
-
bezpośrednich użytkowników.
3.1.1.
Koncepcja logiczna działania na rzecz ochrony informacji
Logika w
działaniu na rzecz ochrony i zapewnienia bezpieczeństwa informacji prowadzi nas
ścieżką opartą na budowaniu krytycznych ocen na kolejnych poziomach
prowadzonych prac analitycznych.
Łańcuch
skojarzeniowy poprawnych działań jest zbiorem kolejnych, współzależnych ocen
określających i oceniających odpowiednio:
- posiadany zasób
informacyjny,
- preparację
części zasobu wg wagi potrzeb (informacje: krytyczne, bardzo istotne, istotnie
ważne, ważne, ważne dla grupy/komórki organizacyjnej/danego stanowiska pracy),
- potencjalne
zagrożenia dla (całości jak też poszczególnych części) zasobu informacyjnego,
wraz ze skutkami ich (częściowej bądź całościowej) materializacji,
- przyjęte
wielkości akceptowalnych ryzyk szczątkowych,
- możliwości
spełnienia założonych celów ochronnych przeznaczonymi siłami i środkami, czyli
teoretyczną skuteczność zabezpieczenia i trwałość ochrony zasobu,
- poprawność
postępowania użytkowników wobec każdej części, stworzonego dla zasobu
informacji, Katalogu Informacji Chronionych (patrz algorytm [4]/ na rysunku).
Rys. 3.
Algorytm postępowania z informacjami w firmie (przykład)
Logiczną
konsekwencją takiego postępowania jest uwzględnienie (w organizacji ochrony
informacji) odpowiednich zasad inżynierii bezpieczeństwa dla poszczególnych
części zasobu informacyjnego oraz przyjęcie odpowiedniego sposobu zachowania
ciągłości zarządzania zasobem/firmą.
3.1.2.
Zasady inżynierii bezpieczeństwa w zarządzaniu zasobem informacyjnym
We wszystkich
działaniach związanych z inżynierią bezpieczeństwa kierujemy się jedyną główną
zasadą, a mianowicie:
poziom i
zakres ochrony jest adekwatny do ważności zasobu chronionego, a dopiero po
określeniu charakteru zasobu i potrzeb jego potencjalnej dostępności dla
uprawnionych użytkowników stosujemy odpowiednio zasady ochrony (wielopoziomowej
lub wielostronnej)[5]/.
Uproszczone
zrozumienie zagadnienia „ochrona wielopoziomowa" to świadomość, że:
- występuje
ograniczona dostępność „wiedzy potrzebnej",
- przepływ
informacji jest chroniony w układzie „góra - dół",
- granice
kontroli przebiegają poziomo, w praktyce opierają się one na określonych
klauzulach informacji/sekwencji uprawnień i funkcjonują, tworząc poziomy
dostępowe.
Należy przy
tym pamiętać, że modelowe rozwiązania ochrony wielopoziomowej typu:
- polityka
bezpieczeństwa wg Bella-LaPaduli (1973 r.),
- modelowe
podejście Kena Biby (1975 r.),
- koncepcja
MLS systemów operacyjnych [(wersje 1983-88 r.), Blacker 1989 r.]
są nagminnie
obciążane błędami stosowania sztywnych reguł w warunkach korzystania z systemów
IT czasu rzeczywistego.
Rozwiązaniem
pozwalającym na przetwarzanie danych wyłącznie na jednym poziomie, czyli
zachowującym warunek bezpieczeństwa [jednokierunkowy przepływ informacji (dioda
danych)], jest opracowana w US Naval Research Laboratory (NRL) pompa NRL,
pozwalająca na ominięcie zagadnienia „zaufanego oprogramowania" i łącząca
klawiaturę i mysz z systemami „Wysokiego" i „Niskiego" poziomu (np.
australijski produkt „Starlight" [6]/ oraz brytyjska „Purple Penelope" [7]/, która ponadto dodatkowo zabezpiecza
ślad rewizyjny prowadzonego działania a także wyklucza automatyzm w procesie
ew. obniżenia poziomu udostępnionej informacji).
Uproszczone
zrozumienie zagadnienia „ochrona wielostronna" to świadomość, że:
- występuje
warunkowa dostępność „wiedzy potrzebnej",
- przepływ
informacji jest chroniony w układzie „w poprzek",
- granice
kontroli przebiegają pionowo (obejmują działy z bazy informacyjnej, a w
praktyce stosuje się anonimizowanie badawcze dla istotnych baz danych), a
poprzez sterowanie wnioskowaniem tworzone są przedziały dostępowe.
Warto przy
tym przypomnieć, że implementowane rozwiązania ochrony wielostronnej typu:
- modelowe
stosowanie przedziałów dostępowych w środowisku wywiadu,
- „krata
etykiet bezpieczeństwa" (równoważna z modelem Bella-LePaduli),
- „Chiński
Mur", czyli modelowe rozwiązanie praktycznie zapobiegające konfliktom interesów
w obszarze zasobów,
- koncepcja
BMA (British Medical Association) opisująca przepływ informacji dopuszczalny w
warunkach zachowania etyki medycznej są
powszechnie stosowane poza środowiskami, z których się wywodzą, ale nagminne
jest obciążanie ich użycia błędami procedur dostępu, w warunkach stosowania
reguł statystycznych korzystania z tak chronionych systemów. Wprowadzone w
końcówce lat 90. zasady sterowania wnioskowaniem nie zawsze spełniają swoją
rolę w procesie ochrony bezpieczeństwa.
Istnieją
również rozwiązania specyficzne (modele będące kombinacjami ww.) oparte na
ściśle określonych podziałach realizowanych funkcji bezpieczeństwa - przykładem
może tu być niezależne rozdzielenie mechanizmów autentyczności od mechanizmów poufności
w praktyce bankowej (wymogi SWIFT [8]/ - norma ISO 8731 dla algorytmu
uwierzytelnienia).
Granicą
ekonomiczną kosztów (z tym wiąże się opłacalność), stosowanych rozwiązań
inżynierii bezpieczeństwa, jest porównanie wartości utraconej informacji ze zsumowanymi
kosztami zmaterializowania się ryzyka jej utraty wobec kosztów sił i środków
użytych do jej ochrony i eliminacji tegoż ryzyka.
3.1.3.
Zachowanie ciągłości działania w zarządzaniu zasobem informacyjnym
Problematyka
zachowania ciągłości działania wobec posiadanych zasobów informacyjnych w
przypadku sytuacji kryzysowych i katastrof ma decydujący wpływ na utrzymanie
zdolności funkcjonowania firmy/organizacji/korporacji.
Żadna
instytucja nie może skutecznie przeciwdziałać wszystkim zagrożeniom, każda
powinna jednak być zdolna do podtrzymania krytycznych procesów w trakcie
incydentów i do odbudowy pełnej zdolności działania po ich zakończeniu.
Skuteczne
zarządzanie zasobem informacyjnym w warunkach kryzysu wymaga wcześniejszego:
- określenia
listy krytycznych procesów, których ciągłość powinna być utrzymana, oraz
opracowania stosownych planów działania,
-
utrzymywania rezerw sprzętowych, materiałowych i finansowych, uzasadnionych
wynikami analizy ryzyka i analiz koszt/efektywność,
- powołania
sztabu kryzysowego wyposażonego we wszystkie niezbędne pełnomocnictwa i
niezależne środki łączności,
-
utrzymywania kontaktów ze służbami ratunkowymi i grupami reagowania
kryzysowego, powołanymi na szczeblu resortowym lub terytorialnym.
Skuteczna
odbudowa utraconego po katastrofie zasobu informacyjnego wymaga co najmniej:
-
ubezpieczania aktywów informacyjnych i dokumentowania ich należytej ochrony w
celu skutecznego egzekwowania odszkodowań,
- regularnego
wykonywania kopii zapasowych wszystkich danych i przechowywania jednej z nich
poza podstawową lokalizacją,
-
przechowywania aktualnej kopii dokumentacji systemów i planów działania poza
podstawową lokalizacją oraz ich konsekwentnego unowocześniania (stosownie do
wprowadzanych zmian w oryginałach).
Całość działań
związanych z zarządzaniem zasobem informacyjnym dla potrzeb ciągłości
funkcjonowania (BCM, BCP, DRP) stanowi w praktyce proces wsparcia i zachowania
naszego bezpieczeństwa informacyjnego i decyduje o sprawności jego odtworzenia.
3.2.
Podstawy opracowania planu bezpieczeństwa informacji
Bazując na
rozwiązaniach systemowych i uzyskanej wiedzy (etapy 1-5 AF), mamy możliwość
wyboru sposobu podejścia do opracowania planu bezpieczeństwa informacji,
jednakże przy zachowaniu zasad systemowych wskazane jest wykorzystanie wniosków
wynikających z istniejących „dobrych praktyk" [zapisanych w postaci norm (ISO
27001, ISO 27002) oraz metodyk (COBIT, TSM/TISM, COBRA itp.)].
Rekomendowane
jest ustanowienie Systemu Zarządzania Bezpieczeństwem Informacji (SZBI/ISMS) i
opracowanie czytelnych Zasad Zarządzania Bezpieczeństwem Informacji,
obowiązujących w warunkach jego stosowania w firmie/organizacji/korporacji,
wskazane jest także opracowanie Deklaracji Polityki Bezpieczeństwa Informacji
jako wykładni funkcjonowania SZBI, co jest podstawą dla działań ogólnych
(rozwinięcia zamierzeń szkoleniowych i systemowych wobec personelu i klientów,
ew. działań marketingowych).
Rys. 4.
Struktura dokumentacji SZBI (na bazie metodyki TISM) [9]/
Przedstawiona
powyżej struktura dokumentacyjna jest przykładowym rozwiązaniem wykorzystującym
zasady normatywne ISMS (Information Security Management System) dla
przedstawionej poniżej struktury organizacyjnej opartej na regułach metodyki
TSM/TISM [10]/.
Zasada: żadna osoba nie może w tym samym czasie pełnić
funkcji ulokowanych w dwóch różnych pionach funkcjonalnych
Rys. 5.
Struktura organizacyjna przykładowego
SZBI
Istotnym
zastrzeżeniem jest konieczność pamiętania o jednostkowych warunkach przygotowywania
i wdrażania SZBI (nie ma dwu jednakowych organizacji, lokalizacji i grup osób
funkcyjnych) oraz o obowiązujących wymogach formalnych i ustawowych.
3.2.1.
Przymusowe wymogi ustawowe
Przy
opracowywaniu planu bezpieczeństwa informacji oraz planowaniu wszelkich
przedsięwzięć ochronnych w zakresie bezpieczeństwa musimy, stosownie do
usytuowania statutowego naszej organizacji, uwzględnić zewnętrzne i, nie zawsze
korzystne dla nas, narzucone nam obowiązkowe wymagania
(sojusznicze/krajowe/lokalne), które to musimy wdrożyć w naszym SZBI pod
rygorem odpowiedzialności karnej (penalizacja wobec osób kierowniczych,
instytucjonalne obciążenia finansowe).
Źródłem
przymusu w zakresie zobowiązań bezpieczeństwa są zobowiązania i wymagania
wynikające z nw. ustaw:
- o
powszechnym obowiązku obrony,
- o ochronie
informacji niejawnych,
- o ochronie
danych osobowych,
- o ochronie
osób i mienia,
- o
rachunkowości,
- o ochronie
baz danych,
- o stanie
zagrożenia państwa
oraz
związanych z nimi rozporządzeń wykonawczych.
Należy
zwrócić tutaj szczególną uwagę na istniejący przymus uzgadniania planów ochrony
fizycznej z komendami wojewódzkimi Policji (metodyka Biura Prewencji KGP).
W odniesieniu
do szeregu instytucji i organizacji znaczącą rolę odgrywają wymagania Rozporządzeń
UE (przyjętych per se przez RP jako uczestnika Wspólnot Europejskich) oraz
resortowe wymogi wynikające z sojuszy wojskowych (NATO - NSC, NOS, Security
Brand SHAPE oraz UE - EDA, ENISA, RS EUMS).
Poszczególne
dokumenty mogą mieć odniesienia zakresowe do:
- wymagań
współpracy cywilno-wojskowej (CIMIC),
- zobowiązań
zadaniowych kraju-gospodarza (HNS),
- zobowiązań
dla przedsiębiorstw o szczególnym znaczeniu gospodarczo-obronnym (PoSZG-O),
- zobowiązań
zadaniowych w planach mobilizacyjno-obronnych (NWMO),
- zobowiązań
zadaniowych w działaniach kryzysowych (CRKW, MCR, GCR), a w
szczególnych wypadkach mogą odnosić się do imiennych zobowiązań personelu
(świadczenia osobowe i materiałowe na rzecz władz lokalnych).
3.2.2.
Wymagania formalne przyjęte samoistnie
Przy
opracowywaniu planu bezpieczeństwa informacji oraz planowaniu wszelkich
przedsięwzięć ochronnych w zakresie bezpieczeństwa powinniśmy uwzględniać
skutki (normatywne/prawne - kontraktowe) wynikające z przyjętych dobrowolnie
zobowiązań, odnoszących się do bezpieczeństwa deklarowanego przez nas lub nam
powierzonego.
Źródłem prac
uzupełniających w zakresie zobowiązań bezpieczeństwa są działania i wymagania
wynikające, między innymi, z przyjętych dobrowolnie:
- norm
bezpieczeństwa (uzyskane certyfikaty, Świadectwa Stosowania - SoA),
- zasad
statutowych uznanych przez organizację za bezwzględnie wymagane,
- zobowiązań
kontraktowych ochrony informacji strony drugiej,
-
powierzonych do przetwarzania informacji strony trzeciej oraz
związanych z nimi dodatkowych czynności ochronnych.
4.
Wdrażanie ochrony informacji
Opracowane w
ramach wcześniejszych prac rozwiązania planowe (etap 6 -AF), przedstawione
powyżej w postaci struktury organizacyjnej SZBI (rys. 4.) wraz z towarzyszącą
jej dokumentacją systemową (rys. 3.), powinny zostać wdrożone (etap 7 - AF)
celem zmiany istniejącego stanu rzeczy, którego stwierdzone niedoskonałości
stały się przyczyną podjętej analizy funkcjonalnej.
Rozwiązania
organizacyjne są w tym przypadku bardzo różnorodne, jednakże należy pamiętać o
zachowaniu trzech podstawowych wymogów:
- czynnego
zaangażowania Najwyższego Kierownictwa w prowadzone prace wdrożeniowe,
-
zgromadzenia odpowiedniego zasobu finansowego niezbędnego dla pełnej realizacji
zamierzonych prac (szkolenie ludzi, opłaty konsultantów zewnętrznych, koszty
zmian organizacyjnych i uzupełnienia sprzętu),
- dobór
zespołu wdrażającego zmiany (wskazane jest typowanie poszczególnych osób jako
funkcyjnych przyszłego SZBI).
4.1.
Podstawy wdrożenia planu
Rekomendowaną
podstawą jest przyjęcie wymagań normy PN-ISO/IEC 27001:2007, co znacząco
upraszcza wszystkie czynności wdrożeniowe i eksploatacyjne SZBI (patrz rys.
6.).
Rys. 6.
Schemat wdrożenia, eksploatacji, monitorowania i doskonalenia SZBI [11]/
Przedstawiony
schemat wiąże elementy analizy ryzyka z zarządzaniem bezpieczeństwem.
4.2.
Zmiany zaistniałego stanu rzeczy
Uzyskanie
pełnego wdrożenia SZBI wymaga świadomej determinacji ze strony kierownictwa,
ponadto szerokiej akcji szkoleniowej dla personelu (szczególnie średniego poziomu
kierowniczego i technicznego) oraz wykazania różnych korzyści na stanowiskach
pracowniczych/wykonawczych.
Warto wskazać
pozytywy wdrażanych zmian w odniesieniu do:
- pozycji
firmy na rynku,
- korzyści
finansowych w perspektywie działań,
- podwyższenia
świadomości bezpieczeństwa całego personelu.
Należy liczyć
się z „oporami organizacyjnymi" (przysłowiowe ...dobre jest wrogiem lepszego)
oraz z wątpliwościami wynikającymi z przeniesienia i zmian obowiązków (zbyt
rygorystyczne wymogi ochrony informacji ograniczają jej przepływ i mogą
doprowadzić do świadomego lub przypadkowego „zatoru informacyjnego"
uniemożliwiającego podjęcie na czas prawidłowych i niezbędnych decyzji.
5.
Wnioski końcowe
Przeprowadzona
analiza funkcjonalna pokazała zakres i sposób możliwych do przeprowadzenia
zmian w istniejącym stanie rzeczy. Rezultatem ich prawidłowego wdrożenia będzie
nowy jakościowo i sprawniejszy organizacyjnie system - SZBI, pozwalający w
sposób świadomy i skuteczny chronić zasoby informacyjne. Wszystko, jednak, zależy
od decydentów (siły, środki, finanse, czas i sposób wdrożenia) oraz personelu
(zrozumienie potrzeb i identyfikowanie się z celami).
Przedstawione
narzędzie badawcze - AF ma za zadanie pomóc w rozwiązywaniu problemu, a
pokazane elementy rozwiązań pełnią rolę przykładową, w każdym bowiem
jednostkowym przypadku postępowanie analityczne będzie dawało różniące się
wyniki, trudno więc jest uznać je za wzorzec, choć pozwala ono dojść do
wzorcowego rozwiązania (dla danej firmy, tu i teraz). Potem pozostaje nam tylko
powielać cyklicznie zrealizowane działania (rys. 7.).
Rys. 7.
Uproszczony cykl zarządzania wdrożonym bezpieczeństwem
6.
Kilka refleksji z praktyki
Dotychczasowe
doświadczenie autora wskazuje na konieczność zachowania przez menedżerów
procesów szczególnej ostrożności wobec wszelkich teoretycznie gotowych
rozwiązań (bezmyślne implementacje „gotowców", przeniesionych z innej
firmy/organizacji/korporacji, generują wielokrotnie wyższe koszty wdrożenia i
późniejszego poprawiania/dopasowywania).
Można jednak
warto korzystać z rozwiązań szkieletowych, ułatwiają one bowiem uświadamianie
wagi problemu i wskazują na jego cechy charakterystyczne, a poprzez wymuszanie
opracowania zmian we własnych strukturach przyczyniają się do przygotowania
poprawnej i użytecznej dokumentacji systemowej.
Co warto
pamiętać i stosować... na co dzień.
Marek Blim
Zabezpieczenia 5/2007
Bibliografia
A.
Dokumenty międzynarodowe:
1.
Decyzja Rady nr 2001/264/WE z dnia 19 marca 2001 r. w sprawie przyjęcia
przepisów Rady dotyczących bezpieczeństwa (Dz. U. WE L 317 z dnia 3 grudnia
2001 r. str.1). Załącznik: Przepisy Rady Unii Europejskiej dotyczące
bezpieczeństwa. (tekst polski dostępny pod adresem:
http:
//eurlex.europa.eu/LexUriServ/site/pl/dd//01/03/32001D0264PL.pdf)
2.
Wytyczne OECD w zakresie bezpieczeństwa systemów i sieci informatycznych: W
kierunku kultury bezpieczeństwa. - nieoficjalne polskie tłumaczenie publikacji
OECD dostępne pod adresem: http://www.oecd.org/dataoecd/16/3/15582300.pdf.
B.
Dokumenty krajowe:
1.
Ustawa z dnia 29 września 1994 r. o rachunkowości (Dz. U. z 1994 r. nr 121 poz.
591, tekst jednolity - Dz. U. z 2002 r. nr 76 poz. 694 z późn. zmianami: Dz. U.
z 2003 r. nr 60 poz. 535, nr 124 poz. 1152, nr 139 poz. 1324, nr 229 poz. 2276,
z 2004 r. nr 96 poz. 959, nr 145 poz. 1535, nr 146 poz. 1546, nr 213 poz. 2155,
z 2005 r. nr 10 poz. 66, nr 184 poz. 1539, nr 267 poz. 2252, z 2006 r. nr 157
poz. 1119, nr 208 poz. 1540).
2.
Ustawa z dnia 22 sierpnia 1997 r. o ochronie osób i mienia (Dz. U. z 1997 r. nr
114, poz. 740, tekst jednolity - Dz. U. z 2005 r. nr 145, poz. 1221 z późn.
zmianami: Dz. U. z 2006 r. nr 104, poz. 708).
3.
Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 1997 r.
nr 133 poz. 883, tekst jednolity - Dz. U. z 2002 r. nr 101, poz. 926 z późn.
zmianami: Dz. U. z 2002 r. nr 153 poz. 1271, z 2004 r. nr 25 poz. 219, nr 33
poz. 285, z 2006 r. nr 104 poz. 708 i 711).
4.
Ustawa z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych (Dz. U. z
1999 r. nr 11 poz. 95, tekst jednolity - Dz. U. z 2005 r. nr 196 poz. 1631 z
późn. zmianami: Dz. U. z 2006 r. nr 104 poz. 708 i 711, nr 149 poz. 1078, nr
218 poz. 1592, nr 220 poz. 1600, z 2007 r. nr 25 poz. 162).
5.
Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz. U. z 2001 r nr 128
poz. 1402 z późn. zmianami: Dz. U. z 2004 r. nr 96 poz. 959).
6.
Ustawa z dnia 17 lutego 2005 r. o informatyzacji podmiotów realizujących
zadania publiczne (Dz. U. z 2005 r. nr 64 poz. 565 z późn. zmianami: Dz. U. z
2006 r. nr 12 poz.65, nr 73 poz. 501).
7.
Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie
minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2005 r. nr 212
poz. 1766).
8.
Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie
minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie
elektronicznej (Dz. U. z 2005 r. nr 212 poz. 1766).
C.
Literatura tematu:
1.
Anderson S.: Inżynieria zabezpieczeń, seria TAO, WNT, Warszawa 2005
2.
Białas A.: Bezpieczeństwo informacji i usług w nowoczesnej instytucji i firmie,
WNT, Warszawa 2006
3.
Drogoń W., Mąka D., Skawina M.: Jak chronić tajemnice? Ochrona informacji w
instytucjach państwowych i przedsiębiorstwach prywatnych, Dom Wydawniczy
BELLONA, Warszawa 2004
4.
Gałach A.: Instrukcja zarządzania bezpieczeństwem systemu informatycznego,
Ośrodek Doradztwa i Doskonalenia Kadr Sp. z o.o., Gdańsk 2004
5.
Gałach A.: Zarządzanie bezpieczeństwem systemu informatycznego - uniwersalna
lista kontrolna, Ośrodek Doradztwa i Doskonalenia Kadr Sp. z o.o., Gdańsk 2005
6.
Molski M., Łacheta M.: Przewodnik audytora systemów informatycznych,
Wydawnictwo HELION, Gliwice 2007
7.
Noonan W.J.: Ochrona infrastruktury sieciowej, Wydawnictwo „Edition 2000",
Kraków 2004
8.
Pipkin D.L.: Bezpieczeństwo informacji. Ochrona globalnego przedsiębiorstwa,
WNT, Warszawa 2002
9.
Polaczek T.: Audyt bezpieczeństwa informacji w praktyce, Wydawnictwo HELION,
Gliwice 2006
10.
Polok M.: Ochrona tajemnicy państwowej i tajemnicy służbowej w polskim systemie
prawnym, Wydawnictwo Prawnicze LexisNexis, Warszawa 2006
11.
Serewa M.: Koncepcja wdrożenia systemów zarządzania ryzykiem i bezpieczeństwem
informacji w jednostce administracji
publicznej, IOSP WIP PW Warszawa, 2007
12.
Sutton R.J.: Bezpieczeństwo telekomunikacji. Praktyka i zarządzanie, WKŁ,
Warszawa 2004
13.
Taradejna R, Taradejna M.: Ochrona informacji w działalności gospodarczej,
społecznej i zawodowej oraz w życiu prywatnym, PIKW, Warszawa 2004
14.
Wygoda K., Jabłoński M.: Dostęp do informacji i jego granice, Wydawnictwo
Uniwersytetu Wrocławskiego, Wrocław 2002
15.
Yourdon E.: Wojny na bity. Wpływ wydarzeń z 11 września na technikę
informacyjną, seria TAO, WNT, Warszawa 2004
D.
Strony internetowe związane z bezpieczeństwem informacji (wybór autora):
www.altkom.pl
www.bsi-poland.com
www.cert.pl
www.clico.pl
www.codo.pl
www.cso.cxo.pl
www.ctpartners.pl
www.ensi.pl
www.egov.pl
www.exegroup.pl
www.iar.wat.waw.pl
www.isaca.org.pl
www.isect.com
www.isokonsultant.com
www.issa.org
www.itti.com.pl
www.kerberos.pl
www.level3.com.pl
www.mswia.gov.pl
www.nbp.pl
www.secure.edu.pl
www.techom.com
www.tuv-nord.pl
www.zabezpieczenia.com.pl
[1]/autorstwo tej maksymy przypisywane jest Konfucjuszowi /551-479 p.n.e./,
wielkiemu myślicielowi i filozofowi chińskiemu, /patrz zapisy: Księga przemian
- Lhotse; Dialogi konfucjańskie - Lynyu/
[2]/Pipkin D.L. „Bezpieczeństwo informacji. Ochrona globalnego przedsiębiorstwa",
seria TAO, wyd. WNT, Warszawa 2002, s.15-21
[3]/za: dr n. praw. St. Małecki, „Nieprawidłowości OIN stwierdzone w
kontrolach za 2004 r.", mat. BOIN MON, Warszawa 2005
[4]/za: dr inż. A. Wójcik „Postępowanie z zasobami informacyjnymi w firmie",
materiały szkoleniowe ES INSTAL, Warszawa 2006
[5]/R. Anderson „Inżynieria zabezpieczeń", seria TAO, wyd. WNT, Warszawa
2002, s.161-218
[6]/patrz: „Starlight: Interactive Link", sprawozdanie 12 Konferencji
Bezpieczeństwa Aplikacji Komputerowych, IEEE, 1996, s.55-63
[7]/patrz: „Purple Penelope" - materiały Defense Evaluation&Research
Agency UK (stosowanie w praktyce teorii „zawiniątka" - ang. wrappers, do ochrony informacji
pochodzącej z zasobów wrażliwych), „Security Systems", DERA UK 1996
[8]/SWIFT - Society for Worldwide Interbank Financial Telecommunication (Stowarzyszenie na Rzecz Światowej Międzybankowej
Telekomunikacji Finansowej)
[9]/za: M. Serewa, „Koncepcja
wdrożenia systemów zarządzania ryzykiem i bezpieczeństwem informacji w
jednostce administracji publicznej", IOSP WIP PW Warszawa, 2007
[10]/za: M. Serewa, „Koncepcja
wdrożenia systemów zarządzania ryzykiem i bezpieczeństwem informacji w
jednostce administracji publicznej", IOSP WIP PW Warszawa, 2007
[11] / za: M. Serewa, „Koncepcja
wdrożenia systemów zarządzania ryzykiem i bezpieczeństwem informacji w
jednostce administracji publicznej", IOSP WIP PW Warszawa, 2007
|