docAudy systemów informatycznych
download 
Reklamacja Transkrypt
Audy systemów informatycznych
4 listopada 2009 1. AUDY SYSTEMÓW INFORMATYCZNYCH 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 KONSEKWENCJE Działanie Niepożądane zdarzenia STRATY(KOSZTY) K1 C1 K2 C2 K3 . . . C3 . . . Ź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. Mariusz Zarzycki, [email protected] 1 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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. Mariusz Zarzycki, [email protected] 2 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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 ISO 8, 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]. Mariusz Zarzycki, [email protected] 3 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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 WYKORZYSTUJĄ RYZYKO ZMNIEJSZAJĄ OO KR EŚ LA ZABEZPIECZENIA ZW IĘ KS ZA JĄ IĘ KS ZA JĄ OGRANICZAJĄ I CHRONIĄ PRZED PODATNOŚCI AN AL IZA REALIZOWANE PRZEZ WYMOGI BEZPIECZEŃSTWA NARAŻAJĄ ZW ZAGROŻENIA ZW IĘ KS ZA JĄ ZASOBY POSIADAJĄ WARTOŚCI Ź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. Określa prawdopodobieństwo i wpływ ryzyka związanego z danym zasobem Projektują techniczne rozwiązania z uwzględnieniem ich kosztów 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 Grupa odpowiedzialna za bezpieczeństwo informacji Inżynierowie IT Operatorzy IT 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, Mariusz Zarzycki, [email protected] 4 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH ł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. 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. 11 Mariusz Zarzycki, [email protected] 5 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH Tabela 3. Integracja procesu zarządzania ryzykiem na tle SDLC Poszczególne fazy Charakterystyka danej Sposób zarządzania ryzykiem SDLC fazy Inicjacja (ang.Initiation) Tworzenie we własnym zakresie bądź nabycie gotowego produktu (ang. Development or Acquisition) Implementacja (ang. Implementation) Faza produkcyjna / utrzymanie (ang. Operation or Maintenance) Wystąpiła potrzeba posiadania systemu informatycznego, którego cel i zakres informacyjny został udokumentowany. System informatyczny został zaprojektowany i zaprogramowany we własnym zakresie bądź zakupiony od zewnętrznego dostawcy. Konfigurowanie, testowanie i weryfikowanie określonych wytycznych co do bezpieczeństwa systemu. 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 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. 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. Czynności związane z zarządzaniem ryzykiem obejmują nowe elementy, które dołączane są do systemu będącego w fazie produkcyjnej, np. nowy interfejs dostępowy do systemu. 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. Likwidacja Faza ta dotyczy schyłku istnienia Czynności związane z zarządzaniem (ang. Disposal) systemu informatycznego. ryzykiem obejmują poszczególne Charakteryzuje się ona kolejnym komponenty, których organizacja chce się pozbywaniem się składowych pozbyć bądź wymienić w celu zapewnienia, systemu, tj. informacji, że pozostałe dane są zarządzane w sposób oprogramowania, sprzętu. właściwy i bezpieczny. 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. Ź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. Mariusz Zarzycki, [email protected] 6 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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. Cano A., Pilar Cruz M., Integrated Methodology for Project Risk Management, Journal of Construction Engineering and Management, November/December 2002 s. 481. 18 Mariusz Zarzycki, [email protected] 7 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH Rysunek 3. Metodologia analizy 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. 9. 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, Mariusz Zarzycki, [email protected] 8 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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. Mariusz Zarzycki, [email protected] 9 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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 Mechanizmy prewencyjne Mechanizmy detekcyjne Mechanizmy korekcyjne Ź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. Mariusz Zarzycki, [email protected] 10 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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. Poziom prawdopodobieństwa Tabela 4. Poziomy 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. Ź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. 21. 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: R f ( L, I , C ) gdzie : R – ryzyko(ang.Risk), L – prawdopodobieństwo zajścia zdarzenia(ang. Likelihood), I – wielkość wpływu ewentualnego zagrożenia na system(ang. Impact), Mariusz Zarzycki, [email protected] 11 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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 Wymagane czynności Poziom ryzyka 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. Ź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. 25. 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ż Mariusz Zarzycki, [email protected] 12 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH wystąpi. W literaturze przedmiotu spotyka się następujące formy łagodzenia ryzyka 21: 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. Mariusz Zarzycki, [email protected] 13 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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 Mariusz Zarzycki, [email protected] 14 4 listopada 2009 AUDY SYSTEMÓW INFORMATYCZNYCH 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 SDLC 23. 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. Mariusz Zarzycki, [email protected] 15
