System Zarządzania Bezpieczeństwem Informacji zgodny z ISO/IEC 27001 (cz. 2)

Artykuł ten jest kontynuacją cyklu poświęconego zarządzaniu bezpieczeństwem informacji zgodnemu z normą ISO/IEC 27001. W kolejnych częściach zostaną omówione elementy Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) oraz jeden z modeli zarządzania bezpieczeństwem systemów informatycznych (PDCA).

1. Wprowadzenie

Zarządzanie bezpieczeństwem systemów informatycznych oznacza ciągły proces składający się z pewnej liczby innych procesów (subprocesów). Dla celów jednoznacznego i przejrzystego zaprezentowania w tym rozdziale zagadnień z tym związanych określono definicję terminu proces. I tak, zgodnie ze słownikami języka polskiego: proces oznacza przebieg następujących po sobie i powiązanychprzyczynowo określonych zmian, stanowiących stadia, fazy, etapy rozwoju czegoś; przebieg, rozwijanie się, przeobrażanie się czegoś.

Zgodnie z normą PN-I-13335-1:1999 do najistotniejszych procesów wchodzących w skład procesu zarządzania bezpieczeństwem
systemów informatycznych można zaliczyć:

• zarządzanie konfiguracją,
• zarządzanie zmianami,
• zarządzanie ryzykiem.

Na rysunku nr 1¹ przedstawiono proces zarządzania bezpieczeństwem systemów informatycznych z uwzględnieniem tworzących go procesów.

2. Zarządzanie konfiguracją

Zarządzanie konfiguracją jest procesem weryfikacji zmian w systemie. Podstawowym celem bezpieczeństwa w tym zakresie
jest wiedza i świadomość wprowadzonych zmian. Zarządzanie konfiguracją ma gwarantować:

• wprowadzanie zmian, które nie obniżą efektywności funkcjonowania systemu, skuteczności mechanizmów zabezpieczających oraz ogólnego bezpieczeństwa organizacji,
• wprowadzanie stosownych zmian dotyczących planowania ciągłości działania i odtwarzania po awarii.

Proces zarządzania konfiguracją nie dotyczy tylko zmian konfiguracji, lecz obejmuje również:

• weryfikację legalności oprogramowania,
• sprawdzenie mechanizmów kontrolnych przechowywania oprogramowania,
• inwentaryzację zasobów organizacji.

W tym obszarze audytor powinien zweryfikować m.in.:

• istnienie procedur gwarantujących, że w rejestrze zasobów wskazane są wyłącznie istniejące i autoryzowane składniki konfiguracji,
• stosowanie procedur zapewniających rejestrowanie wszelkich zmian konfiguracji,
• aktualność, spójność i kompletność rejestru konfiguracji,
• istnienie konfiguracji wzorcowej, czyli punktu kontrolnego używanego do ewentualnego powrotu po zmianach,
• stosowanie oprogramowania antywirusowego,
• stosowanie procedur zabraniających używania własnego i nielicencjonowanego oprogramowania,
• istnienie polityki zarządzania wersjami,
• stosowanie procedur sprawdzania legalności oprogramowania.

3. Zarządzanie zmianami

Zarządzanie zmianami polega na identyfikowaniu nowych wymagań w zakresie bezpieczeństwa, gdy wprowadzane są zmiany w systemie informatycznym.

Szybki rozwój usług i technologii, a także ciągłe pojawianie się nowych zagrożeń oraz podatności sprawia, że systemy informatyczne podlegają nieustannym zmianom. Mogą one dotyczyć:

• nowych procedur i funkcji systemu,
• aktualizacji oprogramowania, zmian sprzętowych,
• pojawienia się nowych użytkowników,
• wprowadzenia dodatkowych połączeń sieciowych i międzysieciowych.

Każda planowana zmiana w systemie informatycznym powinna być poddana analizie pod kątem jej wpływu na bezpieczeństwo, z uwzględnieniem związanych z nią rodzajów ryzyka oraz potencjalnych zysków i kosztów.

W przypadku niewielkich zmian pełna analiza ryzyka nie jest wymagana i może być przeprowadzana w trakcie spotkania
roboczego. Wszelkie ustalenia powinny być jednak odpowiednio udokumentowane. Poważne zmiany w systemie wymagają dokładnej oceny ryzyka w celu określenia nowych wymagań bezpieczeństwa.

W tym obszarze audytor powinien zweryfikować m.in.:

• istnienie procedur wprowadzania zmian w infrastrukturze informatycznej,
• sposób definiowania wymagań funkcjonalnych dla nowych lub modyfikowanych komponentów,
• istnienie wymagań w zakresie mechanizmów bezpieczeństwa, które muszą posiadać nowe lub modyfikowane komponenty,
• istnienie metod sprawdzania stosowania wymaganych mechanizmów bezpieczeństwa w odniesieniu do nowych lub modyfikowanych komponentów,
• sposób analizowania zgodności nowych komponentów z pozostałymi elementami systemu informatycznego,
• istnienie szczegółowego planu wprowadzania zmian,
• sposób planowania infrastruktury informatycznej w organizacji.

Skuteczny proces zarządzania zmianami zapewnia spójność infrastruktury informatycznej, odpowiedni poziom bezpieczeństwa informacji przy projektowaniu nowych rozwiązań oraz wdrożenie komponentów o wysokiej jakości.

4. Zarządzanie ryzykiem

Zarządzanie ryzykiem to proces szacowania ryzyka mający na celu ograniczenie go do akceptowalnego poziomu. Formalny proces zarządzania ryzykiem musi być włączony w planowanie, nabywanie, rozwój, testowanie i działania służące odpowiedniemu rozmieszczeniu systemów informatycznych.

Zgodnie z PN-I-13335-1:1999 – zarządzanie ryzykiem to całkowity proces identyfikacji, kontrolowania i eliminacji lub minimalizowania prawdopodobieństwa zaistnienia niepewnych zdarzeń, które mogą mieć wpływ na zasoby systemu informatycznego.

Efektywny program zarządzania ryzykiem powinien zapewniać osiągnięcie celów biznesowych organizacji przez:

• skuteczniejsze zabezpieczenie systemów informatycznych,które służą do przechowywania, przetwarzania i przesyłania informacji należących do organizacji,
• umożliwienie kierownictwu uzasadnienia swych decyzji dotyczących wydatków na zarządzanie ryzykiem zaplanowanych w budżecie.

Rys. 2.  Wcześniejsze podejście do zarządzania ryzykiem²

Program zarządzania ryzykiem powinien mieć cel zdefiniowany przez dyrektora jednostki. Powinny zostać zdefiniowane także cele szczegółowe, np. ograniczenie kosztów ponoszonych na ubezpieczenie. Skuteczne opracowanie, wdrożenie, utrzymanie i doskonalenie procesu zarządzania ryzykiem wymaga powołania specjalnego komitetu oraz zespołu wykonawczego, a także wsparcia ze strony kierownictwa w zakresie identyfikacji obszarów ryzyka i rozwoju strategii postępowania z ryzykiem.

„Stary model” (wcześniejszy) zarządzania ryzykiem został przedstawiony na rys. 2. W ramach „starego modelu” zarządzania ryzykiem można wyróżnić dwa procesy główne:

• szacowanie ryzyka,
• ograniczanie ryzyka.

Szacowanie ryzyka obejmuje:

1. zidentyfikowanie i określenie wartości aktywów organizacji – można wykorzystać tu metodę jakościową lub ilościową (patrz tab. 1),
2. zidentyfikowanie zagrożeń i określenie prawdopodobieństwa ich wystąpienia,
3. analizę ryzyka – ocenę podatności systemów lub aktywów na wystąpienie czynników ryzyka (czynniki ryzyka sprzyjające wystąpieniu strat).

Tab. 1. Przykładowe porównanie metody jakościowej i ilościowej szacowania wartości aktywów

Poniżej przedstawione zostały dwa modele zarządzania ryzykiem, tzw. „stary model”, bazujący na wcześniejszych normach, oraz „model nowy” (Rys. 3), opracowany na podstawie metodologii ISO/IEC 27001.

Na ograniczanie ryzyka składają się następujące działania:

• wybór odpowiednich mechanizmów zabezpieczeń,
• wdrożenie, testowanie i monitorowanie mechanizmów zabezpieczeń,
• akceptacja ryzyka szczątkowego.

Ryzyko szczątkowe (residual risk) to ryzyko, które pozostaje po wprowadzeniu mechanizmów zabezpieczających.

Proces szacowania ryzyka obejmuje identyfikację informacji lub aktywów informatycznych, które są podatne (wrażliwe) na naruszenie bezpieczeństwa.

Przykładowe aktywa informatyczne to:

• oprogramowanie i sprzęt komputerowy,
• zasoby informacyjne,
• usługi,
• dokumenty organizacji,
• pracownicy,
• zasoby intelektualne,
• spis inwentarza,
• środki finansowe,
• budynki, wyposażenie itp.

  Rys. 3. Nowy model zarządzania ryzykiem

Kolejnym etapem procesu szacowania ryzyka jest zdefiniowanie zagrożeń związanych ze wskazanymi w poprzedniej fazie aktywami oraz określenie prawdopodobieństwa wystąpienia podatności.

Podatność oznacza słabość mechanizmów kontroli wewnętrznej, która może być wykorzystana do uzyskania nieautoryzowanego dostępu do systemu lub zakłócenia jego pracy.

Zagrożenie oznacza niebezpieczeństwo dla systemów informatycznych, podwyższające prawdopodobieństwo poniesienia strat.

Rezultatem wykorzystania podatności przez zagrożenie jest następstwo (np. strata aktywów informatycznych). Następstwo może mieć charakter ilościowy (bezpośrednia strata pieniędzy, niewykorzystanie możliwości, zakłócenie) lub jakościowy (naruszenie prawa, zniszczenie reputacji, odejście załogi) oraz może oznaczać pośrednie lub bezpośrednie straty dla organizacji.

Po zidentyfikowaniu aktywów, zagrożeń i podatności organizacja musi określić akceptowalny poziom ryzyka. Dla wszystkich nieakceptowanych rodzajów ryzyka audytor powinien wskazać i ocenić istniejące mechanizmy kontrolne. Weryfikacja ta wskazuje, czy konieczne jest wdrożenie dodatkowych środków zabezpieczających w celu zredukowania ryzyka lub ograniczenia ryzyka szczątkowego.

Po wdrożeniu mechanizmów kontrolnych w jednostce zawsze pozostaje pewne ryzyko szczątkowe. Kierownictwo może  ykorzystać je do określenia obszarów wymagających dodatkowych mechanizmów kontrolnych. Akceptacja ryzyka szczątkowego zależy od polityki organizacji, planu zarządzania ryzykiem oraz efektywności kosztowej wdrożenia dodatkowych mechanizmów kontrolnych.

Obecnie funkcjonuje również nowe podejście do zarządzania ryzykiem; szczegóły tego podejścia przedstawione zostały na  rysunku 3³ .

W nowym modelu celem procesu zarządzania ryzykiem jest ograniczenie ryzyka do akceptowalnego poziomu przez opracowanie odpowiedniego planu postępowania z ryzykiem. W modelu tym istotną sprawą jest również to, że działania (monitoring, przeglądy) są efektywne, jeśli wykonywane są w sposób ciągły i systematyczny.

W celu lepszego wyjaśnienia zasad regulujących efektywne zarządzanie ryzykiem warto wskazać wzajemne relacje między elementami bezpieczeństwa związanymi z tym procesem (Rys. 4).

5. Identyfikacja ryzyka

Istnieje wiele metod wskazywania ryzyka. Wybór odpowiedniej techniki zależy od charakteru badanego obszaru, a także obszaru dotyczącego zarządzania ryzykiem, tj. systemu bezpieczeństwa informacji. Do istotnych narzędzi identyfikujących ryzyko można zaliczyć:

• analizę środowiskową – ocenę wpływu zmian środowiska zewnętrznego na procesy zarządzania i kontroli w organizacji,
• scenariusze zagrożeń – symulowanie awarii i słabości systemu kontroli wewnętrznej,
• analizę potencjalnych strat – ocenę z punktu widzenia zasobów organizacji,
• identyfikację systemową – ocenę wpływów wszystkich możliwych do zidentyfikowania czynników ryzyka.

Do popularnych wśród profesjonalistów narzędzi analizy ryzyka należą:

1. CRAMM (CCTA Risk Analysis and Management Method) – metoda realizująca wymagania norm poprzez analizę luk i opracowywanie programu poprawy bezpieczeństwa, tworzenie rejestru zasobów informacji, definiowanie zakresu zarządzania bezpieczeństwem informacji oraz poprzez tworzenie dokumentacji wdrożonych środków zaradczych.
2. COBRA (Control Objectives for Risk Analysis) – pełna metodyka analizy ryzyka, zaprojektowana dla zarządu i kierownictwa  rganizacji do całościowej oceny profilu ryzyka związanego z prowadzoną działalnością, ze szczególnym uwzględnieniem bezpieczeństwa wizerunku jednostki, zgodności z obowiązującymi regulacjami prawnymi i ustawodawczymi, oraz do wewnętrznych mechanizmów kontrolnych.
3. MARION (Mission Analysis and Risk Impact on Operations Net-work-tool).
4. MEHARI (Methode Harmonisee d’Analyse de Risques) – realizuje zalecenia norm BS 7799 i ISO/IEC 13335 przy użyciu jednolitego systemu oszacowania ryzyka, prawidłowo dobranych zabezpieczeń i lokalizacji zasobów.
5. EBIOS (Expression des Besoins et Identification des Objectifs de Securite) – to nie tylko metoda szacowania ryzyka, lecz również narzędzie wspomagające zarząd (służące do określania wymagań, definiowania zakresu badania). W powiązaniu z Common Criteria oraz ciągłym rozwojem w zakresie zarządzania bezpieczeństwem informacji (seria ISO 27000) EBIOS staje się techniką całościowego zarządzania ryzykiem.

dr inż. Andrzej Wójcik

1. na podstawie M. Molski, M. Łacheta, Przewodnik audytora systemów informatycznych.
2. na podstawie M. Molski, M. Łacheta, Przewodnik audytora systemów informatycznych.
3. na podstawie M. Molski, M. Łacheta, Przewodnik audytora systemów informatycznych.

Zabezpieczenia 3/4/2008