Wstęp
Analiza ryzyka IT to jedno z głównych narzędzi wykorzystywanych przez zarządzenie ryzykiem IT, czyli proces polegający na uporządkowanym podejściu do kwestii ryzyk związanych z działaniem systemów IT.
Po co zajmować się zarządzeniem ryzykiem IT?
Przede wszystkim po to, aby od strony bezpieczeństwa IT maksymalizować cele organizacji (często celem jest po prostu wynik finansowy czy jak najbardziej optymalne dysponowanie przydzielonymi organizacji środkami finansowymi). Nie chcemy wydawać na bezpieczeństwo za mało, ale również bezpieczeństwa nie chcemy przeinwestować i popadać w nieuzasadnioną przesadę. Nie chcemy również, aby od strony bezpieczeństwa coś nas zaskoczyło w kontekście działania całej firmy. Jeszcze inny powód to zgodność z regulacjami czy wymaganiami prawnymi.
Dokładnych definicji zarządzania ryzykiem IT jest naprawdę wiele, zazwyczaj jednak wchodzą w jego skład takie elementy jak:
- organizacja całego procesu od strony proceduralnej – ustanowienie, opracowanie rozmaitych dokumentacji związanych z bezpieczeństwem,
- wybór metod ochrony przed zagrożeniami,
- identyfikacja nowych ryzyk,
- pomiary bezpieczeństwa,
- doradztwo dla innych działów w firmie w kontekście bezpieczeństwa,
- czy właśnie przeprowadzenie analizy ryzyka.
Proces zarządzania ryzykiem IT jest ciągły – tj. nie można z sukcesem jednokrotnie go wdrożyć, a następnie o nim zapomnieć.
Analiza ryzyka jest jednym z głównych narzędzi zarządzania ryzykiem IT i ma na celu przede wszystkim:
- zidentyfikować zagrożenia dla naszej infrastruktury IT,
- wykonać ich prioretyzację (np. widzimy, które zagrożenia są dla nas najbardziej istotne),
- oszacować potencjalne straty związane z naruszeniem naszego bezpieczeństwa,
- zaproponować rozsądne decyzje o ryzyku (np. jego redukcję) wraz z racjonalnymi ramami budżetowymi.
Mówiąc jeszcze innymi słowy, celem analizy ryzyka jest podniesienie czy wręcz zbudowanie naszej świadomości dotyczącej stanu bezpieczeństwa mojego systemu IT, a w kolejnym kroku podjęcie pewnych działań zaradczych. Prowadzimy ją, przez cały czas mając na uwadze główny cel organizacji (czyli najczęściej maksymalizację profitów / minimalizację strat).
Przy okazji zaznaczam, że jako składniki bezpieczeństwa często definiuje się trzy właściwości:
- poufność,
- integralność,
- dostępność.
Powinniśmy mieć to na uwadze podczas analizy ryzyka.
Jak realnie wykonać analizę ryzyka?
Cały proces składa się najczęściej z czterech kroków, które przedstawiam na diagramie poniżej, a które bardziej szczegółowo opisuję w dalszej części tekstu.
1. Pierwszy krok: inwentaryzacja zasobów IT
Bez wiedzy, co znajduje się w mojej infrastrukturze, ciężko mówić o bezpieczeństwie całości.
Zasobami są przykładowo: konkretne serwery, urządzenia sieciowe, aplikacje, pomieszczenia, w których znajdują się te urządzenia, stacje PC, komputery przenośne (w tym smartfony, tablety), konkretne bazy danych itp. Przy okazji warto tu zastanowić się nad komponentami, które nie znajdują się w mojej infrastrukturze, a które są konieczne do poprawnego działania całej organizacji (systemy działające w modelu outsourcingowym) – przykładem mogą być tutaj serwery poczty / DNS / czy witryna internetowa.
Na tym etapie analizy dla każdego zasobu możemy od razu oznaczyć jego krytyczność dla działania całej organizacji oraz określić aktualnie stosowane metody ochrony (przykładowe metody ochrony można zobaczyć np. tutaj – Sans 20 Critical Security Controls). Krytyczność może być przydatna np. do tego, aby dalszą analizę ryzyka zawęzić i przeprowadzić ją tylko dla systemów krytycznych.
WAŻNE: pierwszą analizę ryzyka niekoniecznie należy wykonać dla wszystkich możliwych zasobów. Można ją ograniczyć np. tylko do jednego działu firmy, jednego produktu, jednego rodzaju zasobów itp. W ten sposób zmniejszamy ilość czekającej nas pracy, a ewentualne problemy w realizacji zadania nie wpłyną na cały proces, tylko zostaną ograniczone. Łatwiej będzie się z nimi zmierzyć, a wnioski z pierwszej analizy zastosować w kolejnej – być może pełniejszej iteracji. Analiza ryzyka IT jest najczęściej właśnie procesem iteracyjnym.
Przykłady możliwych istotnych klas zasobów (wymienionych w normie ISO 27005:2011 – dotyczącej zarządzaniem ryzykiem IT):
- informacje (np. baza danych finansowych, baza danych osobowych),
- procesy biznesowe (np. sprzedaż konkretnych produktów, obsługa spraw obywateli – w urzędach),
- sprzęt (np.: serwery, routery, komputery PC, drukarki),
- oprogramowanie (np. aplikacje webowe, aplikacje instalowane na komputerach PC),
- budynki / pomieszczenia (np. serwerownia, główne centrum przetwarzania),
- osoby (np. pracownicy stali, pracownicy tymczasowi, osoby z firm zewnętrznych),
- sieć (np. okablowanie sieciowe),
- struktura organizacyjna firmy (np. odpowiednie dokumentacje, procedury).
2. Drugi krok: określenie potencjalnych zagrożeń dla każdego zinwentaryzowanego zasobu
Na tym etapie bardzo pomocne są tzw. checklisty, czyli zestawy „standardowych zagrożeń” dla konkretnych komponentów. Dla ułatwienia – każde zagrożenie zazwyczaj można przyporządkować do jednego z czterech obszarów:
- zagrożenia ludzkie, czyli wpływ działania czynnika ludzkiego na bezpieczeństwo naszego systemu IT. W tej kategorii znajdują się słynne „ataki hackerskie”, ale również zwykłe błędy ludzkie (np. administrator, który niepoprawnie przygotował backup);
- zagrożenia naturalne, czyli żywioły: powódź, pożar, wichury, problemy związane z przepięciami itp.;
- zagrożenia techniczne, czyli wszystko, co może zagrozić elementom normalnie potrzebnym do funkcjonowania systemów IT (np. elektryczność, odpowiednia wilgotność powietrza), odpowiednie działanie komponentów (np. dyski twarde, chłodzenie) itp.;
- zagrożenia administracyjne, czyli wynikające z naruszeń obowiązujących nas przepisów prawnych (np. ustawa o ochronie danych osobowych, Rekomendacja D KNF), regulacji zewnętrznych (np.: PCI DSS) lub wewnętrznych zaleceń (np. wymaganych przez naszą centralę); czasem grupa ta wymienia jest jako podzbiór ww. trzech grup zagrożeń.
Często możemy analizę zagrożeń podzielić na dwa ułatwiające cały proces elementy:
- określenie przyczyny zagrożenia (np. hacker, pracownik wewnętrzny); w literaturze anglojęzycznej to często po prostu ‚threat’ – zagrożenie;
- wrogie czynności, które te „przyczyny” mogą potencjalnie „chcieć realizować” (np. hacker: atak zewnętrzny wykradający dane, atak DDoS powodujący niedostępność naszej infrastruktury IT; pracownik wewnętrzny: kradzież danych, błąd skutkujący niepoprawnym przygotowaniem backupu, przypadkowe usunięcie danych, fizyczne zniszczenie); w literaturze anglojęzycznej jest to tzw. ‚threat event’ – wydarzenie, które może być spowodowane przez zagrożenie.
Przykład przydatnej checklisty zawiera dostępny publicznie dokument: NIST SP800-30 – „Guide for Conducting Risk Assessments” (Załącznik E) czy dokument ISO 27005:2011 (Załącznik C). Więcej informacji o różnych checklistach tego typu można znaleźć w rozdziale: Dalsze materiały.
Inną metodą uzyskiwania informacji o zagrożeniach jest po prostu zdrowy rozsądek osoby (lub zespołu) realizującej analizę ryzyka. Często jest to też „wiedza ekspercka”, którą mogą posiadać osoby „opiekujące się” na co dzień konkretnym zasobem.
Wypisanie potencjalnych zagrożeń dla każdego zasobu wydaje się być zadaniem dość trudnym, ale trzeba pamiętać, że dla wielu zasobów zagrożenia powtarzają się, a po pewnym czasie można i tutaj dojść do pewnej wprawy analitycznej.
Kilka przykładowych zagrożeń:
- zalanie,
- pożar,
- atak hackerski wykradający istotne dane,
- atak typu DDoS (na dostępność systemu),
- fizyczna awaria nośników danych,
- awaria okablowania,
- awaria zasilania,
- nieautoryzowane fizyczne uzyskanie dostępu do istotnego pomieszczenia z przetwarzanymi danymi,
- zagubienie / kradzież sprzętu zawierającego istotne dane,
- unieruchomienie części systemu IT spowodowane przez malware,
- sprzedaż sprzętu (np. dysków twardego) bez odpowiedniego, trwałego usunięcia danych,
- użycie pirackiego oprogramowania / pirackiej zawartości wewnątrz organizacji,
- ujawnienie poufnych informacji,
- brak odpowiednich zapisów umownych gwarantujących bezpieczeństwo,
- zagrożenia płynące z innych systemów, na których nasz zasób bazuje.
Zawsze należy zastanowić się, na jakim poziomie szczegółowości chcemy rozważać zagrożenia – przy pierwszej analizie ryzyka warto to zrobić na poziomie ogólnym (np. wypisujemy ogólne zagrożenie: ‚atak hackerski’, a nie wszystkie możliwe typy ataków).
3. Trzeci krok: wskazanie podatności czyli realnych słabości naszych zasobów
Do każdego zasobu (krok pierwszy) mamy już przyporządkowany szereg potencjalnych zagrożeń (krok drugi), teraz chcemy zobaczyć, jakie realnie problemy związane z bezpieczeństwem mogą nas spotkać (tj. czy zagrożenia wskazane w punkcie wyżej mogą rzeczywiście zagrozić naszym zasobom).
PRZYKŁADZasób „firmowy portal informacyjny” oznaczyliśmy m.in. zagrożeniem „atak hackerski”. Teraz chcemy sprawdzić, czy nasz system rzeczywiście posiada pewne słabości (podatności), które umożliwiłyby sukces tego ataku. W tym celu przeprowadza się często testy penetracyjne (czyli symulowane ataki na infrastrukturę IT – tak aby wykryć jej rzeczywiste słabości).
Zasób „główna serwerownia” i zagrożenie „zalanie”. Jeśli pomieszczenie znajduje się w piwnicy, a dodatkowo historycznie występowały na danym terenie podtopienia to teraz wskazujemy, że nasze pomieszczenie jest podatne. Zapisujemy to jako podatność.
Zasób „zewnętrzny portal dla kontrahentów” i zagrożenie „naruszenie ustawy o ochronie danych osobowych”. Jeśli w systemie wykryliśmy błędy umożliwiające nieautoryzowany dostęp do danych lub niezgodność z elementami wymaganymi w stosownym rozporządzeniu wykonawczym, jest to realna podatność.
4. Krok czwarty: określenie ryzyka
Teraz sprawdzimy wpływ wykorzystania konkretnych, zdefiniowanych wcześniej podatności na naszą organizację; inaczej – zweryfikujemy skutki wykorzystania słabości naszego systemu. Konkretna definicja „ryzyka” znowu zależy tutaj często od przyjętego metodologii.
Wyróżniają się dwa podejścia:
A) Podejście jakościowe
W tym modelu ryzyko zazwyczaj określane jest jako niskie / średnie / wysokie (możliwe są też inne, podobne skale), a wartość ryzyka można odczytać z tabeli, w której:
- w kolumnach mamy prawdopodobieństwo wykorzystania danej podatności (niskie, średnie, wysokie),
- w wierszach – wpływ wykorzystania podatności na naszą organizację (niski, średni wysoki).
Taka tabela definiuje finalne ryzyko, które niesie każda kombinacja powyższych warunków. Jako przykład przykład można zacytować dokument OWASP Risk Rating Metodology:
Ryzyko jest tu więc prostą funkcją prawdopodobieństwa wykorzystania podatności oraz idących za tym skutków.
Podejście jakościowe jest zazwyczaj zalecane przy pierwszej analizie ryzyka (o wiele łatwiej oszacować ryzyko tą metodą).
Zagrożenie: „atak hackerski”. W wyniku realizacji testów penetracyjnych dowiedziałem się, że w systemie znajduje się sporo krytycznych podatności (np. SQL injection) umożliwiających całkowite przejęcie kontroli nad tym systemem. Ponieważ podatności są niezbyt łatwe do znalezienia, a potencjalnych atakujących nie jest za dużo, to prawdopodobieństwo skutecznego ataku określam jako „średnie” (Medium), zaś skutek wykorzystania podatności przez zagrożenie jako „wysoki” (High). Na przecięciu odpowiednich wierszy i kolumn w tabeli odczytuję ryzyko: „wysokie” (High).Warto tutaj oczywiście zaznaczyć, że dla jednego zasobu może występować wiele ryzyk (bo i możemy mieć wiele zagrożeń / wiele podatności).
B) Podejście ilościowe
W podejściu ilościowym staramy się określić ryzyko w konkretnych liczbach (np. stracie finansowej, którą potencjalnie generuje ryzyko). Zazwyczaj jest to metoda bardziej skomplikowana, niezalecana dla początkujących.
Najpierw szacuje się prawdopodobieństwo skutecznego wykorzystania podatności przez zagrożenie w zadanym okresie (najczęściej przyjmuje się tutaj jeden rok). Np. szacuję, że mój portal informacyjny zostanie zaatakowany skutecznie raz w przeciągu najbliższego roku (zrealizowałem wcześniej testy penetracyjne, z których wynika, że system zawiera istotne podatności, które umożliwiają nieautoryzowane, zdalne przejęcie kontroli nad portalem).
Oszacowanie strat. Następnie liczę potencjalne straty, czyli koszty, które poniosę w wyniku wykorzystania podatności przez zagrożenie. Powinienem tutaj oszacować możliwie wszystkie wartości takie jak: czas pracowników potrzebny na przywrócenie systemu do stanu początkowego, straty pieniężne, straty reputacji, kary wynikające z umów / ustaw / itd.
Finalnie mogę tutaj wskazać, ile wynoszą moje średnioroczne straty podczas eksploatacji danego zasobu. Pozwala mi to oszacować poziom ryzyka, ale też np. rozsądnie zaplanować budżet (widać np. że nie powinien być on większy niż straty – wtedy czasem lepiej nic nie robić – dojdziemy do tego w punkcie kolejnym dotyczącym podejmowania decyzji o ryzyku).
Często, choć nie zawsze, analiza ryzyka zawiera w sobie jeszcze kolejny krok: podjęcie decyzji o ryzyku (w innych przypadkach jest to ujmowane w ramach nadrzędnego procesu, czyli zarządzeniem ryzykiem).
5. Krok piąty: podjęcie decyzji o ryzyku
Większość metodologii mówi o czterech możliwych, wzajemnie wykluczających się podejściach dotyczących ryzyka, które zostały zobrazowane w dolnej części diagramu, a omówione poniżej.
1. Redukcja ryzyka
Może być realizowana na kilka sposobów, ale najczęściej jest to implementacja odpowiednich korekt w naszym systemie (np. wykonanie aktualizacji nieaktualnego oprogramowania, załatanie podatności w aplikacjach). Przykładowe zestawienie metod ochrony – Sans 20 Critical Security Controls.
2. Akceptacja ryzyka
W przypadku kiedy ryzyko jest małe, a potencjalna redukcja ryzyka kosztowna, możemy chcieć je zaakceptować. Jednak kryteria akceptacji ryzyka powinny być odpowiednio określone (np. w odpowiedniej polityce bezpieczeństwa). Nie chodzi tutaj o przypadek, kiedy nie realizujemy analizy ryzyka, a wszystkie (tj. również nieznane nam) ryzyka akceptujemy.
3. Przekazanie ryzyka
Może przybrać formę ubezpieczenia od ryzyka (postać znana np. w przypadku ubezpieczenia nieruchomości od zdarzeń losowych; dla zagrożeń IT rzadko w Polsce stosowana), ale również outsourcingu. Czyli ryzyko przekazuję do innej firmy, a odpowiedzialność za nie zawieram w odpowiednich zapisach umownych.
4. Uniknięcie ryzyka
Jeśli ryzyko jest duże, a system, w którym ono występuje, nie przynosi mi odpowiednich korzyści, być może najkorzystniejszym rozwiązaniem będzie w ogóle zrezygnowanie z eksploatacji danego systemu (a zarazem uniknięcie ryzyka).
Podsumowanie
W wyniku realizacji analizy ryzyka IT wiem, co grozi bezpieczeństwu moich systemów oraz jakie mogą być konsekwencje urzeczywistnienia zagrożeń. Powinienem też podjąć decyzję, co zrobić ze zidentyfikowanymi ryzykami.
Jeśli dla potencjalnych decyzji nie mam przygotowanych formalnych zasad postępowania, mogę na podstawie wyszczególnionych ryzyk spróbować przygotować formalny dokument mówiący o decyzjach dotyczących ryzyka, np. kiedy akceptuję ryzyko, a kiedy powinienem je redukować (nie robię tego arbitralnie, ale razem z zespołem odpowiedzialnym za zarządzenie ryzykiem w firmie, w tym z osobami, które odpowiadają za działanie całej organizacji, a nie tylko za obszar bezpieczeństwa).
Cały proces analizy ryzyka IT w kontekście zarządzania ryzykiem IT może wyglądać np. tak:
Dalsze materiały
Poniżej przedstawiam dodatkowe materiały dotyczące analizy ryzyka.
- Dostępny publicznie dokument NIST SP800-30 – „Guide for Conducting Risk Assessments”: opisuje kompletny proces przygotowania analizy ryzyka. Dodatkowo zawarto tu sporo gotowych „wzorców”, np.: Załącznik E wymienia w formie checklisty możliwe zagrożenia „THREAT EVENTS – REPRESENTATIVE THREAT EVENTS INITIATED BY THREAT SOURCES”:
NIST SP800-30 – „Guide for Conducting Risk Assessments” – fragment checklisty listującej przykładowe ryzyka
- Norma ISO 27005:2011 – „Information security risk management”: znajdziemy tu m.in. opis procesu analizy ryzyka, podobnie jak w dokumencie powyżej uzupełniony o pewne szablony (np. załącznik C to przykładowe zagrożenia). Dokument jest odpłatny.
Książka: The Security Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessments, Second Edition, która zawiera świetny opis metodologii realizacji całości procesu – w tym rozbudowane listy ułatwiające realizację analizy ryzyka krok po kroku.
Książka The Failure of Risk Management: Why It’s Broken and How to Fix It: opracowanie dla niepokornych pokazuje, dlaczego w wielu przypadkach „standardowe” podejście do ryzyka się nie sprawdza. Podejście zdroworozsądkowe, ale też i sprawdzone przez autora w czasie wieloletniej praktyki podczas realizacji analizy ryzyka. Niech dalszą rekomendacją będzie tytuł jednej z recencji na Amazonie: „One of the Most Important and Valuable Business Books Written in Many Years„.- Książka o mierzeniu bezpieczeństwa – Security Metrics – może rozsądnym jest sprawdzenie czy zarządzanie ryzykiem / analiza ryzyka rzeczywiście w sposób racjonalny zwiększają bezpieczeństwo naszej organizacji? Nic trudnego – wystarczy dobrać odpowiednie metryki bezpieczeństwa i zmierzyć bezpieczeństwo w momencie „zero” oraz gdy nasz proces zarządzania ryzykiem nieco dojrzeje 🙂 Po porównaniu tych obu pomiarów będziemy wiedzieć, czy idziemy w dobrym kierunku.
- OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) – alternatywne podejście do kwestii ryzyka w IT.
- Metodologia organizacji ISACA – Risk IT (wymagana prosta rejestracja).
- Kalkulator ryzyka CVSS2 (Common Vulnerability Scoring System Version 2 Calculator. Liczy ryzyko, z którym związane są podatności techniczne, np. błędy w aplikacjach czy systemach operacyjnych; wartość często podawana np. w skanerach podatności).
- Baza informacji o zarządzaniu ryzykiem publikowana przez organizację ENISA.
Na koniec – raz jeszcze przypomnę, że analiza ryzyka, jak i samo zarządzanie ryzykiem, to procesy iteracyjne. Obrazowo pokazuje to choćby diagram zaczerpnięty z ostatniego, wyżej wspomnianego zasobu.
Michał Sajdak, michal.sajdak@securitum.pl
