SOC PO TO, ŻEBY NIE BYŁO S(Z)OKU


#1 SOC PO TO, ŻEBY NIE BYŁO S(Z)OKU

W dzisiejszych czasach bezpieczeństwo systemów informatycznych jest kluczowe z punktu widzenia ciągłości działania firm i instytucji. Coraz więcej zarządzających biznesem zdaje sobie sprawę, że przerwanie funkcjonowania systemów informatycznych powoduje straty finansowe, nierzadko idące w miliony złotych dziennie, jak i utratę wizerunku.

PRZEMYSŁAW KUCHARZEWSKI

Jak wykryć cyberataki, jak im przeciwdziałać, w jaki sposób kategoryzować zdarzenia naruszające bezpieczeństwo, jak je korelować ze sobą, tak aby organizacja potrafiła działać w sposób nieprzerwany? Z jednej strony istnieją narzędzia pozwalające wykryć i zarejestrować nie-standardowe działania, niektóre są następstwem poprzednich i dopiero ich połączenie pozwala na to, aby wykryć nieprawidłowość czy atak na systemy informatyczne. Czasem konieczne będzie oddzielenie infrastruktury wewnętrznej od sieci zewnętrznej albo wydzielenie części systemów przedsiębiorstwa od reszty, aby przeciwdziałać rozpowszechnianiu się złośliwego oprogramowana czy wyciekowi danych na zewnątrz. Do tego niezbędni są specjaliści o wysokich kompetencjach, którzy potrafią wyciągnąć wnioski z informacji pochodzących z różnych źródeł i na podstawie własnych doświadczeń odpowiednio reagować.

W celu zapewnienia najwyższego stopnia bezpieczeństwa organizacji powołują one (albo korzy-stają z usług firm zewnętrznych) centrum operacji zgłoszenie dopiero połączone z innym pozwala na zaklasyfikowanie danego incydentu jako TI.


Krzysztof Strączkowski, Service Delivery Manager, Trecom

Przystępując do budowy SOC Trecom postawiliśmy na precyzyjnie określone zdolności operacyjne. Na tej podstawie zdefiniowaliśmy organizację zespołu oraz procesy obsługi incydentów. W ten sposób zbudowaliśmy zestaw usług, który nie stanowi jedynie dodatku do oferowanych technologii. W ramach adaptacji usługi do środowiska klienta za każdym razem prowadzimy dialog w celu zrozumienia architektury IT monitorowanego środowiska. Jednak przede wszystkim musimy poznać relacje między elementami tego środowiska, role systemów IT w procesach biznesowych, ryzyka wynikające z zagrożeń oraz ich wpływ na misję. W naszej opinii świadomość sytuacyjna wynikająca ze znajomości chronionego środowiska pozwala na skuteczną analizę zdarzeń i podjęcie właściwych działań w reakcji na incydenty bezpieczeństwa. W procesie reakcji na incydenty niezbędne są również dane kontaktowe do właścicieli procesów i zasobów. Informacje uzyskane na etapie adaptacji usługi SOC w środowisku klienta znajdują odzwierciedlenie w procedurach obsługi incydentów. SOC Trecom dysponuje wypracowanymi metodami postępowania, jednak w większości przypadków musimy dostosować nasze procedury do potrzeb wynikających ze specyficznych wymagań bezpieczeństwa każde-go klienta.
Jak to wszystko się odbywa? Wstępną analizę zdarzeń prowadzą, według określonych procedur, analitycy pierwszej linii (Tier1). Jeśli zdarzenia wymagają zaawansowanej analizy, eskalowane są do analityków drugiej linii (Tier2), zajmujących się także incydentami, bowiem proces reakcji na incydenty (IR) realizowany jest przez analityków drugiej linii SOC. W uzasadnionych przypadkach w prace angażują się eksperci odpowiedzialni za zaawansowane zdolności operacyjne (Avanced Capabilities). Reakcja na incydenty, monitorowanie systemów i dostarczanie dodatkowych danych kontekstowych mogą być wspomagane przez zespół operacyjny (Operations and Management), którego zadaniem jest zarządzanie systemami bezpieczeństwa (SOC – ang. Security Operating Center). SOC to scentralizowana jednostka, która monitoruje, kwalifikuje i przeciwdziała atakom na systemy informatyczne przedsiębiorstwa (począwszy od stron internetowych, aplikacji i systemów, baz danych, centrów danych i pojedynczych serwerów, sieci, wszystkich urządzeń końcowych, takich jak telefony, notebooki czy tablety). W rzeczywistości SOC to zespół analityków, którzy wykorzystując specjalistyczne narzędzia, wykrywają, analizują, reagują oraz raportują i przede wszyst-kim przeciwdziałają incydentom bezpieczeństwa. Centra Operacyjne Bezpieczeństwa działają 24 godziny na dobę, 7 dni w tygodniu, przyjmując zgłoszenia od użytkowników i monitorując zdarzenia w systemach w poszukiwaniu potencjalnych incydentów bezpieczeństwa.
Czym są incydenty bezpieczeństwa (ang. Threat Incidents, w skrócie często nazywane TI)? TI to przeanalizowane zdarzenia (zgłoszenia), które zagrażają integralności, poufności bądź dostępności systemów informatycznych, informacji przetwarzanych, przechowywanych i transmitowanych przez te systemy lub które naruszają bądź zagrażają naruszeniem polityk bezpieczeństwa. Tak więc, nie każde zgłoszenie zostaje zakwalifikowane jako TI. Czasem również jest tak, że pojedyncze bezpieczeństwa Klientów. Struktura Operacyjnego Centrum Bezpieczeństwa Trecom przedstawiona jest na schemacie poniżej.

Outsourcing tańszy?

Dlaczego organizacje decydują się na przeniesie-nie SOC poza własną organizację? Dwa powody – pierwszy z nich to kompetencje, drugi zaś pieniądze. Przykładowy dziesięcioosobowy zespół ze zmianą dzienną i nocną, z managerem zarządzają-cym całą jednostką, kosztami niezbędnych zastępstw, szkoleniami dla pracowników to szacowany średni koszt miesięczny między 200 a 300 tysięcy złotych w zależności od regionu kraju
i kompetencji pracowników. Czy każdą organizację stać na taki wydatek? Nie – na pewno nie szeroko rozumiany średni biznes, czy wręcz duży pomiot krajowy. Co innego międzynarodowe korporacje ustandaryzowanych technologiach i zapleczu IT, które mogą utrzymać takową jednostkę w swoich strukturach, pełniącą rolę „bezpiecznika” w swoim ekosystemie informatycznym obejmującym wiele krajów.


Michał Horubała, Security Operations Center Architect, eSecure Sp. z o.o.

Sercem SOC Trecom jest system SecureVisio polskiej firmy eSecure. 
Produkt ten umożliwia nam łatwą integrację z systemami bezpieczeństwa naszych klientów, zbudowanie bazy CMDB monitorowanego środowiska, analizę ryzyka, obsługę incydentów oraz zarządzanie podatnościami. Nie wymagamy od naszych klientów zakupu ani stosowania konkretnych rozwiązań bezpieczeństwa IT. Analiza zdarzeń i wykrywanie incydentów wymaga jednak odpowiednich źródeł danych. Dlatego monitorowane sieci muszą być wyposażone w systemy dostarczające wskaźników incydentów. Są to rozwiązania klasy Endpoint Security lub EDR, systemy IDS/IPS, systemy do analizy ruchu sieciowego, skanery podatności oraz systemy klasy SIEM / log management. W zależności od środowiska i potrzeb w zakresie bezpieczeństwa możemy skorzystać z systemów klienta lub dostarczyć rozwiązania z naszej oferty (również w rozliczeniu abonamentowym).

Oprócz kwestii finansowych dochodzą koszty czasowe i kwestie zbudowania odpowiednie-go zespołu w organizacji. Projekt uruchomienia jednostki SOC wewnątrz organizacji trwa zwykle od 18 do 24 miesięcy. Rynek cyberbezpieczeństwa jest wręcz zalewany nowymi technologiami jednocześnie cierpiąc na deficyt odpowiednich osób z tej specjalizacji. Zadanie zorganizowania jednostki oraz wyposażenia zespołu w technologie pozwalające sprostać postawionym zadaniom stanowi wyzwanie, któremu bardzo trudno sprostać. Ryzyko błędnych decyzji na etapach określenia misji, planowania, organizacji, zdolności operacyjnych i doboru odpowiednich technologii jest bardzo wysokie, a skutki tych wyborów mogą być bardzo kosztowne.

Czy warto w ten sposób chronić swoją infrastrukturę i dane? Dane są najcenniejszym zasobem w organizacjach. Proszę sobie wyobrazić, co mogłoby się stać, gdyby z banku wyciekły dane transakcjach klientów, jeśli od operatora telekomunikacyjnego wyciekłyby informacje o samych klientach, jak i numerach telefonów, z którymi się łączono, z ośrodka badawczego fabryki samo-chodów informacje nt. prac R&D nowego modelu silnika….

#2 SOC PO TO, ŻEBY NIE BYŁO S(Z)OKU

Jak działa SOC Trecom w praktyce
Wskaźnik incydentu

System Snort został wdrożony w sieci klienta tymczasowo. Klient od niedawna korzysta z na-szych usług. Nie wymagamy od naszych klientów stosowania konkretnych rozwiązań bezpieczeństwa IT. Analiza zdarzeń i wykrywanie incydentów wymaga jednak odpowiednich źródeł danych. Jednym z tych wymagań jest dostępność w sieci klienta systemów klasy IDS/IPS, które stanowią jedno ze źródeł wskaźników incydentów. Klient zdecydował o zakupie rozwiązania, ale na tym etapie był dopiero w trakcie wyboru rozwiązań i przygotowywania postępowania. Sensor Snort w jednej z monitorowanych sieci zaraportował zdarzenie „DNS request for known malware do-main”.
Zdarzenie zostało automatycznie zarejestrowane w systemie zarządzania incydentami, który wzbogacił dane o informacje na temat elementów in-frastruktury klienta, których dotyczył problem. Na tym etapie było to dopiero zgłoszenie, za którego analizę odpowiedzialni są analitycy pierwszej linii SOC. Ze względu na lokalizację hosta (strefa DMZ – ang. DeMilitarized Zone, bezpośrednie narażenie na ataki, poważne konsekwencje), którego doty-czyło zdarzenie oraz jego znaczenie dla organi-zacji, system automatycznie oznaczył zgłoszenie priorytetem „krytyczne”.

Monitoring i selekcja zdarzeń – I linia SOC

Analityk, który zgodnie z procedurami natychmiast rozpoczął prace nad zgłoszeniem, już na etapie weryfikowania podstawowych informacji doszedł do wniosku, że ma do czynienia z incydentem. Hostem, który wysłał do serwera DNS podejrzane zapytanie był zlokalizowany w sieci DMZ serwer WEB organizacji.
Zapytanie dotyczyło domeny chickenkiller.com. Informacje z bazy MISP oraz szybkie poszukiwania w Google wskazały, że domena stanowi część usługi Free DNS i często jest wykorzystywana w celach przestępczych. Oczywiście serwer WEB nie powinien wysyłać podobnych zapytań DNS. Informacje te były wystarczające, aby zakwalifikować zgłoszenie jako incydent i przekazać je do drugiej linii SOC.

Analiza incydentu – II linia SOC

Analityk drugiej linii SOC po przyjęciu zgłoszenia zorientował się, że na serwerze WEB będącym przedmiotem incydentu zidentyfikowano kilka poważnych podatności. Podatności te zostały wykryte przed dwoma tygodniami, a informacja o nich została przekazana klientowi. Niestety, w czasie wystąpienia incydentu konfiguracja serwera nie została jeszcze poprawiona. Szybkie skanowanie narzędziem nikto potwierdziło, że na serwerze WEB wciąż pracuje mocno przeterminowana wersja Apache oraz równie leciwa aplikacja WordPress.

Reakcja na incydent – II linia SOC

Analityk drugiej linii, wykorzystując ustalony kanał komunikacji, poinformował klienta o prawdopodobnym incydencie oraz konieczności podjęcia kolejnych działań. Niestety, SOC nie dysponował danymi do logowania do podejrzanego serwera. Zarządzała nim firma zewnętrzna. Ze względu na prawdopodobieństwo konfliktu interesów zdecydowano o wykonaniu zrzutu zawartości dysku twardego maszyny oraz rozpoczęciu rejestracji ruchu sieciowego w segmencie DMZ przed za-angażowaniem firmy zarządzającej systemem. Do nagrywania ruchu wykorzystano ten sam system, na którym działał sensor Snort. W celu wykonania zrzutu dysku twardego na miejsce wysłano specjalistę wyposażonego w procedurę i narzędzia do pozyskiwania materiału. Ponieważ siedziba klienta znajdowała się w odległej lokalizacji, dojazd z najbliższego oddziału Trecom miał zająć ok. 2 godzin. Za zgodą klienta zdecydowano o odłączeniu serwera od sieci do czasu skopiowania danych. W międzyczasie zmieniono konfigurację zapory sieciowej tak, aby całkowicie odciąć możliwość komunikacji strefy DMZ z siecią LAN. Podjęto również decyzję o wykonaniu kopii zawartości innej maszyny zlokalizowanej w tej samej strefie – serwera SMTP. Operacja kopiowania danych zajęła kolejne pięć godzin. Po zabezpieczeniu materiału skontaktowano się z firmą zarządzającą serwerem i poinformowano administratora o podejrzanym incydencie. Administrator przekazał dane do logowania analitykowi SOC, który mógł zdalnie rozpocząć badanie systemu jeszcze zanim kopia jego zawartości dotrze do laboratorium SOC Trecom w Warszawie. Na serwerze zidentyfikowano zagnieżdżony katalog zawierający prawdopodobnie złośliwy plik. Mogło to wskazywać na włamanie w celu późniejszego wykorzystania serwera w innym celu – na przykład kampanii phishingowej. Dalsze analizy miały zająć co najmniej kilka dni i mogły być prowadzone na kopii danych w laboratorium SOC. Dlatego pod-jęto decyzję o reinstalacji systemu operacyjnego serwera oraz wszystkich aplikacji w celu szybkie-go przywrócenia jego funkcji.
Dalsze badania wykazały, że plik znaleziony na serwerze istotnie wykorzystywany był w jednej z kampanii phishingowych (prawdopodobnie został pobrany przez atakującego z domeny chickenkiller.com – stąd zapytanie DNS. Plik zawierał złośliwy kod typu ransomware). Nie znaleziono śladów włamania na drugiej maszynie ze strefy DMZ. Logi wskazywały jednak na próby rekonesansu. Z tego powodu zarekomendowano klientowi reinstalację oprogramowania również tego serwera.
Po zamknięciu incydentu i przygotowaniu raportu zorganizowano spotkanie w celu prześledzenia procesu reakcji na incydent, wyciągnięcia wniosków i przyjęcia ewentualnych korekt w procedurach. Zwrócono uwagę na brak danych kontaktowych do administratora serwera WWW w bazie SOC oraz na brak świadomości klienta o konieczności posiadania loginów i haseł do wszystkich jego systemów. Przeanalizowano możliwość zmiany hasła root z wykorzystaniem fizycznego dostępu do serwera. Uznano, że w tej konkretnej sytuacji działanie takie nie było uzasadnione, jednak zdecydowano o dołączeniu procedury zmiany hasła na systemie Linux do zestawu procedur, którymi dysponują specjaliści w terenie.
Klient otrzymał raport z incydentu w ciągu dwóch dni od zakończenia prac. W raporcie zawarto szczegółowy opis przebiegu incydentu, zwrócono uwagę na opóźnienia w łataniu wykrytych podatności oraz braki w informacjach.