21:38
12/3/2014

Poniższy artykuł autorstwa Janusza Nawrata nie tylko w sposób rzeczowy objaśnia na czym polega zarządzanie incydentami bezpieczeństwa informacji (m.in. poprzez dogłębny opis poszczególnych etapów obsługi incydentu i sposobu ich klasyfikacji), ale wskazuje również na co zwrócić uwagę przy wdrażaniu lub udoskonalaniu procesu postępowania z incydentami w firmie. Zapraszamy do lektury!

Autorem niniejszego artykułu jest Janusz Nawrat

Informacje ogólne

Efektywne reagowanie na incydenty bezpieczeństwa jest krytyczne dla zapewnienia bezpieczeństwa i ciągłości operacyjnej każdej, bez wyjątku organizacji. Choć — rzecz jasna — ogromnie istotna jest szeroko pojęta prewencja, to jednak nie jest możliwe całkowite wyeliminowanie incydentów, dlatego też będą one się zdarzały mimo podejmowanych różnego rodzaju czynności zapobiegawczych, nawet, jeśli te oparte będą o najdoskonalsze rozwiązania techniczne (techniczne systemy zabezpieczeń) i proceduralno-organizacyjne (standardy bezpieczeństwa, monitoring bezpieczeństwa systemów, efektywny nadzór, audyty, kontrole itp.).

Prawdopodobieństwo wystąpienia incydentów rośnie bowiem wraz ze wzrostem poziomu złożoności systemów, stopnia uzależnienia od nich procesów biznesowych, wraz ze zmianami w charakterze zagrożeń, ze wzrostem liczby identyfikowanych podatności (luk w bezpieczeństwie) w systemach informatycznych oraz niedotrzymaniem kroku tym zmianom przez proces budowania świadomości oraz pozyskiwania niezbędnej wiedzy na temat bezpieczeństwa przez użytkowników systemów i uczestników procesów, w których przetwarzane są wrażliwe informacje.

fot. Brian Klug @Flickr, lic. Creative Commons

fot. Brian Klug @Flickr, lic. Creative Commons

Efektywność procesu reagowania na incydenty bezpieczeństwa informacji zależy od wielu kryteriów. Są nimi w szczególności:

  • regulacje wewnętrzne (Polityki i Standardy), włącznie ze specjalistycznymi, szczegółowymi przepisami odnoszącymi się do postępowania z incydentami i zapobiegania ich występowaniu – ich jakość, kompletność i egzekwowalność, a także przepisy prawa powszechnego;
  • sprawny model wewnętrznej komunikacji w procesie postępowania z incydentami oraz takiż model komunikacji zewnętrznej, związanej ze zgłaszaniem naruszeń prawa, pozostających w związku z incydentów bezpieczeństwa informacji, do organów ścigania i organów wymiaru sprawiedliwości;
  • przeszkolony, doświadczony i kompetentny zespół, zajmujący się reagowaniem na incydenty bezpieczeństwa informacji wyposażony w wiedzę i narzędzia specjalistyczne;
  • narzędzia techniczne, wspomagające postępowanie z incydentami bezpieczeństwa informacji (na przykład sieciowe systemy zabezpieczeń, systemy logowania i korelacji zdarzeń, aplikacje i narzędzia do analizy powłamaniowej);
  • program szkoleń dla zespołu do reagowania na incydenty bezpieczeństwa oraz program szkoleń w tym zakresie dla wszystkich pracowników przedsiębiorstwa.

 
Znajomość kryteriów identyfikacji, klasyfikacji i oceny istotności incydentów bezpieczeństwa informacji jest bardzo ważna dla ograniczenia szkodliwości ich skutków, zasięgu i ewentualnego prawdopodobieństwa oraz częstości ponownego wystąpienia. Wiedza ta ma na celu podniesienie efektywności procesu postępowania z incydentami bezpieczeństwa, w tym zwłaszcza początkowych jego etapów, które w bardzo istotnym stopniu o efektywności decydują.

Zaawansowana diagnostyka i naprawa szkód po wystąpieniu incydentu jest poza zakresem tematyki tego artykułu. Należy jednak podkreślić, że te zagadnienia powinny być przedmiotem specjalistycznych i dostosowanych do konkretnych warunków operacyjnych, rodzaju, skali i typu działalności biznesowej przedsiębiorstwa, instrukcji przeznaczonych dla personelu zaangażowanego w postępowanie z incydentami bezpieczeństwa na późniejszych, eksperckich etapach procesu.

Choć na ogół rozpoznanie i wstępna klasyfikacja incydentu bezpieczeństwa (pod kątem jego typu i poziomu istotności) są często dokonywane przez personel pierwszej linii wsparcia w departamencie IT (zespół wsparcia informatycznego), tym niemniej każdy pracownik przedsiębiorstwa winien pamiętać, że obowiązuje go podstawowa zasada, w myśl której brak wiedzy i umiejętności poprawnego rozpoznania i klasyfikacji typu oraz poziomu istotności incydentu przez zgłaszającego incydent, nie może być przyczyną zaniechania powiadomienia odpowiedzialnych za bezpieczeństwo jednostek o zaistniałym incydencie lub podejrzeniu jego wystąpienia.

Ogólny opis procesu postępowania z incydentami bezpieczeństwa informacji

Na proces postępowania z incydentami bezpieczeństwa informacji składają się następujące etapy:

Planowanie i przygotowania

  • przygotowanie, zatwierdzenie przez najwyższe kierownictwo przedsiębiorstwa i wdrożenie regulacji wewnętrznych, dotyczących postępowania z incydentami bezpieczeństwa;
  • powołanie w przedsiębiorstwie zespołu reagowania na incydenty bezpieczeństwa informacji oraz wyposażenie go w narzędzia, wiedzę specjalistyczną oraz kwalifikacje niezbędne do sprawnego działania;
  • przeprowadzenie szkoleń dla zaangażowanego w proces personelu, zaplanowanie i przeprowadzenie odpowiednich kampanii uświadamiających skierowanych do wszystkich pracowników przedsiębiorstwa;

 
Reagowanie na incydenty bezpieczeństwa

  • ustalenie, czy zdarzenie ma charakter incydentu bezpieczeństwa informacji (rozpoznanie);
  • wstępna ocena incydentu bezpieczeństwa informacji (wstępna klasyfikacja i ocena poziomu istotności);
  • zgromadzenie informacji na temat incydentu bezpieczeństwa informacji oraz stanu systemów w momencie jego zaistnienia (zabezpieczenie materiału dowodowego i diagnostycznego);
  • opanowanie incydentu (powstrzymanie ataku, ograniczenie stopnia szkodliwości incydentu i postępu szkód z nim związanych);
    eliminacja skutków incydentu bezpieczeństwa;
  • przywracanie systemów do stanu poprawnego funkcjonowania (zabezpieczenie ciągłości działania).

 

Czynności końcowe

  • analiza zgromadzonego i zabezpieczonego wcześniej materiału dowodowego pod kątem przyczyn, przebiegu i skutków incydentu, udokumentowanie przeprowadzonych działań;
  • przygotowanie raportu końcowego na temat incydentu;
  • ocena bezpieczeństwa systemów dotkniętych incydentem;
  • weryfikacja aktualnie zastosowanych zabezpieczeń i ich skuteczności (ocena skuteczności środków prewencji na okoliczność zaistnienia w przyszłości podobnych incydentów);
  • ewentualne postępowanie sądowe lub dyscyplinarne – wyciąganie konsekwencji w stosunku do sprawców incydentu.

 
Celem etapu planowania jest zapewnienie późniejszego, sprawnego, skoordynowanego i systematycznego postępowania z incydentami bezpieczeństwa informacji, podejmowania decyzji o priorytetach działań oraz ograniczenie potencjalnych szkód, które mogłyby powstać skutkiem nieprawidłowego przebiegu czynności, zwłoki w podjęciu czynności lub błędów personelu zaangażowanego w proces.

Etap reagowania na incydent bezpieczeństwa ma na celu jak najszybsze przywrócenie ciągłości działania systemu dotkniętego incydentem, minimalizację szkód i zakłóceń działania innych systemów przez incydent bezpieczeństwa, zabezpieczenie systemu przed dalszymi incydentami, identyfikację przyczyn incydentu, oszacowanie szkód i wpływu incydentu na funkcjonowanie systemu, ewentualną aktualizację procedur i polityk stosownie do zaistniałych zmian w systemach zabezpieczeń, zebranie i poprawne zabezpieczenie materiału dowodowego.

Czynności końcowe służą ocenie zaistniałego incydentu bezpieczeństwa, oszacowaniu powstałych szkód, ocenie wpływu incydentu na bezpieczeństwo i działanie systemów, oszacowaniu ryzyka, rozważeniu potrzeb usprawnienia czy wdrożenia nowych mechanizmów zabezpieczeń oraz aktualizacji regulacji wewnętrznych.

Celem nadrzędnym procesu postępowania z incydentami bezpieczeństwa jest jak najszybsze przywrócenie ciągłości działania i integralności zaatakowanego systemu, powstrzymanie postępu ataku oraz ograniczenie materialnych i pozamaterialnych szkód.

Dokumentowanie i raportowanie, stanowią końcowy etap postępowania i służą gromadzeniu wiedzy na temat zaistniałych incydentów, ich przyczyn, przebiegu i skutków. Wiedza ta ułatwia lub wręcz umożliwia rozwiązywanie problemów bezpieczeństwa w przyszłości oraz stanowi materiał źródłowy do analizy ryzyka. Jest ponadto wykorzystywana w usprawnianiu technicznych, organizacyjno-proceduralnych i fizycznych środków bezpieczeństwa. Pozyskane i zabezpieczone materiały dowodowe powinny być traktowane w sposób gwarantujący ich integralność, autentyczność i poufność. Raport należy przygotować rzetelnie z myślą o jego wykorzystaniu w ewentualnym postępowaniu dowodowym w sprawach sądowych i dyscyplinarnych przeciwko sprawcom ataków.

fot. Brian Klug @Flickr, lic. Creative Commons

fot. Brian Klug @Flickr, lic. Creative Commons

Rozpoznanie i wstępna klasyfikacja kategorii incydentu bezpieczeństwa informacji

Incydentem bezpieczeństwa informacji jest zdarzenie, którego bezpośrednim lub pośrednim skutkiem jest (lub może być) naruszenie bezpieczeństwa aktywów informacyjnych. W szczególności incydentami bezpieczeństwa informacji są:

  • przypadki naruszenia poufności informacji wrażliwej (ujawnienie niepowołanym osobom, wycieki danych z systemów), ich integralności (uszkodzenie, przekłamanie, zniszczenie) i dostępności (brak dostępu do informacji w użytecznej postaci, na żądanie uprawnionych użytkowników);
  • niedostępność oraz błędne (niezgodne ze specyfikacją) działanie systemów informatycznych, zwłaszcza systemów i aplikacji krytycznych (z wyłączeniem kontrolowanych i zaplanowanych prac);
  • infekcje, dalsze propagowanie i szkodliwe działanie wrogiego oprogramowania (malware – kody wykazujące szkodliwe lub złośliwe działanie, do których zaliczają się miedzy innymi wirusy, robaki internetowe, konie trojańskie, spyware (oprogramowanie szpiegujące), keylogger (rejestrator klawiatury), rootkit, dialer, exploit (wytrych));
  • rozpoznanie, penetracja i próby omijania systemów zabezpieczeń;
  • ataki odmowy usługi na systemy informatyczne;
  • ataki nieuprawnionego dostępu do aplikacji, systemów oraz ataki eskalacji poziomu uprawnień w systemach;
  • kradzież lub umyślne zniszczenie urządzeń przechowujących informacje oraz nośników danych;
  • wyłudzenia informacji wrażliwych (lub próby wyłudzeń), takich jak np. poświadczenia tożsamości (w tym hasła dostępowe), informacje podlegające ochronie prawnej, takie jak dane osobowe czy tajemnice przedsiębiorstwa oraz – w przypadku banków dodatkowo – tajemnica bankowa.

 
Do rozpoznania i wstępnej klasyfikacji incydentów będą przydatne wyszczególnione poniżej typowe objawy wskazujące na prawdopodobne wystąpienie takowych:

dotyczące działania systemów:

  • komunikat od systemu operacyjnego o naruszeniu bezpieczeństwa, alarm systemowy, zdarzenie zarejestrowane w logach lub dziennikach zdarzeń;
  • powiadomienie (alarm) pochodzące z systemów zabezpieczeń (oprogramowanie antywirusowe, zapora sieciowa, system przeciwdziałania włamaniom (IPS) itp.);
  • zafałszowanie oraz całościowo lub częściowo usunięte logi ze standardowych miejsc ich zapisywania i deponowania;
    nagłe awarie i załamania systemów;
  • nieoczekiwany, istotny wzrost czasu odpowiedzi oraz spadek wydajności działania systemów;
  • wszelkie odbiegające od normy zdarzenia, takie jak zarejestrowane, liczne na ogół, przypadki wielu po sobie następujących, nieudanych prób logowań na konta systemowe i konta użytkowników uprzywilejowanych (na przykład administratorów);
  • podejrzana aktywność zarejestrowana na kontach systemowych lub kontach użytkowników uprzywilejowanych (administratorów), np. użytkownika „root” (systemy unixowe) lub „administrator” (systemy Windows), polegająca na masowym przeglądaniu i zmianach dokonywanych w plikach współdzielonych oraz występujących na współdzielonych udziałach sieciowych, czy – co ważniejsze – zmianach w plikach konfiguracyjnych i ustawieniach systemowych, istotnych z punktu widzenia bezpieczeństwa;

 
dotyczące kont użytkowników:

  • nieoczekiwane tworzenie lub usuwanie kont użytkowników w systemach, zmiana lub kasowanie haseł użytkowników;
  • wyłudzenia poświadczeń tożsamości i socjotechniki, na przykład rozmowy telefoniczne, w trakcie których dzwoniący żąda podania identyfikatorów, haseł itp. poufnych informacji, podając się zazwyczaj za administratora, pracownika zespołu wsparcia informatycznego lub osobę odpowiednio wysoko usytuowaną w hierarchii służbowej;
  • niemożliwość zalogowania się użytkownika na swoje konto spowodowana modyfikacją tegoż konta;
  • pojawianie się „dziwnych” komunikatów o błędach na stacji roboczej użytkownika;

 
dotyczące plików i danych:

  • nieoczekiwane tworzenie, modyfikacja i usuwanie plików;
  • nieoczekiwane tworzenie, modyfikacja i usuwanie danych w bazach i dokumentach;
  • pojawienie się na dyskach plików o podejrzanych nazwach (zwłaszcza istotnie różniących się od dotąd tam występujących);
    nieoczekiwana modyfikacja wielkości plików, dat modyfikacji i praw dostępu, zwłaszcza jeśli dotyczy ona plików wykonywalnych (programów);
  • modyfikacje plików systemowych (na przykład ważnych plików konfiguracyjnych);
  • nieoczekiwana, o przyczynach trudnych do wskazania, niedostępność plików i danych;
  • występowanie dokumentów z poufnymi informacjami we współdzielonych lub ogólnodostępnych katalogach (na przykład w katalogach tymczasowych i na udziałach sieciowych).

 
W pewnych przypadkach pojedynczy symptom, spośród wyżej wymienionych, wskazuje na incydent bezpieczeństwa, w innych dopiero kilka symptomów, układających się w określoną sekwencję i skorelowanych z sobą czasem wystąpienia, stanowi przesłankę do rozpoznania ciągu zdarzeń jako incydentu bezpieczeństwa.

Na możliwość wystąpienia ataku odmowy usługi mogą wskazywać:

  • całkowita niedostępność lub ograniczona dostępność systemu albo bardzo długie czasy jego odpowiedzi;
  • nieoczekiwana utrata połączenia systemu z siecią lub częste zmiany stanu takiego połączenia;

 
Na możliwość ataku przeprowadzanego przy pomocy wrogich kodów (malware) mogą wskazywać:

  • alerty od oprogramowania kontroli antywirusowej na komputerach;
  • nagły przyrost liczby wiadomości poczty;
  • zmiany szablonów dokumentów (edytory, arkusze kalkulacyjne, prezentacje);
  • usunięte, uszkodzone lub niedostępne pliki;
  • „dziwne” komunikaty o błędach na komputerze użytkownika;
  • bardzo wolno uruchamiające się programy;
  • niestabilność działania, zawieszanie się i załamania systemu;
  • nieznane procesy działające na komputerach;
  • duży wolumen generowanego przez komputer ruchu sieciowego;
  • nieuprawnione dostępy, zwłaszcza na konta użytkowników uprzywilejowanych

 
Na możliwość ataku nieuprawnionego dostępu mogą wskazywać:

  • obecność na dysku komputera nielegalnego oprogramowania narzędziowego do testów i przełamywania systemów zabezpieczeń;
  • wystąpienie nieuprawnionych zmian w konfiguracji systemu (rejestr, pliki konfiguracyjne itp.);
  • na ogół często po sobie następujące zmiany stanu systemu (na przykład restarty);
  • pojawianie się w systemie nowych kont użytkowników, na ogół kont użytkowników uprzywilejowanych;
  • nieuprawniona modyfikacja ważnych plików, zmiana znaczników czasowych plików (czas ostatniej modyfikacji) oraz praw dostępu (zwłaszcza plików wykonywalnych, bibliotek systemowych oraz plików konfiguracyjnych);
  • nieoczekiwana, duża aktywność rejestrowana na kontach do tej pory mało aktywnych; to samo konto wykorzystywane w tym samym czasie na wielu komputerach zlokalizowanych w różnym miejscach;
  • nieoczekiwane blokowanie dostępu do kont użytkowników i kont systemowych;
  • istotna zmiana w poziomie wykorzystaniu zasobów komputerów (przeciążenie procesora, wysycenie pamięci operacyjnej, zapełnienie systemów plików);
  • niedostępność określonych systemów dla ich legalnych użytkowników;
  • komunikaty od systemów zabezpieczeń (zapora sieciowa, oprogramowanie antywirusowe, systemy przeciwdziałania włamaniom itp.);
  • obecność na dyskach plików lub katalogów o „dziwnych” nazwach;
  • wystąpienie nieoczekiwanych wpisów do logów systemowych i aplikacyjnych,
  • zmiany i przekłamanie w bazach danych i dokumentach;

Pracownik przedsiębiorstwa, który sam nie potrafi właściwie rozpoznać incydentu, albo ma wątpliwości co do słuszności rozpoznania lub klasyfikacji, powinien zwrócić się o pomoc do odpowiednich jednostek zaangażowanych w proces zarządzania incydentami bezpieczeństwa. Będzie to najczęściej Service Desk IT oraz/lub jednostka w przedsiębiorstwie odpowiedzialna za bezpieczeństwo informacji.

Incydenty niedostępności informacji i systemów

Incydenty tego typu skutkują uniemożliwieniem lub istotnym ograniczeniem dostępu do systemów oraz zbiorów informacji dla uprawnionych do tego użytkowników.

Zgłaszaniu i raportowaniu, jako incydenty niedostępności systemów, powinny podlegać te zdarzenia, które odnoszą się do systemów serwerowych oraz urządzeń i systemów infrastruktury teleinformatycznej, głównie wspierających ważne dla ciągłości operacyjnej przedsiębiorstwa procesy. Nie podlega na ogół raportowaniu niedostępność aplikacji desktopowych (zainstalowanych na stacjach roboczych czy komputerach przenośnych typu oprogramowanie biurowe etc.), chyba że istnieją przesłanki, że ma ona związek z działaniem wrogiego oprogramowania.

Incydenty naruszenia poufności informacji

Naruszenie poufności informacji następuje w sytuacji jej ujawnienia niepowołanym osobom. Często jest ono konsekwencją uzyskania nieuprawnionego dostępu do systemów i zbiorów informacji. Zdarzeniem poprzedzającym nieuprawniony dostęp do systemu może być na przykład atak eskalacji poziomu uprawnień, podszycie się pod uprawnionego użytkownika, sieciowy „podsłuch” informacji, ataki na mechanizmy uwierzytelniające, czy w zaawansowanych technicznie przypadkach, ataki przez rejestrację i odkodowanie emisji elektromagnetycznej urządzenia (na przykład monitora).

Eskalacja poziomu uprawnień bywa często rezultatem ataków na podatne systemy (przez wykorzystanie luk w bezpieczeństwie oprogramowania) lub błędów konfiguracyjnych (profile uprawnień skonfigurowane niezgodnie z zasadą wiedzy koniecznej (need-to-know) i minimalnych uprawnień koniecznych (need-to-do)). Niezależnie od zastosowanego mechanizmu, efekt materializacji ryzyka jest ten sam – atakujący, swoim celowym działaniem, uzyskuje wysoki poziom uprawnień (na przykład uprawnienia administratora systemu). Dalsze konsekwencje mogą być bardzo poważne – od ujawnienia czy wycieku wrażliwych informacji, po destabilizację lub zatrzymanie systemów krytycznych i tym samym spowodowanie nieciągłości operacyjnej biznesu przedsiębiorstwa.

Prawdopodobna jest również taka sytuacja, kiedy pełnoprawny użytkownik systemu uzyskuje zbyt wysoki poziom uprawnień na skutek błędów działania aplikacji czy też błędów konfiguracji technicznych mechanizmów zarządzania uprawnieniami. Na ogół w takim przypadku, sam użytkownik zauważa, że posiada dostęp do zasobów informacji, który nie został mu jawnie przypisany i powinien zgłosić efekt swojej obserwacji jako incydent bezpieczeństwa informacji.

Naruszenie poufności informacji bywa także skutkiem podszycia się agresora pod uprawnionego użytkownika określonego systemu. Może ono być poprzedzone nakłonieniem użytkownika do ujawnienia jego haseł dostępowych (social engineering), zarejestrowaniem lub podglądnięciem wpisywanego hasła (bezpośrednio lub z użyciem kamery, przez zastosowanie rejestratora klawiatury czyli keyloggera, konia trojańskiego podstawionego lub dołączonego do programu do zmiany hasła, wirusa rejestrującego wpisywane hasła itp.), uzyskaniem dostępu do notatek, gdzie użytkownik zapisał hasła, sieciowym „podsłuchem” haseł (sniffer), atakami słownikowymi czy siłowymi na przechwyconą bazę haseł itp.

Innym sposobem naruszenia poufności informacji jest szeroko rozumiany ich „podsłuch”.

Możliwe sposoby „podsłuchiwania”, to rejestrowanie transmisji danych w sieci (przy pomocy snifferów), rejestrowanie aktywności klawiatury (przy pomocy keyloggerów), rejestrowanie zrzutów ekranowych lub przejmowanie pulpitu (przy pomocy oprogramowania do zdalnego zarządzania komputerem lub przez wirusy komputerowe), ataki podszycia się pod innego użytkownika) itp.

Incydenty naruszenia integralności informacji

Możliwe ataki tego typu, to między innymi przekłamania informacji w bazach i dokumentach, zafałszowanie plików konfiguracyjnych systemów, przekłamania logów, nieuprawnione zmiany lub podmiana treści stron WWW, podstawianie koni trojańskich w miejsce oprogramowania systemowego, narzędziowego czy aplikacji (infekcja plików systemu operacyjnego wrogim oprogramowaniem).

Wrogie oprogramowanie – malware

Incydentami bezpieczeństwa informacji są także: infekcje, propagacja i działanie wrogich kodów, czyli malware. Oprogramowanie złośliwe może charakteryzować się bardzo rożnymi mechanizmami i sposobem działania (modus operandi). Cechą wspólną malware jest – mimo jego ogromnej różnorodności – to, że oprogramowanie to zostało opracowanego z myślą o wyrządzaniu szkód, takich jak na przykład zakłócanie ciągłości działania systemów, kradzież wrażliwych informacji, działania przestępcze z wykorzystaniem komputera (tzw. e-fraudy na przykład w systemach transakcyjnych), niszczenie systemów, wysycanie zasobów komputera i sieci. Wrogie oprogramowanie można sklasyfikować jako przynależne do następujących kategorii:

  • wirusy komputerowe;
  • robaki internetowe (samoreplikujące się programy, które – w przeciwieństwie do wirusów – nie wymagają wektora propagacji kodu, co oznacza, że nie muszą one „doklejać się” do innych wykonywalnych programów, w celu rozprzestrzeniania się wraz z nimi i infekowania innych systemów – robią to samodzielnie);
  • konie trojańskie (kody, które podstawione w miejsce legalnych programów realizują wszystkie lub większość podstawowych funkcji tych drugich, ale dodatkowo, w różny sposób naruszają bezpieczeństwo zainfekowanego komputera, na przykład otwierając tzw. „tylne wejście” do systemu);
  • backdoory (tylne wejścia do systemu dla nieuprawnionych użytkowników);
  • stealware (oprogramowanie do kradzieży poświadczeń tożsamości użytkownika, takich jak identyfikatory kont użytkowników do różnych systemów, w tym systemów bankowości elektronicznej, hasła i kody dostępowe, kody autoryzacyjne, PIN-y);
  • keyloggery (programy do logowania aktywności klawiatury, które pozwalają na przechwycenie i ujawnienie agresorom na przykład haseł użytkowników);
  • spyboty (małe programy szpiegujące, dodawane do innych programów);
  • rootkity (programy służące do ukrywania plików i procesów, na przykład plików i procesów keyloggerów, trojanów czy innych złośliwych kodów, przed działaniem systemów operacyjnych oraz systemów zabezpieczeń);
  • exploity – wytrychy (programy lub skrypty wykorzystujące luki w bezpieczeństwie systemu, służące na ogół do przejęcia kontroli nad systemem, zablokowania dostępu do usług, pogorszenia parametrów transmisyjnych sieci itp.);
  • dialery (programy inicjujące nawiązywanie połączeń, przy pomocy modemu, dołączonego do komputera użytkownika, do różnych odpłatnych serwisów lub/i połączeń realizowanych w celu narażenia zaatakowanego użytkownika na znaczne, na ogół, koszty rachunku telefonicznego albo zdalne przejęcie kontroli nad zainfekowanym komputerem).

 

Rozpoznanie, penetracja i pomijanie systemów zabezpieczeń

Rozpoznanie, penetracja i próby omijania systemów zabezpieczeń stanowią kolejną kategorię incydentów bezpieczeństwa informacji.

Na ogół czynności rozpoznawcze (rekonesans) poprzedzają właściwy atak. Na tym etapie następuje identyfikacja rodzaju zabezpieczeń oraz możliwych do wykorzystania luk w zabezpieczeniach (podatności), wynikających zarówno z wad w kodzie oprogramowania, jak i błędów implementacyjnych oraz konfiguracyjnych.

Penetracja systemów zabezpieczeń może mieć na celu nieuprawniony dostęp do komputera, eskalację poziomu uprawnień, zatarcie czy usunięcie śladów włamań (zablokowanie lub wyłączenie funkcji zapisywania logów, usunięcie lub przekłamanie logów, ukrycie informacji o ataku w nadmiarze generowanych logów), zainstalowanie wrogiego oprogramowania (malware), przejęcie zdalnej kontroli nad zaatakowanym systemem i systemami zależnymi oraz powiązanymi lub przekłamanie konfiguracji mechanizmów zabezpieczeń komputera.

Pomocne w rozpoznaniu rekonesansu, penetracji bądź omijania systemów zabezpieczeń komputera jest śledzenie (i nielekceważenie) komunikatów i powiadomień o zdarzeniach pochodzących zarówno z systemu operacyjnego, jak i systemów zabezpieczeń funkcjonujących na komputerze (na przykład od osobistej zapory sieciowej).

Ataki odmowy usługi

Ataki odmowy usługi (DoS – Denial of Service) polegają na zablokowaniu lub ograniczeniu dostępu do sieci, systemów lub aplikacji przez wysycenie zasobów (przeciążenie procesora, wysycenie pamięci, pasma łączy sieciowych czy przestrzeni dyskowej na serwerach).

Przykładami tego typu ataków są:

  • całkowite wysycenie pasma sieci przez generowanie dużego wolumenu „śmieciowego” ruchu,
  • wysyłanie do atakowanego komputera złośliwie spreparowanych pakietów w celu spowodowania jego awarii,
  • wysyłanie do serwera żądań wykonania operacji niezgodnych ze specyfikacją protokołów sieciowych czy aplikacji,
  • przeciążanie serwera nadmierną ilością żądań połączeń czy nadmierną aktywnością w ramach sesji,
  • wysycenie przestrzeni dyskowej na przykład przez utworzenie tam plików o dużych rozmiarach.

 
Z uwagi na to, że pojedynczy komputer atakującego przeważnie nie jest w stanie wygenerować takiego wolumenu ruchu, który byłby w stanie zablokować dostęp do dużych farm serwerów lub wysycić pasmo nowoczesnych technologicznie sieci o wysokich przepustowościach, w celu zwiększenia skuteczności ataków odmowy usługi, agresor może wykorzystać wiele skoordynowanych z sobą komputerów (na przykład komputerów zombie tworzących razem botnet). Ze względu na geograficzne rozproszenie komputerów, wykorzystywanych do przeprowadzenia tego typu ataków, określa się je mianem rozproszonych ataków odmowy usługi (DDoS – Distributed Denial of Service).

W przypadku jakichkolwiek wątpliwości odnośnie rozpoznania czy klasyfikacji incydentu oraz sposobów pozyskania informacji diagnostycznych o incydencie i okolicznościach jego zaistnienia, należy niezwłocznie skontaktować się z powołanym w przedsiębiorstwie zespołem odpowiedzialnym za postępowanie z incydentami bezpieczeństwa.

Nieznajomość sposobu pozyskania tych informacji nie może być okolicznością usprawiedliwiającą zaniechanie zgłoszenia incydentu.

fot. Brian Klug @Flickr, lic. Creative Commons

fot. Brian Klug @Flickr, lic. Creative Commons

Zgłoszenie incydentu bezpieczeństwa informacji

Incydenty bezpieczeństwa informacji należy zgłaszać stosownie do obowiązujących w przedsiębiorstwie zasad i standardów.
W opisie incydentu należy zamieścić takie istotne informacje jak:

  • na czym polega incydent;
  • data i godzina wystąpienia incydentu;
  • imię i nazwisko oraz informacje kontaktowe (miedzy innymi numer telefonu) zgłaszającego;
  • jakiego systemu czy aplikacji dotyczy incydent;
  • nazwa i adres sieciowy komputera, w którym zaistniał incydent oraz ewentualnie analogiczne informacje o innych komputerach dotkniętych skutkami incydentu;
  • system operacyjny komputera (i ewentualnie jego wersja);
  • krótki opis konfiguracji sprzętowej komputera, jeśli jest on istotny dla diagnostyki i klasyfikacji incydentu;
  • opis incydentu (dokładniejsze informacje o incydencie);
  • kiedy wystąpił i czy jest powtarzalny (nieregularnie lub regularnie z określonym cyklem powtórzeń),
    ewentualny wpływ incydentu na funkcjonowanie systemu, w którym incydent wystąpił oraz w systemach z nim powiązanych i zależnych;
  • wstępne oszacowanie szkód, jeśli doszło do materializacji takowych;
  • czy czynnik wywołujący incydent (na przykład intruz albo oprogramowanie złośliwe) został zidentyfikowany i czy jego aktywność nadal trwa;
  • zależność systemu, w którym wystąpił incydent względem innych systemów dotkniętych skutkami incydentu;
  • komunikaty oraz (jeśli są dostępne) logi systemowe (w załącznikach);
  • ewentualnie zrzuty ekranowe (w załącznikach).

 
Umiejętność identyfikacji incydentów bezpieczeństwa, w tym odróżniania ich od zdarzeń, które nimi nie są, decyduje o możliwości szybkiego reagowania.

Jeśli użytkownik nie dysponuje kompletem informacji, albo kiedy ich skompletowanie byłoby czasochłonne i w istotnym stopniu wpłynęłoby na opóźnienie czasu zgłoszenia, dopuszczalne powinno być ograniczenie ilości przesłanej w zgłoszeniu informacji do następujących, podstawowych faktów:

  • na czym polega incydent;
  • data i godzina wystąpienia incydentu;
  • imię i nazwisko oraz informacje kontaktowe (miedzy innymi numer telefonu) zgłaszającego;
  • jakiego systemu czy aplikacji dotyczy incydent;

 
W toku dalszego postępowania, pozostałe informacje powinny zostać uzupełnione dla pełnej diagnostyki, oceny ryzyka i określenia dalszych wymaganych czynności w procesie.

Jak ocenić istotność incydentu bezpieczeństwa informacji?

Czynnikiem decydującym o skuteczności postępowania z incydentami bezpieczeństwa informacji jest nie tylko ich jak najwcześniejsze rozpoznanie, lecz także ocena poziomu istotności. Ocena ta jest podstawą określenia priorytetów, a tym samym właściwego zaplanowania dalszych działań naprawczych oraz priorytetów raportowania.

Kryteriami, które należy brać pod uwagę, dokonując wstępnej oceny poziomu istotności incydentów są:

  • wpływ incydentu na ciągłość operacyjną przedsiębiorstwa i funkcjonowanie jego krytycznych procesów biznesowych;
  • krytyczność systemów dotkniętych skutkami incydentu bezpieczeństwa;
  • wrażliwość informacji, których poufność, integralność czy dostępność naruszono (na przykład czy naruszono bezpieczeństwo informacji prawnie chronionej – tajemnicy bankowej, danych osobowych i tajemnicy przedsiębiorstwa);
  • rozległość wpływu incydentu na działanie systemów (nie działa jeden komputer, cała sieć itp.);
  • rozmiar szkód powstałych skutkiem incydentu;
  • poziom uzyskanych przez atakującego uprawnień, warunkujący skuteczność dalszych ataków;
  • koszt usunięcia i naprawy skutków incydentu bezpieczeństwa;
  • skąd atak nastąpił i jakie metody komunikacji zostały wykorzystane przez agresorów (z sieci Internet, z segmentu e-commerce (tzw. strefa DMZ, w której działają serwery przedsiębiorstwa, dostępne dla klientów), z sieci lokalnej (LAN), zdalnie – przez modem, przez połączenie VPN itp.);
  • prawdopodobieństwo wykorzystania lokalnych systemów jako wektorów do dalszej propagacji ataku na inne systemy wewnętrzne;
  • szacowany czas przywrócenia ciągłości działania dotkniętego incydentem bezpieczeństwa systemu;
  • zasoby wymagane do przywrócenia ciągłości działania systemu (personel, wsparcie firm zewnętrznych, wymagane dodatkowe czy zamienne urządzenia oraz oprogramowanie, czas odtwarzania systemów z kopii zapasowych itp.);
  • prawdopodobieństwo zaistnienia dalszych szkód (oraz wystąpienia ryzyk prawnych czy reputacyjnych).

 
Krytycznymi będą te incydenty bezpieczeństwa informacji, które dotykają infrastruktury teleinformatycznej i systemów, od których zależy ciągłość operacyjna przedsiębiorstwa.

Krytyczne też będą na pewno incydenty naruszenia poufności danych podlegających ochronie z mocy obowiązującego prawa powszechnego – tajemnicy bankowej, danych osobowych oraz tajemnicy przedsiębiorstwa.

Kierując się wrażliwością informacji, należy sklasyfikować jako incydent o wysokim poziomie istotności, nieuprawniony dostęp do komputera użytkownika końcowego, na którego lokalnym dysku były przechowywane informacje wrażliwe mimo, że w innych okolicznościach, z braku tych informacji, tenże nieuprawniony dostęp byłby prawdopodobnie traktowany jako incydent bezpieczeństwa niskiego ryzyka.

Skala skutków incydentu decyduje o jego poziomie istotności w tym sensie, że – na przykład – zainfekowanie wirusem jednej stacji będzie oceniane jako incydent bezpieczeństwa niskiego ryzyka, a masowa infekcja wielu komputerów przedsiębiorstwa będzie z całą pewnością incydentem wysokiego ryzyka.

Postępowanie ze zdarzeniami, które nie są incydentami bezpieczeństwa informacji

W przypadku zgłoszenia przez pracownika przedsiębiorstwa takiego zdarzenia, które po bliższym zbadaniu okazuje się nie być incydentem bezpieczeństwa, zgłaszający powinien otrzymać informację o tym fakcie i o zakończeniu dalszego postępowania w sprawie obsługi zgłoszenia, w komunikacji zwrotnej od jednostki odpowiedzialnej za bezpieczeństwo.

Postępowanie w przypadku problemów z identyfikacją, klasyfikacją i oceną istotności incydentu

W przypadku problemów z rozpoznaniem, klasyfikacją lub określeniem poziomu istotności incydentu, zgłaszający powinien zwrócić się z zapytaniem do jednostki odpowiedzialnej w przedsiębiorstwie za bezpieczeństwo informacji.

Brak wiedzy i umiejętności poprawnego rozpoznania i klasyfikacji oraz oceny poziomu istotności incydentu po stronie zgłaszającego nie może być przyczyną zaniechania powiadomienia jednostek odpowiedzialnych w przedsiębiorstwie o zaistniałym incydencie lub podejrzeniu wystąpienia takowego.

Autorem niniejszego artykułu jest Janusz Nawrat


Przeczytaj także:

41 komentarzy

Dodaj komentarz
  1. Świetny artykuł! Od dawna poszukiwałem tekstu, który zebrałby całość incident handlingu w jednym miejscu w przystępnej formie i po polsku. Brawo! Już rozesłałem chłopakom z IT.

  2. Dał bym piwo za tego posta ale nie widzę ikonki w rogu ;)

    • Może dlatego, że zagubiła się w potoku zdań? ;P

    • Przepraszam, że artykuł do krótkich form wypowiedzi raczej nie należy ;)

  3. Bardzo ciekawy artykuł. Mam pytanie do Pana Janusza; czy mógłby Pan polecić jakieś dobre książki z tematyki reagowania na incydenty. Interesuje mnie podejście zarówno techniczne (zwłaszcza nakierowanie na odpowiednie narzędzia wspomagające obsługę tych procesów) jak i podejście ,,managerskie”, czyli wskazówki jak szybko i tanio ;] wdrożyć nawet prostą wersję zarządzania incydentem.

    • Technicznie – sieciowo, polecam książkę Bejtlicha
      The Practice of Network Security Monitoring: Understanding Incident Detection and Response

      Krótka recenzja sprzed miesiąca:
      http://nsm.lubas.org/179/recenzja-the-practice-of-network-security-monitoring-understanding-incident-detection-and-response/

    • Jest kilka fajnych książek. W weekend przeglądnę swoją biblioteczkę i wrócę z rekomendacjami. Obiecuję.

    • Jest trochę wartościowej literatury na tematy Security Incident Handlingu i to postrzeganego zarówno z perspektywy technicznej, proceduralno-organizacyjnej, jak i managerskiej. Zachęcam jednak, by przed lekturą zacząć od spisania, jakie mamy oczekiwania względem tego, co planujemy wdrożyć w firmie, bo mając klarowne intencje, łatwiej szuka się sposobów i narzędzi, by je wcielić w czyn. Wiadomo na przykład, że nasz Security Incydent Handling będzie inaczej wyglądał, kiedy – załóżmy – będziemy go realizowali w ramach całkowitego outsourcingu, niż wtedy, gdy będziemy mieli zamiar polegać wyłącznie na własnych zasobach i know-how albo na częściowym outsourcingu.

      Model biznesowy procesu to jeden z argumentów. Inne, które powinniśmy wziąć pod uwagę to między innymi:

      • Zakres działania (incydenty wewnętrzne versus incydenty w systemach e-commerce, działanie dla pewnych jednostek przedsiębiorstwa versus wszystkich jego struktur organizacyjnych);
      • Zasięg geograficzny (krajowy versus międzynarodowy);
      • Tryb działania (24 godziny na dobę versus tylko godziny robocze);
      • Liczebność zespołu, podział ról i odpowiedzialności w zespole oraz jego struktura i lokalizacja geograficzna;
      • Kompetencje zespołu (wszystkie etapy cyklu obsługi incydentu versus niektóre etapy tego cyklu, wymagany poziom kompetencji, podział kompetencji);
      • Budżet;
      • Narzędzia;
      • Kooperacja ze strukturami zarządzania kryzysowego i strukturami BCM;
      • Wymagania prawne i wymagania regulatorów branżowych (na przykład KNF w bankach);
      • Uwarunkowania organizacyjne i techniczne wynikające ze współpracy z podmiotami zewnętrznymi, w tym operatorami telekomunikacyjnymi, operatorami ośrodków przetwarzania danych i organami wymiaru sprawiedliwości.

      Mógłbym długo pisać na ten temat, ale nie chciałbym zanudzać mniej cierpliwych czytelników.

      Kwestie proceduralno-organizacyjne są przyzwoicie omówione w książce: “The Computer Incident Response Planning Handbook: Executable Plans for Protecting Information at Risk” autorstwa teamu: N.K. McCarthy, Matthew Todd, Jeff Klaben.
      Zapowiadane jest też trzecie wydanie niezłej książki: “Incident Response and Computer Forensics” – autorstwa Chrisa Prosise, Kevina Mandia i Matta Pepe.
      Kwestie dotyczące zarządzania są poruszone w książce: “Computer Incident Response and Forensics Team Management: Conducting a Successful Incident Response” autorstwa Leightona Johnsona.

      Sprawom technicznym poświęconych jest wiele książek, bo to istny ocean tematów. Chętnie bym coś polecił, ale wcześniej musiałbym wiedzieć, jakie konkretnie tematy interesują czytelników – diagnostyka, zabezpieczanie i analiza materiału dowodowego, analiza wsteczna, analityka zdarzeń, analiza malware, development narzędzi wspomagających incydent handling itp.

      Osobiście polecam też – już poza tematyką ściśle związaną z obsługą incydentów – książkę „Carry On: Sound Advice from Schneier on Security” autorstwa oczywiście starego dobrego Bruce’a Schneiera.

      Życzę miłej lektury.

  4. Pozdrawiam Pana Janusza i przyłączam się do prośby o literaturę.

  5. NIST SP 800-61

  6. Tylko żeby to wszystko spełnić potrzeba:
    1. Czasu
    2. Pieniędzy
    3. Wiedzy
    A tego nasi decydenci w państwie/firmach nie rozumieją.

    • Mam swoje przemyślenia i sprawdzone w praktyce metody, jak wspomóc decydentów w podejmowaniu decyzji o sponsorowaniu inicjatyw spod znaku Security :-)

    • Muszę dodać, że planując rozwiązania pod incydent handling, nie robimy tego w oderwaniu od innych ważnych procesów związanych z zarządzaniem bezpieczeństwem systemów informatycznych w firmie. Musimy na przykład powołać do życia solidny proces zarządzania podatnościami i wyposażyć ludzi w kompetencje do przeprowadzania testów podatności i pen-testów. To działa synergistycznie, bo narzędzia i know-how z tej „działki” wnoszą bez wątpienia potężną wartość dodaną do incydent handlingu. Weźmy inny przykład – zarządzanie zdarzeniami. Jeśli zainwestujemy (a powinniśmy) w rozwiązania klasy SIEM i wyposażymy ludzi w wiedzę i umiejętności niezbędne do biegłej analizy zdarzeń, to przy tej okazji od razu w niebo szybują nasze kompetencje i „narzędziownia” w dziedzinie zarządzaniu incydentami. Dalszych przykładów mógłbym podać wiele.
      Jeśli chodzi o czas wdrożenia i wysiłek potrzebny do tego, by zbudować porządny incydent handling, to weźmy pod uwagę, że świat gna do przodu, a czas i tak biegnie, nie czekając na nikogo. Więc jeśli nie będziemy się rozwijać, to za kilka lat niechybnie ktoś „zgasi po nas światło”.
      Jeśli zaś chodzi o środki, to od tego jest szefostwo Security, żeby chociaż usilnie starać się je pozyskać :-) od najwyższego kierownictwa.

    • A ja znów wrócę do pracy u podstaw co zrobić by dojść do SIEMa (o ile naprawdę będzie to konieczne), a po drodze zbierać kolejne “sprawności” i zostać świetnym harcerzem – defensywnym bezpiecznikiem.

      Nie będę się rozpisywał, polecam następujące źródła:

      http://chuvakin.blogspot.com/2010/02/logging-log-management-and-log-review.html
      http://raffy.ch/blog/2010/06/07/maturity-scale-for-log-management-and-analysis/

    • To prawda, że nie zawsze będziemy potrzebowali rozwiązania klasy SIEM z najwyższej półki (na przykład ArcSight). W pewnych okolicznościach starczy nam narzędzie o skromniejszych możliwościach (na przykład Splunk). Nawet, jeśli zdecydujemy się na SIEM-a, to tutaj też mamy sporo pytań, na które trzeba sobie uczciwie i wyczerpująco odpowiedzieć przed “otwarciem portfela” i wydaniem (niemałych) pieniędzy. Przykładowo, trzeba sobie odpowiedzieć na takie pytania jak:
      (1) Czy stać mnie na system SIEM-a z prawdziwego zdarzenia?
      Pytanie to nabiera szczególnego znaczenia w dobie obostrzeń i cięć budżetowych. Choć nie ulega wątpliwości, że nie powinno się oszczędzać na czymś tak ważnym jak bezpieczeństwo, to jednak realia ekonomiczne są jakie są i takimi należy je postrzegać, nie zaś takimi, jakimi chcielibyśmy, żeby były. Mówiąc o kosztach, trzeba wziąć pod uwagę nie tylko koszty zakupu, wdrożenia i utrzymania lecz także koszty skalowania i rozwoju systemu. Ważnym elementem w strukturze kosztów jest także pamięć dyskowa na przechowywanie danych operacyjnych i być może także archiwalnych. O tym także trzeba koniecznie pamiętać przy wycenie.
      (2) Czy system, którego wybór rozważamy, będzie potrafił nas wspierać na każdym etapie naszego procesu zarządzania zdarzeniami bezpieczeństwa?
      Chodzi tutaj o takie funkcje jak klasyfikacja zdarzeń, normalizacja, korelacja, ocena ryzyka, monitoring on-line, wykrywanie nieprawidłowości, detekcja złożonych incydentów bezpieczeństwa o wieloetapowym i wielowątkowym przebiegu, diagnostyka przyczyn zdarzeń, analizy forensicowe, zabezpieczenie dowodów po incydentach, raportowanie, współdziałanie z systemami helpdeskowymi, notyfikacja różnymi kanałami o wystąpieniu zdarzeń (poczta, pop-up, SMS itp).
      (3) Czego dokładnie spodziewamy się po procesie zarządzania zdarzeniami bezpieczeństwa w naszej organizacji oraz jego interakcjach z innymi procesami?
      (4) Czy źródłami danych o zdarzeniach będą jedynie systemy standardowe, to znaczy takie, dla których system SIEM dysponuje predefiniowanymi mechanizmami pozyskiwania i przetwarzania logów (na przykład urządzenia sieciowe, urządzenia i systemy zabezpieczeń, systemy operacyjne itp.), czy też rozważamy podłączenie jako źródeł zdarzeń także systemów niestandardowych, w tym aplikacji i systemów transakcyjnych?
      W tym drugim przypadku będziemy musieli zmierzyć się być może z ogromnym wyzwaniem. Trzeba będzie opracować specjalnych agentów, zdolnych do czytania i poprawnej interpretacji nieraz bardzo specyficznych logów aplikacji. Specyficznych w sensie struktury, wielkości, miejsca i sposobu deponowania, mechanizmów transportowych itp. Problem staje się tym poważniejszy, że – zwłaszcza w już istniejących i produkcyjnie działających systemach – logi nie zawsze pozostają zgodne ze standardami. Musimy być przygotowani na wykonanie ogromnej pracy na etapie kontroli jakości logów i korygowania zidentyfikowanych nieprawidłowości, które często – pod bliższym zapoznaniu się – okazują się być prawdziwym bałaganem, niełatwym do ogarnięcia. Z nowo budowanymi aplikacjami rzecz jest oczywiście dużo prostsza, bo w tym przypadku specyfikacja wymagań bezpieczeństwa powinna wymuszać odpowiedni standard logów od samego początku cyklu ich rozwoju.
      (5) Czy potrzebny jest nam system oparty na agentach, czy system bezagentowy?
      System oparty na agentach posiada wiele zalet, z których najistotniejsze to: (A) możliwość bezprzerwowego działania bez utraty zdarzeń (w trybie off-line) kolektora danych, w sytuacji chwilowego braku połączenia z sercem systemu czyli z serwerem zarządzającym i repozytorium zdarzeń; (B) możliwość wstępnego parsowania, normalizacji, zabezpieczania integralności i znakowania znacznikiem czasowym logów już po stronie agenta; (C) szyfrowanie transmisji do managera (serwera zarządzającego) i repozytorium logów. Oczywistą wadą systemu ‘agentowego’ jest potrzeba instalacji agentów dla niestandardowych źródeł zdarzeń, ale jest to wada o marginalnym znaczeniu, jeśli weźmie się pod uwagę korzyści, rozwiązania ‘agentowego’.
      (6) Czy potrzebujemy systemu działającego w architekturze podwyższonej dostępności i niezawodności, czy system ma działać w strukturach hierarchicznych?
      (7) Czy potrzebujemy systemu potrafiącego przetwarzać logi o rozmiarach przekraczających maksymalny rozmiar logów Sysloga, wynoszący 1024 bajty?
      (8) Czy planujemy deponowanie logów w bazie danych czy w płaskich plikach? Jak zamierzamy zapewnić logom integralność i poświadczyć ich autentyczność, a co za tym idzie wartość dowodową w ewentualnych postępowaniach sądowych i dyscyplinarnych po incydentach bezpieczeństwa?
      (9) Jak będziemy archiwizować logi?
      (10) Gdzie znajduje się granica skalowalności naszego systemu SIEM?
      (11) Kto ma być beneficjentem wiedzy zgromadzonej w systemie SIEM?
      Tutaj chodzi w szczególności o bezpieczną dystrybucję wiedzy do jej odbiorców i zapewnienie im dostępu do systemu w zgodzie z zasadą wiedzy koniecznej w oparciu o paradygmat Role Based Access Control.
      (12) Jakich narzędzi wizualizacji i prezentacji treści (raporty, dashboardy etc.) będziemy potrzebować?
      (13) Czy i jakie aplikacje chcemy budować na bazie systemu SIEM?

      To tylko niektóre z ważnych pytań, które należy zadać i uczciwie na nie odpowiedzieć przed wyborem takiego czy innego rozwiązania. Pełną listę pytań i matrycę oceny każda organizacja musi opracować sama, biorąc pod uwagę lokalne uwarunkowania, potrzeby, założenia projektowe czy wreszcie preferencje.

      Konkludując: wybieramy system SIEM nie tylko dlatego że dobrze wypadł w analizie Gartnera lecz przede wszystkim pod kątem możliwie jak najściślejszego jego dopasowania do specyfikacji naszych wymagań.

    • Tak po prawdzie to podniesione kwestie względem SIEMa nie dotyczą tylko niego.

      To samo tyczy się innych narzędzi do zarządzania logami i nie posiadając SIEMa trzeba się z nimi zmierzyć. Nie potrzeba dużych inwestycji (licencje i oprogramowanie) by osiągnąć znakomitą część, w mojej ocenie tą najbardziej wartościową, działki monitorowania i obsługi incydentów.

      Dodatkowo: mając SIEMa, a nie mając narzędzi do sprawnego zarządzania logami może się okazać, że potrafimy wykrywać incydenty, ale mamy kłopot z ich szybkim i wygodnym (możliwie automatycznym i bezobsługowym) wyjaśnianiem. SIEMy zazwyczaj nie pozwalają na szybkie przeszukiwanie logów ad-hoc, ich wdrożenie zazwyczaj trwa długo (miesiące) zanim zobaczymy pierwsze efekty na poziomie zaawansowania wyższym niż alarmy opierające się na zdarzeniach z AV, ze dana stacja jest zarażona ;-) Nie mówiąc już o monitoringu w oparciu o logi aplikacyjne spoza dedykowanych systemów bezpieczeństwa – tutaj musimy uzbroić się w cierpliwość, siebie i wszystkich, którzy oczekują na rezultaty, a w końcu musieli zainwestować sporo $ w tą działkę.

      Reasumując: wg. mojego doświadczenia znakomitą większość monitoringu bezpieczeństwa i sprawną obsługę incydentów da się zrobić bez SIEMa i dużego budżetu na narzędzia.

    • Tak, to prawda. Czasem do szybkiego przeszukania logów starczy Splunk lub narzędzia na bazie regexp-ów, napisane samodzielnie w ulubionym języku skryptowym.
      Jednak logika korelacyjna SIEM-a bywa nie do przecenienia przy detekcji incydentów o rozproszonym w czasie i miejscu przebiegu, na przykład przy incydentach z wykorzystaniem malware APT.

    • Jeszcze nie miałem przyjemności spotkania się z regułami korelujacymi zdarzenia w SIEMie, których nie da się zaimplementowac/ułożyć w języku Splunka czy podobnych narzędzi, natomiast widziałem takie, których w SIEMach szybko nie da napisać bo trzeba np. dołożyć parser co w tych rozwiązaniach jest bardziej czasochłonne, często wymaga wsparcia serwisu lub dewelopera parserow w firmie.

      Wartością dodana SIEMow jaka ja widzę jest dostarczony przez producenta opis i kategoryzacja zdarzeń dla popularnych systemów i urządzeń. W mojej opinii SIEM to wisienka na torcie, a wczesniej dużo pracy by ten system miał sens.

      Mój sceptyczny punkt widzenia wynika z dotychczasowych doświadczeń ze SIEMami oraz opiniami kolegów, którzy mieli lub mają wdrożenia u siebie.

      Jeśli ktoś ma udane wdrożenie SIEMa i chciałby o tym porozmawiać bardzo chętnie wymienię się doświadczeniami.

    • Prawda jest taka, że narzędzia, takie jak chociażby SIEM, stanowią kwestią drugoplanową. Na pierwszym planie są zawsze wykwalifikowani ludzie i dobry proces. Pewnie nie odkryję Ameryki stwierdzeniem, że bez kompetentnych ludzi nie da się niczego sensownego zrobić – ani ‘rozhulać’ sensownego procesu, ani też skompletować przyzwoitej ‘narzędziowni’, więc zanim zacząłbym martwić się brakiem narzędzi, najpierw zainwestowałbym w know-how zespołu. Potem, przy pomocy swoich profesjonalistów, zbudowałbym sprawny operacyjnie proces, oparty o najlepsze standardy, na jakie mnie stać w realiach firmy, dla której pracuję. Jeśli zaś chodzi o narzędzia, to oczywiście dobrze jest mieć coś z ‘górnej półki’, ale – nauczony działania w warunkach ograniczonych zasobów (bo kto z nas ma ich zawsze pod dostatkiem?) – to, czym dysponuję, zawsze wykorzystuję w maksymalnym możliwym stopniu. W końcu, sprawni i pragmatyczni profesjonaliści zawsze potrafią niedoskonałości ‘narzędziowni’ skompensować swoimi kompetencjami, często dostosowując narzędzia Open Source do swoich potrzeb, albo – w ostateczności – pisząc narzędzia własnego developmentu.

    • Podpisuję się i pod tym. :-)

  7. Chciałbym zwrócić uwagę, ze implementacja i wdrożenie takiego podejścia w realnym świecie wymaga tego co już się pojawiło w komentarzach: czasu, pieniędzy, wiedzy, ŚWIADOMOŚCI, zasobów ludzkich.

    Natomiast warto sobie zadać pytanie czym najpierw się zając, jak rozwiązać problemy i wyzwania z jakimi spotka się zespół CSIRT/CERT, kiedy realnie uruchomić zespół by zaczął pracować operacyjnie – na jakim etapie budowy monitoringu, kto ma rozwijać monitoring, czy zespół czeka na zgłoszenia czy sam wykrywa, czeka na alarmy czy sam poluje i wiele wiele innych.

    Wszystkiego nie zrobimy, ale może i wcale nie potrzebujemy tego. Realizacja powyższego planu w większości to nawet nie tygodnie czy miesiące, ale lata pracy wdrozeniowej.

    SIEM to naprawdę tylko jedno z wielu narzędzi i zanim stanie się użyteczny trzeba się sporo napracować w wielu innych miejscach, a to nie jest koniec.

    W tematach DFIR polecam takie hasła dla Google jak: Anton chuvakin, Richard bejtlich, Raffael Marty i ich blogi/prezentacje/papierki/książki.

    • Oczywiście, że zgadzam się z argumentami, że zbudowanie w firmie dobrego incident handlingu nie jest proste. Zgadzam się też z podejściem, że decyzje o jego kształcie zawsze muszą wynikać z rzetelnej oceny ryzyka. To prawda, że z budową struktur organizacyjnych, procesu, narzędzi i know-how wiążą się niemałe koszty. Mimo wszystko jednak warto to zrobić. Ne zawsze przy tym trzeba mierzyć najwyżej, jak się da. Nie zawsze potrzeba nam działającego w trybie 24-godzinnym Security Operation Center. Może starczy rozwiązanie na mniejszą skalę, ale za to skuteczne, dostosowane w pełni do realiów organizacyjnych i ekonomicznych firmy. Można oczywiście mierzyć wysoko – i ja to rozumiem – tylko czy warto, marząc o zakupie Porsche, chodzić do końca życia na piechotę, czy też lepiej w międzyczasie kupić Toyotę i cieszyć się z większych możliwości, jaki stwarza nowa forma przemieszczania się. Może Toyota nie dostarczy nam tych wrażeń, co Porsche, ale będzie równie niezawodna.

  8. Od razu widać, że mamy tu połączenie szerokiej wiedzy teoretycznej z wieloletnią praktyką. Bardzo ciekawy tekst!

  9. Że warto nie trzeba mnie przekonywać :-) Od kilku lat “jeżdżę” Toyotą, choć po chip tuningu czasem udaje się zawstydzić CSIRT a’la Porsche ;) i polecam utworzenie zespołu lub zamówienie takiej usługi każdej firmie, która ma co chronić. Dlaczego każda firma o tym nie myśli to temat na odrębną dyskusję.

    Każdy kto zajmował się defensywną częścią bezpieczeństwa wie jak wymagająca to praca i wielu przez to odpuszcza zanim stanie na starcie do biegu – jestem zdania, że dużo trudniejsza niż ofensywna. Defensywa to ciągły bieg, oczekiwanie na syrenę alarmową, to rodzaj dyżuru pod “112”.

  10. Jest dużo darmowych narzędzi, polecam: span-port + snort + BASE do tego pisanie własnych reguł, Cacti lub/i Nagios do tego dashboard, oddzielny serwer na logi.
    Wszystkie serwery (wewnątrz sieci i z zewnątrz) i stacje robocze systematycznie skanować przy użyciu programu NESSUS(płatny) lub OpenVAS( uwaga, nie skanować drukarek, chyba że macie dużo papieru :) ).
    Na SIEMa na początek polecam Splunk’a w wersji testowej, na początek wystarczy. Splunk jest rewelacyjną platformą analityczną, łatwo i szybko daje się w nim przeszukiwać logi. Jak coś się stanie można zaimportować do niego logi z interesującego nas przedziału czasu i analizować.

    • :-) oto przykład, że jak się chce to się da.

  11. Nie można bezpieczeństwa traktować tylko i wyłącznie w kontekście IT, tak samo dużym błędem jest traktowanie incydentu jako tylko i wyłącznie incydentu bezpieczeństwa informacji. ISO27001 wymaga np. zarządzania incydentami ZWIĄZANYMI z bezpieczeństwem informacji. Zajmuję się bezpieczeństwem zawodowo, piszę z punktu widzenia praktyka. Moim zdaniem tytuły rozdziałów niepotrzebnie zawierają odwołania do bezpieczeństwa informacji, reszta artykułu mówi o incydentach bezpieczeństwa jako takich, więc nie wiem skąd ta niespójność. No i to skupianie się na IT…

    • Najlepiej by odpowiedział Janusz – w końcu jest autorem artykułu :)

      Nie zgodzę się z tak arbitralnym stwierdzeniem, że nie można tak podchodzić. Otóż można o ile są do tego stosowne warunki: np. analiza ryzyka mówi, że możemy to obecnie zaniedbać lub w naszym biznesie można to do tego sprowadzić – pomijam przypadki mniejszej świadomości/doświadczenia, nie każdy defensywny bezpiecznik urodził się z doświadczeniem – jest taki w ogóle? ;) Normę ISO 27k, a konkretnie ISO 27035 (ona bezpośrednio adresuje tematy związane z zarządzaniem incydentami) traktuję jako jedno ze źródeł inspiracji na co zwracać uwagę, ale nie świętą wyrocznię jak należy to bezwzględnie robić. Normy i standardy mówią o pewnym pomyśle na bezpieczeństwie i są czymś w rodzaju podstawy/fundamentów, a nie pełnym rozwiązaniem problemów. Nie chcę sprowokować dyskusji o tym jak daleko/blisko jest od standardu/normy do bezpieczeństwa w instytucji bo odejdziemy od tematu. Osobiście preferuję podejście “quick-win’owe” w najbardziej wrażliwych obszarach i regularne, małymi krokami (choć często wysoko podnoszącymi poprzeczkę), podnoszenie dojrzałości programu bezpieczeństwa – choćby np. w tematach zarządzania incydentami.

    • @Tomasz, skup się na CIA, trzeba zapewnić Poufność Integralność i Dostępność, niektórzy mówią jeszcze Rozliczalność, Autenyczność ale to nas nie interesuje, to jest działka właściciela biznesowego.
      Każde naruszenie Poufności Integralności czy Dostępności, generuje incydent. To mogą być różnego rodzaju zdarzenia, np. kradzież komputera/nośnika/dokumentu, powódź, atak hakerski, itp.
      Seria zdarzeń też może wywołać incydent, np.:
      Ktoś obcy kręci się po firmie. Trzeba przeanalizować jak się dostał, gdzie przebywał.
      Jest awaria zasilania ale UPS podtrzymał zasilanie, mamy zdarzenie ale nie incydent, chyba że mamy kolejne zdarzenie, padnie UPS i systemy, wtedy mamy incydent.
      Natomiast, nie interesuje nas to że główny informatyk wygrał w lotto i nie przyjdzie już więcej do pracy, winda się zepsuła czy zabrakło papieru toaletowego.

      @Przemek, do czerpania inspiracji polecam NIST 800 61

    • @Mariusz: thx, polecam blog z konkretną serią: https://securosis.com/blog/incident-response-fundamentals-index-of-posts i pokrewne tematy, rzeczowo i praktycznie. Powiem szczerze, że na jakiś czas starczy mi źródeł inspiracji, trzeba mieć też czas na wdrażanie zmian :)

  12. Info – dla Przemka .
    Jest już w Polsce kilka udanych wdrożeń SIEM. Ew. więcej danych na e-maila: marek.znaczysie@gmail.com

    • thx, maila znajdziesz na skrzynce ;-)

  13. Nie chciałbym wchodzić w nadmiar niepotrzebnych analiz, bo jestem zwolennikiem w pełni pragmatycznego podejścia do zarządzania incydentami bezpieczeństwa informacji. Zaś pisząc o informacjach, mam na myśli aktywa informacyjne posiadające określoną wartość dla przedsiębiorstwa (nie tylko systemy informatyczne). Wszystkim tym aktywom, rzecz jasna, należy się ochrona sposobami i środkami opisanymi w Polityce i Standardach bezpieczeństwa obowiązujących w przedsiębiorstwie. Nośniki informacji – co jest oczywiste – nie zawsze mają charakter elektroniczny, ale – czy tego chcemy, czy nie – systemy informatyczne są i będą wszechobecne w naszej rzeczywistości, stąd moje nimi szczególne zainteresowanie. Celowo nie chciałem poruszać w artykule tematów takich jak role i odpowiedzialność poszczególnych podmiotów zaangażowanych w procesie zarządzania incydentami bezpieczeństwa informacji (w tym kwestie odpowiedzialności właścicieli i gestorów aktywów informacyjnych) oraz na przykład – bardzo istotnych – prawnych aspektów zarządzania incydentami, bo to jest temat na zupełnie oddzielny artykuł, który mogę opublikować, jeśli będzie taka potrzeba i rzecz jasna wola Niebezpiecznika ;)

  14. Jaki soft proponujecie do zarządzania incydentami i zdarzeniami?
    najchętniej darmowy.

    • zależy co konkretnie chcesz osiągnąć i jakie zadania kryją się pod zarządzaniem incydentami.

      W mojej opinii wystarczy system ticketowy pozwalający definiować własne pola i ich wartości: np. RT (+RTIR), JIRA (są wersje darmowe), itp.

    • @Przemek, dzięki. Chodzi o system ticketowy, myślałem że są jakieś dedykowane tak jak np. Mantis dla programistów.

    • Z pełnym przekonaniem polecam OTRS-a. Wymaga on co prawda nieco developmentu i parametryzacji, by dostosować go do Waszych konkretnych potrzeb, jednak taka inwestycja w postaci odrobiny własnej inwencji i pewnego wysiłku na starcie będą skutkowały finalnie bardzo dobrej jakości systemem, który może Was skutecznie wesprzeć na praktycznie każdym etapie procesu zarządzania incydentami.

  15. SIEM – jest kilka rozwiązań dostępnych w naszym kraju. Ze względu na specyfikę branży security – nie miałem możliwości testowania rozwiązań darmowych (nie chce przez to powiedzieć ze sa gorsze czy lepsze – po prostu brak mi wiedzy na ich temat).
    Natomiast zajmowałem się dość dogłębnie 4 produktami dostępnymi w naszym kraju.
    ArcSight/ QRadar/ RSA i Splunk.
    Każdy z tych produktów ma swoje blaski i cienie, każdy z nich nadaje się dla innego typu Klienta – zatem nie ma jednej konkretnej odpowiedzi. Musisz przesłać więcej danych (np. skala wielkości danego Klienta, ilość pracowników/ ilość zdarzeń/sek/ czy interesuje ich jedynie monitoring czy sprawy związane z korelacja zdarzeń,….
    pzdr.
    marek

  16. Kiedy jeszcze szukałem nic dedykowanego (poza RTIRem, który ma kilka przydatnych przy incydentach, pre definiowanych pól) nie znalazłem. Z czasem okazywało się, że trzeba było nieco zmienić te pola, wyszukiwanie/raportowanie wg. nich i przy instancjach RTIRa, które miałem niestety zachowywał się bardzo niestabilnie. Dlatego finalnie przeszedłem na inny system.

    Wadą RTIRa za czasów kiedy z niego korzystałem był brak synchronizacji projektów RT i RTIR (RTIR to dodatek do RT), przez co np. aktualizując RT rozlatywał się RTIR, definiując swoje pola często okazywało się, że deklarowanie typów to życzeniowe podejście developera, który niepoprawnie waliduje dane i np. wprowadzenie wartości, która powinna dać się wprowadzać kończyła się tym, że cały RT się składał, bez ręcznego usunięcia rekordu w bazie do RT(RTIR) nie dało się nawet zalogować.

    Jak się ma czas i akceptuje dłubanie to wyglądał sensownie, ale szczególnie nie polecam z powodów jak wyżej.

  17. […] Autorem poniższego artykułu jest Janusz Nawrat, który na łamach Niebezpiecznika opublikował już cieszący się dużą popularnością artykuł–przewodnik dotyczący obsługi incydentu bezpieczeństwa informacji. […]

  18. […] Wszystkich, którzy są zainteresowani jak poprawnie należy obsługiwać incydenty informatyczne zapraszamy do lektury świetnego artykułu autorstwa Janusza Nawrata pt. “Gdy na wojnę trzeba pójść” […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: