Reakcja na incydenty bezpieczeństwa informacji

Wstęp

Ostatni razem dowiedziałeś się, jak stworzyć plan reagowania na incydenty bezpieczeństwa informacji. Jeśli go nie przeczytałeś, to wróć tu, bo będzie Ci łatwiej zrozumieć dzisiejszy temat.

Dziś poznasz fazy reagowania na incydenty bezpieczeństwa informacji. Mam nadzieję, że ten artykuł będzie równie zajmujący jak poprzedni i równie Cię zaangażuje, plus wyciągniesz z niego dużo wiedzy o tym, jak postępuje się z incydentami.

Od razu podkreślę, że nie każdy incydent musi przejść przez wszystkie poniższe fazy, ale też przy niektórych te fazy nie będą wystarczające, ponieważ, tak jak już Ci to wspomniałem w poprzednim artykule, możliwości incydentów jest bez liku i trzeba na nie dynamicznie reagować. Choć postaram Ci się tu wypisać ogólne fazy, byś miał pogląd, co i jak.

Wykrywanie

Dobrze więc, zacznijmy od pierwszej i zarazem najważniejszej fazy, czyli wykrycia napastnika. Tu na pewno trzeba popracować, bo średni czas, w którym zostaje wykryty napastnik w sieci firmowej, to 56 dni. Przynajmniej takie były wnioski z incydentów za rok 2020, a skutki malware to czasem nawet kilka miesięcy.

Teraz zastanów się, ile zła możesz zrobić przez 2 miesiące, buszując po sieci firmowej. Nawet nie mówiąc, żebyś coś popsuł czy posadził jakieś serwery — wystarczy sam nasłuch w wypadku, gdy sieć wewnętrzna nie jest szyfrowana. Tak, wiem, że dane są za rok 2020, bo takie tylko znalazłem. Ale biorąc pod uwagę, że dużo firm zaczęło pracę zdalną, zmigrowało się do chmury i tak dalej, to wątpię, by statystyki się polepszyły. Myślę, że wręcz odwrotnie — jest dużo gorzej.

Dlatego my jako bezpiecznicy musimy jeszcze bardziej się edukować i jeszcze bardziej dopinać te systemy, sieci i aplikacje, by było bezpieczniej. Lecz musimy też pamiętać, by te zasoby były dostępne, bo co nam po komputerze bez internetu czy bazie na serwerze, do którego nie da się dostać.

Dobrze, ale jak zwykle odpłynąłem od tematu, więc wracamy. Faza wykrycia jest to najważniejsza faza, ponieważ to właśnie ona daje organizacji znać, że coś jest nie tak. Jeśli o czymś nie wiemy, to nie możemy na to zareagować. Dlatego faza wykrycia jest pierwszą z faz, chociaż właściwie przed nią jest jeszcze jedna faza, która jest nazywana często „dwell time”. Po polsku już nie brzmi tak ładnie: faza czasu oczekiwania. Faza czasu oczekiwania jest to faza, w której incydent miał miejsce, ale my jako organizacja jeszcze o nim nie wiemy i nie mamy żadnej świadomości, że coś się stało. To jest ta faza, w której napastnik działa najwięcej ;).

Wracając do fazy wykrywania, aby było ona możliwa, musimy mieć funkcjonalność wykrywania/przeglądania zdarzeń. By taką funkcjonalność zapewnić, należy zbierać dzienniki logów czy wykorzystywać inne narzędzia takie jak EDR, skanery sieci, honeypoty, honeynety, monitoring sieci itd. Narzędzi, dzięki którym można wykrywać napastników czy to w sieci, czy to na endpointach, jest naprawdę sporo. Niektóre są tańsze, niektóre droższe, jedne lepiej działają, drugie gorzej, ale ten artykuł nie jest o tym. Może innym razem napiszę o narzędziach, jakie można wykorzystać, jeśli będziesz zainteresowany;) Poza narzędziami, które możemy zaimplementować, mamy też inne możliwości wykrywania incydentów — poniżej postaram się Ci je wylistować.

Lista możliwości wykrywania incydentów

• Zgłoszenie przez użytkownika — wyedukowany personel powinien rozpoznawać przynajmniej podstawowe rodzaje incydentów. Już parę razy zdarzyło mi się, że systemy nie zadziałały, jak trzeba, ale wiedza uratowała użytkowników i dali znać, że coś jest nie tak :).
• Zgłoszenie przez analityka SOC — Osoby monitorujące sieci, endpointy, serwery są często w stanie wykryć coś, co systemy ochronne przeoczyły i zgłosić incydent.
• Zgłoszenie przez klienta — klient może zgłosić, że miał naruszenie, które spowodowało również wyłam w naszej organizacji.
• Zgłoszenie przez social media — Klient czy ktoś inny może zaobserwować incydent i zgłosić go nam przez firmowe social media. Na przykład ktoś się chwali wykradzioną bazą naszych haseł na darknecie 😉
• Powiadomienie od urzędu — W wypadku kradzieży danych wrażliwych może na przykład się do nas zgłosić UODO, że padliśmy ofiarą incydentu (raczej od razu z karą, by uzupełnić budżet :)). Lub też może się zgłosić do nas inny urząd.
• Zgłoszenie od wolnego strzelca — Mamy złych bughunterów, ale na szczęście mamy też dobrych — i taka osoba też może nam zgłosić czy to incydent, czy to potencjalny incydent. Na szczęście prawo trochę się zmieniło i już nie grozi im takie ryzyko, gdy przetestują i zgłoszą temat danej firmie.
• Zgłoszenie od nieznanej osoby — może się też zdarzyć, że dostaniemy stary dobry anonim 😉

Ogłoszenie incydentu

Dobrze, jak już zdaliśmy sobie sprawę z faktu, że coś się dzieje — mamy incydent, który się akurat toczy bądź też taki, jaki już miał miejsce — trzeba ogłosić jego obecność w organizacji wszystkim, którzy powinni o nim dowiedzieć. Tak jak opisywałem Ci w poprzednim artykule o tworzeniu planu odpowiedzi na incydenty, powinna istnieć procedura, w której znajdują się informacje, jak zadeklarować taki incydent i jakie kroki powinno się podczas tego wykonać. Deklaracja ogólnie zawiera komunikację dla kluczowego personelu jak i np. dla managera bezpieczeństwa czy też dla managera IT oraz dla zespołu zajmującego się incydentami.

Choć już to powtarzałem, warto i tutaj wspomnieć, że zespół do spraw incydentów powinien wybrać sobie koordynatora, który będzie wyznaczał ilość zasobów czy to ludzkich, czy innych, które są niezbędne to wykorzystania podczas incydentu. Ale również będzie zajmował się komunikacją wewnątrz zespołu do spraw incydentów, by wszyscy byli odpowiednio poinformowani. Koordynator też będzie często odpowiadał za zadeklarowanie incydentu, ale nie zawsze tak będzie. Przypomnę, że mogą też się zdarzyć false positive, ale nie można nazbyt negować i naskakiwać na koordynatora, by nie bał się deklarować incydentów. Oczywiście, jak we wszystkim, trzeba mieć umiar i ciągłe false positive powinny prowadzić do analizy, co jest nie tak. Ale nie ma co od razu naskakiwać na koordynatora, bo będzie się bał deklarować i może wyjść tak, że incydent nie zostanie zadeklarowany, a wszystko się posypie. Ale to tylko w ramach przypomnienia, bo pisałem o tym już parę razy 🙂

Ocena i nadanie priorytetu

Tutaj są dwie fazy, ponieważ jedna od razu dzieje się po drugiej bądź dzieją się one jednocześnie. Więc nie widziałem sensu, by je dzielić. Pierwszą z tych faz będzie ocena zebranych informacji, które pomogły nam zadeklarować incydent. Pozwoli nam to określić charakter incydentu. Może też do tego być potrzebne wykorzystanie technik kryminalistycznych, by sprawdzić, jak w ogóle do tego incydentu mogło dojść.

W poprzednim artykule dałem Ci piękną tabelkę co do klasyfikacji incydentu. Nie wszystkie incydenty są jednakowe, nie wszystkie potrzebują wykorzystania tych samych zasobów. Jest masa incydentów różnej maści, kilka z nich opisałem w poprzednim artykule (link tutaj), ale nie da się ich opisać wszystkich, bo mogą się one różnić zależnie od organizacji. Musimy więc nauczyć się klasyfikować te incydenty i właśnie to jest kolejny krok po ocenie dowodów. Od razu klasyfikujemy dany incydent, nadając mu rangę według naszych standardów, które sobie wcześniej określiliśmy.

To pomaga w określeniu zasobów niezbędnych do wykorzystania. Jeżeli tego nie zrobimy, możemy zaangażować za mało bądź za dużo zasobów — zarówno jedno, jak i drugie podejście jest nieoptymalne. Przy za małej ilości możemy nie poradzić sobie z incydentem, a znowuż przy za dużej incydent może i zostanie zamknięty, ale jeśli w tym samym czasie nastąpi kolejny, nie będzie osób, by nim się zająć. Dlatego moim zdaniem jest to niezbędny punkt w procesie i każdy, ale to każdy na początku ścieżki procesu powinien to znać i umieć skategoryzować.

Śledztwo

Śledztwo kryminalistyczne też jest z jedną faz, które czasem mają miejsce. Pozwalają one określić przyczyny i skutki wystąpienia incydentu. Nie jest to zawsze wymagane, bo czasem mamy od razu jasność co do przyczyny i skutków danego incydentu, ale zdarzają się sytuacje, gdy nie mamy takiej wiedzy i właśnie wtedy należy przeprowadzić dokładne śledztwo. Poza tym śledztwo może być wymagane do procesów sądowych, a w takiej sytuacji, gdy specjalista zbiera dowody, musi to robić w odpowiedni sposób (jeśli opisałem to wkleić link ), gdy zbiera, analizuje i przechowuje informacje.

Poniżej opiszę Ci główne punkty, które określają efektywne przeprowadzenie śledztwa:

• Wykrycie — Opisanie dowodów, które zostały zebrane wraz z opisem narzędzi, które zostały wykorzystane do zebrania tych dowodów. Dowody mogą zostać zebrane zarówno z urządzeń sieciowych — komputerów czy telefonów — ale też mogą zostać zebrane poprzez wywiady z ludźmi, którzy byli lub są zaangażowani.
• Ochranianie — Opisanie technik i narzędzi użytych do zabezpieczenia dowodów już zebranych.
• Analiza — Opisanie analizy zebranych dowodów. Może nawet się zdarzyć, że musimy odtworzyć cały incydent po kroku.
• Prezentacja — Formalny dokument, które będzie opisywał całość śledztwa, zebrane dowody, narzędzia.

Uruchomienie BCP i DRP

Ostatnim razem rozmawiałem z kilkoma specjalistami zajmującymi się bezpieczeństwem. Akurat rozmawialiśmy o incydentach i podpytałem ich, czy organizacje, z którymi współpracują, mają w planie reakcji na incydenty zapisy odnośnie tego, kiedy uruchamiamy BCP i DRP, gdy mamy jakiś krytyczny incydent. Wyraz ich twarzy od razu powiedział mi, jak jest 🙂

Tak więc w planie powinna znajdować się nie tylko informacja, kiedy w wypadku incydentu uruchamiamy BCP czy DRP, czy też kto to robi. Ale osoby zajmujące się incydentami powinny wiedzieć również, kiedy incydent staje się tak krytyczny, że należy uruchomić już BCP czy DRP i że nie należy z tym dłużej zwlekać.

Likwidacja

Ta faza polega na pozbyciu się przyczyny incydentu. Zależnie od incydentu może to np. polegać na pozbyciu się malware z systemów, pozbyciu się podatności, przez którą ma dostęp napastnik. Na przykład poprzez zamknięcie RDP w maszynie, która jest wystawiona na świat. Czy też pozbycie się fizycznie wpiętego urządzenia w biurze. Jest naprawdę wiele możliwości.

W dzisiejszych czasach przeważającą ilością incydentów będą incydenty bardziej logiczne niż fizyczne — takie, które związane są z malware czy też z ransomware, jakie dostały się poprzez sieć, niż razem z wpiętym urządzeniem sieciowym. Dodatkowo coraz cięższe staje się pozbycie się tego typu wirusów, ukrywają się, pozostawiają furtki. Tak że ta faza staje się coraz i coraz trudniejsza, mamy coraz więcej serwerów, często konfiguracja jest słabo zrobiona, coraz to nowsze podatności i zero-day dają się we znaki zespołom, które ogarniają incydenty. Na szczęście my jako bezpiecznicy też się rozwijamy i specjalizujemy, jest nas coraz więcej, ale w dalszym ciągu walka nie jest łatwa.

Przywracanie

Jak sama nazwa wskazuje, faza ta odpowiada za przywrócenie do normalnego działania. Czy to plików, które zostały zaszyfrowane, czy też systemów do stanu sprzed incydentu. Tu najważniejsze jest odpowiednie podejście do kopii zapasowych samych konfiguracji i wszystkiego, co jest możliwe do zachowania. Na tym etapie przydaje się też mieć dobrą komunikację z administratorami. Mogą oni sprawdzić kopie i konfiguracje, czy wszystko jest zgodne, bo sami siedzieli nad tymi konfiguracjami i w łatwy i szybki sposób powinni znaleźć błędy czy też zmiany.

Wykluczanie/poprawianie

Kolejnym krokiem jest wykluczenie zaistnienia incydentu tego typu kiedykolwiek w przyszłości. Gdy już znaleźliśmy przyczynę incydentu i działamy normalnie, wszystko jest ok, wtedy jest pora na to, aby pozamykać wszelkie podatności, które mogą spowodować tego typu zdarzenie w przyszłości.

Na pewno znacie historie, w której to firma została zaatakowana przez ransomware. Następnie zapłaciła, bo nie miała odpowiednich kopii, odszyfrowała się i po kilku tygodniach znowu została zaszyfrowana. Takich historii na pewno jest dużo, nie wszyscy się nimi chwalą czy też takie informacje o nich nie wyciekają. Wracając, jest to jeden z ważniejszych punktów, bo co nam po przywróceniu działania, jak za tydzień nas znowu położą.

Oczywiście lepiej przeciwdziałać niż leczyć — można to robić np. poprzez skanowanie podatności i testy penetracyjne. Ale może się zdarzyć tak, że ani jedne, ani drugie nie znajdą podatności. Właśnie wtedy należy aplikować rozwiązania danych podatności z incydentów, które nie zostały wykryte poprzez powyższe. Ale podstawą powinno być robienie testów i skanów podatności, by wykryć i załatać jak najwięcej przed jakimkolwiek zdarzeniem.

Zamykanie

Gdy już mamy zrobione wszystko, przywrócone systemy i sieci do normalności, biznes działa jak zwykle i wszystko jest już miodzio, trzeba jeszcze wykonać kilka tematów. Zanim przejdziemy do przeglądu po incydencie, musimy go jeszcze zamknąć. Poprzez zamknięcie mam na myśli to, że musimy zarchiwizować dowody ze śledztwa, ponieważ nawet jeśli teraz okazało się, że nie ma legalnych konsekwencji czy procesów sądowych wynikających z incydentu, nikt nie mówi, że to się nie może zdarzyć za pół roku czy rok. Musimy być przygotowani na taką ewentualność. Musimy zarchiwizować również wszelkie zapisy rozmów. W sumie nie napisałem Ci tego wcześniej, ale cała komunikacja wokół incydentu jest ważna, ponieważ trzeba będzie ją zachować 😉 Nie tylko w ramach dowodów, ale też w ramach przeglądu po incydencie. Ale o tym zaraz. No i ważne też jest, aby wszyscy, którzy uczestniczyli w incydencie — czy to wewnętrznie, czy zewnętrznie — byli poinformowani o fakcie zamknięcia incydentu. Niby logiczne, ale warto wspomnieć.

Przegląd po incydencie

Już jak kurz opadł, wszyscy są spokojni, bo wszystko działa i nie widać incydentu, należy zrobić tak zwany przegląd po incydencie. Czyli zbieramy się całą drużyną i rozmawiamy na temat znalezisk: co się działo podczas incydentu, o komunikacji podczas incydentu i jak to możemy poprawić. Poniżej podaję Ci listę typowych zdarzeń, które powinny się wydarzyć w wypadku przeglądu po incydencie.

• Świadomość incydentu — Trzeba się zastanowić i przeanalizować, czy organizacja wystarczająco szybko zdała sobie sprawę z incydentu. Dla mnie, jeśli to nie jest natychmiastowe, oznacza to, że coś jest do poprawy i trzeba poprawiać do skutku.
• Wewnętrzna komunikacja — Trzeba się zastanowić i przeanalizować, czy wewnętrzną komunikacją była na odpowiednim poziomie, czy czegoś nie zabrakło, czy na pewno wszyscy zrozumieli co i jak od razu itd.
• Zewnętrzna komunikacja — Tu mamy podobną sytuację jak powyżej, z tym że dotyczy ona komunikacji zewnętrznej. Wszystko trzeba analizować 😉
• Procedury odpowiedzi — Trzeba się zastanowić i przeanalizować, czy na pewno procedury są napisane tak, jak trzeba. Czy można je poprawić, czy ludzie postępują zgodnie z nimi i tak dalej, i tak dalej.
• Odporność — Trzeba się zastanowić i przeanalizować procesy biznesowe i zastosowaną technologię: czy są one na odpowiednim poziomie, czy można je jakoś poprawić, zapewnić im większe bezpieczeństwo.

Podsumowanie

Ten artykuł jest mało techniczny, bardziej ma za zadanie pokazać, na czym polega proces odpowiedzi na incydent. W głównej mierze ma przedstawić biznesowi, jak trudne jest to zadanie i ile często potrzeba poświęcić czasu oraz zasobów, by taki incydent rozwiązać. Ma to też pomóc specjalistom, na których zwalana jest całość pracy dotycząca bezpieczeństwa w organizacji — tak, by potrafili w prosty sposób za pomocą tego artykułu pokazać, że wymaga to szeregu umiejętności, czasu i zasobów. I powiedzenie, że Ty się zajmujesz bezpieczeństwem, to dasz sobie radę z incydentami, nie działa.

Mam nadzieję, że dzięki temu artykułowi będziesz w stanie wywalczyć czy to zasoby ludzkie, czy to czas lub pieniądze na zbudowanie odpowiedniego procesu dla odpowiedzi na incydenty bezpieczeństwa. Lub też oddelegować to do zewnętrznego SOC. Ma to swoje minusy, ale dużo lepiej, niż jak miałbyś sam ogarniać ten incydent 😉

Pozdrawiam – Pusz ????