MITRE ATT&CK w pracy analityka SOC, rozumienie technik ataków cybernetycznych i zdolność ich wykrywania

Kontekst: nadmiar danych to nie to samo, co nadmiar wiedzy

Analityk SOC (Security Operations Center) rzadko skarży się na brak informacji. Systemy SIEM, EDR i XDR generują setki, czasem tysiące zdarzeń dziennie — problemem nie jest ich ilość, lecz brak struktury pozwalającej odróżnić pojedynczy, nic nieznaczący sygnał od fragmentu większej, złośliwej sekwencji działań. To rozróżnienie ma niewiele wspólnego z ilością zebranych logów, a bardzo wiele z tym, czy zespół dysponuje wspólnym modelem myślenia o tym, jak w ogóle wygląda atak.

W tym miejscu pojawia się MITRE ATT&CK — otwarta baza wiedzy opisująca taktyki, techniki i procedury (TTP) stosowane przez rzeczywistych aktorów zagrożeń. W środowiskach opartych o Linux specyfika telemetrii różni się istotnie od świata Windows: zamiast Sysmon i rejestru systemowego analityk pracuje na logach auditd, journald, historii powłoki czy mechanizmach takich jak sudo. Nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), wdrażająca dyrektywę NIS2, wymaga zdolności wykrywania incydentów i reagowania na nie — ale sam wymóg prawny niewiele mówi o tym, jak faktycznie zbudować tę zdolność w głowach ludzi, którzy codziennie patrzą na konsolę alertów.

Z naszego doświadczenia we wdrożeniach SOC i audytach gotowości do NIS2/KSC największym ryzykiem nie jest brak narzędzi technicznych. Jest nim złudzenie, że narzędzia same w sobie tworzą zdolność detekcyjną — podczas gdy realna zdolność powstaje dopiero wtedy, gdy zespół ma wspólny, ustrukturyzowany sposób interpretowania tego, co widzi.

Mechanizm: dlaczego framework zmienia sposób myślenia, nie tylko listę reguł

Sensemaking w warunkach niepewności. Koncepcja opisana przez badacza organizacji Karla Weicka tłumaczy, jak ludzie nadają sens niejednoznacznym, fragmentarycznym sygnałom pod presją czasu. Analityk patrzący na pojedynczy alert — „nietypowe wywołanie procesu z powłoki bash na serwerze produkcyjnym” — dysponuje surowym bodźcem, ale nie ma z niego jeszcze żadnej narracji. Sensemaking to proces osadzania pojedynczego zdarzenia w szerszym schemacie interpretacyjnym: co mogło je poprzedzać, co może po nim nastąpić. ATT&CK dostarcza gotowego schematu — otagowanie zdarzenia jako T1059.004 w ramach taktyki Execution natychmiast osadza je w kontekście, zamiast zostawiać analityka z izolowanym, niezrozumiałym faktem.

Wspólne modele mentalne zespołu. Zespoły koordynujące działania pod presją czasu potrzebują nie tylko dobrej komunikacji, ale wspólnego, podzielanego rozumienia sytuacji — inaczej każda osoba buduje własną, częściowo odmienną interpretację tych samych danych. W SOC bez wspólnego języka analityk pierwszej linii, inżynier detekcji i osoba prowadząca threat hunting mogą patrzeć na to samo zdarzenie i wyciągać zupełnie inne wnioski, bo każde z nich operuje innym, prywatnym słownikiem. ATT&CK działa jak wspólna mapa: gdy ktoś mówi „T1003.008”, cały zespół natychmiast wie, o jakiej kategorii zagrożenia mowa, bez tłumaczenia kontekstu od nowa przy każdej rozmowie.

Iluzja głębi wyjaśnienia. Zjawisko badane w psychologii poznawczej pokazuje, że ludzie systematycznie przeceniają, jak dobrze rozumieją złożone systemy, dopóki nie zostaną poproszeni o szczegółowe wyjaśnienie mechanizmu krok po kroku — dopiero wtedy iluzja kompetencji pęka. W SOC ma to konkretny odpowiednik: organizacja może być przekonana, że „ma pokrycie” danej techniki, bo formalnie istnieje reguła audytowa albo wpis w dokumentacji. Dopiero pytanie „pokaż mi konkretne zdarzenie, które ta reguła by wygenerowała, i udowodnij, że dociera ono do SIEM ze wszystkich hostów” ujawnia, czy pokrycie jest realne, czy istnieje wyłącznie na papierze.

Poczucie sprawczości a orientacja proaktywna. Praca oparta wyłącznie na reagowaniu na napływające alerty, bez ram pozwalających przewidzieć, czego można się spodziewać, sprzyja stanowi zbliżonemu do wyuczonej bezradności — poczuciu, że kolejny incydent i tak zaskoczy zespół. Threat hunting oparty na hipotezach — „jeśli w naszej infrastrukturze działa aktor stosujący ruch lateralny przez SSH, powinienem znaleźć w logach określony wzorzec” — to nie tylko lepsza metodyka. To przywrócenie poczucia sprawczości: analityk przestaje być wyłącznie odbiorcą zdarzeń, a staje się osobą aktywnie testującą własne przypuszczenia.

ATT&CK nie jest kolejnym standardem do odhaczenia w dokumentacji compliance. To praktyczne narzędzie pracy - wspólny język między analitykami, inżynierami detekcji i red teamem, pozwalający odpowiedzieć na pytanie, które techniki są dla nas najbardziej prawdopodobne i czy faktycznie potrafimy je wykryć na hostach linuksowych, a nie tylko deklarujemy, że potrafimy.

Kamil Ciaś, współzałożyciel betternow.group | Chief Information Security Officer | Dyrektor ds. Bezpieczeństwa Informacji / Dyrektor ds. Cyberbezpieczeństwa

Jak brak wspólnego języka wygląda w praktyce SOC

Alert bez kontekstu staje się izolowanym faktem. Zespół bez wspólnego frameworku widzi zdarzenie, reaguje na nie punktowo i zamyka zgłoszenie — bez pytania, jaka szersza sekwencja działań mogłaby je poprzedzać lub po nim nastąpić.

Pokrycie deklarowane różni się od pokrycia rzeczywistego. Reguła audytowa może istnieć na jednym serwerze referencyjnym, ale nie być wdrożona spójnie na całej flocie hostów. Dokumentacja mówi „pokryte”, rzeczywistość mówi co innego — różnica ujawnia się dopiero podczas incydentu albo świadomie zaplanowanego testu.

Każdy zespół mówi własnym słownikiem. Red team opisuje działanie w kategoriach technik ofensywnych, blue team w kategoriach reguł korelacyjnych, zarząd w kategoriach ryzyka biznesowego. Bez wspólnego punktu odniesienia te narracje nigdy się nie spotykają.

Nowa technika publikowana przez MITRE zostaje niezauważona. Zespół bez nawyku systematycznego przeglądu dowiaduje się o istotnej luce we własnym pokryciu przypadkowo — zwykle po incydencie, nie przed nim.

Analityk traktuje framework jako obciążenie biurokratyczne. Jeśli tagowanie reguł metadanymi ATT&CK jest wprowadzane odgórnie, bez wyjaśnienia, jak realnie skraca czas analizy, zespół zaczyna je wypełniać pobieżnie, tracąc jego rzeczywistą wartość.

Od struktury poznawczej do działającej reguły

Przełożenie wiedzy o technice ATT&CK na realnie działającą regułę SIEM to proces wieloetapowy, i to właśnie w nim ujawnia się różnica między organizacją, która „zna” framework, a organizacją, która potrafi go stosować.

Punktem wyjścia jest wybór techniki na podstawie faktycznych priorytetów organizacji, a następnie zrozumienie, jakie artefakty systemowe powstają podczas jej wykonania na konkretnej platformie, i identyfikacja źródeł danych, które mogłyby to zarejestrować. Na Linuksie odpowiada im przede wszystkim podsystem audytu jądra auditd, logi journald, historia powłoki czy logi sshd.

Weźmy konkretny, wysoko priorytetowy przykład: technikę T1003.008 (OS Credential Dumping), czyli nieautoryzowany odczyt plików /etc/passwd i /etc/shadow — klasyczny krok w fazie Credential Access, zwykle poprzedzony eskalacją uprawnień poprzez nadużycie źle skonfigurowanego sudo (T1548.003). Samo posiadanie logów nie daje jeszcze widoczności — konieczna jest świadomie skonfigurowana reguła audytowa typu watch na tych plikach.

To dopiero połowa pracy. Reguła korelacyjna musi odróżnić legalny dostęp administracyjny (moduły PAM, sshd, passwd) od dostępu zasługującego na uwagę analityka. Dojrzałe podejście — takie, jakie stosujemy przy wdrożeniach SOC opartych o Wazuh — nie poprzestaje na jednym progu alarmowym, lecz buduje logikę wielopoziomową: bazowe zdarzenie o umiarkowanej istotności, obniżony priorytet dla dostępu z typowych narzędzi powłoki interaktywnej, i gwałtowny wzrost krytyczności, gdy w krótkim oknie czasowym po odczycie /etc/shadow pojawi się uruchomienie narzędzia kojarzonego z łamaniem haseł offline. Taka korelacja dwóch niezależnych zdarzeń radykalnie redukuje liczbę fałszywych alarmów i pozwala analitykowi ufać temu, co widzi na ekranie.

Każda tak zbudowana reguła, otagowana identyfikatorem techniki, automatycznie zasila to, co w dojrzałym SOC nazywa się heatmapą pokrycia — wizualnym obrazem tego, które techniki są objęte realną detekcją, a które pozostają całkowicie niewidoczne.

Najciekawsze w pracy z zespołami SOC nie jest to, jak szybko potrafią wdrożyć nową regułę. Jest to moment, w którym analityk przestaje pytać „co mam teraz zrobić z tym alertem” i zaczyna pytać „czego jeszcze się spodziewam, jeśli moja hipoteza o ataku jest trafna”. To przejście od reagowania do przewidywania to zmiana psychologiczna, nie tylko techniczna - i to ona, bardziej niż liczba wdrożonych reguł, decyduje o dojrzałości zespołu.

Edyta Müller-Ciaś, współzałożycielka betternow.group | Chief Change & Culture Officer | dyrektorka ds. rozwoju organizacji | ekspertka ds. zarządzania zmianą i psychologii biznesu

Jak budować tę zdolność organizacyjnie, nie tylko technicznie

Wspólny przegląd macierzy jako regularny rytuał zespołu, nie jednorazowe wdrożenie. Heatmapa pokrycia traci wartość, jeśli powstaje raz i nigdy nie jest aktualizowana. Warto wbudować w rytm pracy zespołu regularny przegląd: nowe techniki publikowane przez MITRE, wnioski z testów purple teamowych, zmiany w krajobrazie zagrożeń dotyczące konkretnie infrastruktury organizacji, oraz retrospektywna analiza każdego obsłużonego incydentu jako źródła wiedzy o realnych lukach.

Purple teaming jako wspólny język, nie test jednej strony przez drugą. Ćwiczenia, w których red team wykonuje konkretne techniki na hostach testowych, a SOC weryfikuje w czasie rzeczywistym, czy dana technika generuje alert, mają największą wartość wtedy, gdy obie strony traktują je jako wspólne budowanie wiedzy, a nie jako egzamin, który jedna strona zdaje przed drugą. Framework działa jako neutralny grunt do tej rozmowy — technika ma swój identyfikator niezależnie od tego, kto ją wykonał i kto ją wykrył.

Rozróżnienie „pokryte” od „faktycznie zweryfikowane”. Zamiast binarnej oceny, warto stosować skalę dojrzałości uwzględniającą jakość źródła danych, precyzję logiki korelacyjnej, spójność wdrożenia reguł na wszystkich hostach oraz częstotliwość walidacji. To rozróżnienie chroni organizację przed najgroźniejszym scenariuszem: przekonaniem o bezpieczeństwie, które nie wytrzymuje konfrontacji z rzeczywistym incydentem.

Tłumaczenie priorytetów na język zrozumiały dla każdej roli. Analityk myśli w kategoriach technik i artefaktów systemowych, zarząd w kategoriach ryzyka i konsekwencji. Ten sam framework, który porządkuje pracę techniczną, może służyć jako most do rozmowy z zarządem o tym, gdzie organizacja ma realne luki — pod warunkiem że ktoś świadomie przełoży identyfikator techniki na język konsekwencji biznesowych, zamiast zakładać, że zarząd sam dokona tego przekładu.

Nazywanie postępu, nie tylko braków. Zespoły pracujące wyłącznie w trybie wykrywania kolejnych luk w pokryciu, bez odnotowywania tego, co już działa, szybko tracą motywację do dalszego rozwijania zdolności detekcyjnej. Widoczne, konkretne potwierdzenie — „ta reguła faktycznie zadziałała podczas ostatniego testu” — buduje wiarygodność procesu w oczach zespołu równie mocno, jak wykryta luka buduje jego priorytety.

Studium przypadku

Firma świadcząca usługi hostingowe i utrzymaniowe dla klientów e-commerce, zarządzająca infrastrukturą opartą niemal wyłącznie na serwerach linuksowych, została objęta wymogami znowelizowanej ustawy o KSC jako podmiot ważny. Dwuosobowy zespół SOC, wydzielony z wcześniej istniejącego działu utrzymania, przez pierwsze miesiące pracował w trybie czysto reaktywnym: obsługiwał alerty generowane przez SIEM, zamykał zgłoszenia po doraźnej analizie i przechodził do kolejnych.

Podczas przeglądu gotowości do audytu dokumentacja wskazywała formalne „pokrycie” większości kluczowych technik ataku istotnych dla infrastruktury webowej. Test purple teamowy pokazał zupełnie inny obraz. Symulowana próba odczytu pliku /etc/shadow na jednym z serwerów produkcyjnych nie wygenerowała żadnego alertu — reguła audytowa była poprawnie skonfigurowana na serwerze referencyjnym, wykorzystywanym rok wcześniej podczas wdrożenia, ale nigdy nie została rozpropagowana na pozostałe kilkanaście maszyn dołączonych do infrastruktury już po tym wdrożeniu.

Diagnoza nie wykazała złej woli ani braku kompetencji zespołu — reguła tam, gdzie istniała, działała dokładnie tak, jak powinna. Problem leżał w braku systematycznego procesu weryfikującego spójność wdrożenia w czasie, w miarę jak infrastruktura rosła. Zespół „wiedział”, że ma pokrycie tej techniki, w sensie deklaratywnym — nikt nie sprawdził tego założenia empirycznie, dopóki nie wymusił tego zaplanowany test.

Firma zmieniła podejście na dwóch poziomach. Na poziomie technicznym reguły audytowe zostały scentralizowane w systemie zarządzania konfiguracją, obejmującym automatycznie każdy nowy host, zamiast polegać na ręcznej instalacji. Na poziomie organizacyjnym wprowadzono comiesięczny, krótki rytuał zespołowy: przegląd trzech losowo wybranych technik z macierzy pokrycia, z pytaniem nie „czy mamy regułę”, lecz „kiedy ostatni raz faktycznie zweryfikowaliśmy, że działa na wszystkich hostach”. Po kwartale takiej pracy zespół identyfikował samodzielnie, bez zewnętrznego audytu, kolejne trzy podobne luki powstałe w wyniku organicznego wzrostu infrastruktury — zanim którakolwiek z nich została wykorzystana podczas rzeczywistego incydentu.

Wnioski praktyczne

• MITRE ATT&CK działa najsilniej nie jako lista technik do odhaczenia, lecz jako wspólny schemat interpretacyjny, który pozwala zespołowi osadzać pojedyncze alerty w szerszej narracji ataku, zamiast analizować je w izolacji.
• Deklarowane pokrycie techniki i rzeczywiście zweryfikowane pokrycie to dwie różne rzeczy — różnica ujawnia się dopiero podczas testu lub incydentu, jeśli nikt wcześniej świadomie jej nie sprawdził.
• Purple teaming ma największą wartość, gdy obie strony traktują framework jako wspólny język do budowania wiedzy, a nie jako narzędzie oceniania jednej strony przez drugą.
• Przejście analityka od reagowania na alerty do formułowania i testowania hipotez to zmiana psychologiczna — przywraca poczucie sprawczości i chroni przed stanem zbliżonym do wyuczonej bezradności wobec nieprzerwanego strumienia zdarzeń.
• Heatmapa pokrycia traci wartość bez regularnego, wbudowanego w rytm pracy przeglądu — nowe techniki, wyniki testów i wnioski z incydentów muszą systematycznie ją aktualizować, nie tylko przy okazji audytu.
• Wzrost infrastruktury bez scentralizowanego zarządzania konfiguracją regularnie tworzy luki między pokryciem deklarowanym a rzeczywistym — nawet wtedy, gdy pierwotne wdrożenie było wykonane poprawnie.

Czy Twój zespół SOC wie, które techniki ataku faktycznie potrafi wykryć na każdym hoście w infrastrukturze, czy tylko na tym, który posłużył do pierwotnego wdrożenia reguł? BetterNow.Group łączy głęboką wiedzę techniczną z zakresu detekcji i inżynierii bezpieczeństwa z doświadczeniem w budowaniu zespołów i procesów, które przekładają framework na realną, zweryfikowaną zdolność obronną. Skontaktuj się z nami.