LDáDQ LH 1 LH SR* G DQ H zdarzenia -...

4 listopada

2009 AUDY SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, [email protected] 1

1. Zarządzanie ryzykiem

Przedstawione dotychczas informacje o zagrożeniach związanych z elementami

środowiska informatycznego pozwalają stwierdzić, że w celu zapewnienia bezpieczeństwa

tego środowiska, wymagane jest precyzyjne podejście do procesu zarządzania ryzykiem,

które poprzedza tworzenie polityki bezpieczeństwa informacji.

Problematyka kontrolowania ryzyka sięga czasów, w których zauważono, iż zdarzenia

przyszłe są przewidywalne i wynikają ze zdarzeń przeszłych. „Obecne zdarzenia wynikają ze

zdarzeń przeszłych. Wynika to z podstawowej zasady, zgodnie z którą żadne zdarzenie nie

może istnieć bez przyczyny[…] Wszystkie zdarzenia podlegają prawom natury, wliczając w

to nawet te, które ze względu na swoje znikome znaczenie pozornie nie są ich wynikiem”1.

Znajomość ryzyka stanowi podstawę podejmowania decyzji.

W codziennym życiu pojęcie ryzyka występuje w wielu znaczeniach. Bazowa

definicja ujmuje ryzyko jako „przedsięwzięcie, którego wynik jest nieznany, niepewny,

problematyczny bądź możliwość, że coś się uda bądź nie uda”2. Ogólny model ryzyka

przedstawia rysunek 1.

Rysunek 1. Ogólny model ryzyka

DziałanieNiepożądane

zdarzenia

K1

K2

K3

C1

C2

C3

KONSEKWENCJE STRATY(KOSZTY)

.

.

.

.

.

.

Źródło: Aven T., Reliability and Risk Analysis, Elsevier Applied Science, London & New York 1992, s. 7 w

Idzikowska G., Wiarygodność danych a bezpieczeństwo zasobów w środowisku informatycznym

rachunkowości, Wyd. UŁ. Łódź 2002, s. 170.

Rozważania na temat zarządzania ryzykiem sprowadzają się do operowania czterema

parametrami, do których zalicza się3:

zagrożenia związane z dostępnymi alternatywami,

wpływ zagrożeń na osiąganie zamierzonych celów,

prawdopodobieństwo realizacji zagrożeń - czyli liczba określająca możliwość

wystąpienia danego zdarzenia; oczywistym jest, iż im mniejsze

1 Pierre Simone Laplace, Theorie analitique des probabilites w Forystek M., Audyt informatyczny, InfoAudit,

Warszawa 2005, s.10. 2 Słownik wyrazów obcych, PWN, Warszawa 1992, s. 660.

3 Forystek M., op.cit., s. 11.

4 listopada



prawdopodobieństwo, tym mniejsza szansa wystąpienia zdarzenia i odwrotnie;

warunkiem koniecznym do możliwie wiarygodnej oceny prawdopodobieństwa

wystąpienia danego zdarzenia jest posiadanie dokładnej informacji o częstości

jego zachodzenia,

poziom akceptowalnego ryzyka.

Wpływ(konsekwencje) zdefiniowanego wcześniej zagrożenia na osiągnięcie

zaplanowanych celów jest istotnym parametrem w aspekcie procesu zarządzania ryzykiem. W

literaturze przedmiotu brak jest jednoznacznej definicji wpływu zagrożenia. Często pod tym

pojęciem rozumie się potencjalną stratę(ang. exposure) rozumianą jako rezultat

zmaterializowania się ryzyka, jeśli jego skutki są istotne4. Na przykład w aspekcie

zarządzania projektem spotyka się pięć kategorii określających wpływ zagrożenia5:

katastrofalne, poważne, znaczące, marginalne, nieistotne oraz sześć stopni określających

prawdopodobieństwo wystąpienia danego zdarzenia: bardzo prawdopodobne,

prawdopodobne, dość prawdopodobne, mało prawdopodobne, bardzo mało prawdopodobne,

niezwykle mało prawdopodobne. Tabela 1 pokazuje wymagane działania uzależnione od

określonego wpływu ryzyka na możliwość realizacji zamierzonego celu.

Tabela 1. Wymagane działanie w zależności od wpływu ryzyka na możliwość realizacji

zamierzonego celu Wpływ ryzyka Wymagane działanie

Nie do przyjęcia Należy wyeliminować lub przenieść ryzyko(np. na ubezpieczyciela).

Niepożądany Należy podjąć próbę uniknięcia lub przeniesienia ryzyka

Do przyjęcia Należy utrzymać ryzyko na tym poziomie i próbować nim kierować

Nieistotny Można pominąć ryzyko

Źródło: RAMP – Risk Analysis and Management of Projects, Institute of Civil Engineers and Institute of

Actuaries, 1998 w Chong.Y.Y., Brown E.M., Zarządzanie ryzykiem projektu, Oficyna Ekonomiczna, Kraków

2001, s. 27.

Pojęciem, które ma fundamentalne znaczenie w analizie ryzyka, jest pojęcie istotności,

definiowane przez K.Czerwińskiego6 jako iloczyn prawdopodobieństwa wystąpienia danego

zdarzenia oraz jego wpływu na organizację. Istotność jest miarą7:

4 Czerwiński.K., Analiza ryzyka w audycie wewnętrznym, Wydawnictwo Link, Szczecin 2003, s.12, 14. Autor

dokonuje również próby zdefiniowania wpływu – wyliczony(na ogół w wartościach pieniężnych) efekt zajścia

zdarzenia. 5 RAMP – Risk Analysis and Management of Projects, Institute of Civil Engineers and Institute of Actuaries,

1998 w Chong.Y.Y., Brown E.M., Zarządzanie ryzykiem projektu, Oficyna Ekonomiczna, Kraków 2001, s. 26. 6 Czerwiński.K., op.cit., s. 14-15.

7 Inne znaczenie ma istotność w audycie finansowym, a inne w operacyjnym czy IT. Różnice w poszczególnych

rodzajach audytów zostaną wyjaśnione w następnym rozdziale. Również wtedy zostanie omówiona istotność w

aspekcie audytu informatycznego.

4 listopada



możliwych bezpośrednich i pośrednich konsekwencji finansowych w przypadku

zajścia zdarzenia(w tym kosztów działań naprawczych);

znaczenia poszczególnych celów realizowanych przez organizację(skutkiem zajścia

zdarzenia jest niezrealizowanie tych celów; znaczenie powinno być, o ile to możliwe,

wymierne w zł);

strat, które nie mają wymiaru finansowego, np. utrata dobrego imienia(reputacji).

Ze względu na problematykę poruszaną w pracy konieczne jest zdefiniowane ryzyka

w aspekcie informatycznym. Najczęściej wykorzystywaną i powszechnie znaną definicją

ryzyka w tym kontekście jest definicja przyjęta przez ISO8, która mówi, że ryzyko

informatyczne oznacza prawdopodobieństwo, iż określone zagrożenie może wykorzystać

słabości zasobów lub grup zasobów powodując ich utratę lub zniszczenie.

Zarządzanie ryzykiem(ang. Risk Management) w kontekście technologii

informatycznej jest procesem umożliwiającym menadżerom balansowanie pomiędzy

operacyjnymi a ekonomicznymi kosztami operacji zabezpieczających osiągnięcie

zamierzonych celów poprzez ochronę systemów IT, jak i informacji stanowiących kluczowy

zasób organizacji. Innymi słowy, zarządzanie ryzykiem jest procesem, w ramach którego

dokonywana jest ciągła ocena istniejących zagrożeń i słabości posiadanych zasobów i

procesów, np. informatycznych, wykorzystywanych do osiągnięcia zamierzonego wcześniej

celu. Jednocześnie zarządzanie ryzykiem określa pośrednio mechanizmy kontrolne,

wykorzystywane do kontrolowanie ryzyka, tj. utrzymywania go na określonym wcześniej,

akceptowalnym poziomie. COBIT9 definiuje zarządzanie ryzykiem jako reagowanie na

zagrożenia przez ograniczanie złożoności, wzrost obiektywności oraz rozpoznanie ważnych

czynników w celu zmniejszenia ryzyka. Definicja ta obejmuje odpowiedzialność za

zarządzanie ryzykiem, różne rodzaje ryzyka IT (technologiczne, bezpieczeństwa, zachowania

ciągłości, regulacyjne itd.) oraz zdefiniowane i przedstawione profile tolerancji ryzyka.

Ponadto, definicja uwzględnia ilościowy i/lub jakościowy pomiar ryzyka, metodykę

szacowania ryzyka, personel, plan działań związany z ryzykiem, ponowne szacowanie

ryzyka, wykonywane we właściwym czasie.

Proces zarządzania ryzykiem jest procesem wszechobecnym w każdej dziedzinie życia

ludzkiego i nie jest wyjątkowy dla problematyki środowiska informatycznego. Związki

8 ISO, International Organization for Standardization [cit. 2005-04-10], http://www.iso.org Guidelines for the

Management of IT Security. 9 Korytowski J., Praktyki kontrolne w zakresie zarządzania ryzykiem, Repozytorium wiedzy ISACA Polska,

http://www.isaca.org.pl/PIR_INDEX.htm [cit.2005-10-20].

http://www.iso.org/

http://www.isaca.org.pl/PIR_INDEX.htm

4 listopada



zachodzące w procesie zarządzania ryzykiem pomiędzy elementami biorącymi w nim udział

prezentuje rysunek 2.

Rysunek 2. Związki w procesie zarządzania ryzykiem

Źródło: Opracowanie własne.

W całym procesie zarządzania ryzykiem istotna jest znajomość zarówno samego ryzyka, jak i

środków zapobiegawczych umożliwiających utrzymywanie go poniżej akceptowalnego

poziomu. Dlatego też należy określić jasno cele, jakie stawia sobie organizacja do osiągnięcia,

oraz grupę osób odpowiedzialną za analizę zagrożeń, które mogą destrukcyjnie wpłynąć na

możliwość osiągnięcia tych celów. Odpowiedzialność za zarządzanie ryzykiem zawsze

ponosi kadra zarządzająca jednostką, najczęściej zarząd. Tabela 2 prezentuje poszczególnych

uczestników procesu zarządzania ryzykiem wraz z odpowiedzialnością im przypisaną.

Tabela 2. Uczestnicy procesu zarządzania ryzykiem oraz ich odpowiedzialność

Rola Odpowiedzialność Właściciel

Określa wartość zasobów gospodarczych.

Grupa odpowiedzialna za

bezpieczeństwo informacji

Określa prawdopodobieństwo i wpływ ryzyka związanego z

danym zasobem

Inżynierowie IT Projektują techniczne rozwiązania z uwzględnieniem ich kosztów

Operatorzy IT Projektują komponenty operacyjne rozwiązań z uwzględnieniem

ich kosztów

Źródło: Microsoft Corporation [cit.2005-01-12], The Security Risk Management Guide, Microsoft Solutions for

Security center of excellence, http://www.microsoft.com

Zarządzanie ryzykiem najczęściej sprowadza się do trzech faz:

identyfikacji szacowania ryzyka(ang. Risk Assessment) – w przypadku IT

identyfikacja zagrożeń, związanych np. z zasobami generującymi kluczowe

informacje,

RYZYKO

ZAGROŻENIA PODATNOŚCI

ZASOBYZABEZPIECZENIA

WARTOŚCIWYMOGI

BEZPIECZEŃSTWA

REALIZOWANE PRZEZ

OGRANICZAJĄ I CHRONIĄ PRZED

WYKORZYSTUJĄ

NARAŻAJĄ

POSIADAJĄ

ZWIĘ

KSZA

JĄ

ZWIĘKSZAJĄ

AN

ALI

ZA

OO

KR

EŚLA

ZMNIEJSZAJĄ

ZWIĘKSZAJĄ

http://www.microsoft.com/

4 listopada



łagodzenia ryzyka(ang.Risk Mitigation) – w kontekście IT może m.in. być określenie

mechanizmów kontrolnych według zasad10

: efektywności kosztowej11

, „apetytu na

ryzyko”12

, preferencji środków13

zmniejszających prawdopodobieństwo realizacji

zagrożeń,

monitorowanie ryzyka(ang. Risk Evaluation and Monitoring) – w aspekcie IT może

oznaczać między innymi szacowanie ryzyka w przypadku zmian systemowych.

Zarządzanie ryzykiem jest iteracyjnym procesem, skorelowanym z poszczególnymi fazami

cyklu życia systemu(SDLC - ang.System Development Life Cycle). Integrację procesu

zarządzania ryzykiem na tle SDLC przedstawia tabela 3.

Zarządzanie ryzykiem na tle SDLC odgrywa szczególnie ważną rolę w przypadku

projektów informatycznych, w ramach których tworzone są duże systemy, a projekt

realizowany jest w okresie kilku lat, np. systemy operacyjne, systemy zarządzania bazami

danych, zintegrowane systemy informatyczne itp14

. W aspekcie zintegrowanych systemów

informatycznych zarządzanie ryzykiem jest o tyle ważne oraz czasochłonne, iż dotyczy ono

całego środowiska informatycznego.

1.1. Identyfikacja ryzyka

Identyfikacja ryzyka stanowi pierwszy etap w procesie zarządzania ryzykiem15

.

Szacowanie(identyfikacja) ryzyka jest procesem wspomagającym dla większości procesów

decyzyjnych. Powinno ono stanowić ważne narzędzie projektowania i wdrażania

wewnętrznych mechanizmów kontrolnych, określania strategii informatycznej oraz

mechanizmów monitorowania16

.

10

Forystek. M., op. cit., s. 23. 11

Koszt wdrożenia i utrzymania mechanizmów kontrolnych nie może być większy niż ryzyko, przed którym

mają chronić. 12

Mechanizmy kontrolne powinny ograniczać ryzyko do poziomu nie niższego niż ustalony przez kierownictwo

– jest to kwestia strategii i polityki firmy oraz sposobu zarządzania. 13

Zależnie od prowadzonej polityki występują preferencje wobec mechanizmów kontrolnych – transfer ryzyka,

minimalizacja prawdopodobieństwa zagrożeń, minimalizacja skutków realizacji zagrożeń.. 14

Murthi S., Preventive Risk Management for Software Projects, Software Development IT Pro,

Wrzesień/Październik 2002, s. 9 - Badania pokazują między innymi, iż złe zarządzanie ryzykiem może

destrukcyjnie wpłynąć na realizację projektu co do przyjętego budżetu i czasu realizacji. 15

Cooper D.F., Grey S., Raymond G., Walker P., Project Risk Management Guidelines. Managing Risk in Large

Project and Complex Procurements, John Wiley & Sons, Chichester, West Sussex 2005, s. 37. 16

Forystek. M., op.cit., s. 137.

4 listopada



Tabela 3. Integracja procesu zarządzania ryzykiem na tle SDLC

Poszczególne fazy

SDLC

Charakterystyka danej

fazy

Sposób zarządzania ryzykiem

Inicjacja

(ang.Initiation)

Wystąpiła potrzeba posiadania

systemu informatycznego,

którego cel i zakres

informacyjny został

udokumentowany.

Proces identyfikacji ryzyka stanowi bazę do

określenia parametrów systemowych,

uwzględniając wymogi bezpieczeństwa

systemu oraz strategię bezpieczeństwa

operacji zachodzących w systemie

Tworzenie we

własnym zakresie

bądź nabycie

gotowego produktu

(ang. Development or

Acquisition)

System informatyczny został

zaprojektowany i

zaprogramowany we własnym

zakresie bądź zakupiony od

zewnętrznego dostawcy.

Czynności związane z zarządzaniem

ryzykiem uwzględniają analizę

bezpieczeństwa w określonym systemie, w

celu stworzenia wytycznych dla

projektantów oraz przyszłych twórców

systemu.

Implementacja

(ang. Implementation)

Konfigurowanie, testowanie i

weryfikowanie określonych

wytycznych co do

bezpieczeństwa systemu.

Proces zarządzania ryzykiem skupia się na

skorelowaniu modelowanego środowiska z

systemem, którego implementacja właśnie

się rozpoczyna. Decyzje co do

ewentualnych zagrożeń, a co za tym idzie i

ryzyka, muszą zostać określone przed

rozpoczęciem wdrożenia.

Faza produkcyjna /

utrzymanie

(ang. Operation or

Maintenance)

Pomimo wykonywania przez

system swoich funkcji, jest on

ciągle modyfikowany w celu

zwiększenia wydajności bądź

skorelowania się ze

zmieniającym środowiskiem

gospodarczym. Modyfikacje

mogą dotyczyć zmian

sprzętowych, programowych

wynikających ze zmian w

procesach organizacyjnych,

politykach czy innych

procedurach.


ryzykiem obejmują nowe elementy, które

dołączane są do systemu będącego w fazie

produkcyjnej, np. nowy interfejs dostępowy

do systemu.

Likwidacja

(ang. Disposal)

Faza ta dotyczy schyłku istnienia

systemu informatycznego.

Charakteryzuje się ona kolejnym

pozbywaniem się składowych

systemu, tj. informacji,

oprogramowania, sprzętu.

Czynności mające na celu

pozbycie się ww. składowych

mogą oznaczać przeniesienie,

archiwizowanie, porzucenie,

usunięcie informacji bądź

odpowiednie zredukowanie

ilości posiadanego sprzętu i

oprogramowania

wykorzystywanego przez

system.


ryzykiem obejmują poszczególne

komponenty, których organizacja chce się

pozbyć bądź wymienić w celu zapewnienia,

że pozostałe dane są zarządzane w sposób

właściwy i bezpieczny.

Źródło: Opracowanie własne na podstawie Stonebumer G., Goguen A., Feringa A., Risk Management Guide

for Information Technology Systems, National Institute of Standards and Technology, Październik 2001, s. 5.

4 listopada



W ramach identyfikacji procesów zachodzących w organizacji należy określić jej

stosunek do17

:

ryzyka – jednostka powinna go określić jednoznacznie w formie polityki lub innej

regulacji, w której opisane będą:

filozofia i cele organizacji w zakresie zarządzania ryzykiem(w tym stosunek

do ryzyka informatycznego),

metodyki oceny ryzyka,

zasady współpracy przy prowadzeniu analizy ryzyka(podział na oceniających

ryzyko oraz modelujących mechanizmy kontrolne),

odpowiedzialność za zarządzanie ryzykiem,

mechanizmy eliminowania ryzyka;

odpowiedzialności za zarządzanie ryzykiem – odpowiedzialność za

zarządzanie(pomiar, budowanie planów działania, nadzór na ich realizacją) powinna

być jednoznacznie przypisana na podstawie regulacji wewnętrznej; jednostka

odpowiedzialna za zarządzanie ryzykiem musi uwzględniać takie czynniki, jak

wyniki:

audytów,

inspekcji,

zidentyfikowanych incydentów.

Istnieje szereg metod analizy ryzyka. Przykładowe zestawienie prezentują Alfredo del Cano

oraz M.Pilar de la Cruz18

. Wynikiem przeprowadzonej analizy podczas szacowania ryzyka

jest identyfikacja określonych mechanizmów kontrolnych, mających na celu zredukowanie

bądź wyeliminowanie ryzyka. Metodologię analizy ryzyka przedstawia rysunek 3. Pierwszy

krok w tej metodologii stanowi charakterystyka badanego systemu, polegająca na określeniu

jego zakresu w ramach zasobów informacji, wedle których jest formowany.

17

Forystek M., op.cit., s. 137-138. 18

Cano A., Pilar Cruz M., Integrated Methodology for Project Risk Management, Journal of Construction

Engineering and Management, November/December 2002 s. 481.

4 listopada



Rysunek 3. Metodologia analizy ryzyka



Identyfikowanie ryzyka dla systemu informatycznego wymaga dogłębnego zrozumienia

środowiska przetwarzania tego systemu, tj. zebrania informacji na temat elementów biorących

udział w tym przetwarzaniu. Do elementów tych zaliczyć można sprzęt, oprogramowanie,

4 listopada



rodzaje wykorzystywanych połączeń, personel odpowiedzialny za system, dane i informacje

oraz poziom ochrony wymagany do zachowania integralności, poufności i dostępności

systemu. W zbiorze szczegółowych danych na temat systemu informatycznego spotyka się

również takie informacje, jak: funkcjonalne wymagania systemu, użytkowników systemu,

politykę bezpieczeństwa systemu, topologię sieci teleinformatycznej, przepływ informacji w

systemie.

Informacje charakteryzujące system będący w fazie „zamysłu” bądź projektu mogą

pochodzić bezpośrednio z dokumentów wstępnych i projektowych. W przypadku systemów

będących już w fazie tworzenia, wymagane jest określenie przyszłych zasad bezpieczeństwa.

Dokumenty projektowe oraz plany bezpieczeństwa systemu mogą stanowić użyteczną

informację dotyczącą bezpieczeństwa systemu, będącego przedmiotem projektu. W

przypadku systemów w fazie produkcyjnej źródłem informacji potrzebnych do

przeprowadzanie analizy ryzyka mogą być dokumenty na temat bezpieczeństwa istniejącej

infrastruktury, tj. danych, konfiguracji, połączeń. Istnieje wiele metod zbierania informacji

potrzebnych do scharakteryzowania systemu informatycznego. Do najbardziej znanych

należą: kwestionariusze ankietowe, bezpośrednie wywiady z personelem informatycznym,

przegląd istniejącej dokumentacji dotyczącej systemu.

Kolejnym krokiem w procesie identyfikacji ryzyka jest rozpoznanie potencjalnych

źródeł zagrożeń, które uaktywnione mogą wykreować ryzyko związane z elementami systemu

na nie podatnymi. Do spotykanych rodzajów zagrożeń należą: naturalne, tj. powodzie,

trzęsienia Ziemi, tornada, lawiny, przepięcia elektryczne, ludzkie, czyli zdarzenia wywołane

przez człowieka. Wśród zdarzeń wywołanych przez człowieka wyróżnia się zdarzenia

nieumyślne, np. błędne wprowadzenie danych, bądź celowe, np. nieautoryzowany dostęp do

poufnych danych, oraz środowiskowe, np. długi brak zasilania, zanieczyszczenia, chemikalia,

zalania. Motywy oraz sposoby przeprowadzania ataków na systemy informatyczne, jakie

niosą ludzie, czyni ich potencjalnie niebezpiecznym źródłem zagrożeń. Informacje o

istniejących źródłach zagrożeń mogą również pochodzić z raportów specjalnych agencji

prowadzących ciągły monitoring ataków oraz nowych źródeł, zagrożeń, jak również zasobów

sieci Internet19

.

Trzecim krokiem w procesie identyfikacji ryzyka jest opracowanie listy słabości

systemu świadczących o jego podatności na wykryte w poprzednim kroku zagrożenia. Należy

19

Patrz raporty http://SecurityFocus.com, http://SecurityWatch.com, http://SecurityPortal.com, http://SANS.org.

4 listopada



podkreślić, że typy istniejących słabości oraz metodologia pozwalająca je oszacować różnią

się w zależności od natury systemu informatycznego oraz od fazy SDLC, w której system

informatyczny się znajduje. Jeżeli system nie został jeszcze zaprojektowany, ewentualnych

słabości należy poszukiwać w istniejącej bądź planowanej polityce bezpieczeństwa oraz w

definicjach wymagań systemowych. Informacje o słabościach systemu, który jest właśnie w

fazie implementacji bądź już znajduje się w fazie produkcyjnej, można czerpać przede

wszystkim z dokumentacji systemu oraz z raportów z testów bezpieczeństwa

przeprowadzanych na badanym systemie.

Analiza mechanizmów kontrolnych stanowi kolejny krok w procesie identyfikacji

ryzyka. Głównym celem tego etapu jest określenie mechanizmów kontrolnych, które już

istnieją bądź są planowane w organizacji w celu zminimalizowania, ewentualnie

wyeliminowania prawdopodobieństwa, że określone zagrożenie może wykorzystać słabości

zasobów lub grup zasobów powodując ich utratę lub zniszczenie. Analiza mechanizmów

kontrolnych obejmuje zarówno obszar techniczny: sprzęt komputerowy, oprogramowanie,

mechanizmy kontroli dostępu, identyfikacji, autentyfikacji, enkrypcji, jak i aspekt

nietechniczny rozumiany jako wszelkie procedury operacyjne oraz organizacyjne występujące

na szczeblu zarządczym i operacyjnym. W literaturze przedmiotu spotyka się trzy kategorie

mechanizmów kontrolnych, które zostały zaprezentowane na rysunku 4.

Rysunek 4. Kategorie mechanizmów kontrolnych

Źródło: Opracowanie własne na podstawie Spencer Pickett K.H., The Internal Auditing Handbook, John Wiley

& Sons 2003, s. 515.

Mechanizmy prewencyjne mają na celu zwiększenie niezawodności systemu

informatycznego. Mechanizmy detekcyjne służą wykrywaniu problemów, a korekcyjne

wskazują sposoby doprowadzające system do stanu sprzed wystąpienia zagrożenia. W

szybko zmieniających się systemach informatycznych zauważalną tendencją jest wzrost

znaczenia mechanizmów prewencyjnych, w stosunku do mechanizmów korekcyjnych20

.

20

Jest to sytuacja odwrotna w stosunku do tendencji panującej wcześniej.

Mechanizmy

prewencyjne

Mechanizmy

detekcyjne

Mechanizmy

korekcyjne

4 listopada



Następnym krokiem identyfikacji jest ocena prawdopodobieństwa ryzyka

informatycznego. Aby dokonać oceny prawdopodobieństwa, że określone zagrożenie może

wykorzystać słabości zasobów lub grup zasobów powodując ich utratę lub zniszczenie,

konieczne jest uwzględnienie rezultatów płynących z wcześniejszych kroków procesu

identyfikacji ryzyka, tj. źródeł ewentualnych zagrożeń, motywów działań, natury istniejących

słabości w systemie oraz istnienia efektywnych mechanizmów kontrolnych.

Prawdopodobieństwa można ująć w trzech aspektach: wysokie, średnie, niskie. Tabela 4

przedstawia charakterystykę każdego z poziomów.

Tabela 4. Poziomy prawdopodobieństwa

Poziom

prawdopodobieństwa

Charakterystyka

Wysokie Źródło zagrożenia jest poważne i może stanowić bodziec do powstania ryzyka

związanego ze słabością systemu. W dodatku istniejące mechanizmy kontrolne

są nieefektywne.

Średnie Istniejące mechanizmy kontrolne są na tyle kompleksowe i zaawansowane, że

skutecznie mogą zapobiec zagrożeniom, na które narażony jest system.

Niskie Zagrożenia są na tyle mało istotne bądź mechanizmy kontrolne na tyle

zaawansowane, że niwelują lub znacznie ograniczają możliwość ich

wystąpienia bądź wpłynięcia na działanie systemu.



Kolejnym istotnym krokiem do pomiaru poziomu ryzyka jest określenie negatywnego

wpływu zagrożenia, które wykorzystało słabości zasobów lub grup zasobów powodując ich

utratę lub zniszczenie. Analiza wpływu zagrożenia musi być poprzedzona uzyskaniem

informacji przedstawionych częściowo przy charakteryzowaniu systemu, m.in. celu systemu

oraz krytyczności danych w nim zawartych. Negatywny wpływ zagrożeń na system może być

określony przykładowo poprzez pryzmat trzech, zdefiniowanych wcześniej zagadnień,

związanych z bezpieczeństwem: integralności, dostępności oraz poufności.

W następnej kolejności określany jest poziom ryzyka, które można wyrazić jako

funkcję trzech zmiennych:

),,( CILfR

gdzie :

R – ryzyko(ang.Risk),

L – prawdopodobieństwo zajścia zdarzenia(ang. Likelihood),

I – wielkość wpływu ewentualnego zagrożenia na system(ang. Impact),

4 listopada



C – planowane bądź istniejące mechanizmy kontrolne, zmniejszające lub całkowicie

eliminujące wystąpienie zagrożenia(ang. Controls).

W literaturze przedmiotu często spotyka się określanie poziomu ryzyka jako

wypadkowej prawdopodobieństwa zajścia zdarzenia oraz jego ewentualnego wpływu na

system. Poziom ryzyka jest wskazówką dla kadry zarządzającej do podjęcia określonych

czynności(patrz tabela 5).

Tabela 5. Skala ryzyka

Poziom ryzyka Wymagane czynności

Wysokie Występuje zdecydowana potrzeba przeprowadzenia czynności korekcyjnych,

które dokonają potrzebnych poprawek w systemie. Czynności korekcyjne

powinny zostać wykonane tak szybko jak to możliwe.

Średnie Istnieje potrzeba opracowania procedur uwzględniających czynności

korekcyjne, których wdrożenie nie jest konieczne natychmiastowo, tak jak w

przypadku ryzyka sklasyfikowanego jako wysokie.

Niskie Należy dokonać wyboru pomiędzy akceptacją występującego ryzyka bądź

należy opracować procedury dotyczące czynności korekcyjnych.



Ostatnimi etapami w procesie identyfikacji ryzyka są rekomendacje dalszej kontroli

oraz raport z przeprowadzonych czynności. Rekomendacje co do dalszych kontroli powinny

uwzględniać łagodzenie bądź eliminowanie ryzyka. Przy ich określaniu uwzględnia się takie

czynniki, jak: efektywność proponowanych rozwiązań, zgodność z normami prawnymi,

zgodność z wewnętrznymi procedurami organizacyjnymi oraz bezpieczeństwo. Zalecane

kontrole stanowią bazę wejściową do następnego etapu w procesie zarządzania ryzykiem, tj.

do etapu łagodzenia ryzyka.

Raport z przeprowadzonych czynności przewidziany jest dla kadry zarządzającej;

prezentuje on ewentualne przeszkody, jakie mogą być napotkane w drodze ku osiągnięciu

planowanych celów. W przeciwieństwie do raportu poaudytowego, skupiającego się na

uwypukleniu tego, co jest złe w danym środowisku informatycznym, raport z identyfikacji

ryzyka ma charakter systematycznego i analitycznego podejścia do zagadnienia mającego na

celu wyszukanie słabości systemu w celu uchronienia się przed ewentualnymi zagrożeniami.

1.2. Łagodzenie ryzyka

Drugim etapem procesu zarządzania ryzykiem jest etap łagodzenia ryzyka, który

sprowadza się do wyborów mechanizmów kontrolnych zmniejszających prawdopodobieństwo

wystąpienia zagrożenia bądź zmniejszenia ewentualnego wpływu na działalność, gdy już

4 listopada



wystąpi. W literaturze przedmiotu spotyka się następujące formy łagodzenia ryzyka21

:

akceptacja ryzyka(ang.Risk Assumption), unikanie ryzyka(ang. Risk Avoidance), ograniczanie

ryzyka(ang. Risk Limitation), planowanie ryzyka(ang. Risk Planning) oraz transfer

ryzyka(ang. Risk Transference). Rysunek 5 prezentuje metodologię łagodzenia ryzyka.

Pierwszym z wymienionych kroków jest hierarchizacja czynności, jakie należy

przedsięwziąć w celu zminimalizowania wystąpienia zagrożenia. Wagi, a co za tym idzie i

kolejność czynności, przypisywane są na podstawie poziomów ryzyka ustalonych w etapie

identyfikacji ryzyka.

Rekomendowane w procesie identyfikacji ryzyka mechanizmy kontrolne nie

koniecznie muszą stanowić optymalne rozwiązanie dla danej organizacji. Dlatego też w

drugim kroku etapu łagodzenia ryzyka dokonuje się ponownego przeglądu rekomendowanych

wcześniej mechanizmów w celu wyodrębnienia tych, które w rozważanym aspekcie są

najbardziej efektywne i przydatne. W następnej kolejności przeprowadzane są analizy

opłacalności(efektywności kosztowej) stosowania mechanizmów kontrolnych. Przyjętą

zasadą jest, aby koszt wdrożenia i późniejszego utrzymania mechanizmów kontrolnych nie

przewyższał ewentualnych strat, jakie dane ryzyko niesie ze sobą. Wybór mechanizmów

kontrolnych uzależniony jest również od preferencji organizacji co do wymienionych

wcześniej form łagodzenia ryzyka, tj. transferu ryzyka bądź jego minimalizacji.

Efektywnie wybrane mechanizmy kontrolne przypisywane są konkretnym osobom, na

których spoczywa odpowiedzialność wprowadzenia ich w życie z uwzględnieniem ciągłego

monitoringu ich działania.

21

Stonebumer.G., Goguen.A., Feringa.A., Risk Management Guide for Information Technology Systems,

National Institute of Standards and Technology, Październik 2001, s. 27.

4 listopada



Rysunek 5. Metodologia łagodzenia ryzyka

Źródło: Opracowanie własne na podstawie Stonebumer G., Goguen A., Feringa A., Risk Management

Guide for Information Technology Systems, National Institute of Standards and Technology, Październik

2001, s. 31.

Zastosowanie najbardziej kompleksowych mechanizmów kontrolnych nie eliminuje

ryzyka do poziomu zerowego. Dlatego też ryzyko pozostałe po wdrożeniu mechanizmów

kontrolnych, nazywane jest ryzykiem rezydualnym(pozostałym). Ryzyko to stanowi podstawę

do dalszych działań i analiz. Jeżeli zdaniem zarządzającego audytem kierownictwo wyższego

szczebla przyjęło zbyt niski poziom ryzyka rezydualnego, wtedy powinien on omówić te

kwestie z kierownictwem wyższego szczebla. Jeżeli decyzja dotycząca ryzyka rezydualnego

4 listopada



nie zostanie zmieniona, zarządzający audytem wewnętrznym i kierownictwo wyższego

szczebla powinni przekazać sprawę do decyzji rady właścicielskiej(np. rady nadzorczej)22

.

1.3. Monitorowanie ryzyka

Cechą środowisk informatycznych jest ich ciągła zmiana, która dotyczyć może

sprzętu, oprogramowania, personelu oraz procedur bezpieczeństwa ewoluujących z dnia na

dzień. Taki stan rzeczy generuje nowe zagrożenia, z którymi dana organizacja musi się

uporać.

Ostania faza procesu zarządzania ryzykiem polega na monitorowaniu działania

zastosowanych mechanizmów kontroli oraz na identyfikacji ryzyka w przypadku zaistnienia

nowych, nieznanych jeszcze zagrożeń. Kompleksowy proces identyfikacji ryzyka przeważnie

powtarzany jest w odstępie trzech lat. Jednakże coraz częściej praktykowanym podejściem

jest uwzględnienie identyfikacji ryzyka w ramach SDLC23

. Celem tego podejścia jest

zapewnienie możliwie najszybszej reakcji na uaktywnione zagrożenia. Proces monitoringu

ryzyka powinien dawać zapewnienie, że istniejące mechanizmy kontrolne odzwierciedlają

zagrożenia związane z procesami gospodarczymi w organizacji24

.

22

Międzynarodowe Standardy Profesjonalnej Praktyki Audytu Wewnętrznego, Oddział Instytutu Audytorów

Wewnętrznych w Polsce, http://www.iia.org.pl [cit.2005-10-10]. 23

Autor ma na myśli audytowania ciągłe opisane w dalszej części pracy. 24

Microsoft Corporation [cit. 2003-01-30], http://www.microsoft.com, A Risk Management Standard, s. 11.

http://www.iia.org.pl/

http://www.microsoft.com/

LDáDQ LH 1 LH SR* G DQ H zdarzenia -...

Documents

Transcript of LDáDQ LH 1 LH SR* G DQ H zdarzenia -...