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).
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
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 I
