Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Jak skutecznie radzić sobie z phishingiem? Studium przypadku
Czy kiedykolwiek zastanawialiście się, jak wyglądałaby nasza („bezpieczników”, zespołów odpowiedzialnych za bezpieczeństwo informacji, administratorów bezpieczeństwa informacji…) codzienna praca, gdyby – określana obecnie jako jedna z najbardziej uciążliwych i najtrudniejszych w zwalczaniu metod – phishing, okazała się nieco mniej groźna i możliwa do przezwyciężenia dostępnymi środkami i bez nadmiernego angażowania sił?
Studium przypadku – znana większości (lub wszystkim) z Was, tegoroczna majowa kampania phisingowa wykorzystująca wizerunek firmy logistycznej DHL w spreparowanych wiadomościach e-mail wyłudzających dane (przykład poniżej), versus kampania antyphishingowa przeprowadzona przez jedną z firm w sektorze usług IT, może być dla Was przykładem oraz inspiracją w walce z zagrożeniami sieciowymi, w tym przypadku – phishingiem, czyli jedną z metod oszustwa sieciowego.
Phishing polega na podszywaniu się przez oszustów pod inną osobę, instytucję, organizację w przekazywanych odbiorcy treściach – m.in. właśnie w wiadomościach e-mail, poprzez fałszywe witryny internetowe udające prawdziwe itp., w celu nakłonienia atakowanego (użytkownika) do wykonania określonych działań, powodujących utratę ważnych przez atakowanego danych, np. numerów kart kredytowych, danych osobowych, danych logowania itp. i – nierzadko – uszczuplenie portfela atakowanego lub finansów firmy, w której pracuje…
Rys 1. Przykładowy e-mail z kampanii phishingowej, widok ogólny (źródło).
Rys 2. Przykładowy e-mail kampanii phishingowej – podejrzane elementy (źródło).
Rys 3. Przykładowy e-mail kampanii phishingowej – podejrzane elementy (źródło).
Tak skonstruowane wiadomości docierały do użytkowników – wobec czego, niezwłocznie podjęliśmy walkę z phishingiem.
Przebieg wypadków
Fundamentem postępowania było podejście incident response, założenia procesu zarządzania incydentami bezpieczeństwa informacji, a także procesu zarządzania incydentami w ujęciu ITIL – w praktycznym zastosowaniu.
Dzięki temu możliwe było usystematyzowanie działań według charakterystycznych etapów, które – oceniając z perspektywy zdobytego dotychczas doświadczenia – w znakomitej większości są typowe dla większości „nękających” nas incydentów bezpieczeństwa. Myślę, że ów rozpoznawalny wzorzec, znacznie uprościł i przyspieszył nasze działania, co przełożyło się na dodatni efekt końcowy.
Praktycznie i skrótowo ujmując, etapy „walki” były następujące:
1. Wystąpienie oraz identyfikacja incydentu bezpieczeństwa związanego z pocztą elektroniczną. Opis oraz ocena sytuacji.
2. Reakcja na incydent, „gaszenie pożaru”. Wczesna ocena przeprowadzonych dotychczas działań.
3. Wynik i ocena działań; monitorowanie i raportowanie (wewnętrzne i dla klienta).
4. Wnioski z incydentu. Lessons learned.
Zmagania z phishingiem realizowały następujące „siły”:
- IT Admins, IT Sec – warstwa techniczna;
- Help Desk, użytkownicy, przedstawiciel klienta.
Ważną rolę odegrała firma DHL. W okresie maj – czerwiec br., prawdopodobnie w związku z otrzymanymi zgłoszeniami – zaktualizowała komunikaty na swojej stronie, ostrzegające przed oszustwami internetowymi oraz SPAM-em z użyciem nazwy firmy.
Charakterystyka poszczególnych etapów
1. Wystąpienie oraz identyfikacja incydentu bezpieczeństwa związanego z pocztą elektroniczną – ocena sytuacji
Aby czas poświęcony w tym etapie został jak najlepiej spożytkowany, niezbędna była współpraca zespołów IT Admins, IT Sec oraz Help Desk. Poniższy opis (czy też schemat) może wydawać się nieco na wyrost. Przekonacie się, że zyskuje na znaczeniu w miarę upływu czasu i wykonanych działań. Zapewnia bowiem kontekst nadający właściwy kierunek całemu procesowi i często jest wykorzystywany jako „mapa drogowa” – nie tylko w walce z zagrożeniami, niewątpliwie wyzwalającej stres, presję i – czasami – tymczasowy chaos w szeregach walczących. Jest niezbędny w następnych etapach – punktach kontrolnych, w których przeprowadza się ocenę wykonanych działań, zastosowanego podejścia i – co najistotniejsze – kiedy wypracowywane są wnioski na przyszłość, tzw. lessons learned.
Rzeczywisty opis sytuacji – IT Admins, IT Sec
1. Przyczyna wystąpienia: celowe działanie – masowe rozsyłanie niechcianych wiadomości e-mail (spam) zawierających podejrzane elementy (phishing).
2. Skutek: niechciane e-maile z podejrzaną i potencjalnie niebezpieczną treścią w skrzynkach odbiorczych użytkowników:
a) „informacja” DHL o przesyłce, w treści wiadomości spreparowany odnośnik do rzekomego pliku w formacie *.pdf
b) „e-faktura” „zdjęcia” z załącznikiem typu *.rar, *.zip – „fałszywe archiwum”
3. Zagrożenia, ryzyko (wg priorytetów):
I. utrata, wyciek ważnych danych firmowych/prywatnych w wyniku działań użytkownika z zawartością wiadomości – tj. uruchomienie malware, otwieranie złośliwych załączników, próby zapisywania zawartości na zasobach lokalnych użytkownika, itd.
II. zalew spamem (klientów i organizacji)
III. pojawienie się firmy na czarnych listach (black lists), co w konsekwencji mogłoby spowodować niedostępność usługi poczty elektronicznej – brak możliwości wysyłania i odbierania wiadomości e-mail.
4. Plan reakcji na incydent, zwięzła misja, plan komunikacji:
a) warstwa techniczna – IT Admins, IT Sec – działania i instrukcje dla administratorów, realizacja wskazówek z audytu.
b) warstwa biznesowa – Help Desk – kontakt z użytkownikami, klientem, kierownictwem firmy – instrukcje dla użytkowników, klienta.
5. Wykonawcy – IT Admins, IT Sec, Help Desk.
Ocena sytuacji
1. Analiza i audyt – IT Admins, IT Sec, Help Desk:
1.1. Wynik analizy elementów, załączników wiadomości:
a) „DHL” – malware z bibliotekami szyfrującymi (Cryptolocker) – żaden z użytkowników nie podjął ryzykownych działań
b) „e-faktura”, „zdjęcia” – malware wykradający dane – niestety, sporo zgłoszeń; raport systemu AV potwierdził skalę zdarzenia (nie wszyscy użytkownicy podzielili się z nami niechlubnym faktem wykonania ryzykownych działań… ;))
1.2. Liczba zgłoszeń dotyczących podejrzanych wiadomości e-mail w trendzie wzrostowym.
1.3. Raport systemu AV z liczbą zainfekowanych stacji roboczych w wyniku działań użytkowników – klikanie w link, próby otwarcia załączników itp.;
1.4. Ocena, czy jesteśmy w stanie zwalczyć zagrożenie oraz ile zajmie nam to czasu (orientacyjnie); istotne było poinformowanie kierownictwa firmy o wystąpieniu zagrożenia i stanie faktycznym – w przypadku gdyby niezbędne okazało się uzupełnienie zasobów;
1.5. Zalecenia z audytu IT Sec:
– natychmiastowa aktualizacja AV – IT Admins,
– pozaplanowe skanowanie AV – IT Admins,
– rekonfiguracja filtrów antyspamowych – IT Admins,
– zgłoszenie firmie DHL faktu podszywania się pod nią oszustów internetowych – SPAM – IT Sec.
Dzięki opisowi i ocenie sytuacji uzyskano cenne dane wejściowe, ułatwiające szybką reakcję i podjęcie niezbędnych, skoordynowanych działań w warstwach biznesowej i technicznej. Zaoszczędzono czas, usystematyzowano działania w etapach następnych.
2. Reakcja na incydent, „gaszenie pożaru”
Jak wynika z opisu, reakcję na incydent można (wręcz trzeba!) zaplanować – tak samo jak w przypadku gaszenia pożaru.
Podział ról oraz koordynacja działań umożliwiły płynną realizację działań opisanych w punkcie 1. W warstwie technicznej zespoły IT Admins i IT Sec opanowywały sytuację od strony systemów, natomiast Help Desk – w warstwie biznesowej.
Pomoc użytkownikom, wczesne informowanie w usystematyzowany sposób przedstawiciela klienta oraz kierownictwa firmy o zagrożeniu wpłynęła na pozytywne postrzeganie firmy przez stronę biznesową. Zyskaliśmy sojusznika w następnych etapach walki z phishingiem, która przerodziła się w… kampanię antyphishingową.
Warstwa techniczna
- Aktualizacja systemu antywirusowego.
- Zmiana konfiguracji filtrów antyspamowych.
- Pozaplanowe skanowanie AV.
- Niezwłoczne skanowanie AV zainfekowanych stacji roboczych – na podstawie raportu systemu antywirusowego.
- Monitorowanie działania systemów (AV, antyspam).
- Ocena, czy podjęte działania zneutralizowały rozprzestrzenianie spamu.
- Ocena, czy konieczna jest ponowna rekonfiguracja systemów.
- Wskazówki do hardeningu systemów.
- Zgłoszenie SPAM-u wykorzystującego wizerunek firmy do DHL.
Warstwa biznesowa
Koordynacja działań z użytkownikami (telefonicznie, e-mail), przekazanie użytkownikom instrukcji postępowania, poprzez:
- Kontakt z użytkownikami, którzy otrzymali podejrzaną korespondencję i uruchomili szkodliwe treści oraz zgłosili ten fakt,
- Kontakt z użytkownikami, którzy otrzymali podejrzaną korespondencję i uruchomili szkodliwe treści i nie zgłosili tego faktu.
Podstawa – raport AV, na bieżąco aktualizowany i przekazywany do Help Desk przez IT Sec.
- Kontakt z użytkownikami, którzy zgłosili otrzymanie podejrzanej korespondencji, nie uruchomili szkodliwych treści.
- Poinformowanie strony biznesowej (przedstawiciela klienta) oraz kierownictwa firmy o zdarzeniu.
- Obsługa zgłoszeń w ITSM (systemie wspomagającym zarządzanie usługami IT) dotyczących phishingu.
- Pozyskanie i przekazanie informacji zwrotnej od przedstawiciela klienta, kierownictwa, użytkowników dla IT Admins/IT Sec.
- Wstępny raport ze zdarzenia.
Sprawdzający się schemat komunikatu o incydencie dla „biznesu”, zawiera następujące elementy:
- ogólna przyczyna wystąpienia – informacje techniczne na minimalnym poziomie, potencjalne ryzyka wynikające ze zdarzenia i ich wypływ na klienta, orientacyjna skala zdarzenia – w zakresie dotyczącym klienta;
- zwięzła informacja o prowadzonych przez nas działaniach oraz orientacyjnym czasie rozwiązania problemu;
- wstępne instrukcje postępowania dla użytkowników, przedstawiciela klienta, typu „padłeś ofiarą phishingu – co robić, jak żyć” (np. zmiana haseł do systemów, blokada karty, niezwłoczne skanowanie komputera, z kim się kontaktować itd.) i kto przekazuje użytkownikom te instrukcje;
- zwięzła informacja dla przedstawiciela klienta – w stylu „wake-up call” z wszystkimi powyższymi elementami.
3. Wynik i ocena działań. Monitorowanie, raportowanie – wewnętrzne i dla klienta. Dokumentowanie
Niezbędny punkt kontrolny – dzięki niemu systematyzowane są działania procesu zarządzania incydentem bezpieczeństwa informacji oraz kształtuje się dobre praktyki – zarówno wewnętrznie, jak i w odniesieniu do klienta.
Do oceny działań wykorzystano:
- logi potwierdzające prawidłowe działanie zaktualizowanych i zrekonfigurowanych systemów;
- raport z AV o stanie stacji roboczych – brak „nowych” infekcji;
- raport Help Desk – brak zgłoszeń dotyczących SPAM-u; opis statusu zgłoszeń zarejestrowanych i rozwiązanych, instrukcje przekazane;
- weryfikacja wewnętrznych zależności i poprawności zastosowanego podejścia, opracowanie wniosków;
- informacja zwrotna dla kierownictwa firmy – efekt podjętych działań, czas realizacji, wykonane prace, wstępne wnioski;
- informacja zwrotna od przedstawiciela klienta:
- czy wyjaśniliśmy zamiary przeciwnika i jakie miały one wpływ na zasoby klienta?
- czy wyposażyliśmy użytkowników w odpowiednią wiedzę i narzędzia do obrony?
- czy nie pojawiło się zapotrzebowanie na wiedzę w zakresie ochrony zasobów firmowych klienta oraz kształtowania świadomości pracowników klienta w walce z zagrożeniami sieciowymi?
Raportowanie i dokumentowanie – dość często (i niesłusznie!) postrzegane jako zadanie zbędne i uciążliwe w realizacji, stanowi sedno całego podejścia. Informacje zagregowane i uporządkowane w tej fazie, są wykorzystane do poprawy stanu bezpieczeństwa środowiska przetwarzania zapewnianych przez firmę usług.
W opisywanym przypadku dokumentowanie i raportowanie było znacznie ułatwione, ponieważ wykorzystano schemat opracowany w punkcie 1., którego poszczególne sekcje uzupełniane były wnioskami i ocenami po „walce” w warstwach biznesowej i technicznej. Pozwoliło także zidentyfikować słabe punkty stosowanych rozwiązań i obszary, które powinny być objęte analizą nie tylko na poziomie ich eksploatacji, ale także – ewentualnych przyszłych wdrożeń. Zwróciło również uwagę na korzyści i redukcję kosztów własnych, jak i klienta.
Ściąga: gdy odważysz się przekazać raport z incydentu bezpieczeństwa na zewnątrz (do klienta)
Odpowiednio skonstruowany i właściwie przekazany do klienta (odpowiedniej osobie) raport z incydentu, może posłużyć jako doskonałe (stosunkowo tanie i efektywne) narzędzie budowy i utrzymania profesjonalnego wizerunku firmy.
Należy pamiętać wówczas, aby w raporcie pojawiły się zalecenia poprawy i np. wstępne uzgodnienia z klientem. Niezbędne jest także przekazanie przez nas praktycznych wskazówek i wniosków, a także – uwzględnienie odpowiedzi klienta na pytania postawione w punkcie 3.6.
Warto sklasyfikować taki dokument oraz uzgodnić z klientem zasady jego przekazywania i rozpowszechniania – raczej nie chcielibyśmy, aby pojawił się jako news na pierwszej (lub jakiejkolwiek) stronie… gdziekolwiek ;)
W tym etapie urzeczywistniliśmy ideę kampanii antyphishingowej, w którą czynnie włączono przedstawiciela klienta.
Sytuacja zagrożenia posłużyła jako trigger (wyzwalacz) do akcji uświadamiającej, polegającej na rozesłaniu pocztą elektroniczną do wszystkich użytkowników klienta specjalnego biuletynu poświęconego zapobieganiu i obronie przed zagrożeniami sieciowymi. Zaproponowaliśmy również, aby intranetowe zasoby klienta zostały uzupełnione o nową sekcję dotyczącą praktycznych zasad bezpieczeństwa informacji, podstawowej i zaawansowanej obrony przed phishingiem oraz innymi oszustwami sieciowymi.
Na prośbę klienta, opracowałam i przekazałam materiały szkoleniowe; według informacji zwrotnej, odzew był bardzo pozytywny (o tym, jak tworzyć zajmujące i zapadające w pamięć treści szkoleniowe to temat na kolejny artykuł…).
4. Wnioski z incydentu, lessons learned
Etap końcowy, stanowiący podstawę do prac i działań wynikających z incydentu, niekoniecznie związanych z nim bezpośrednio. W opisywanym przypadku było podsumowaniem – listą prac do wykonania:
- Wdrożenie monitorowania i alertowania działania systemu antyspamowego; termin realizacji, zespół lub osoby odpowiedzialne za realizację zadania (harmonogram prac i jego lokalizacja, id zgłoszeń do dostawcy – jeśli koniecznie itd.), kto potwierdza prawidłowe wykonanie prac.
- Przeprowadzenie kampanii antyphishingowej dla wszystkich klientów (nie czekaliśmy na następną kampanię phishingową…;) – specjalny biuletyn + uzupełnienie zasobów klienta o stałą sekcję dotyczącą bezpieczeństwa informacji – z elementami jw. (termin, kto odpowiedzialny, kto potwierdza).
- Analiza ryzyka wskazanych zasobów, które „ujawniły się” podczas walki; plan postępowania z tymi ryzykami.
- Propozycja planu szkoleń i warsztatów dla klientów z zakresu bezpieczeństwa informacji wiązała się z konkretną ofertą; wymagane potwierdzenia klienta, pozostałe elementy – jw.
- Aktualizacja bazy wiedzy z pozyskaną wiedzą po incydencie – do wykorzystania w szkoleniach, warsztatach i materiałach szkoleniowych.
Lessons learned learned jest podejściem polegającym na podsumowaniu przeprowadzonych działań, szacowaniu strat i zysków po “walce”; próbą zrozumienia na ile przeprowadzone działania mogą być adekwatne w odniesieniu do innych (przyszłych) incydentów. Grupowanie zastosowanych środków, działań zapobiegawczych według kategorii ułatwia dopasowanie oraz użyteczność danej techniki, metody, czy podejścia w przypadku innych kategorii incydentów, zdarzeń – nawet gdy nie mogą być one zastosowane bezpośrednio.
źródło: opracowanie własne, na podstawie
The Practical Guide to Defect Prevention, Marc Mc Donalds, Robert Musson, Ross Smith.
Początkowe opory przed dzieleniem się spostrzeżeniami, trudnościami i przeszkodami w działaniu – zarówno w warstwie biznesowej, jak i technicznej, przeważyły nad korzyściami, jakie dostarcza ten etap.
W naszym przypadku, skupiliśmy się na:
- efektywności procesu – zaleceniach dotyczących zmian,
- możliwości automatyzacji oraz wykorzystanych (i niewykorzystanych) technologii – m.in. stworzeniu/poprawy narzędzi monitorujących, wykrywających, zapobiegawczych,
- niezgodnościach i ryzykach – przyczynach i ich znaczeniu dla firmy,
- możliwości szkoleń.
Należy zadbać o to, aby lessons learned były odrobione – czyli wprowadzone w życie… a to już osobny temat.
Podsumowując – po tym incydencie, każdy z nas zyskał świadomość, że naprawdę solidnie odrobiliśmy tę lekcję.
Czy uważasz, że dzięki temu artykułowi, „sprawozdaniu z pola walki”, phishing może okazać się mniej groźny?
Co sądzisz o całym artykule?
– Scutum
Co to za bełkot?
Po trzech akapitach nie dałem już rady przez to brnąć.
Podzielisz się swoimi doświadczeniami w temacie? :)
Zgodzę się- bełkot. Dotarłem do „Rzeczywisty opis sytuacji – IT Admins, IT Sec” i doszedłem do wniosku, że pisał to ktoś kto z rzeczywistością spamowa ma mało do czynienia, Dostał do analizy problem „Phishinng + DHL + reakcja na incydenty i opisał na podstawie tego co „gdzieś” wyczytał. Włączył do tego podejście proceduralne i … wyszło.
Wypunktowane jakieś informacje … trudno złapać wspólny kontekst. To bardziej wygląda jak konspekt do być może interesującego wystąpienia. Jednak na artykuł do czytania się nie nadaje.
Moje pytania o kontekst artykułu:
Jakiej firmy dotyczy problem (profil)? To ma ogromne znacznie. Komercyjna firma inaczej będzie reagowała, dostawca usług inaczej, a instytucje publiczne inaczej.
Kiedy podejmujemy działanie? CO uznajemy za atak (phishing) co za zwykły spam.
Jakie mamy rodzaje phishingu …
Artykuł przekazuje w punktach .. że jest phishing, że jest groźny, że trzeba się bronić, że trzeba mieć opracowany plan i pisać raporty.
Dla mnie, brakuje konkretów …
– jak przeprowadzić kampanię antyphishingową (nie mogę co dziennie wysyłać maila do miliona użytkowników by nie otwierali faktur)
– jak wykrywać phishing … bo nie uwierzę, że ktoś polega na automatach opartych o sygnatury, itp…
Niestety takie odnoszę wrażenie.
A teraz konstruktywnie.
Reagowanie na incydenty związany z phishingiem jest niesamowicie trudne, bo bardzo dużo zależy od użytkownika końcowego. Jego wyobraźnia jest nieograniczona.
To niemal zawsze gaszenia pożarów. Można się wspomagać cudownymi rozwiązaniami (AV, Antyspam, Antyphishing, DLP). Jednak bardzo często skutki dotykają użytkownika końcowego, a po jakimś czasie firmę (bo to wypłynie po czasie).
Trzeba dodać, że kampanie phisingowe są różne … i wyciągnięcie wniosków z jednej kampanii, wcale nie uchroni nas przed inną.
Kampania DHL lub Poczta Polska byłą masową kampania, i niestety zebrała duże skutki, poprzez swoją masowość. Bo generalnie te kampanie były łatwe do wyłapania i zablokowania. Jednak jak nawet jeden promil „wpadnie” to na milion użytkowników mam 1000 trafionych stacji końcowych. Znacznie częściej przychodzi phising znacznie lepiej przygotowany niż DHL (choćby popularne faktury od operatora, gdzie wszystko było sensownie w języku polskim sklecone). I co wtedy… jak niektóre działy w firmie muszą czytać umowy, inne muszą czytać faktury … jakie kryteria walki obrać.
Do tematu phishingu warto wrócić, ale warto zrobić to kompletnie.
W pierwszej części komentarza też jesteś konstruktywny ;) tylko trzeba czytać między wierszami.
Co do części merytorycznej ogólna zgoda (szczegółów nie będę się czepiał bo musielibyśmy sobie zarysować szerzej i głębiej kontekst), mam tylko drobny komentarz.
Jednym z problemów w przekazywaniu wiedzy i dzieleniu się doświadczeniem o szeroko pojętej obronie jest kontekst sytuacji. Z jednej strony czasem ludzie opisują bardzo konkretną sytuację (choć nie zawsze to zaznaczają i mamy pewien problem poznawczy), z drugiej chcemy zobaczyć cały/większy obrazek, to jednak wymaga znacznie dłuższych tekstów (właściwie to serii tekstów), a te znów powodują, że trzeba znacznie więcej zaangażować energii i czasu na to. Nawet jak spotkają się wyjadacze, którzy pracują nad tym samym, ale z różnych perspektyw to dla każdego z nich podejście kolegi jest niekompletne – dlatego warto się spotykać, rozmawiać, wymieniać doświadczeniami. Może w bliskiej przyszłości uda mi się namówić kilku kolegów/gości (może są chętnie wśród czytelników sekuraka! – proszę takie osoby o kontakt [mail na mojej stronie]) by przeprowadzić kilka rozmów na temat obrony, np. w postaci podcastu – jestem przekonany, że prawie się „poszarpiemy”, w pozytywnym tego słowa sensie ;)
Wiedza nie jest uniwersalna, a do jej użycia jest niezbędny całkiem sprawny umysł.
To jest mój punkt widzenia na ten i podobne tematy.
Fajnie, że podzieliłeś się takim komentarzem – autorka tekstu będzie miała z czego wyciągać wnioski. Dzięki za to!
Przemek – bardzo dziękuję za wsparcie, Pana fundamentalny wkład w dyskusję oraz przede wszystkim – zmotywowanie mnie do podzielenia się doświadczeniami defensywy :) Fenomenalnie wyjaśniona jej złożoność – być może kiedyś uda mi się podobnie ją ująć… chociaż w połowie :)
Pozdrawiam.
Prawie się zaczerwieniłem ;-) proszę tylko nie przez „Pan”. Wierzę, że defensywnych bezpieczników obu płci będzie coraz to więcej, szczególnie, że jest na to racjonalnie uzasadnione.
Pozdrawiam i czekam na kolejne artykuły, także w tak niestandardowej formie!
Itar, uwierz – uczestniczyłam w tym od początku do końca i nikt mi tematu nie „wpychał” :) Ale nie w tym rzecz, aby przekonywać do siebie a do tematu. Niektóre zagadnienia – z natury rzeczy, musiały być przedstawione tak a nie inaczej (czyli skrótowo, ogólnie) :) Kampania antyphishingowa była opracowana z przedstawicielem klienta, rozsyłanie maili realizował Help Desk. Taką ma rolę. Materiały nie były załączane do wiadomości – użytkownicy otrzymali linki od plików na serwerze.
Zgadzam się i nie zgadzam, to zależy od podejścia, czego oczekujesz od artykułu. Ja bym wolał wersję bardziej techniczną typu przykłady konfiguracji np. spamassasina czy innych narzędzie w oparciu o kilka kampanii phishingowych, bo nie lubię teorii, zdecydowanie bardziej wolę klikać. Ale z drugiej później trzeba napisać raport dla ludzi którzy techniczni nie są, i zrozumieją tylko konkretne liczby, ładne wykresy i raporty co się stało, co zostało zrobione, co trzeba wprowadzić nowego, dlaczego trzeba zainwestować dodatkową kasę itd itd. I moim zdaniem ten artykuł jest czymś, na czym można oprzeć taki raport dla biznesu.
Celne uwagi ale w mojej ocenie nie do zastosowania tutaj. To nie jest kartka z podręcznika, to nie jest instrukcja działania. Od pierwszego zdania jest to „studium przypadku” w formie „gorącej relacji”, a jako takie nie może być ogólne i stosowane do wszystkich sytuacji.
Przecież phishing to stara technika, jedna z odmian „fałszerstwa” znana od setek lat. Pierwotnie używana do kradzieży danych osobowych i danych logowania, kuponów, tokenów itp co zostało „przewrotnie” zacytowane przez autorkę. Obecnie to co nazywamy phishingiem jest już dalekie od jego pierwotnej formy i najczęściej ma na celu albo dostarczenie złośliwego oprogramowania albo oszustwo (podmienione rachunki bankowe, nie istniejące faktury za nie istniejące towary itp.). Nie można podejść do tematu holistycznie, bo prawdę mówiąc nikt już nie używa tego terminu zgodnie z jego definicją. APT głównie zaczyna się od phishingu (a nie jak dawniej pisano od socjotechnik), spam i scam tak samo jak malversiting jest również podciągany pod phishing. Z całej definicji pozostało tylko to, że użytkownik jest nakłaniany do realizacji czynności na postawie zaufania jakim darzy rzekomego nadawcę wiadomości…
Ten artykuł nie rozstrząsa phishingu jako zjawiska w akademickim znaczeniu, opisuje je jako zagrożenie dla bezpieczeństwa organizacji, konkretnie.
Podaje też bardzo konkretne rozwiązanie: szkolenie użytkowników, co jest jak do tej pory jedynym, dającym cień nadzieji mechanizmem detekcji i przeciwdziałania takim zagrożeniom.
Jeśli potrzebujesz technologii wspierającej szkolenia uzytkowników moim zdaniem zacznij od poszukania takich, które w łatwy i relatywnie szybki sposób można zasilać IOC lub CybOX-em, do tego wiarygodne źródła danych o tych wskaźnikach, skanowanie na wejściu+sandbox na wejściu+skanowanie na hoście+monitorowanie procesów/systemu plików na hoście, standardowo AV i update systemu, przeglądarki i pakietu Office, javy, flasha itp.
Przestępcy są niewiarygodnie szybcy, ostatnio wykryliśmy przypadek, w którym dana wersja malware umieszczona była w pliku, którego utworzenie było datowane na ok. 5 dni wstecz (również kampania typu firma kurierska). Pliku nie raportował VT, AV był jednak w stanie zajrzeć do środka i znaleźć dobrze znanego downloadera. Tyle że to było „masowe”, więc AV sobie poradził. Sprawa jest dużo trudniejsza gdy AV nic nie zobaczy, lub plik będzie zaszyfrowany, albo to co ostatnio modne, złośliwa treść będzie ukryta „na widoku”.
Dlatego nie ma jednego rozwiązania, schematu, środka czy technologii. A sam wiesz najlepiej na co nabrać swoją księgową, zespół PR czy HR. To jest dobry punkt wyjścia do opracowania szkolenia…
Mi to wygląda na belkot akademicki. Ale poziom rozlania wskazuje na raczej lokalne, prywatne uczelnie.
Mamy trochę bardziej technicznych tekstów, ale mamy trochę bardziej proceduralno/zarządczych – jak ten. IMO warto pamiętać o wszystkim.
„Akademicki bełkot” – uzasadnij proszę. Na pewno konstruktywny komentarz może pomóc – autorce i czytelnikom.
Przesadziłem z `akademickim`, ale chętnie napiszę co mi się nie podoba.
Jest to post na blogu, a zawiera w sobie spis treści (wyszczególnione etapy, które następnie są opisywane). To jeszcze przejdzie.
Dużo wstawek angielskich, moim zdaniem nieuzasadnionych, kalek językowych (np. mapa drogowa, gaszenie pożaru – firefighting). Sugeruję używać angielskich określeń jak coś nie ma polskiej nazwy, albo jak uważamy że jest to przydatne dla spójności słownictwa (np. spam, phishing, wszyscy wiemy o co chodzi). Masa powtórzeń, trójca IT Admins, IT Sec, Help Desk lata po ekranie w co drugiej linijce, nie wiem jak to ma ktoś czytać.
Dałoby się to napisać zwyczajnie i zwięźle, kto, co i dlaczego zrobił.
Wszystko jest ujęte w jakąś dziwną i niekonsekwentną numerację (etapy arabskimi, następnie ponownie arabskie z podpunktami a).., a dalej jeszcze raz arabskie, ale już 1.1)
Momentami to brzmi jak jakaś przeklejka z niekonsekwentnie budowanej dokumentacji.
Na koniec phishing jest pochylony, zgaduję jako słowo obce, ale wcześniej nie jest.
Brak korekty, z błędami w stylu „Lessons learned learned jest podejściem”.
Ogólnie fajny temat i można to świetnie opisać, nie brak przykładów po angielsku takich aftermath :P. Czuję się jakby było to klepane na liczbę słów, jak niektóre książki polskich akademików.
z mojej strony dzięki! :)
Również dziękuję. Proszę mi wierzyć – takie wyrażenia „kalki” funkcjonują w naszym środowisku pracy i są dla nas naturalne (nie pamiętam, aby ktoś miał zastrzeżenia). Lubimy w szczególności „gaszenie pożaru” – niezmiennie nas to bawi :) Sądzę, że najważniejsza jest ich funkcja – „kalki” – jako wspólne i znane pojęcie, znakomicie ułatwiają komunikację oraz współpracę pomiędzy zaangażowanymi w obsługę incydentów działami. Co do reszty – cóż, mam nadzieję, że wyczerpująco opowiedziałam się w moim pierwszym komentarzu :)
Może potrzebujesz to przeczytać dzieląc cały artykuł na kilka części.
Dlaczego „bełkot”? – uzasadnij swoją hipotezę/zdanie.
Jako „bezpiecznik” musiałbym takie pisać? ;(
Zależy od roli jaką byś pełnił. Z czasem zrozumiesz, że nie da się osiągnąć wysokiego poziomu zarządzania bezpieczeństwem w średniej-dużej firmie bez uwzględnienia takich procesów jak opisany w tym artykule.
Jak toto wdrożyć w filtry antyspamowe nie blokując DHLa?
w oryginalnych mailach z DHL w polu „from” jest domena DHL.
To w systemie antyspamowym masz tylko filtry dla pól nagłówka? Może warto również wzbogacić system ochrony poczty po stronie serwera pocztowego o AV? Warto również rozważyć bardziej zaawansowane mechanizmy ochrony poczty z użyciem usług reputacyjnych, sandboxów i całego szeregu technik. Na rynku jest tego zatrzęsienie…
Brawo dla autorki.
Po pierwsze za decyzję o publikacji
Po drugie za podejście procesowe
Po trzecie za komunikację
Po czwarte za raporty
Gdyby tak każdemu się chciało jak wam…
Temat wróci jak bumerang jak akcja phisingowa znowu nabierze na sile ( u mnie w firmie do dzisiaj wariuje pocztapolska i jej przesyłki z logiem poczty ) .
Artykuł obszerny ze studium przypadku dla praktyków a nie miłośników przekazania wiedzy a la ” demotywatory” jeden obrazek i 3 wyrazy
Bo bronić trzeba też chcieć, bym cierpliwym, wytrwałym, konsekwentnym.
To nie „zabawa”. Fantastycznie, że wśród czytelników sekuraka są świadomi tego ludzie i że się ujawniają. Bez Was cały ten świat skazany jest na porażkę – ktoś ma wątpliwości? – ja nie!
Artykuł tego typu pewnie nie wykręci rekordu popularności, ale jest warty więcej niż większość dużo bardziej nośnych tematów.
Przemku,
ja się z Tobą zawsze zgadzam … szczególnie cenię twoje podejście obronne. Sam pracuję po „tej stronie mocy”, gdzie tylko mogę się bronić, dlatego dokładanie analizuję Twoje teksty, jak i inne scenariusze obronne.
Ale podaj mi w kontekście tego konkretnie artykułu – jak się bronić przez phishingiem. Jak klikałem w artykuł miałem nadzieję, że coś interesującego się dowiem – o phishingu.
Wnioski z incydentu mogą dotyczyć każdego rodzaju incydentu.
Mówiąc wprost widziałem ten artykuł przed publikacją (generalnie zdarza mi się „recenzować” teksty defensywne publikowane na sekuraku – nawet niezależnie od redakcji :)) i sam rekomendowałem by go tak puścić jak jest, bo prawdopodobnie wywoła dyskusję.
Dlaczego? – bo artykuł pokazuje phishing z perspektywy, której może nikt inny by nie chciał pokazać. Czy trafi do każdego? – pewnie nie i dlatego nie znalazłeś czegoś interesującego dla siebie i to nie oznacza, że coś jest złego z Tobą czy z samym tekstem.
Jesteśmy (mam na myśli ludzi broniących) na różnych poziomach (bo tak chcemy, tak potrzebujemy, bo ciągle się rozwijamy, a model zagrożeń ulega zmianom, itd.) i potrzebujemy różnych perspektyw – osobiście sam bardzo dużo się z tego uczę i proponuję próbować czytać między wierszami, inspirować się choćby małymi elementami, które pozwolą stworzyć coś większego – coś np. dla Ciebie interesującego.
Dosłownie dzień-dwa temu pisałem do Artura (tak mi się wydaje, że to ten Artur z komentarzy powyżej ;)), że obrona jest dużo bardziej złożona, a wciąż wiele osób oczekuje, że w „jednym artykule”, na „2 dniowym szkoleniu” lub w 10 przykazaniach dowie się jak w sposób spełniający jego oczekiwania (jego realia, możliwości, ograniczenia, potencjał, charakter firmy czy jej zarządzających) rozwiązać dany problem. Tak się moim zdaniem nie da, a jeśli ktoś tak potrafi to sam chętnie wybiorę się na takie szkolenie i przeczytam takie artykuły, nawet postaram się o pracę w takim miejscu. Obrona to proces i tylko w części przypadków da się przenosić dane rozwiązania z realiów firmy X do firmy Y w sposób 1:1.
Sugeruję pozbawienie się negatywnego nastawienia do artykułu i poszukania w nim czegoś interesującego dla siebie – niekoniecznie w całości. Jeśli miałbym coś zasugerować od siebie to całkiem inspirujący dla części organizacji może być lista punktów („Warstwa techniczna”, punkty od 1-9), które mnie np. podpowiadają by sprawdzić czy mierzę skuteczność obrony realizowanej za pomocą narzędzi które posiadam (AV, antyspam, itd.), jeśli mierzę to czy reaguję na wartości tych miar adekwatnie do sytuacji i incydentów jakie mam w tym obszarze, itd.
Jeśli spróbowałeś poszukać czegoś interesującego dla siebie i coś znalazłeś, daj proszę znać :)
PS
Cieszę się, że czytasz moje teksty, każda informacja zwrotna (pozytywna/negatywna, a najlepiej konstruktywna!) bardzo mile widziana :) wkrótce kolejne artykuły.
Itar – pozwól, że podpowiem – gdy zaangażujesz w obronę i walkę nie tylko siły wewnętrzne oraz narzędzia, ale przede wszystkim – użytkownika, klienta, firmę której wizerunek jest w phishingu wykorzystywany… (pomysłów jest sporo!) – dostarczysz niezbędne wsparcie i nauczysz, jak się bronić. Wbrew pozorom, nie jest to tak oczywista sprawa :)
Witam,
dziękuję za wsparcie i zrozumienie oraz konstruktywną krytykę.
Nie zdawałam sobie sprawy, jak trudne jest pisanie artykułów, dopóki nie zdecydowałam się na opracowanie i publikację tego tekstu (przyznam, że pisałam go w nieco zwariowanych dla mnie okolicznościach, stąd faktycznie mogło się pojawić wrażenie pośpiechu, pisania na rekord, czy też pewne niedociągnięcia) oraz jak ważne jest wsparcie, za które jeszcze dziękuję. Starałam się uwzględnić potrzeby czytelników, także tych, dla których wiele pojęć jest nowych, ale będących stałymi czytelnikami sekuraka. Tych, których styl nieco zniechęcił, zachęcam do przeczytanie artykułu jeszcze raz, tak jak polecają koledzy.Postaram się odnosić sukcesywnie do komentarzy. Pozdrawiam.
Scutum, artykul odebrałem jak relację z placu boju, bo tak to zwykle wygląda, to nie ćwiczenia, to nie „nagranie w studiu”. O ile dobrze zrozumiałem to nie jest poradnik w stylu youtubowych „how to” czy instrukcji do wdrożenia, a propozycja podejścia do rozwiązania tematu.
To co najcenniejsze dla mnie to wykazanie, że można z modelu „ad hoc”, czysto reaktywnego ale nie zarządzalnego przejść do mantrowego incident response&lessons learned. To jest ten „Święty Graal” -jak przejść od nerwowej bieganiny i morza emocji do sytuacji bardziej komfortowej dla obrońców, gdzie role są podzielone, jest komunikacja i kierunek działań.
O tym jak wyglądać ma stan docelowy procesu zarządzania incydentami napisano już gigabajty (wcześniej tony papieru), jednak proces przejścia do tego modelu nie jest uniwersalny, bo być nie może. Twój przykład Scutum analizowany krok po kroku pozwala wyciągnąc wnioski tym, którzy szukają takich modeli transformacji. Jest ogólny tam gdzie dotyczy organizacji a szczególny gdzie dotyczy technologii. Dlatego wart jest udostępniania innym.
Raz jeszcze dziękuję za włożoną pracę i odwagę, bo łatwo jest dzielić się cytatami z cudzych książek, a o niebo trudniej owocami swojej pracy.
PS.
Przemku, tak ten sam Artur :)
Artur – faktycznie. Była to relacja z pola walki. Bez studium przypadku, zakotwiczenia w rzeczywistości, mogłaby stać się kolejnym bajtem „pitu-pitu” o incydentach bezpieczeństwa informacji… ;)
Dziękuję za uznanie. Cieszę się, że relacja wzbudziła tyle entuzjazmu. Wygląda na to, że dyskusja i komentarze (sumarycznie) chyba przekroczyły objętość samego artykułu ;) Najbardziej jednak ucieszyło mnie to, że doskonale wyjaśnił Pan intencję tekstu, co więcej – wskazał, gdzie jest i na czym polega „Święty Graal” incident response oraz lessons learned, a także wiele innych niuansów, które nie były z miejsca oczywiste dla niektórych czytelników. Pozdrawiam.
Itar – myślałam o poruszanym przez Ciebie problemie z e-fakturami. Sądzę, że jest kilka „życiowych” rozwiązań – chociażby prawnych (oczywiście nie idealnych, ale to zawsze coś;)), które pomagają w ogarnięciu tego problemu. Jeśli jesteś zainteresowany, wal śmiało ;)
Pozdrawiam.
Co do komentarzy – inaczej wygląda obsługa dla 20 użytkowników, inaczej w 10000. Inaczej w niszowej firmie, inaczej w banku. Tylko założenia ogólne są podobne. Ten tekst jest charakterystyczny dla organizacji sporej, ale nie wysokiego ryzyka. Strzelam że jakieś korpo. W banku było by zupełnie inaczej, w małej firemce też.
Uwagi do całego artykułu:
1) wygląda to jakby ktoś na siłę wtłoczył obsługę incydentu w ramy normy/procedury z ISO27xxx.
2) Opisy IT Admins, IT Sec, helpdesk – bo w artykule opisane jest coś, co powinno być na diagramie. Mi nie przeszkadza (choć na osi czasowej było by czytelniej…). Dodatkowo brakuje „rozpisania na role” w podpunkcie „Reakcja na incydent”. Kto informował DHLa, kto użytkowników, kto zarząd?
3) Co mnie niepokoi – poleganie wyłącznie na AV, logach i antyspamie. Do ostatnich kampanii – u mnie antyspam działał ok (antywirus też…). W ostatniej kampanii – maile przechodziły, antywirus uparcie milczał, a virustotal widział w porywach 4/63. (Choć AV to zapewne także firewall…) Dziwi ZERO informacji o IDS/IPS (nie ma w organizacji?!?) oraz o sprawdzeniu integralności systemów. A co jak antywirus nie wykrył rootkita/backdora itp? Antywirus to mimo wszystko tylko JEDNA z linii obrony.
4) Ani słowa o szkoleniu użytkowników. Brak infekcji sugeruje że takie były (albo – że antywirus nic nie wykrył mimo infekcji ;P) – u mnie mimo szkoleń, ostrzeżeń itp. kliknięcia sie zdarzają… Fajnie było by też opublikować ów biuletyn…
Cisco wlasnie opublikowalo plakat reklamujacy ich polroczny raport bezpieczenstwa. Jest o tyle ciekawy (Raport i plakat), ze odnosi sie do mieszanych technik ataku 4 najpowszechniejszych zagrozen (Dridex, Rombertik, Angler i Adware multiplug). Polecam podeslac swojemu CISO lub CIO a raport przeczytac.
Plakat:
http://www.cisco.com/assets/global/DK/pdfs/cisco_2015_msr_overview_infographic_final.pdf
Raport:
http://www.cisco.com/web/offers/pdfs/cisco-msr-2015.pdf
Artykuł czyta się niełatwo, bo jest miejscami sztucznie rozdrobniony na podpunkty (np. ocena sytuacji). Gdyby był bardziej obszerny nie byłoby problemu. Z drugiej strony, obszernego przeczytaliby nieliczni. Łączy się z tym druga sprawa to używanie epitetów-ogólników niewyjaśniających o co chodzi, męczą odbiorcę (wielokrotne: usystematyzowane, zaplanowane, niezbędne, skoordynowane, informacje) – przez to czyta się tekst dłużej, mimo że jest krótki.
Co do treści, podoba mi się całościowy opis od zera do rozwiązania. Coś mi tam nakreślił, coś tam skumałem bo z SIEMów korzystam, choć SoCa nie prowadzę. Teraz przydałoby się zrobić np. 3 częsciowy cykl w sekuraku onffline, który to uszczegółowi. Zagrożenia, plan, ocena, mętne; nieodseparowane od siebie. Fajne byłoby uzupełnienie jako odniesienie do jakichś metodyk zarządzania bezpieczeństwem (wspomnienie czegoś oprócz luźnego rzucenia hasłem ITIL). Personalnie proponowałbym wprowadzić czytelników w zarządzanie incydentami ITsec, lub lepiej z metodykami obronnymi (tak jak był super cykl o metodykach testów penetracyjnych, po tym cyklu wchłonąłem OSSTMa, PTESa i pół wiki Owaspa + NIST 800-115 ;)).
Jako wprowadzenie do zarządzania incydentami i ciągłymi procesami monitoringu poczytaj to: http://sekurak.pl/tag/defensywa/ – wkrótce kolejne artykuły w tej serii.
Zapraszam też tutaj: http://blog.whitecatsec.com – właściwie publikuję w jednym z tych dwóch miejsc.