Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Reagowanie na incydenty bezpieczeństwa IT - dokumentacja

Reagowanie na incydenty bezpieczeństwa IT - dokumentacja

Poniżej udostępniamy przykładową dokumentację określającą sposób reagowania na incydenty bezpieczeństwa IT (może być ona bezpłatnie wykorzystana w firmie / instytucji, jednak dokumentu nie można odsprzedawać / dystrybuować dalej).

Aby otrzymać bezpłatnie dokumentację reagowania na incydenty bezpieczeństwa IT w formie edytowalnej (.doc) prosimy o przesłania takiej prośby na adres:

  • dokumentacja@securitum.pl z podaniem nazwy firmy/organizacji.

1.     Wstęp

Incydent bezpieczeństwa to naruszenie bezpieczeństwa jednego z elementów systemu IT: poufności, integralności lub dostępności.  Przykłady incydentów:

    • aktywacja wirusa na jednej ze stacji PC w LAN,
    • przypadkowe usunięcie istotnych danych przez administratora aplikacji,
    • atak zewnętrzny na jeden z systemów znajdujących się w DMZ,
    • brak zasilania elektrycznego skutkujący niedostępnością istotnej infrastruktury IT,
    • skopiowanie nielegalnych utworów do sieci LAN,
    • drastyczne nieprzestrzeganie obowiązujących procedur bezpieczeństwa lub Ustaw (np. Ustawy o Ochronie Danych Osobowych),
    • wyciek istotnych danych biznesowych z firmy,
    • przedłużający się brak dostępności energii elektrycznej,
    • zalanie pomieszczeń serwerowych.

2.     Przygotowanie do wykrywania incydentów.

Aby odpowiednio reagować na incydenty, należy w pierwszej kolejności mieć możliwość ich wykrycia. W tym celu odpowiednio musi  być przygotowana zarówno infrastruktura IT oraz pracownicy Firmy. Zalecenia przygotowawcze zostały przedstawione poniżej:

A.     Minimalne kroki dotyczące przygotowania infrastruktury IT:

  • okresowe przeglądanie logów systemów klasy firewall - np. raz na miesiąc lub częściej,
  • okresowe przeglądanie logów systemów umożliwiających zdalne logowanie do zasobów firmy (systemy VPN, usługa RDP, itp.) - np. raz na miesiąc lub częściej,
  • udostępnienie centralnej usługi NTP, z którą synchronizowany jest czas na istotnych systemach infrastruktury IT,
  • stworzenie centralnego miejsca przechowywania logów. Uwaga: być może jest to element wymagający znacznych nakładów czasowych,
  • wdrożenie systemu klasy IDS - przynajmniej dla systemów, do których możliwy jest publiczny dostęp (np. systemy w DMZ) wraz ze skonfigurowaniem automatycznych alertów, wysyłanych np. przez e-mail.

B.     Minimalne kroki dotyczące przygotowania pracowników Firmy:

  • Wyznaczenie zespołu (lub osoby) odpowiedzialnej za operacje związane z obsługą incydentów IT. W skład zespołu powinny wchodzić osoby:
    • posiadające techniczną wiedzę IT,
    • przedstawiciel departamentu prawnego ,
    • przedstawiciel departamentu HR,
    • osoba odpowiedzialna za ew. kontakt z mediami,

      Zespól nie musi być dedykowany do realizacji obsługi incydentów, wystarczy formalne wskazanie osób wchodzących w skład zespołu, określenie ich obowiązków a także ich zaznajomienie się z niniejszym dokumentem
  • wskazanie kontaktu gdzie mogą być zgłaszane potencjalne naruszenia bezpieczeństwa
    (e-mail, numer telefonu) oraz poinformowanie o tym kontakcie pracowników,
  • zwrócenie uwagi pracownikom na konieczność zgłaszania ewentualnych zagrożeń bezpieczeństwa infrastruktury IT (np. w trakcie rutynowych szkoleń dla pracowników),
  • okresowe (np. raz na rok) testy obsługi wybranego incydentu, obejmującego wszystkie role wskazane powyżej (dział prawny, dział IT, HR, itp.).

3.     Etapy obsługi incydentów IT.

Obsługa incydentów zazwyczaj odbywa się etapowo. Poniżej zostały opisane stosowne kroki:

A.     Wykrycie incydentu.

Incydenty mogą być wykrywane na kilka sposobów:

  • automatyczne zgłoszenie przez jeden z systemów (np. IDS, antywirus),
  • zgłoszenie przez osobę nie będącą pracownikiem Firmy,
  • zgłoszenie przez pracownika biznesowego,
  • zgłoszenie przez pracownika technicznego (np. administratora, osobę analizującą okresowo logi systemowe).

B.     Potwierdzenie oraz wstępna analiza incydentu wraz z nadaniem priorytetu

Drugim krokiem po wykryciu incydentu, jest jego potwierdzenie (zgłaszany problem bezpieczeństwa niekiedy może okazać się fałszywy – tj. w rzeczywistości nie jest on problemem bezpieczeństwa). Po pozytywnym potwierdzeniu problemu następuje jego wstępna analiza. Analiza ta obejmuje następujące elementy:

  • określenie krytyczności problemu (priorytetu incydentu) oraz poznanie istoty problemu,
  • określenie ewentualnego wpływu na inne systemy,
  • dodatkowa analiza następuje również w punkcie D poniżej.

W trakcie tego punktu określany jest również priorytet incydentu (niski, średni, wysoki). Określenie stopnia krytyczności incydentu można określić na podstawie następującej tabeli:

Wpływ
na  zasób

Krytyczność zasobu

Niska

Średnia

Wysoka

Wysoki

Średni

Wysoki

Wysoki

Średni

Niski

Średni

Wysoki

Niski

Niski

Niski

Średni

 

Priorytet incydentu determinuje czasy obsługi incydentu:

Priorytet incydentu

Czas na podjęcie działań nad incydentem

Maksymalny czas obsługi incydentu

Niski

do 48h

do 21 dni

Średni

do 24h

do 7 dni

Wysoki

do 4h

do 2 dni

 

C.     Ograniczenie wpływu incydentu na inne systemy

Po udanej analizie problemu (punkt poprzedni) należy ograniczyć wpływ incydentu na inne systemy. Przy realizacji tego punktu należy rozważyć zyski i straty związane z ograniczeniem wpływu na inne systemy oraz działalność całej firmy (np.  odseparowanie systemu krytycznego może wprowadzić istotne zaburzenia w działalności firmy, co może być większym problemem niż incydent, który jest obsługiwany).

Przykładowe sposoby ograniczania incydentu na inne systemy:

  • rekonfiguracja systemu (np. zablokowanie, portu przez który następuje wyciek danych z LAN, usunięcie niewykorzystywanej usługi systemu operacyjnego, która jest często atakowana),
  • usunięcie zasadniczej przyczyny problemu (np. usunięcie malware z zainfekowanej stacji PC),
  • wyłączenie systemu,
  • fizyczne odcięcie systemu od sieci.

D.     Usunięcie skutków incydentu oraz zebranie dowodów

Zasadniczym celem usunięcia skutków jest przywrócenie stanu bezpieczeństwa infrastruktury IT oraz danych sprzed incydentu.

Usunięcie skutków incydentu może przybrać dość różną postać, w zależności od konkretnego incydentu (może to być np. rekonfiguracja firewalla, wgranie odpowiednich patchy do systemu czy wprowadzenie dodatkowych metod ochrony dla wybranych danych – np. zabezpieczenie aplikacji webowej przed dalszymi atakami).

Przy usuwaniu skutków incydentu, należy pamiętać aby nie zniszczyć ewentualnych dowodów wystąpienia incydentów. Zebranie dowodów polega z reguły na dokładniejszej analizie istoty problemu, łącznie z takimi informacjami jak:

  • kto lub co było przyczyną incydentu,
  • potwierdzenie dokładnej daty wystąpienia incydentu.

Przy zbieraniu dowodów istotne jest zachowanie niezmienionego stanu (obrazu) zaatakowanego systemu, który następnie jest analizowany. W tym przypadku często wymagane jest użycie specjalistycznych narzędzi, które umożliwiają „zamrożenie” całego systemu w danej chwili (zarówno zwartość dysków twardych jak i pamięci). Takie dane mogą być umieszczone na nośniku read-only oraz analizowane bez zagrożenia nieautoryzowanej zmiany przez zespół  analizujący.

 E.      Odpowiedz na incydent

Odpowiedź na incydent może być realizowana niezależnie w dwóch trybach:

  • reakcja wewnętrzna – np. : rekonfiguracja systemów, uzupełnienie procedur, eskalacja problemu w strukturze organizacyjnej firmy, wyciągnięcie konsekwencji personalnych, implementacja wniosków na przyszłość,
  • reakcja zewnętrzna – np.: kontakt z właścicielem systemu z którego nastąpił atak, powiadomienie policji, prokuratury, mediów.

Odpowiedź powinna być zawsze dostosowana do konkretnego incydentu oraz stopnia jego priorytetu.

4.     Prowadzenie ewidencji incydentów

Każdy incydent powinien być odnotowywany jako osobna pozycja w tabeli incydentów. Tabela taka powinna zawierać takie dane jak:

  • data wykrycia incydentu,
  • status (w trakcie wyjaśniania, zamknięty, odrzucony jako nieprawdziwy),
  • data rozwiązania incydentu,
  • opis incydentu,
  • podjęte działania,
  • zalecenia na przyszłość.

Okresowo – np. raz na pół roku należy analizować ewidencję incydentów oraz wyciągać odpowiednie wnioski prewencyjne – tj. ograniczające ilość incydentów w przyszłości.

--Michał Sajdak, Securitum

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS