-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

Czym jest analiza ryzyka IT – wprowadzenie

09 stycznia 2014, 13:36 | Teksty | komentarze 22

  • Czym jest analiza ryzyka IT?
  • Po co ją realizować?
  • Jak wystartować?

Zanim przejdziemy do odpowiedzi na te pytania – ważna uwaga: pojęcie „analiza ryzyka IT” może być rozumiane na wiele różnych sposobów. Jest to też obszar dosyć skomplikowany, zatem w tekście świadomie przyjąłem pewne uproszczenia, które jednak umożliwiają lepsze zrozumienie całego procesu. W artykule zamieszczam też informacje umożliwiające dalsze poszerzanie wiedzy (rozdział: Dalsze materiały).

Jeśli potrzebujesz wsparcia w realizacji audytu bezpieczeństwa IT – warto zapoznać się z ofertą Securitum.

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ć.

ra1

Wybrane elementy wchodzące w skład zarządzenia ryzykiem IT.

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.

ra2

Etapy analizy ryzyka.

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ŁAD

Zasó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:

owasp_risk

OWASP Risk Rating Metodology – obliczanie ryzyka.

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

PRZYKŁAD

Wykorzystamy powyższą tabelę dla zasobu „portal informacyjny”.
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.

    Analiza ryzyka uzupełniona o proces decyzji o ryzyku.

Analiza ryzyka uzupełniona o proces decyzji o ryzyku.

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:

Proces analizy ryzyka w kontekście zarządzania ryzykiem

Proces analizy ryzyka w kontekście zarządzania ryzykiem

 

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"

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.
  • risk_ksiazkaKsiąż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.
  • The-Failure-of-Risk-Management2Książ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.

risk_enisaNa 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<at>securitum.pl

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Darek

    Dobry artykuł!

    Odpowiedz
  2. nareszcze artykul ktory krok po kroku pokazuje analize ryzyka… bardzo w prosty i przystepny sposob jest wszystko opisane, super, przyda mi sie w pracy

    Odpowiedz
  3. józek

    Przeczytałem. Jedyny wniosek jaki udało mi się wyciągnąć to taki, że moje wszystkie działalności, firmy, projekty itd. nie miały prawa się udać i to prawdziwy cud, że mogę nic nie robić do końca życia xD

    Odpowiedz
    • Rozumiem że zrobiłeś analizę ryzyka swoich działalności? ;-)

      Odpowiedz
      • John Sharkrat

        A po co miał robić? W 99,99999% przypadków potrzebne to jak w Porsche dyszel.

        Odpowiedz
      • itakpowiem

        jako programista nie mam czasu na takie pierdoły, a kod się sam nie napisze, domyślnie dbam się o bezpieczeństwo, dorabianie polityki strachu i szacowanie tego strachu, niebawem przestaniemy spać… to nie robota dla coderów.

        Odpowiedz
        • „domyślnie dbam się o bezpieczeństwo” -> my obserwujemy zazwyczaj podejście „domyślnie olewam się o bezpieczeństwo” czy raczej „domyślnie niewiem co to bezpieczeństwo” :-)

          A analiza ryzyka właśnie po to jest żeby nie straszyć, tylko opierać różne decyzje na względnie twardych faktach.

          Odpowiedz
          • Tomek

            Wszystko rozbija się potem o klasyk „I accepted the risk” :)

          • Też Tomek

            Nie ma żadnego bezpieczeństwa, jeżeli jesteś celem zginiesz.
            Nie ma żadnych szans.

      • jozek

        Wow, to już 4 lata temu. Czas leci.

        Ale Was przyatakowali :D Oczywiście, że z punktu widzenia programistycznego (administracyjnego, sieciowego) analiza ryzyka nie ma najmniejszego znaczenia. Świat dąży do uproszczenia i optymalizacji, za programistów teraz myślą frameworki.

        Aktualnie zacząłem się zajmować inwestycjami. Analiza ryzyka przydaje się przy operowaniu kasą. Wiecie, jeżeli zespół programistyczny wyskakuje mi z informacją, że można zaimplementować coś przy użyciu GoLanga, a mój analityk mi powie „hej, szefie, według analizy GoLang obecnie ma sporo luk informacyjnych, sporo braków w dokumentacji, brak gotowych przetestowanych rozwiązań i specjalistów na rynku, jest dość spore ryzyko, że nie poradzimy sobie z naprawą błędów co przyniesie nam spore koszty i sporo czasu na research”, to ja sam się nie muszę zagłębiać dokładnie o co wogóle w GoLangu chodzi, żeby mieć odpowiedni pogląd, tylko zwracam się do leadera i przekazuje mu info: „ok, macie możliwość spróbowania, ale okrajacie to do wersji minimum i najpierw testujemy łącznie z zewnętrzną firmą”, SCRUM – chłopaki działają, dają mi MVP, krótki okres intensywnych testów i wynik źle/dobrze.

        Ale jak do mnie przychodzą chłopaki z implementacją Javy, to według gotowych analiz mogę śmiało im pozwolić na co tylko chcą, bo ryzyko jest minimalne.

        Podsumowanie? Analiza ryzyka w moim przypadku… wróć, my stosujemy szreoką analizę, nie tylko zagrożenia, ale czas, środki i zasoby okołoprocesowe, pomaga podejmować decyzje. I w sumie tyle.

        Dalej jestem przeciwko RODO, SRODO i innemu syfowi w celu „niby ochrony prywatności”. Jak mój team chciał wprowadzać ograniczenia dot. udostępniania danych w zeszłym miesiącu bo się naczytali sekuraka czy innego z3s (muszę, no sorry, muszę, to wasza wina ;p), to reklamodawcy nam zagrozili zerwaniem umowy, a użytkownicy mają to całkowicie w d. Przez pierwsze kilka miesięcy ludzie faktycznie zmieniali swoje ustawienia itp. teraz dostajemy tylko negatywny feedback, że ekraniki z akceptacjami cookiesów, rodo, srodo, grodo, frodo, hwdopo są za duże i zbyt irytujące i jakiś głąb jeszcze wymyślił odświeżanie cookiesów, bo się naczytał ISO, że tam wymóg aktualizacji danych pośrednich i metadanych jest.

        Średni czas wyświetlania komunikatów obowiązkowych – 3 sekundy na desktopach, ~2 sekundy na mobilnych (bo zajmują cały ekran xd), ilość akceptacji ~98.730%.

        Aktualnie jesteśmy na etapie robienia oprogramowania, które skanuje nasze CRMy i gity itd. żeby robiło z automatu dokumentację dot. wymaganych właśnie analiz bezpieczeństwa według RODO, żebyśmy w razie incydentów posiadali jakieś 2 miliony sztuk dokumentów udowadniających, że robilismy wszystko co w naszej mocy, by takim cudom przeciwdziałać.

        Chociaż widzę, że prawo i tak ma to w d. bo jeżeli takie firmy jak facebook dostają kary z RODO przy incydentach, mimo że wydają miliardy dolarów rocznie na bug bounty czy właśnie na cały dział prawno-zgodny, to nie ma większego sensu. Trzeba podpisać umowę z firmą ubezpieczeniową, wrzucić incydenty jako potencjalna strata dla firmy i wliczyć RODO w koszty.

        Komunizm, taki piękny.

        Odpowiedz
        • Olek

          Pocieszę Cię – w administracji musimy przeprowadzić analizy ryzyka z RODO, analizy ryzyka od strony zarządzania, co roku audyt zgodności z KRI, prowadzić rejestr czynności przetwarzania, pilnować upoważnień dla każdego byle stażysty, praktykanta byle jego zakres zadań się z tym pokrywał, na byle pierdołę obowiązek informacyjny i najlepiej z potwierdzeniem zapoznania się, bo w razie kontroli NIK trzeba udowodnić. Na stronach, jak piszesz – cookie info, zgodność z WCAG AA, klauzula o zgodności, wymaga się prowadzenia fora konsultacji społecznych, transmisje sesji rady gminy. uff pewnie mi jeszcze z 1/3 obowiązków umknęła. A najlepsze to, że małe urzędy nie mają budżetu na zlecenie takich audytów czy dokumentacji firmom zewnętrznym (dla przykładu ośrodek pomocy społecznej z 3 paniami obowiązują te same przepisy, co wielki urząd wojewódzki z działami IT ).

          Odpowiedz
  4. józek

    Teraz już tak ;_;

    Odpowiedz
  5. bl4de

    Każdego dnia dowiaduję się, jak mało jeszcze wiem… :/

    Odpowiedz
  6. Xavery

    Bardzo dobry artykuł, tzn. w moim przypadku uporządkował tę wiedzę, którą już posiadałem. Mam kilka pytań:

    1. Czy wykonywana w firmie samoocena przy pomocy programu wspierającego zarządzanie ryzykiem operacyjnym, to nie jest właśnie analiza ryzyka / identyfikacja?

    2. Jak podejść praktycznie do opisywanego zagadnienia? Siadam przy biurku, odpalam worda i co dalej? Wypisuję najpierw zasoby IT – nie wiem, tworzę tabelę wg uznania z kolumnami typu „nazwa zasobu” / „RTO” / „RPO” / potencjalne zagrożenia / plan awaryjny itd itp? Jak do tego wszystkiego podejść praktycznie?? Bo przecież to ma być cykliczny proces, a nie jednorazowa akcja, podczas której powstanie jakiś dokument pt. „analiza ryzyka IT”. Wysraczy raz na rok dokonać aktualizacji tegoż dokumentu i viola ? ;)

    3. W nawiązaniu do powyższego pkt2 to wszystko przypomina mi budowanie teorii na siłę do pewnych rzeczy. Czytam różne blogi nt ryzyk i sam się zastanawiam, kto to wszystko wymyśla? Jestem programistą, znajomość kodu jest naprawdę przydatna w praktyce, tworząc coś widzę efekt w postaci działającego programu. A te teoretyczne wywody, opasłe tomy na temat analizy ryzyka bardziej kojarzy mi się to wszystko z akacemickimi wywodami, niż czymś praktycznym, wprost do użycia na co dzień. Sama świadomość ryzyk to oczywiście konsekwencja codziennej pracy w firmie, gdzie chociażby tworząc budżet planuje się zakup pewnych rozwiązań, które będą w efekcie minimalizować ryzyko. Nie wiem, czy do tego potrzeba zatrudniać jakiegoś fachowca od Risk Management od razu ;) Nie uważacie, że czasami ludzie lubią sobie komplikować życie? Tak, nie jestem zwolennikiem nadmiernej papierologii :)

    Odpowiedz
  7. michal.sajdak

    Xavery: jeśli chodzi o definicje to jest to bardzo płynne :)

    Temat cykliczności – pierwszego podejścia. Jest to dość trudne do wytłumaczenia w komencie – w końcu są o tym aż całe szkolenia. Proponuję na start wybrać jeden zasób – np. aplikację i kilka standardowych zasobów + wybrać metodę jakościową. A później to iteracyjnie w razie potrzeby rozbudowywać. To na początek.

    Co do 3. rzeczywiście czasem jest to przesada, ale analizę ryzyka można zrobić niewielką / podstawową (często to zupełnie wystarcza), a czasem może to przytłoczyć wszelakie inne czynności związane z security w firmie. Swoją drogą czasem taka analiza to wymóg prawny i/lub pewnych regulacji, więc nikt nie dyskutuje ;) Często też są przypadki wdrożenia ISO2700X – ale efekt na bezpieczeństwo techniczne jest taki sobie żeby nie powiedzieć prawie zerowy ;)

    Sam też nie jestem zwolennikiem papierów, ale tzw. „kultura” security nakazuje żeby każdy mniej więcej wiedział czym jest analiza ryzyka i *w razie potrzeby* widział jak się do tego zabrać ;)

    Odpowiedz
  8. Przemek

    @Xavery:

    Ad 1. Ryzyko operacyjne to znacznie szerszy temat niż analiza ryzyka związanego z bezpieczeństwem IT. Analiza ryzyk bezpieczeństwa IT to składowa analizy ryzyka operacyjnego. Tak bym do tego podszedł.

    Ad 2. Najpierw proponuję poćwiczyć na mniejszych obiektach niż cała firma. Np. na pojedynczej aplikacji lub procesie za pomocą takiej metody jak modelowanie zagrożeń – finalnie i tak wyjdzie analiza zidentyfikowanych ryzyk. (https://www.owasp.org/index.php/Threat_Risk_Modeling i https://www.owasp.org/index.php/Application_Threat_Modeling). Jak będzie większa świadomość i czucie tematu, co idzie łatwiej/trudniej to można spróbować wyjść wyżej niż pojedyncza aplikacja/proces. Analiza ryzyka czy też Zarządzanie Ryzykiem w firmie to proces wymagający doświadczenia w tym. Każda firma jest inna i moim zdaniem należy ten proces do niej dopasować, ma on swoje niezmienne zasady, ale też na siłę nie ma co się trzymać tam gdzie nikt nie _zmusza_ by było _dokładnie_tak_ – np. regulator. Natomiast w praktyce nie spotkałem się by ktoś wymógł na kimkolwiek bez uzasadnienia jeden sposób działania/myślenia. Sama analiza ryzyka mówi o stosowaniu rozwiązań kompensujących – czyli takie, które wprost nie są rozwiązaniem (np. aktualizacja aplikacji z SQL Injection) tylko innym rozwiązaniem przysłaniającym podatność – np. Web Application Firewall, co będzie już podejściem niestandardowym, którego nie da się zastosować w każdej firmie tak samo.

    Odpowiedz
  9. Pasta do zębów

    Świetny artykuł. Dodałabym jeszcze ISO 27001 i kilka polskich publikacji, np. „Zarządzanie ryzykiem. Ujęcie interdyscyplinarne” (T.T. Kaczmarek, Difin).
    Nowa odsłona ISO27k z 2013 kładzie większy nacisk na kontekst organizacji, jak i samego ryzyka.
    W praktyce (z mojego doświadczenia), kontekst pojawił się już w iteracji 1′ (jakieś 2,5 roku temu) ;) AR jest czasem morderczo wymagająca – z każdej strony – nie tylko właściciela; dobrze prowadzona może sporo pomóc organizacji. Nie są potrzebne specjalne narzędzia – „poczciwy” excel wystarczy, jak i jego średnio zaawansowana znajomość. Pozdrawiam.

    Odpowiedz
  10. Artur

    Dzięki za zebranie w jednym miejscu tak wielu materiałów i odnośników do różnych podejść, znacznie to redukuje „polecenia”. Do tego bardzo wartościowy materiał w języku polskim. Mam nadzieję, że nie jedna polska firma, małego, średniego i dużego biznesu użyje tych zasobów do edukacji swojego personelu.

    Odpowiedz
  11. Łukasz

    Jest taka aplikacja do zarządzania ryzykiem. Simplerisk się nazywa ;)

    Odpowiedz
    • Paweł

      Simplerisk czy to w pełni bezpłatne i czy jest coś podobnego? po zainstalowaniu wygląda to całkiem fajnie ale trudne do modyfikacji.

      Odpowiedz
      • Wredziol

        Proponuję Excel – zwykle wystarcza i jest dość elastyczny ;)

        Mam wrażenie, że programów do analizy ryzyka szukają osoby, które przeraża konicznej pracy. Ale program tego nie zmieni. Może poprowadzi Was za rączkę, ale nie będziecie wiedzieć dokąd idziecie. I może się skończyć w ten sposób, że będziecie mieli pięknie wypełnione tabelki, ale nie będzie to miało żadnego przełożenia na praktyczny wynik analizy.

        Jeżeli nie jesteście międzynarodową korporacją, jeżeli nie musicie co miesiąc przedstawiać zarządowi ładnych wykresów – zostańcie przy Excelu.

        Odpowiedz
  12. Wredziol

    Stary ten tekst, lubię do niego czasami wrócić i widzę, że ale co najmniej dwie rzeczy się nie zmieniły:
    -nadal musimy zacząć od inwentaryzacji
    -działy IT nadal mówią: „a po co?”, „tego się nie da zrobić”, „to się ciągle zmienia”, „musimy kupić magiczny program, który spisze nam sprzęt”. Zamiast wziąć się do roboty i w kilka godzin lub dni sprawę załatwić.

    Odpowiedz

Odpowiedz