Badanie incydentów za pomocą zapytań SQL

Gdy CloudTrail i Flow Logs są już skatalogowane, dochodzenie staje się serią SQL queries, które redukują miliardy zdarzeń do kilku istotnych. Kluczowa jest wiedza o tym, o co zapytać: kto co zrobił, skąd i kiedy. W tej lekcji omówiono wzorce zapytań, na których polegają osoby prowadzące dochodzenia.

Gdy istnieje podejrzenie przejęcia danych uwierzytelniających, należy odpytać o wszystkie działania danego principal. Filtrowanie CloudTrail według userIdentity.arn lub identyfikatora klucza dostępu ujawnia każde wykonane przez niego wywołanie API, w kolejności ich wystąpienia. Taka oś czasu działań atakującego jest często najcenniejszym rezultatem dochodzenia.

Filtrowanie według sourceIPAddress pokazuje wszystko, co wykonano z danego adresu. Jeśli mają Państwo jeden podejrzany adres IP z ustalenia GuardDuty, pozwala to wykryć każde wywołanie wykonane przez ten adres w różnych usługach, co pomaga określić zakres skutków ataku i ustalić, z jakimi zasobami zetknął się atakujący.

Odpytywanie o zdarzenia, w których errorCode ma wartość AccessDenied lub UnauthorizedOperation, ujawnia rekonesans: atakujący sprawdza, co może zrobić za pomocą skradzionych danych uwierzytelniających. Seria odrzuceń dotyczących jednego principal, po której następuje udane wywołanie, pokazuje, że atakujący znalazł uprawnienie, które działa — jest to wyraźny sygnał eskalacji.

Należy obserwować wrażliwe zdarzenia IAM, takie jak CreateUser, AttachUserPolicy, CreateAccessKey lub PutUserPolicy. Atakujący często próbuje zapewnić sobie trwały dostęp, tworząc nowe tożsamości lub klucze. Odpytywanie o te nazwy zdarzeń szybko ujawnia próby umocnienia dostępu uzyskanego podczas początkowego włamania.

Skuteczne dochodzenia łączą źródła danych: zestawiają działania principal z CloudTrail z VPC Flow Logs dotyczącymi tej samej instancji albo z logami ALB dotyczącymi obsługiwanych przez nią żądań. Korelacja aktywności w płaszczyźnie sterowania i w sieci pozwala odtworzyć pełny przebieg ataku, a nie tylko odizolowane fragmenty.

Zawsze należy ograniczać zapytania do time window za pomocą znacznika czasu zdarzenia. Skupia to dochodzenie na istotnym okresie, a w połączeniu z partycjami znacznie zmniejsza ilość skanowanych danych i koszt. Rozpoczęcie od szerokiego przedziału czasu, a następnie jego zawężanie, jest naturalnym sposobem pracy w miarę wyjaśniania sytuacji.

Agregacje ujawniają wzorce: użyj GROUP BY dla adresu IP źródła, aby znaleźć adresy generujące najwięcej ruchu, policz różne nazwy zdarzeń dla każdego principal, aby ocenić zakres aktywności, albo zliczaj błędy w czasie, aby wykryć nagły wzrost. Takie podsumowania przekształcają surowe wiersze w trendy wskazujące rzeczywisty incydent.

To samo podejście oparte na SQL stosuje się do Flow Logs w S3: można wyszukiwać duże transfery wychodzące, zliczać odrzucane porty według źródła albo wyświetlać zewnętrzne adresy IP, z którymi kontaktowała się instancja. Połączenie CloudTrail (co wykonano za pośrednictwem API) z Flow Logs (co przesłano przez sieć) zapewnia pełny obraz sytuacji.

Sprawdzone zapytania dotyczące dochodzeń należy zapisywać jako named queries lub widoki, aby zespół mógł szybko uruchomić je ponownie podczas kolejnego incydentu. Biblioteka zweryfikowanych zapytań, takich jak „wszystkie działania wykonane za pomocą klucza dostępu” lub „odrzucone wywołania z ostatniej godziny”, przekształca doraźne działania w powtarzalną zdolność reagowania.

Zapytania dostarczają dowodów, a dowody wyznaczają działania: unieważnienie klucza, odizolowanie instancji czy usunięcie nieautoryzowanego użytkownika IAM. Zdyscyplinowany proces odpytywania — najpierw principal, następnie adres IP, potem zdarzenia eskalacji i korelacja — zapewnia pełne i wiarygodne zrozumienie sytuacji, niezbędne do właściwego opanowania incydentu.

Dochodenia to SQL queries wykonywane na skatalogowanych logach. Należy zacząć od principal lub source IP, wyszukiwać denied calls w celu wykrycia rekonesansu, obserwować zdarzenia IAM, takie jak CreateAccessKey, pod kątem escalation, a wszystko ograniczać do określonego czasu. Należy group and count, aby znaleźć wzorce, correlate CloudTrail z Flow Logs oraz zapisywać sprawdzone named queries, aby gromadzenie dowodów stało się powtarzalną zdolnością reagowania.