Incydenty, incydenty bezpieczeństwa, incydenty związane z bezpieczeństwem informacji, incydenty związane z danymi osobowymi to tematy bardzo bliskie dla każdego zajmującego się bezpieczeństwem lub kogoś, kto chciałby się tym zajmować.
Niestety, ale zarówno na początku kariery przyszłego „bezpiecznika”, jak i później incydenty sprawiają wiele problemów z zarządzaniem nimi, bo zarządzanie incydentami bezpieczeństwa jest bardzo obszerną dziedziną wiedzy.
Przenikają się w niej obszary wysokopoziomowego zarządzania IT, technicznych aspektów administrowania systemami, informatyki śledczej (informatyki sądowej) czy wreszcie zagadnień prawnych, organizacyjnych, a nawet zarządzania kryzysowego czy wreszcie ochrony danych osobowych.
Celem niniejszego tekstu jest krótkie wprowadzenie do problemu zarządzania incydentami oraz wskazanie dalszych źródeł do ewentualnych własnych studiów nad zagadnieniem.
W literaturze funkcjonuje wiele definicji związanych z incydentami, ale wydaje się, że można je tutaj pominąć, bo bardziej istotne jest to, że na incydenty można patrzeć z trzech różnych stron:
- po pierwsze od strony normatywnej, czyli od strony obowiązujących, stosowanych mniej lub bardziej powszechnie norm, zbudowanych w oparciu o te normy systemów zarządzania bezpieczeństwem informacji (SZBI);
- po drugie od strony technicznej, czyli analizy zdarzeń zachodzących w administrowanych systemach, odróżnieniu anomalii od incydentów, które można zaklasyfikować jako incydenty bezpieczeństwa, określenia powiązanych z nim IOC (Indicator of compromise);
- po trzecie od strony prawnej, czyli strony wymagań prawnych wynikających z obowiązujących dokumentów strategicznych, ustaw, rozporządzeń itp.
Niestety, ale w życiu nie jest tak prosto, i w praktyce zarządzanie incydentami jest połączeniem trzech wyżej wymienionych stron, które muszą być stosowane jednocześnie.
Połączenie to generuje pierwszy podstawowy problem zarządzania incydentami.
Jak to wszystko razem połączyć?
Jak zbudować wspólny słownik pojęć, jak ujednolicić rozbieżne definicje i wydobyć z nich najbardziej istotne, spójne elementy? Incydenty w rozumieniu IT nie do końca są tym samym, co incydenty w rozumieniu Działu bezpieczeństwa, różne definicje;
Jak przełożyć język norm na język techniczny? Definicje incydentów zawarte w normach np. z rodziny ISO 27001 są mało techniczne, zwracają uwagę na bezpieczeństwo informacji, a więc na – semantycznie biorąc – coś znacznie bardziej ogólnego niż bezpieczeństwo systemu;
Jak połączyć logikę uregulowań prawnych (często mało konkretnych) z generalnym, stosunkowo miękkim podejściem norm a potem przełożyć to na procedury związane z zarządzaniem systemami, konfigurację urządzeń, itp.?
Jak stworzyć dokumentację systemu, która będzie dokładnie taka, jak ma być, nie za długa (bo nikt jej nie będzie czytał), nie za krótka (ma ujmować wszystkie istotne elementy z punktu widzenia zarządzanego systemu), nie skopiowana z innego systemu, ale dopasowana do tego, którego ma dotyczyć, oparta o rzetelną analizę ryzyka, a nie o wydumane podstawy.
Drugi problem, powiązany z pierwszym, ale znacznie wykraczający poza jego zakres, zawiera się w odpowiedzi na pytanie:
Po co mamy się zajmować incydentami?
Najbardziej oczywiste odpowiedzi są dwie:
- przepisy prawa wymuszają takie działanie,
- wdrożyliśmy i utrzymujemy system zarządzania bezpieczeństwem informacji, poddaliśmy lub chcemy poddać się certyfikacji, ewentualnie recertyfikacji.
Trzecia odpowiedź jest trochę mniej oczywista, bo nie jest wymuszona przepisami prawa, wdrożonym systemem, a opiera się na naszym własnym wyborze.
Zajmujemy się incydentami, bo chcemy to robić. Chcemy to robić, bo uważamy że wiedza o incydentach związanych z bezpieczeństwem naszych systemów jest istotna.
Tu pojawia się kolejny – trzeci – istotny problem związany z zarządzaniem incydentami, a mianowicie kwestia właściwego zrozumienia problemów opisanych wcześniej (problem 1 i 2).
Wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji (w ramach którego zarządza się też incydentami) nie podnosi naszego bezpieczeństwa. Jesteśmy zgodni z przyjętą normą, mamy wymagane procedury, zarządzamy incydentami zgodnie z daną normą i tyle. Aż tyle. Mamy przygotowane procedury na okoliczność incydentów, które wcześniej, czy później nastąpią. Ale czy mamy potencjał techniczny? Jeśli nie, to funkcjonowanie SZBI jest iluzoryczne.
Podobnie będzie ze zgodnością z przepisami prawa. Zgodność z przepisami prawa nie zapewni nam bezpieczeństwa. Zapewni nam to, że nie zapłacimy grzywny lub kary za niezrealizowanie przepisów. Znowu musimy postawić pytanie o potencjał techniczny, bez którego zgodność prawna jest trochę „papierowa”.
Zarządzanie incydentami na poziomie technicznym jest tym poziomem, który może rzeczywiście podnieść bezpieczeństwo organizacji. Należy jednak zwrócić uwagę, że brak powiązania mechanizmów technicznych z odpowiednimi procedurami (SZBI) czy realizacją wymogów prawnych sprawi, że będzie to rozwiązanie ułomne.
Zarządzanie incydentami musi być spójnym procesem, gdzie reprezentowane są wszystkie trzy strony podejścia do incydentów opisane na początku tekstu.
Jak napisano na początku niniejszy tekst miał być krótkim wprowadzeniem do problematyki, zasygnalizowaniem niektórych problemów, postawieniem pytań do dalszych rozważań.
Do tekstu dołączone jest zestawienie kilku wybranych pozycji (z mini opisem), które mogą pomóc w dalszym rozwijaniu zainteresowań. Nie uwzględniono pozycji dotyczących incydentów związanych z danymi osobowymi i incydentów związanych z zarządzaniem systemami IT (ITIL, ISO 20 000).
Incydenty bezpieczeństwa dotykają wszystkich istniejących na rynku systemów. Najbardziej szeroko pod kątem opisywanych środowisk podchodzi publikacja oznaczona jako [3], pozycja [5] dotyczy MacOsa, a [6] Linuxa.
Pod numerem [4] wymieniona jest norma ISO/IEC 27035. Norma ta nie jest powszechnie znana na rynku polskim, nie jest przetłumaczona na język polski, ale powinna być stosowana przez organizacje zajmujące się incydentami w sposób profesjonalny. Kolejną kwestią jest właściwe zabezpieczenie dowodów. Opisuje to szereg dokumentów normatywnych, ale one również są mało znane, ba, można mieć uzasadnione wątpliwości, czy stosują je nawet biegli sądowi [*PN-EN ISO/IEC 27037:2016-12 Technika informatyczna – Techniki bezpieczeństwa – Wytyczne do identyfikacji, gromadzenia, pozyskiwania i zachowania śladów cyfrowych (dowodowych); **PN-EN ISO/IEC 27041:2016-12 Technika informatyczna – Techniki bezpieczeństwa – Wytyczne do zapewnienia stosowności i adekwatności metody dochodzeniowej w związku z incydentem; ***PN-EN ISO/IEC 27042:2016-12 Technika informatyczna – Techniki bezpieczeństwa – Wytyczne do analizy i interpretacji śladu cyfrowego (dowodowego); ****PN-EN ISO/IEC 27043:2016-12 Technika informatyczna – Techniki bezpieczeństwa – Pryncypia i procesy w dochodzeniach związanych z incydentem; *****PN-EN ISO/IEC 30121:2016-12 Technika informatyczna – Nadzór nad strukturą ryzyka związanego z informatyką śledczą]. Szczegółowe omówienie wyżej wymienionych norm mogłoby być tematem na zupełnie inny tekst, ale wymienienie ich tutaj być może skłoni zainteresowanych czytelników do zapoznania się z tymi dokumentami.
Sugerowane pozycje do dalszej lektury
[1] Carvey H., Analiza śledcza i powłamaniowa. Zaawansowane techniki prowadzenia analizy w systemie Windows 7, Gliwice 2013 – znakomita książka wybitnego specjalisty, warto do niej sięgnąć mimo, że pochodzi z 2013 roku i w tytule odnosi się do Windows 7;
[2] Chojnowski A., Informatyka sądowa w praktyce, Gliwice 2020 – pionierska praca napisana przez długoletniego biegłego z zakresu elektroniki i informatyki, bogata w przykłady;
[3] Luttgens J, Pepe M., Mandia K.: Incydenty bezpieczeństwa. Metody reagowania w informatyce śledczej, Gliwice 2016 – pierwszy i jedyny do tej pory na polskim rynku wydawniczym podręcznik dotyczący reagowania i zarządzania incydentami;
[4] ISO/IEC 27035-1:2016 Information technology – Security techniques – Information security incident management – Part 1: Principles of incident management – podstawowa norma dotycząca zarządzania incydentami, w tej edycji rozbita na kilka części. Pierwsze wydanie z roku 2011 było w jednym zeszycie;
[5] https://taomm.org The Art of Mac Malware, bardzo interesujący, unikalny zbiór materiałów dotyczący pisania malware na macOS, analizy złośliwego oprogramowania itp., tworzony przez Patricka Wardle;
[6] Ziaja A., Praktyczna analiza powłamaniowa. Aplikacja webowa w środowisku Linux, Warszawa 2017 – książka z jednej strony pokazuje tradycyjne podejście informatyki śledczej, a z drugiej reagowanie na incydenty, koncentruje się na analizie powłamaniowej aplikacji webowej w środowisku Linux.
