Security Case Study 2014

Beata Marek Bezpieczeństwo teleinformatyczne, Cyberzagrożenia i cyberprzestępczość Leave a Comment

Wczoraj i dzisiaj miałam przyjemność uczestniczyć w konferencji Security Case Study 2014, którą zorganizowała Fundacja Bezpieczna Cyberprzestrzeń. Szczegółowe sprawozdanie już wkrótce (info o możliwości pobrania pojawi się na FB, Twitterze, LinkedIN i Goldenline także zapraszam do polubienia jednego z profili Cyberlaw). Dzisiaj na blogu na gorąco refleksja z tych dwóch fajnych dni.

Ochrona cyberprzestrzeni RP oczami NIK

Gen. Marek Bieńkowski (NIK) jeszcze przed oficjalną prezentacją raportu (premiera I kwartał 2015r.) przedstawił ustalenia i wstępne wyniki kontroli w zakresie realizacji przez podmioty państwowe zadań ochrony cyberprzestrzeni RP.

Co ciekawe przeprowadzenie kontroli zostało zainicjowane z własnej inicjatywy NIK głównie z uwagi na 3 czynniki:
1. wzrost cyberzagrożeń,
2. zdefiniowanie cyberprzestrzeni jako nowego obszaru działań podmiotów państwowych,
3. przekonanie o niskiej świadomości obywateli i urzędników na temat bezpieczeństwa IT.

Celem było zweryfikowanie ryzyk (m.in. czy jest spójny system działań, jak wygląda szacowanie ryzyka, jaki jest podział kompetencji, jakie zostały wdrożone mechanizmy koordyndacji). Wyniki okazały się miażdżące.

Kwerenda aktów prawnych wykazała przede wszystkim brak kompleksowych regulacji prawnych (relacje pomiędzy podmiotami państwowymi a prywatnymi kuleją na całej linii) oraz szereg nieprawidłowości w organach państwowych. Przykładowo Ministerstwo Spraw Wewnętrznych nie uczestniczyło w budowie systemu ochrony cyberprzestrzeni państwa, nie została określona rola Ministra w ramach systemu ochrony cyberprzestrzeni, nie wdrożono zapisów Polityki Ochrony Cyberprzestrzeni (już abstrahując od merytoryki tego dokumentu), a co najciekawsze nie dysponowano wiedzą na temat własnych systemów – zasobów podlegających ochronie. Komenda Główna Policji pomimo tego, że ma powołane jednostki do zwalczania przestępczości komputerowej to jednak ma problem komunikacyjny i merytoryczny na linii CERT – Policja, nie ma także kompleksowego systemu reagowania na incydenty (jedynie przekazują informacje, nie podejmują dalszych działań, nie pytają o przyczyny i sposób załatwienia danego zdarzenia), nie mają własnego zespołu CERT. Ministerstwo Obrony Narodowej wypadło całkiem nieźle, ale co najciekawsze ustalono, że Narodowe Centrum Kryptologii podporządkowane jest personalnie jednej osobie!. W przypadku Agencji Bezpieczeństwa Wewnętrznego dostrzeżono jako główne problemy ograniczone zasoby ludzkie i finansowe oraz brak umocowania prawnego zespołu CERT.GOV.PL jak i jego kontrowersyjne usytuowanie. W przypadku NASKu podkreślono, że jeśli od strony prawnej miałby pełnić rolę CERTU to musi być to uregulowane prawnie. Rządowe Centrum Bezpieczeństwa oberwało m.in. za brak spójności systemów zarządzania kryzysowego i ochrony cyberprzestrzeni, ale i tak wypadło całkiem nieźle. Urząd Komunikacji Elektronicznej mógłby lepiej postarać się w kwestii informowania obywateli na temat zgłoszonych mu incydentów przez operatorów (warto dodać, że zgodnie z przepisami system notyfikacji polega na pełnej dobrowolności zgłaszania incydentów do UKE co powoduje, że mamy do czynienia z pewną fikcją dokonywania zgłoszeń – otóż w ciągu ostatnich 5 lat zgłoszono zaledwie 5 incydentów choć CERT dysponował informacjami, że było ich de facto więcej). Najsłabiej wypadło Ministerstwo Administracji i Cyfryzacji, które odpowiada za koordynację Polityki Ochrony Cyberprzestrzeni, a jak ustalili kontrolerzy nie wdrożono tam POC, a dopiero po otrzymaniu pytań dotyczących realizacji zadań rozpoczęto wstępne prace nad realizacją POC w Ministerstwie!. NIK dostrzegł także, że w MAiC brak jest świadomości obowiązków w zakresie ochrony cyberprzestrzeni, działania prowadzone są ad hoc – bez właściwego przygotowania, nie zbudowano kapitału osobowego w zakresie utrzymania ciągłości bezpieczeństwa w cyberprzestrzeni. Dopiero od lutego 2014r. przypisano zadania do wydziału – początkowo było 2 pracowników, obecnie jest 4 (jednak są wątpliwości czy pracownicy Ci są merytorycznie przygotowani do pełnienia zadań).

Wnioski są następujące:

1. Podmioty państwowe nie prowadzą spójnych zadań w zakresie ochrony cyberprzestrzeni RP.
2. Brak świadomości nowych zagrożeń u decydentów politycznych i kierownictwa administracji rządowej oraz brak zainteresowania kwestiami bezpieczeństwa IT ze strony najważniejszych osób w państwie!
3. Działania prowadzone są bez przygotowania i spójnej wizji systemowej.
4. Brak ośrodka decyzyjnego i koordynacyjnego.
5. Rozproszenie kompetencji i brak współpracy instytucji rządowych i państwowych.
6. Brak kompleksowych regulacji prawnych.
7. Niewykorzystanie istniejących przepisów (firmy telefinformatyczne realnie nie zgłaszają incydentów).
8. Bierne czekanie na dyrektywę NIS co wymaga modyfikacji.
9. Potrzeba pilnego podjęcia decyzji odnośnie zbudowania spójnej strategii.

APT28

Bardzo ciekawe było także studium przypadku APT28. Malware APT28 jest dużo bardziej zaawansowany, jest bardzo trudny do analizy, posiada wszechstronne możliwości. Jest bardzo indywidualizowany pod kątem celu ataku (posiada moduły / w zależności od celu są odpowiednio konfigurowane). Próbki bronią się przed analizą (od prostych czynności typu zaciemniane stringi, do bardziej zaawansowanych gdzie zmienia się zachowanie malware w przypadku wykrycia określonego środowiska – np. sandbox).

Na przykładzie tej grupy wskazano dwa główne wektory ataku czyli:
1. spearphishing mail,
2. infekowanie ze strony webowej.

Pełen raport dostępny jest tutaj.

Dragonfly

Marcin Siedlarz (Symantec Security Response) podzielił się case study na temat kampanii cyber-szpiegowskiej, która miała miejsce w latach 2013-2014 (głównie ataki ukierunkowane na branżę energetyczną). Używane były 3 wektory ataku (spear phishing / strony webowe / infekcja oprogramowania, które jest używane przez firmy z branży energetycznej). Kampania ukierunkowana była na inżynierów i osoby z wyższym stanowiskiem (malware w .pdf gdzie wykorzystywali podatności Adobe). W przypadku stron webowych przestępcy/szpiedzy stosowali ukryte ramki w źródle strony. Same exploity pisane były na IE i Javę (nie używano 0day).

Warto napisać, że wszystkie wektory ataków były współbieżne, a wszystkie wykradzione dane miały docelowo być szyfrowane (3DES, o tym jak udało się odszyfrować napiszę szczegółowo w sprawozdaniu), wysyłane były na serwer C&C (czyli najczęściej zainfekowane CMSy za pomocą przejętych hostów/stron). Analiza czasów kompilacji próbek wykazała standardowy dzień pracy (UTC+4 czyli czas dla Moskwy albo dla Seszeli). Próbki były kompilowane głównie od poniedziałku do piątku, sporadycznie w sobotę. Najwięcej zdecydowanie we wtorek ;).

Jakie ślady zostawiają znani cyberprzestępcy?

O tym po jakich śladach i w jaki sposób udało się namierzyć i złapać groźnych cyberprzestępców opowiedział Adam Haertle (ISACA, CSA Polska). Na wszystkich prezentacja ta zrobiła ogromne wrażenie. Jeżeli interesują Ciebie informacje na temat różnych infekcji i ataków koniecznie odwiedź zaufanatrzeciastrona.pl .

Atak DDOS – jak nie stracić głowy na froncie?

O tym co zrobić przed, co w trakcie ataku, a co po ataku DDoS mówił Borys Łącki (LogicalTrust). Zdecydowanie warto pamiętać, że:

1. Atak może nie być w łącze a w konkretną usługę dlatego sieć należy monitorować z zewnątrz.
2. Warto sobie skonfigurować dodatkowy kanał gdy dojdzie do ataku, żeby można było go uruchomić.
3. Warto mieć Plan Działania Ciągłości Biznesowej i wpisać sobie wagę poszczególnych usług (Borys jako przykład podał rozpisanie sobie diagramu z hierarchią usług).
4. Kiedy dojdzie do ataku warto nie tylko analizować ruch sieciowy, ale i skontaktować się z zewnętrznymi firmami, które mogą pomóc.
5. Dobrze jest zaangażować osoby spoza IT, które mogą się przydać/są kompetentne.
6. Nowe pokolenie administratorów, które jest wychowane na środowiskach graficznych może nie potrafić dodawać kilkuset linii kodu naraz, list ACL i często nie potrafi.
6. W dokumentacji warto mieć spisane adresy IP bizesowych klientów (czyli, żeby np. wyciąć całych ruch, ale zostawić tych najważniejszych klientów).
7. Czasem zbytnie ograniczanie pasma może doprowadzać do restartowania urządzeń.
8. Serwery DNS nie powinny być w tej samej sieci bo podczas ataku może okazać się, że usługi przestaną działać.
9. Komunikacja wewnętrzna powinna dobrze działać (np. informowanie pracowników by komentarzy udzielał tylko PR).
10. Komunikacja zewnętrzna z klientami też jest istotna (zbyt szybko nie wysyłać informacji, najlepiej przygotować jeden spójny komunikat, korzystajmy z social media).
11. Po przeprowadzeniu ataku dane powinny być przechowywane w odpowiednim miejscu.
12. Za przekazywanie informacji, komunikację z policją, zabezpieczanie i przechowywanie danych powinny być odpowiedzialne określone osoby.
13. Jeżeli będziemy przekazywać policji tylko zrzut ruchu sieciowego może być problem dlatego warto wyeksportować te dane do prostych informacji (np. adresów IP).
14. Koniecznie trzeba zaktualizować dane po przeprowadzeniu ataku i przeprowadzić spotkanie podsumowujące (spotkanie w gronie nie tylko działu IT, ale także innych kierowników).

Symulacja włamania

Mariusz Stawowski (Clico) przykuł uwagę case study jednej z firm, która zaniepokoiła się po otrzymaniu od kilku klientów informacji, że konkurencja dzwoni do nich i zna wszystkie szczegóły poufnych negocjacji. Co w takiej sytuacji zrobiono?

Zebrano dane z wywiadów, kontaktów nt. incydentu (kto potencjalnie mógł zarobić / np. handlowcy nie bo dostają duże premie z dużych kontraktów, a jak nie wyrobią targetów to są zwalniani, szef handlowców też odpadł, serwisanci i audytorzy też nie mogli ukraść danych bo byli monitorowani). Po rozrysowaniu całej infrastruktury i warstw ochrony ustalono, że dane wyciekły z serwera bazy danych.

Badano krok po kroku różne przyjęte scenariusze ataków i je symulowano. Okazało się, że dział kadr nie informował informatyków o tym, że handlowcy opuszczają firmę. Informatycy nie usuwali im dostępu, a zatem to byli handlowcy wynosili informacje. Warto dodać, że w Polityce Bezpieczeństwa był zapis zobowiązujący do tego by informować dział IT o zmianach.

Pełne sprawozdanie już wkrótce.

Autor grafiki promującej wpis: David Lanham