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)
[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