Wstęp
Zwinność w zarządzaniu projektami umożliwia szybkie i elastyczne reagowanie na zmieniające się warunki rynkowe oraz technologiczne. Implementacja metodyk zwinnych nie wystarczy, jeśli nie zostaną uwzględnione kwestie bezpieczeństwa.
Niniejszy artykuł uwzględnia wytyczne zawarte we francuskim poradniku stworzonym przez ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) oraz DINSIC (Direction Interministérielle du Numérique et du Système d'Information et de Communication de l'État).
Stopniowe badanie ryzyka w metodykach zwinnych
Wybrana metodyka w zarządzaniu projektem determinuje podejście do zarządzania ryzykiem. Projekty kaskadowe (waterfall) zakładają oddanie funkcjonalnego produktu na koniec projektu, dlatego środki bezpieczeństwa są definiowane i wdrażane dla docelowego produktu. W podejściu zwinnym, funkcjonalne części produktu są oddawane w trakcie trwania projektu. Należy dobrać adekwatne środki bezpieczeństwa dla każdego z poszczególnych etapów, kiedy produkt nie jest jeszcze kompletny.
Rozpatrywanie kwestii bezpieczeństwa w metodykach zwinnych ma więc charakter ciągły (przez cały czas budowania i doskonalenia produktu). Priorytet mają działania wynikające z oceny realnego ryzyka, a więc zakłada się także istnienie ryzyka szczątkowego, które będzie eliminowane wtedy, gdy produkt okaże się sukcesem.
Zwinny zespół i warsztaty analizy ryzyka
Zwinny zespół powinien charakteryzować się:
- szerokim zakresem kompetencji - członkowie zespołu mają różne umiejętności, które wspólnie wykorzystują w projekcie,
- samoorganizacją pracy – zespół decyduje o zadaniach i kolejności ich wykonywania,
- dążeniem do doskonalenia umiejętności indywidualnych i zespołowych,
- nakierowaniem na dostarczenie produktu wysokiej jakości.
Sercem procesu są warsztaty analizy ryzyka. W trakcie warsztatów omawiane są zagrożenia, które mogą mieć wpływ na użytkowników produktu. W trakcie spotkań podejmowane są decyzje, jak radzić sobie z omawianymi zagrożeniami.
Kiedy rozpocząć warsztaty?
Na rozmowę o bezpieczeństwie cyfrowym i na ocenę ryzyka, które jest związane z realizacją projektu, nigdy nie jest za późno. Fakt, że osiągnięto jeden z etapów rozwoju produktu, a nawet to, że produkt został udostępniony pierwszym użytkownikom, nie jest wystarczającym powodem, aby rezygnować z podjęcia kwestii bezpieczeństwa. Najlepiej jednak rozpocząć analizę ryzyka jeszcze przed początkiem prac wdrożeniowych.
W jaki sposób zorganizować warsztaty?
Zasadniczo spotkania zespołów projektowych mają charakter zamknięty. Efektywność warsztatów zależy od inicjatywy samych uczestników. Istnieje ryzyko, że obecność osób niezaangażowanych w produkt zmniejszy efektywność. Obecność eksperta od spraw bezpieczeństwa cyfrowego zwykle okazuje się niezbędna. Ekspert może odgrywać rolę wiodącą lub wyłącznie pomocniczą, dzieląc się swoją wiedzą w razie potrzeby.
Niezbędne jest przestrzeganie zasad skutecznej komunikacji, dlatego ważną rolę odgrywa moderator warsztatów, który:
- zapewnia wszystkim uczestnikom prawo równego głosu,
- dba o to, by grupa nie odbiegała od tematu,
- dba o utrzymanie dobrej atmosfery,
- dba o efektywne wykorzystanie czasu.
W trakcie pierwszych warsztatów należy określić zakres planowanej analizy. Należy ustalić to, za co odpowiada zespół i wykluczyć to, za co odpowiadają inne osoby. Nie należy wahać się przed zaplanowaniem głównych kroków, które uwarunkują kierunek podejścia do bezpieczeństwa cyfrowego. W trakcie kolejnych warsztatów zespół dokona szczegółowej analizy zagrożeń i zaplanuje odpowiednią reakcję.
Warsztaty nie powinny trwać zbyt długo, ale powinny odbywać się w regularnych odstępach czasu. Ważne, by poprosić uczestników o zapisane tego, co udało się ustalić podczas warsztatu (sformalizowanie wyników).
Co robić po każdych warsztatach?
Sformalizowanie wyciągniętych wniosków jest zalecane, aby zapewnić ciągłość pracy między warsztatami. Zespół może wybrać sposób, w jaki będzie dokumentował swoją pracę, przy czym francuscy specjaliści zalecają m.in.:
- wykorzystanie strony typu Wiki lub innej przestrzeni dokumentacyjnej, która jest łatwo dostępna dla wszystkich członków zespołu,
- uszeregowanie zagadnień wedle priorytetów, opisanych etykietami „ukończone” i ewentualnie „gotowe”.
Aktualizacja i doskonalenie wyników
Wyniki analizy ryzyka powinny być okresowo aktualizowane i doskonalone. Dla przykładu, w następujących sytuacjach:
- nastąpi zmiana w architekturze, np. dodanie lub modyfikacja komponentu technicznego,
- zostaną ujawnione innych dane niż te, które wcześniej były uważane za przetwarzane (np. dane osobowe, podczas gdy wcześniej ich nie zidentyfikowano),
- powstanie potrzeba poświęcenia uwagi funkcjonalności produktu, która jest szczególnie wrażliwa pod względem bezpieczeństwa,
- opinie użytkowników wymuszą dokonanie odmiennej oceny wartości biznesowej lub potrzeb w zakresie bezpieczeństwa,
- liczba użytkowników ulegnie znacznej zmianie, przez co zwiększy się ekspozycja na ryzyko.
Czym jest dług techniczny
Dług techniczny to sytuacja, w której zespół tymczasowo nadaje priorytet dostarczaniu nowej funkcjonalności kosztem praktyk projektowych, takich jak refaktoryzacja, automatyzacja obsługi testów czy dzielenie się wiedzą. Ta strategia może się opłacić, ale musi wynikać ze świadomego wyboru, a nie z braku kompetencji w niezbędnych dziedzinach. Intencją jest szybsze wypuszczenie nowej wersji produktu oraz uzyskanie informacji zwrotnej przed „spłaceniem” długu w późniejszym czasie.
Przez analogię możemy mówić o „długu zabezpieczeń”, gdy zespół jest zmuszony do odłożenia eliminacji pewnych ryzyk, aby doprowadzić do szybszego przetestowania produktu przez pierwszych użytkowników. Taka strategia również powinna wynikać ze świadomego wyboru, a nie z braku dbałości o analizę ryzyka czy z braku kompetencji w tym zakresie.
Aspekt bezpieczeństwa cyfrowego i uwzględnienie ekosystemu produktu w analizie ryzyka
Celem analizy ryzyka jest identyfikacja krytycznych scenariuszy ryzyka oraz środków bezpieczeństwa, które pozwolą na poradzenie sobie z nimi. Efektem tego ma być osiągnięcie poziomu bezpieczeństwa, który odpowiada rzeczywistym wyzwaniom i potrzebom w podejściu zwinnym.
Scenariusz ryzyka jest opisywany w postaci potencjalnego celowego nadużycia lub przypadkowego wydarzenia, które może mieć szkodliwy wpływ na wizerunek firmy, a nawet prowadzić do utraty klientów:
Przykład:
- Działanie użytkownika: „Rezerwuję przez Internet bilet na spektakl”.
- Celowe nadużycie: „Haker uniemożliwia klientom internetową rezerwację biletów na spektakl, zalewając serwer atakiem typu denial of service.”.
- Przypadkowy scenariusz: „Usługa internetowej rezerwacji staje się niedostępna z powodu błędu w aktualizacji oprogramowania serwera, której dokonuje firma dostarczająca system.”.
Wśród scenariuszy ryzyka, które należy uwzględnić w analizie ryzyka, szczególnie groźne są działania celowe. Analiza ryzyka powinna pozwolić na identyfikację konkretnych scenariuszy nadużyć, które nie są objęte środkami bezpieczeństwa. Analiza od pięciu do dziesięciu scenariuszy nadużyć, stanowi solidną podstawę tego procesu.
Udany atak na system informatyczny rzadko jest wynikiem wykorzystania pojedynczej luki. Zamierzone ataki zazwyczaj opierają się na sekwencyjnym podejściu, które w wykorzystuje kilka podatności systemu w skoordynowany sposób. Francuscy specjaliści przestrzegają przed typową, następującą sekwencją działań cyberprzestępców:
- wstępne rozpoznanie - atakujący zbiera informacje o celu wszelkimi możliwymi sposobami, ze źródeł otwartych (sieci społecznościowe) lub zamkniętych (biura),
- włamanie - atakujący włamuje się do systemu, np. przez e-mail z załącznikiem, który zawiera złośliwe oprogramowanie, SQL injection, niezałataną dziurę,
- wewnętrzne rozpoznanie - atakujący przeprowadza wewnętrzne działania rozpoznawcze w celu zmapowania architektury sieci, zidentyfikowania istniejących mechanizmów bezpieczeństwa, określenia podatności na atak oraz zlokalizowania krytycznych usług, informacji i komponentów,
- podnoszenie uprawnień - atakujący utrzymuje swój dostęp w tajemnicy, by rozwijać swoje możliwości działania w systemie, np. instaluje złośliwe narzędzia,
- wykorzystanie ataku – atakujący wykorzystuje swoje możliwości w systemie, np. do kradzieży danych lub tożsamości, oszustw, nadużyć, bądź sabotażu (usunięcie danych).
Migracje, chmury, systemy.
RODO w IT.
Niezbędne jest holistyczne spojrzenie na cały ekosystem organizacji. Taki ekosystem tworzy zbiór zainteresowanych osób, które działają wokół danego produktu i są dla tego produktu niezbędne. Należy zastanowić się nad odpowiedzią na następujące pytania:
- Czy jestem zależny od usług świadczonych przez ten podmiot? Czy ta relacja jest krytyczna dla mojego biznesu?
- W jakim stopniu zainteresowany ma dostęp do moich zasobów wewnętrznych (moich pomieszczeń, mojej sieci IT)?
- Czy usługi i sieci IT zainteresowanego są narażone na zagrożenia pochodzące z Internetu? Czy są wystarczająco bezpieczne?
- Czy mogę założyć, że intencje zainteresowanego wobec mnie są dobre?
Identyfikacja scenariuszy zagrożeń, zwłaszcza tych o charakterze intencjonalnym, wymaga pewnej wiedzy z zakresu bezpieczeństwa cyfrowego. W szczególności dotyczy to ataków wyrafinowanych, realizujących zaplanowaną sekwencję sposobów oddziaływania na kilka elementów – najczęściej technicznych i ludzkich – zarówno produktu, jak i jego ekosystemu. To właśnie z tego względu wsparcie zespołu przez eksperta w dziedzinie bezpieczeństwa cyfrowego może być czynnikiem sprzyjającym powodzeniu warsztatów, proporcjonalnie do stopnia skomplikowania produktu i ekosystemu.
Analiza ryzyka – podstawowe kryteria bezpieczeństwa
Francuscy specjaliści posłużyli się przykładem platformy Le.Taxi, której funkcją jest dostarczanie informacji o dostępności i geolokalizacji taksówek.
Podstawą metodologii są następujące kryteria, które są krytyczne dla funkcjonowania i zgodności organizacji:
- [D] dostępność: funkcjonalność jest dostępna na żądanie,
- [I] integralność: dane są niezmienne i kompletne,
- [P] poufność: informacje są ujawniane tylko osobom upoważnionym,
- [R] rozliczalność: dane zgromadzone w systemie, można wykorzystać w przypadku sporu.
Analiza ryzyka, krok 1 – historyjki użytkowników i ich potrzeby
W pierwszym kroku należy określić główne elementy funkcjonalności produktu dla użytkownika, a następnie oszacować związane z nimi potrzeby w zakresie bezpieczeństwa. Dokonuje się tego poprzez tworzenie tzw. „historyjek użytkownika” (ang. „user stories”).
Przykład:
Klient może złożyć zamówienie (wirtualnie wezwać taksówkę), ocenić zakończoną podróż lub zgłosić incydent.
Dla każdej historyjki użytkownika należy ustalić wagę potrzeb bezpieczeństwa. Stopień wagi potrzeb może być wyrażony przez prosty indeks, np. „ważna potrzeba” i „bardzo ważna potrzeba”. Potrzeba określona jako „bardzo ważna” oznacza, że jest niezbędna dla produktu.
Zespół rozpoczyna swoją pracę od historyjek użytkowników z założeniem, że środki bezpieczeństwa służą wartości dostarczanej użytkownikom. W istocie dla każdej ważnej potrzeby bezpieczeństwa związanej z historyjką użytkownika, istnieje co najmniej jedno niebezpieczne zdarzenie i co najmniej jeden scenariusz ryzyka, który może zagrozić wartości funkcjonalności.
Na przykładzie platformy Le.Taxi określono następujące historyjki użytkowników i związane z nimi potrzeby:
Analiza ryzyka, krok 2 – źródła ryzyka
Kolejnym etapem jest identyfikacja źródeł ryzyka: kto lub co może zagrozić potrzebom bezpieczeństwa. Źródła ryzyka mogą być przypadkowe lub celowe, zewnętrzne lub wewnętrzne.
Przykład:
- Konkurencyjny operator dążący do zdyskredytowania lub sabotowania usługi.
- Przestępcy dążący do pozyskania danych osobowych do realizacji nielegalnych celów.
Zaleca się identyfikację źródeł ryzyka o różnym charakterze i różnej motywacji, w celu zapewnienia reprezentatywnej próbki ryzyka, na podstawie której można budować scenariusze z różnymi zagrożeniami i metodami działań.
Przykłady motywacji, które stoją za celowymi atakami:
- ideologia, agitacja, propaganda – np. hakerzy aktywiści, cyberterroryści,
- zabawa – np. nastolatkowie, doświadczeni hakerzy,
- szpiegostwo, wywiad gospodarczy – np. agencje wywiadowcze, wyspecjalizowane biura,
- sabotaż, niszczenie – np. jednostki wyspecjalizowane, agencje wywiadowcze,
- oszustwo, zysk - cyberprzestępcy,
- złośliwość, zemsta – np. niezadowoleni pracownicy, nieuczciwi konkurenci.
Analiza ryzyka, krok 3 – zdarzenia, których się obawiano, i ich wpływ
W tym etapie identyfikowane są potencjalne zdarzenia, których wystąpienie jest niepożądane. W ten sposób tworzy się tzw. „zdarzenia budzące obawę (OZ)”.
Przykład:
Konkurencyjny przewoźnik wzywa taksówkę, podając się za klienta, co powoduje zbędny i kosztowny przejazd.
Obawa przed niepożądanym zdarzeniem (OZ) wynika z braku zaspokojenia potrzeby bezpieczeństwa, która została zidentyfikowana w historyjce użytkownika w kroku nr 1. Należy także określić wpływ danego zdarzenia (na bieżące zadania, bezpieczeństwo osobiste, finansowe, prawne, wizerunkowe, środowiska itp.) oraz szacowany stopień jego wagi. Skala ocen może być różna, np. zawiera trzy poziomy wagi: niski, średni, wysoki.
Zdarzenie budzące obawę należy określić w krótkim zdaniu, które ułatwia zrozumienie szkody związanej z rozpatrywaną historyjką użytkownika. Zaleca się, aby najbardziej prawdopodobne źródło ryzyka, które może spowodować zagrożenie, było wymienione w tytule OZ. W pierwszej kolejności warto zidentyfikować zdarzenia których konsekwencje byłyby trudne do przezwyciężenia.
Na przykładzie platformy Le.Taxi określono następujące potencjalne zdarzenia i ich wpływ:
Analiza ryzyka, krok 4 – ekosystem i elementy wrażliwe na ryzyko
W tym etapie należy określić, które z elementów produktu:
- służą lub przyczyniają się do realizacji historyjek użytkownika, które określono w kroku nr 1,
- oraz stać się celem dla źródła ryzyka, które zidentyfikowano w kroku nr 2.
Przykład:
Baza danych firmy (podatności możliwe do wykorzystania: dostęp do odczytu/zapisu z Internetu, częste modyfikacje).
Identyfikacja takich elementów może być zorganizowana w następujący sposób:
- infrastruktura fizyczna: budynki, lokale, przestrzenie fizyczne umożliwiające aktywność i wymianę informacji,
- organizacja: struktury organizacyjne, procesy biznesowe i pomocnicze, zasoby ludzkie,
- sprzęt i oprogramowanie: systemy komputerowe i telefoniczne, sieci telekomunikacyjne.
Kluczowe elementy, które należy zidentyfikować, to te, które przyczyniają się (bezpośrednio lub pośrednio) do realizacji historyjek użytkowników związanych z „ważnymi” potrzebami bezpieczeństwa.
Warto także ustalić, które z zainteresowanych osób w ekosystemie mogą zostać wykorzystane do ułatwienia ataku na dany element produktu. W pierwszej kolejności należy rozważyć zainteresowanych o znaczeniu krytycznym, którzy mają związek z jednym ze zidentyfikowanych elementów.
Przykład:
Dostawca usług IT zapewniający zdalne utrzymanie serwera z bazą danych.
Analiza ryzyka, krok 5 – historie nadużyć (abuser stories) i środki zaradcze
Funkcja IOD.
To się dobrze przekazuje
- źródła ryzyka ustalone w kroku 2,
- niepożądane zdarzenia, które określono w kroku 3,
- elementy wrażliwe na ryzyko ustalone w kroku 4.
Celem jest sprawdzenie: w jaki sposób źródło ryzyka - może wykorzystać podatność elementu wrażliwego - którego skutkiem będzie zdarzenie, którego się obawiano.
Przykład:
- Atakujący uzyskuje dostęp do danych osobowych klientów, podszywając się pod serwer lub wykorzystując niezałataną lukę.
- Klient w złej wierze wystawia kierowcy taksówki złą ocenę.
Każda historia nadużycia może być oceniona pod względem prawdopodobieństwa, a następnie krytyczności, w świetle tego jak dotkliwe będzie związane z nią zdarzenie.
Dla każdej historii nadużycia można określić odpowiedni sposób postępowania z ryzykiem, tj.: unikanie, ograniczenie, przeniesienie, akceptacja.
Jeśli ryzyko wymaga ograniczenia, należy określić środki bezpieczeństwa, które należy wdrożyć. Ich wdrożenie jest odnotowywane przez zespół.
Analiza ryzyka, krok 6 – ryzyko rezydualne
Ryzyko rezydualne to ryzyko, którego nie udało się całkowicie wyeliminować, pomimo wdrożenia środków bezpieczeństwa. Może być obecne już na etapie projektowania (zespół zaakceptował obecność ryzyka) lub zidentyfikowane w terminie późniejszym (np. podczas audytu zewnętrznego). Zespół powinien zamknąć warsztat analizy ryzyka określeniem ryzyka rezydualnego.
Dotyczy to:
- historii nadużyć, które zostały nie zaadresowane (akceptacja) lub które udało się ograniczyć tylko częściowo (np. wprowadzono środki bezpieczeństwa, które nie eliminują ryzyka),
- historii nadużyć, które zostały objęte transferem ryzyka (takie działanie zwykle nie eliminuje wszystkich negatywnych skutków np. ubezpieczenie nie obejmuje szkód w wizerunku).
Warto przeprowadzić swoistą konsolidację ryzyk rezydualnych, w celu dokonania aktualnej oceny stopnia ryzyka cyfrowego produktu. Najbardziej znaczące ryzyka rezydualne powinny zostać zidentyfikowane i wyróżnione jako priorytetowe. Cenną pomocą w obiektywnym i spójnym ustalaniu priorytetów dla ryzyk rezydualnych będzie np. stosowanie skal powagi, prawdopodobieństwa i krytyczności, powiązanych z progami akceptacji ryzyka. Dokonana ocena powinna być uzupełniona o wszelkie podatności rezydualne zidentyfikowane podczas audytów bezpieczeństwa.
Przykład raportu z warsztatów analizy ryzyka
Poniżej przedstawiamy raport z jednego z francuskich warsztatów analizy ryzyka dla usługi Le.Taxi.
Krok 1 – historyjki użytkowników:
Krok 2 – źródła ryzyka:
Krok 3 – potencjalne zdarzenia i ich wpływ:
Krok 4 – elementy systemu i ekosystem:
Krok 5 - historie nadużyć:
Krok 6 – ryzyko rezydualne:
Podsumowanie
Analiza ryzyka w metodykach zwinnych pozwala na bieżące reagowanie na kluczowe zagrożenia w poszczególnych etapach rozwoju produktu. Sercem tego procesu są warsztaty analizy ryzyka, w trakcie których identyfikuje się problemy, które należy zaadresować w sposób adekwatny do fazy rozwoju, w której znajduje się produkt.
W erze cyfrowej głównym polem walki o bezpieczeństwo jest obszar technologiczny. Z tego względu niewystarczające będą zabezpieczenia o charakterze prawnym i organizacyjnym, takie jak stworzenie odpowiednich procedur i skuteczne przeszkolenie personelu. To oznacza, że niezbędny będzie udział w procesie eksperta z dziedziny bezpieczeństwa cyfrowego. Jeżeli firma nie posiada odpowiednio rozbudowanego działu IT, powinna skorzystać z możliwości outsourcingu. Jeżeli firma posiada takie zasoby, często okazuje się, że zewnętrzne wsparcie stanowi skuteczną i wartościową pomoc dla działającego wewnątrz firmy personelu IT.
Sprawdź co pamiętasz - za poprawną odpowiedź nagroda!
Kiedy należy przeprowadzić analizę ryzyka dotyczącą nowego produktu?