Ostatnia historia włamania do Ubera czy ponownie pojawiające się raporty o aktywności Emoteta mogą skłaniać do pytań o zasadność poszczególnych funkcji w całokształcie organizacji bezpieczeństwa organizacji. Po co bowiem zaawansowane zespoły zajmujące się analizą powłamaniową dla celów produkcji threat intelligence czy threat huntingiem, skoro problem leży w podstawach? To bardzo zasadne pytanie, jednak odpowiedź na nie nie jest łatwa, biorąc pod uwagę mnogość sytuacji przed jakimi może stać dany podmiot.
Aby ustrukturyzować ocenę sytuacji skorzystamy z dwóch modeli. Pierwszym z nich jest Sliding Scale of Cyber Security autorstwa Roberta M. Lee. Model ten opisuje to, jak poszczególne elementy organizacji bezpieczeństwa przyczyniają się do ogólnego poziomu bezpieczeństwa organizacji i jaki zwrot inwestycji przynosi każda z funkcji. Skalę ilustruje następująca grafika:
Przesuwając się od lewej do prawej, kolejne funkcje są coraz droższe w implementacji i przynoszą niższe zwroty inwestycji. Aby maksymalizować korzyści, organizacje powinny więc zaczynać od podstaw (architektura, automatyczne środki bezpieczeństwa), a dopiero potem budować kolejne stopnie dojrzałości i dodawać kolejne funkcje.
Pierwszym poziomem, zapewniającym zdecydowanie największy zwrot inwestycji, jest architektura definiowana jako planowanie, budowanie i utrzymywanie systemów z myślą o bezpieczeństwie. Architektura powinna przede wszystkim wspierać codzienną pracę organizacji, a w zakresie bezpieczeństwa, przewidywać wystąpienie sytuacji kryzysowych i incydentów bezpieczeństwa. Celem architektury jest więc nie tyle zapobieganie atakom i obrona przed cyber operacjami, a sprawienie, że incydenty takie jak infekcja malwarem czy uzyskanie dostępu do konta użytkownika przez atakujących nie doprowadzą do rozległych uszkodzeń infrastruktury.
Dalej mamy środki pasywnej obrony. W modelu oznacza to urządzenia i oprogramowanie zapewniające ochronę, ale nie wymagające ciągłej obsługi przez człowieka. Znajdziemy tutaj więc „klasyczne” rozwiązania z zakresu bezpieczeństwa takiej jak antywirusy i inne anty-malware’y, firewalle, IDSu, IPSy. Naturalnie instalacja i konfiguracja wymaga wstępnego zaangażowania personelu, tak samo jak późniejsze aktualizacje i rozwiązywanie problemów. Same działania obronne takie jak zablokowanie połączenia czy usunięcie malware’u z systemu są podejmowane w toku pracy automatycznie.
Kolejnym stopniem jest obrona aktywna, której nie należy jednak mylić z działaniami ofensywnymi czy innymi akcjami wychodzącymi poza chronione środowisko. Obrona aktywna to szeroko pojęty threat hunting i działania związane z oceną zdarzeń występujących w środowisku przez człowieka. Automatyczne systemy przestają tutaj pełnić funkcje zabezpieczenia samego w sobie, a stają się narzędziami przyśpieszającymi pracę analityków starających się wykryć bardziej zaawansowane wrogie aktywności. Przejście na poziom obrony aktywnej jest w mojej ocenie największym przeskokiem jakościowym i kosztowym w całej Skali. Na tym poziomie bowiem nie uciekniemy już od zaangażowania dedykowanego zespołu zajmującego się operacjami bezpieczeństwa na cały etat lub przynajmniej przez większość czasu. O ile architektura i pasywne systemy to w dużej mierze domena inżynierów i administratorów systemów, to już threat hunting to praca wymagająca wiedzy i umiejętności ściśle z zakresu analizy zagrożenie i reagowania na zdarzenia będące efektem bardziej złożonych wrogich operacji.
W końcu na czwartym miejscu i w pewnym sensie ostatnim o czym za chwilę, docieramy do threat intelligence. W modelu tym intelligence, nawet bez przedrostka threat, definiowane jest jako proces zbierania i przetwarzania danych w celu wypełnienia wcześniej zidentyfikowanych luk w wiedzy. Threat Intelligence to natomiast dyscyplina wywiadu zajmująca się analizą wrogiej aktywności w celu wspomagania działań obrońców przez umożliwienie lepszej identyfikacji wrogich działań i metod reakcji na nie. Same definicje wskazują dlaczego intelligence jest tak daleko na skali przyjętej w tym modelu. Aby wykorzystać w pełni możliwości tej funkcji, musimy być w stanie ocenić braki w widoczności środowiska czy możliwościach detekcji. Jeżeli nie jesteśmy w stanie skutecznie zapobiegać atakom, które mogą powstrzymać zautomatyzowane systemy, to trudno oczekiwać, że będziemy w stanie wykorzystać produkty wywiadowcze w celu konstruowania zaawansowanych detekcji. Warto zwrócić uwagę na ścisły związek wywiadu i aktywnej obrony w tym kontekście – funkcją wywiadu jest tworzenie produktów wywiadowczych, a aktywnej obrony ich konsumpcja w toku działań obronnych.
Wspomniałem, że intelligence może być traktowany jako ostatnia funkcja dlatego, że faktycznie na samym końcu znajduje się dziedzina o bardzo ograniczonej użyteczności dla większości organizacji – działania ofensywne. Po pierwsze wymagają one bardzo solidnych podstaw w poprzednich funkcjach, a w szczególności możliwości atrybucji ataków. Po drugie nie przynoszą żadnych korzyści w kontekście już zaistniałych incydentów. Należy tutaj również wyraźnie podkreślić, że dla prywatnych organizacji zgodne z prawem działania ofensywne ograniczone są właściwie do działań prawnych, takie jak wystosowanie pozwu kończącego się sądowym nakazem zajęcia infrastruktury. Jakkolwiek kuszące są tzw. hackback to nieautoryzowany dostęp do systemu informatycznego pozostaje przestępstwem niezależnie od relacji pomiędzy napastnikiem i ofiarom.
Jak widzimy, threat intelligence jest w modelu dość daleko, tak naprawdę na samym końcu funkcji obronnych. Specyfiką tej dyscypliny jest to, że w kontekście bezpieczeństwa organizacji stanowi funkcje wsparcia, nie właściwego zabezpieczenia. Rola zespołu threat intelligence jest więc wyznaczona przez to jakie wymagania wywiadowcze zostaną mu wskazane i jakie jest grono odbiorców produktu. Oceniając rolę tego zespołu w kontekście zwrotu inwestycji należy wziąć pod uwagę dwa czynniki. Po pierwsze czy pieniądze i środki zainwestowane w threat intelligence nie przyniosłyby większych korzyści w ramach innych funkcji. Odpowiedź na to pytanie będzie jednak wysoce zależna od struktury organizacyjnej danego podmiotu – na przykład pod kątem tego czy mówimy o czysto wewnętrznym zespole intelligence, czy zespole działającym jednocześnie w ramach świadczenia usług dla klientów. Czynnikiem któremu przyjrzymy się tutaj jest natomiast to, czy intelligence można przesunąć bardziej na lewą stronę skali, poprzez to, że dostarczane produkty będą wspomagać funkcje architektury i pasywnej obrony.
W tym miejscu do akcji wejdzie drugi model – cykl wywiadowczy, czyli metodologia pracy wywiadowczej zakładająca pięć etapów, o której już wspominałem na blogu przy okazji metodologii OSINTu.
Pomimo, że cykl ma zamknięty charakter z kolejnymi fazami wynikającymi z siebie, to jednak niewątpliwym początkiem jest faza planowania. I właśnie tutaj widzimy clou sprawy, w dojrzałych organizacjach, ograniczenie roli threat intelligence do pracy tylko z aktywną obroną może nie być pełnym wykorzystaniem jego potencjału. Zastanówmy się więc jak faza planowania i wyznaczanie wymagań może skierować wysiłki threat intelligence na wcześniejsze fazy Skali.
W kwestii architektury, wymagania wywiadowcze mogą skupić się na wektorach ataku i celach które chcą osiągać atakujący, działający w ramach grup aktywności mających znaczenie dla całej organizacji. Przekładając na konkretne przykłady:
- Pierwsze przykładowe wymaganie wywiadowcze może brzmieć: jaka technika jest najczęściej wykorzystywana do uzyskania pierwotnego dostępu przez grupy aktywności zagrażające naszej organizacji? Wymaganie to musi być poprzedzone analizą modelu zagrożeń i określeniem grup aktywności, które mogą być zainteresowane naszą organizacją. Jednak odpowiedź na nie może być istotnym impulsem dla modyfikacji i dostosowania infrastruktury aby uniemożliwić uzyskanie dostępu. Spójrzmy na najczęstsze techniki uzyskania dostępu – maile phishingowe i wykorzystanie podatności w urządzeniach wystawionych do Internetu. Wsparcie zespołu intelligence może wskazać inżynierom i architektom scenariusze zagrożenie, które muszą wziąć pod uwagę, decydując o kwestiach takich jak sposób wymiany dokumentów w organizacji – czy dopuszczamy w ogóle dokumenty w załącznikach mailowych, czy wymagamy aby były one przekazywane za pomocą udzielenia dostępu np.: do zasobu w usłudze OneDrive. Dalej, decyzje o dostępie do zasobów firmy z zewnątrz (choćby dla zdalnych pracowników) mogą być lepiej podejmowane, jeżeli scenariusze zagrożeń i techniki wykorzystywane przez atakujących zostaną wprost zaprezentowane inżynierom.
- Kolejny przykład: jakie techniki mogą wykorzystać grupy aktywności zagrażające naszej organizacji do osiągnięcia swoich celów? Drugą stroną problemu jest zabezpieczenie przed ostatnimi fazami cyklu ataku i uniemożliwienie osiągnięcia przez nie celów. Przedstawienie choćby sposobu działania rodziny ransomware’u i tego jakich technik używa aby uniemożliwić odzyskanie danych, może wpłynąć na implementację sposobu tworzenia backupów i architektury przechowywania szczególnie istotnych materiałów.
Celem jest tutaj więc wsparcie architektury poprzez ilustrację scenariuszy ataków przykładami obserwowanych i analizowanych aktywności. Threat Intelligence służy jako źródło świadomości sytuacyjnej i wiedzy z zakresu trendów w sposobach ataku aby uzupełniać prace administratorów i architektów.
Paradoksalnie trudniejsze może być wspieranie pasywnych środków ochrony. Jeszcze jakiś czas temu threat intelligence kojarzyło się często z wszelkimi strumieniami indykatorów jak adresy IP czy hashe, które można bezpośrednio przekazać do IDSów czy innych urządzeń. Użyteczność tego rodzaju danych dla celów detekcji czy zapobiegania zagrożeniom jest jednak obecnie znikoma. Rola zespołu Intelligence będzie więc miała ponownie charakter doradczy w kontekście obserwowanych technik ataku:
- Pierwszy przykład wymagania: jak stosowane przez nas pasywne środki ochrony można przypisać do technik stosowanych przez grupy aktywności atakujące podmioty w naszym sektorze? Ponownie operujemy na poziomie wsparcia planowania środków ochrony, a ściślej rzecz biorąc oceny luk w widoczności i możliwościach zapobiegania. Przesuwamy więc rolę threat intelligence z dostarczania czysto taktycznych informacji, do uczestnictwa w procesie zwiększania skuteczności pasywnej obrony.
- Drugi przykład: jakie są najbardziej powszechne zautomatyzowane techniki wykorzystywane przez grupy aktywności zagrażające naszej organizacji? Tak jak stosowanie pojedynczych indykatorów takich jak adresy IP jest nieskuteczne, tak stosowanie reguł np.: Snort, może być bardziej interesujące. Celem pasywnej ochrony jest odsianie najbardziej powszechnych i stosunkowo niezłożonych technicznie ataków. Threat intelligence powinno więc zapewniać wsparcie w fazie konfiguracji systemów, tak aby faktycznie nie wymagały one ludzkiego nadzoru dla skutecznych działań.
Intelligence jest więc wysoce „plastyczną” funkcją organizacji. Jej wspierający charakter sprawia, że tylko od postawionych przed nią zadań zależeć będzie w jakim miejscu organizacji się znajdzie. Wracając jednak do pytania z samego początku posta, dotyczącego powszechności prostych technicznie i znanych metod ataku, czeka nas zapewne jeszcze wiele dyskusji nad efektywnością poszczególnych środków ochrony. Oceniając jednak pracę zespołów, trzeba mieć na uwadze to, jak współpracują i jak zazębiają się zakresy odpowiedzialności. W tym kontekście ograniczenie roli intelligence tylko do produkcji na potrzeby aktywnej obrony może być marnowaniem potencjału. Szczególnie, że nie sposób nie zgodzić się z Robertem M. Lee – produkcja wywiadu to kosztowna i wymagająca dojrzałości organizacyjnej funkcja. Tym bardziej więc, starając się o najwyższy możliwy zwrot inwestycji możemy jeszcze raz spojrzeć na Skalę i upewnić się, że wszystkie funkcję adekwatnie wykorzystują możliwości wynikające z analizy i obserwacji zagrożeń.
Polish 
English