10:00
16/9/2014

Poniższy artykuł opisuje jak postępować z incydentami bezpieczeństwa informacji, gdy już się zdarzą. Jego autorem jest osoba, która chciała pozostać anonimowa. Jeśli ktoś z Was również chciałby przekazać za naszym pośrednictwem wiedzę innym internautom albo podzielić się refleksjami na jakiś temat związany z bezpieczeństwem IT (czy to pod swoim nazwiskiem, czy anonimowo) — to zapraszamy do kontaktu.

1. Wstęp

Postępowanie z incydentami bezpieczeństwa informacji stanowi bardzo ważny element programu zarządzania bezpieczeństwem w każdym przedsiębiorstwie. Wraz z procesami zarządzania ryzykiem (ang. risk management), zarządzania zdarzeniami bezpieczeństwa (ang. security event management), zarządzania podatnościami (ang. vulnerability management) i testami bezpieczeństwa, ma na celu zapewnienie ciągłości operacyjnej oraz ograniczenie wpływu przypadków naruszeń bezpieczeństwa aktywów informacyjnych na działalność przedsiębiorstwa, w tym na ciągłość operacyjną jego procesów biznesowych, systemów i infrastruktury teleinformatycznej.

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 (ujawnienie niepowołanym osobom), integralności (uszkodzenie, przekłamanie, zniszczenie) i dostępności (dane nie są dostępne w użytecznej postaci na żądanie uprawnionych użytkowników) danych, niezależnie od ich nośnika, w tym także przechowywanych i przetwarzanych w systemach informatycznych oraz transmitowanych przez łącza sieci;
  • niedostępność oraz działania niezgodne ze specyfikacją (błędne) systemów informatycznych, zwłaszcza systemów i aplikacji krytycznych (z wyłączeniem kontrolowanych i zaplanowanych prac oraz dysfunkcji niemających wpływu na bezpieczeństwo informacji;
  • infekcje, propagacja i działanie szkodliwego oprogramowania (malware – kody i skrypty mające szkodliwe, przestępcze lub złośliwe działanie, do których zaliczają się miedzy innymi wirus, robak internetowy, koń trojański, spyware, keylogger, rootkit, dialer, exploit etc.);
  • rozpoznanie, penetracja i próby omijania systemów zabezpieczeń;
  • niewłaściwe wykorzystywanie lub nadużywanie zasobów informacyjnych;
  • ataki odmowy usługi na systemy informatyczne;
  • ataki nieautoryzowanego dostępu do aplikacji, systemów oraz ataki eskalacji poziomu uprawnień w systemach;
  • kradzież lub zniszczenie urządzeń przetwarzających lub/i przechowujących informacje oraz nośników danych;
  • wyłudzenia (lub próby wyłudzeń) informacji wrażliwych, takich jak np. hasła dostępowe czy tajemnice przedsiębiorstwa;
  • ataki socjotechniczne, ataki z wykorzystaniem phishing’u, skimming’u oraz innych technik zagrażających naruszeniu poufności, dostępności i integralności informacji;
  • incydenty wielokomponentowe (złożone incydenty dotyczące wielu systemów, wykorzystujące wiele wektorów ataków itp.);
  • łamanie zasad regulacji wewnętrznych obowiązujących w przedsiębiorstwie w obszarze bezpieczeństwa informacji lub wynikających z nich zapisów w umowach z Podmiotami Zewnętrznymi oraz przepisów prawa powszechnego regulujących kwestie bezpieczeństwa w działalności przedsiębiorstwa (w tym Ustawy o ochronie danych osobowych, a w bankach dodatkowo Ustawy Prawo Bankowe w jej części dotyczącej ochrony tajemnicy bankowej).


Skuteczne polityki z obszaru bezpieczeństwa informacji, właściwa kontrola dostępu do zasobów informacyjnych, edukacja i poprawa poziomu świadomości personelu oraz Pracowników Podmiotów Zewnętrznych współpracujących z przedsiębiorstwem, wszystkie rozwiązania techniczne i organizacyjne zwiększające bezpieczeństwo zasobów informacyjnych przedsiębiorstwa, wczesne wykrywanie incydentów bezpieczeństwa oraz natychmiastowa, właściwa reakcja na zaistniałe incydenty, pozwalają na istotne zmniejszenie ryzyka wystąpienia oraz kosztów incydentów bezpieczeństwa informacji.

2. Proces zarządzania incydentami bezpieczeństwa

Proces zarządzania incydentami bezpieczeństwa składa się z następujących etapów:

  • Przygotowanie do postępowania z incydentami bezpieczeństwa [0];
  • Identyfikacja i zgłoszenie incydentu [1];
  • Gromadzenie informacji o incydencie [2];
  • Ocena i selekcja informacji [3];
  • Analiza zgromadzonych informacji [4];
  • Ograniczenie zasięgu i szkodliwych skutków zaistniałego incydentu bezpieczeństwa oraz powstrzymywanie wpływu incydentu na działalność przedsiębiorstwa [5];
  • Postępowanie naprawcze, którego celem jest przywrócenie procesów i systemów do normalnego stanu działania oraz odtworzenie danych [6];
  • Dokumentowanie [7];
  • Raportowanie incydentu [8];
  • Opracowanie i implementacja planów przeciwdziałania określonym incydentom w przyszłości [9].

schemat

Etap 0 – Przygotowanie do postępowania z incydentami bezpieczeństwa

Etap ‘0’ procesu zarządzania incydentami bezpieczeństwa informacji ma na celu nie tylko zapewnienie możliwości wykrycia, prawidłowej identyfikacji i kategoryzacji incydentu oraz właściwego postępowania z zaistniałym incydentem, lecz także aktywne przeciwdziałanie wystąpieniom incydentów.

Etap przygotowań stanowią następujące zadania:

  • opracowanie i wdrożenie regulacji w obszarze zarządzania incydentami bezpieczeństwa informacji;
  • powołanie i przeszkolenie zespołu do spraw reagowania na incydenty oraz wyposażenie go w niezbędne narzędzia;
  • zarządzanie podatnościami (ang. vulnerability management);
  • zapewnienie bezpiecznej konfiguracji systemów (ang. hardening);
  • testy bezpieczeństwa systemów;
  • zarządzanie zdarzeniami bezpieczeństwa (ang. security event management) i monitoring systemów pod kątem naruszeń bezpieczeństwa;
  • badanie zgodności systemów z wymaganiami standardów, polityk i wytycznych bezpieczeństwa (ang. information security compliance management);
  • zarządzanie ryzykiem (ang. risk management);
  • akredytacja aplikacji i systemów oraz zapewnienie bezpieczeństwa w zarządzaniu projektami;
  • szkolenie personelu, opracowywanie i przeprowadzania działań podnoszących świadomość zagadnień bezpieczeństwa informacji.

Etap 1 – Identyfikacja i zgłoszenie incydentu

Incydenty bezpieczeństwa informacji mogą być identyfikowane w różny sposób, przez ewentualne zastosowanie różnych narzędzi pomocniczych oraz przez różne osoby (personel przedsiębiorstwa, Podmioty Zewnętrzne). Osoba zgłaszająca odpowiada za wyczerpujące opisanie incydentu adekwatnie do posiadanej wiedzy i umiejętności. Brak tej wiedzy i umiejętności poprawnego rozpoznania, a także klasyfikacji typu oraz poziomu istotności incydentu po stronie osoby zgłaszającej nie może być przyczyną zaniechania zgłoszenia.

Naruszenia bezpieczeństwa aktywów informacyjnych mogą być zgłaszane przez użytkowników końcowych, administratorów systemów, klientów firmy, a także Podmioty Zewnętrzne współpracujące z firmą. Incydenty mogą być sygnalizowane przez alerty z systemów zabezpieczeń (firewall, IPS, antywirus itp.), komunikaty z systemu zarządzania zdarzeniami, raporty o nieprawidłowościach weryfikacji integralności plików, logi z systemów operacyjnych, urządzeń sieciowych i aplikacji, obserwacje i oceny eksperckie dokonywane przez personel jednostki zajmującej się bezpieczeństwem informacji itp.

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.

Istotnym czynnikiem warunkującym sprawność zarządzania incydentami bezpieczeństwa informacji, zwłaszcza w sytuacji spiętrzenia liczby zgłoszeń jest właściwa identyfikacja incydentów i odróżnianie ich od zdarzeń mających charakter fałszywych alarmów (powiadomień o zdarzeniach, które – po zbadaniu – okazują się nie stanowić incydentów bezpieczeństwa). Problem ten ujawnia się zwłaszcza w przypadkach, kiedy notyfikacje pochodzą z systemów zabezpieczeń generujących duży wolumen logów.
Zagwarantowanie odpowiedniej jakości danych na początku procesu zarządzania incydentami w znacznym stopniu decyduje o powodzeniu dalszych jego etapów.

Etap 2 i 3 – Gromadzenie informacji o incydencie oraz ocena i selekcja informacji

Dodatkowe informacje o incydencie mogą być także gromadzone z wykorzystaniem systemów monitorujących, systemów zabezpieczeń i urządzeń sieciowych, systemu zarządzania zdarzeniami bezpieczeństwa (wyposażonego w mechanizmy korelacji zdarzeń), repozytoriów logów, baz wiedzy (szczególnie na temat wcześniejszych wystąpień analogicznych incydentów), baz informacji o podatnościach, analizy strumienia danych sieciowych przy pomocy analizatorów sieciowych itp.

W przypadku, gdy zgłoszone zdarzenie nie jest incydentem bezpieczeństwa, koordynator procesu informuje o tym fakcie osobę zgłaszającą. W etapie gromadzenia informacji niezbędne jest zabezpieczenie danych tak, aby nie utraciły one atrybutów dostępności, integralności, poufności i autentyczności (materiały muszą zachowywać wartość dowodową). Na podstawie zgromadzonych informacji incydent jest oceniany pod kątem krytyczności i rozmiaru wpływu na całą organizację bądź jej poszczególne procesy biznesowe (ocena poziomu istotności).

Etap 4 – Analiza zgromadzonych informacji

Na etapie analizy zgromadzonych danych koordynator procesu i zaangażowani członkowie zespołu reagowania na incydenty bezpieczeństwa dokonują przeglądu i weryfikacji pozyskanego materiału pod kątem poprawności, jakości i kompletności. Koordynator odpowiedzialny jest za określenie ‘łańcucha dowodów’, co stanowi jeden z kluczowych czynników analizy powłamaniowej. Po zakończonym etapie analizy zgromadzonych informacji, musi powstać odpowiedni raport.

Bardzo istotnym wyznacznikiem skuteczności postępowania z incydentami bezpieczeństwa informacji jest ich wcześniejsza klasyfikacja pod kątem poziomu istotności. Klasyfikacja taka jest podstawą określenia priorytetów podejmowanych działań naprawczych oraz priorytetów raportowania.

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 lub których skutkiem mogą być znaczne straty finansowe czy też poważny uszczerbek na reputacji przedsiębiorstwa itp.

Kierując się wrażliwością danych, należy sklasyfikować jako incydent o wysokim poziomie istotności nieuprawniony dostęp do stacji roboczej użytkownika, na której lokalnym dysku były przechowywane informacje wrażliwe mimo, że w innych okolicznościach nieautoryzowany dostęp do tej stacji 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 w przedsiębiorstwie będzie z całą pewnością incydentem wysokiego ryzyka.

Etap 5 – Ograniczenie zasięgu i szkodliwych skutków zaistniałego incydentu bezpieczeństwa. Powstrzymywanie przebiegu incydentu i jego wpływu na działalność przedsiębiorstwa.

Po rozpoznaniu incydentu bezpieczeństwa i pozyskaniu na jego temat niezbędnych danych, bardzo ważne jest podjęcie przez zespół reagowania na incydenty bezpieczeństwa odpowiednich działań, mających na celu powstrzymanie dalszego przebiegu incydentu, ograniczenie zasięgu oraz szkodliwości jego skutków.

Zatem etap 5 polega na natychmiastowej identyfikacji luk w bezpieczeństwie systemów i procesów (podatności) oraz zaplanowaniu i uruchomieniu działań powstrzymujących przebieg incydentu, a także rozszerzanie się jego zasięgu i zwiększenie szkodliwości wpływu na działalność przedsiębiorstwa.

Metody postępowania na tym etapie zależą od typu incydentu bezpieczeństwa, dlatego zalecane jest opracowanie i udokumentowanie strategii powstrzymywania przebiegu incydentów dla poszczególnych ich typów. W pewnych przypadkach może okazać się konieczne opóźnienie zastosowania procedur powstrzymywania przebiegu incydentu w celu zgromadzenia dodatkowych materiałów dowodowych czy identyfikujących agresora. W takich przypadkach należy skonsultować z Departamentem Prawnym możliwość zastosowania opóźnienia. Decyzję ostateczną w tej sprawie podejmuje szef jednostki odpowiedzialnej za bezpieczeństwo przedsiębiorstwa.

Etap 7 – Postępowanie naprawcze

Etap „Postępowania naprawczego” polega na zaplanowaniu i wdrożeniu działań, mających na celu przywrócenie ciągłości operacyjnej przedsiębiorstwa, odzyskanie danych, przywrócenie pełnej funkcjonalności oraz zapewnienie bezpieczeństwa systemów i procesów, usunięcie z systemów śladów incydentów (usuniecie szkodliwego oprogramowania, odblokowanie kont użytkowników zablokowanych wskutek wystąpienia incydentu itp.), a także przeciwdziałanie podobnym incydentom w przyszłości.

W ramach tego etapu wykonywane są dodatkowo między innymi takie czynności jak przywracanie poprawnej konfiguracji z kopii zapasowych, instalacja poprawek bezpieczeństwa, zmiana haseł, wzmacnianie bezpieczeństwa instalacji i ustawień systemów (hardening), włączanie innych, wymaganych zabezpieczeń (na przykład zabezpieczeń firewall, dodatkowej kontroli dostępu, zmiany reguł w systemach IPS itp.).

Etap 8 – Dokumentowanie oraz nauka i wyciąganie wniosków

Działania na każdym z etapów procesu powinny być na bieżąco dokumentowane. Na tym etapie postępowania z incydentami należy uporządkować zgromadzoną do tej pory dokumentację oraz zbiorczo udokumentować:

  • całość pozyskanego materiału diagnostycznego i dowodowego;
  • wprowadzone zmiany w systemach i procesach;
  • straty związane z incydentem.

Medium wykorzystywane do celów dokumentowania jest zależne od rodzaju incydentu, w związku z czym należy zapewnić odpowiednie do okoliczności środki (dyski, taśmy, cyfrowy aparat fotograficzny z kartą pamięci, dyktafon, magnetofon itp.).

Metody dokumentowania muszą spełniać wymagania autentyczności i integralności, zwłaszcza w takich przypadkach, kiedy zachodzi prawdopodobieństwo ich wykorzystania w charakterze materiału dowodowego w sądzie.

Dokumentacja dotycząca incydentu powinna być przygotowana i utrzymywana w takim stanie, żeby zawierała zawsze rzetelne i aktualne pełne informacje o incydencie..

Dokumentacja dotycząca incydentów bezpieczeństwa zawiera wrażliwe dane, zatem dostęp do niej musi być ograniczony oraz właściwie monitorowany. Dokumentacja ta musi także zostać właściwie zabezpieczona przez zastosowanie metod i środków adekwatnych do jej poziomu klasyfikacji, zgodnie z obowiązującymi w przedsiębiorstwie, oddzielnymi regulacjami w tym obszarze. Dokumentacja z postępowania z incydentami bezpieczeństwa musi być przechowywana przez okres czasu wymagany ogólnie obowiązującymi przepisami prawa.

Bardzo ważnym aspektem w procesie zarządzania incydentami bezpieczeństwa jest wykorzystywanie wiedzy nabytej w trakcie postępowania z incydentami bezpieczeństwa do ciągłego doskonalenia tak kompetencji merytorycznych zespołu powołanego do reagowania na incydenty bezpieczeństwa, jak i samego procesu. W tym celu powinny być organizowane spotkania tego zespołu z udziałem innych osób zaangażowanych w postępowanie z incydentami, w trakcie których omawiane są mechanizmy incydentów, najskuteczniejsze metody postępowania, środki najskuteczniejszej prewencji, ryzyka związane z incydentami oraz najskuteczniejsze środki przeciwdziałania incydentom w przyszłości.
Tematem spotkania powinny być także wnioski odnośnie zaobserwowanych nieprawidłowości i niedociągnięć oraz potrzeb w zakresie budżetu, wiedzy, umiejętności i narzędzi.

Etap 9 – Raportowanie incydentu

Po udokumentowaniu prac należy przygotować odpowiedni raport. Raport ten musi zostać zaprezentowany kierownictwu przedsiębiorstwa oraz właścicielowi biznesowemu aktywów informacyjnych, których bezpieczeństwo zostało naruszone w wyniku incydentu.

Etap 10 – Opracowanie i implementacja planów przeciwdziałania określonym incydentom w przyszłości

Plany przeciwdziałania incydentom powstają na podstawie rekomendacji zawartych w raporcie oraz oceny ryzyka. Analiza ryzyka dokonywana jest na podstawie dokumentacji powstałej i zgromadzonej na poszczególnych etapach procesu zarządzania incydentami. Wynikająca z przeprowadzonej analizy ocena ryzyka ma na celu wybór środków postępowania z ryzykiem, które będą w pełni adekwatne do poziomu ryzyka. Plany podlegają zatwierdzeniu przez szefa jednostki odpowiedzialnej za bezpieczeństwo przedsiębiorstwa.

Przeczytaj także:

16 komentarzy

Dodaj komentarz
  1. Dzięki za ten artykuł. Pomógł mi uporządkować wiedzę z obsługi incydentów. Niby wszystko to można znaleźć w sieci, ale często porozrzucane i bez całościowego ujęcia.

  2. Rozumiem, że ktoś napisał wypracowanie na zaliczenie i chciał się podzielić? Ręka w górę, kto się dowiedział czegokolwiek z tego elaboratu :/

    No i czym ta procedura różni się od obsługi incydentów nie związanych z bezpieczeństwem?

    • tekst jest solidny. jesli uwazasz ze czegos mu brakuje to napisz polemike albo rozwiniecie. mysle ze redakcja z checia opublikuje ja na lamach niebezpiecznika.

      ja na ten przyklad bardzo chcialbym poogladac przyklady raportow z obslugi incydentu. takich prawdziwych. oczywiscie mozecie zamazac dane identyfikujace firme ;]
      podejmujesz rekawice @adrb?

    • @kr0z: nikt powazny sie nie skusi. Kto ma dostep do wesolych kwitow ten ma podpisane inne kwity, ktore skutecznie zniechecaja do szerzenia wiedzy wsrod gawiedzi ;)

  3. Jaka jest licencja tego artykułu?

    • dobre pytanie

    • Autor zgodził się na wykorzystywanie tego tekstu :)

  4. Podoba mi się ten artykuł. Spełnia wymagania normy ISO 27001:2013 oraz wytycznych ISO 27035:2011.

  5. Gdzie czytać więcej? Polecacie jakieś źródła za free i nie za free (literatura oprócz samych wymagań norm 27001)?

    • 27035 i NIST SP 800-61. Dla mnie 27035 zdecydowanie bardziej czytelne i zrozumiałe.

    • Ot, choćby: “Bezpieczeństwo informacji i usług w nowoczesnej instytucji i firmie”, A. Białas, WNT 2006.

  6. Dobry artykuł jako szkielet regulaminu dla służb bezpieczeństwa w firmie. Gratuluję
    W etapie przygotowania dodałbym punk o zdefiniowaniu tzw. szybkich kroków w określonych znanych i definiowanych naruszeniach zasad bezpieczeństwa, np atak DDOS, czy wyłudzanie haseł

  7. Dobry, a nawet dodam obowiązkowy również dla każdego zwykłego pracownika (biurowego i terenowego) obsługującego komputer czy inne medium mogące służyć do transmisji danych.
    Z pewnością doda nieco uwagi na aspekt bezpieczeństwa. W końcu to pracownicy jako użytkownicy tych systemów najczęściej ściągają kłopot, tak więc warto zadbać o ich świadomość.
    Poza tym pięknie jest ubrać intuicję w słowa.
    Pozdrowienia dla Autora.

  8. A ja złośliwie (bo nie widzę zgłoś błąd na stronie czy coś podobnego) przyczepię się, że zniknął etap 6. Gdyby nie spis treści przysiągł bym, że nie spełniał jakiś norm :).

    Informacje dla każdego obytego niby jasne i można pomyśleć przecież piszą o, rzeczach oczywistych. Ale udokumentowanie i opisanie takiego procesu krok po kroku wcale nie jest takie proste. Ile osób w swoich firmach mając osoby odpowiedzialne za bezpieczeństwo ma takie coś spisane w dokumentacji :).

  9. Procedura zgłaszania słabości jest etapem przed postępowanie z incydentami i nie musi być integralną częścią postępowania z incydentami. Jest jedną z danych wejściowych do prezentowanej procedury. Zgadzam się, że zdefiniowanie szybkiej ścieżki bardzo pomaga w ograniczaniu eskalacji incydentu.Wszystkie firmy posiadające certyfikat ISO 27001 muszą mieć taką lub podobną procedurę/politykę aby otrzymać certyfikat zgodności. Pozdrawiam

  10. Dobra robota – przelane na papier to co nieraz robimy, ale niekoniecznie mamy opisane :-)
    Ja bym tylko dodał do tego jedną uwagę – należy oddzielić od siebie zespoły które zajmują się merytoryczną stroną incydentu (technicznych) od grupy zajmującej się kontaktem z klientem/użytkownikiem. Bo jeśli ta sama ekipa ma się zajmować stukaniem szukaniem rozwiązania i telefonami to nic dobrego z tego nie wyniknie, wszystko będzie trwało tylko dłużej i będzie więcej błędów.

Twój komentarz

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

RSS dla komentarzy: