Budowa stosu cyberbezpieczeństwa dla obronności, część 2: SIEM/SOAR dla enklaw niejawnych

Część 1 zbudowała fundament wywiadowczy. Część 2 wdraża warstwę operacyjną, która konsumuje ten wywiad: SIEM agreguje i koreluje telemetrię, SOAR automatyzuje reagowanie, oba wpięte w topologię sieci enklaw niejawnych definiującą cyberbezpieczeństwo obronne. Komercyjne produkty SIEM i SOAR istnieją; ich inżynieria pod wdrożenie obronne to miejsce, w którym większość programów niedoszacowuje pracy. Część 2 prowadzi przez to, jak ta praca naprawdę wygląda.

Ujęcie na poziomie filarowym jest w Kompletnym przewodniku po cyberbezpieczeństwie dla obronności; głębsze szczegóły inżynierskie SIEM/SOAR w SIEM i SOAR dla integracji wojskowej.

Krok 1: Architektura wdrożenia per enklawa

Najbardziej konsekwentna decyzja architektoniczna: nie uruchamiaj jednej instancji SIEM przez wiele poziomów klauzul. Każda enklawa niejawna prowadzi własny stos SIEM/SOAR z własnym magazynem danych, własną treścią detekcji, własnym logiem audytowym. Stosy są fizycznie odseparowane; ruch danych między nimi przechodzi przez akredytowane cross-domain solutions, a nigdy przez wspólną infrastrukturę.

Uzasadnienie jest strukturalne: dane SIEM są nadzbiorem klauzul źródeł, które pochłaniają. SIEM agregujący logi sieci SECRET przechowuje treść o klauzuli SECRET; połączenie tego magazynu z UNCLASSIFIED logami administracyjnymi nieumyślnie podniosłoby klauzulę magazynu administracyjnego poprzez efekt agregacji SIEM. Izolacja per enklawa temu zapobiega.

Wzorzec wdrożenia dla przykładu prowadzącego:

• UNCLASSIFIED SIEM — sieci administracyjne, aktywa wystawione do internetu, zarządzanie dostawcami. Dostarczany przez dostawcę SaaS może być tu akceptowalny.
• NATO RESTRICTED SIEM — koalicyjne sieci misyjne, infrastruktura podpięta do FMN. Self-hosted na akredytowanej infrastrukturze; SaaS dostawcy rzadko akceptowalny.
• NATO SECRET SIEM — operacyjne sieci niejawne. Self-hosted; odcięty od internetu (air-gap); aktualizacje przez kontrolowane kanały.
• Krajowy SIEM niejawny — systemy krajowe na wyższej klauzuli. Dostawcy jednoźródłowi z krajową akredytacją; bespoke wdrożenie.

Współdzielenie wywiadu między enklawami płynie przez propagację CTI (mechanizm z części 1) i przez kontrolowane raporty podsumowujące — a nie przez wspólne dashboardy SIEM.

Krok 2: Potok agregacji logów

SIEM jest strukturalnie potokiem logów z detekcją nałożoną na wierzch. Zrób potok dobrze, a detekcja stanie się wykonalna; zrób go źle, a koszt potoku zdominuje wszystko inne.

Etapy potoku:

Zbieranie. Agenci na endpointach (Sysmon na Windows, auditd na Linux, agenci dostawców EDR), sensory sieciowe (produkty NDR, urządzenia IDS, kolektory NetFlow), logi aplikacyjne (format custom i Syslog), logi płaszczyzny kontroli chmury (gdzie chmura jest w zakresie), telemetria OT (część 3 tej serii).

Normalizacja. Heterogeniczne formaty źródłowe znormalizowane do wspólnego schematu. Elastic Common Schema (ECS), OCSF, schematy specyficzne dla dostawcy — wybierz jeden i wyrównaj. Niezgodności schematu w produkcji to powracające źródło missów detekcyjnych.

Wzbogacanie. Dodaj kontekst, którego brakuje surowemu logowi: klauzulę aktywa z inwentarza (część 1), tagi CTI z potoku wywiadowczego, kontekst atrybutów użytkownika z systemów tożsamości, geolokalizację, powiązanie z podmiotem zagrożenia.

Routing. Zdarzenia płyną do hot tier SIEM-a do korelacji na żywo, do długoterminowego cold storage na potrzeby retencji forensycznej i selektywnie do SOAR-a do wyzwalania playbooków. Reguły routingu są jawną polityką.

Retencja. Cyberbezpieczeństwo obronne ma wymogi długiej retencji — kampanie podmiotów państwowych dwell przez miesiące lub lata. Potok wspiera retencję warstwową: hot (korelacja na żywo), warm (niedawne zapytania forensyczne), cold (długoterminowe archiwum). Budżety retencji to decyzje programowe; niedoszacowanie wymusza przedwczesne kasowanie danych.

Krok 3: Treść detekcji jako kod

Reguły detekcji SIEM out-of-the-box łapią zagrożenia commodity. Detekcja klasy obronnej łapie zagrożenia państwowe. Luką jest treść detekcji: reguły skrojone pod inwentarz aktywów, model zagrożeń i potok CTI.

Dyscyplina treści detekcji jako kodu:

Reguły Sigma jako format źródłowy. Sigma to neutralny względem dostawców format reguł detekcji; reguły napisane w Sigma konwertują się do Splunk, Elastic, Sentinel, QRadar i innych. Pisanie w Sigma trzyma detekcję przenośną; tuning specyficzny dla dostawcy zachodzi przy wdrożeniu.

Reguły per aktywo i per podmiot zagrożenia. Generyczna detekcja „PowerShell encoded command" łapie szum. „PowerShell encoded command na hoście NATO SECRET od użytkownika spoza OU inżynierskiego" to sygnał. Inwentarz aktywów i model zagrożeń informują specyficzność reguły.

Testowanie CI względem przechwyconych danych zdarzeń. Reguły detekcji są unit-testowane w CI. Przechwycone ślady zdarzeń z wcześniejszych incydentów i ćwiczeń red-team służą jako ground truth. Zmiana reguły, która już nie wykrywa przechwyconego incydentu, jest regresją blokującą merge.

Mapowanie na MITRE ATT&CK. Każda reguła mapuje się na jedną lub więcej technik ATT&CK. Mapowanie umożliwia analizę pokrycia (które techniki są dobrze pokryte, które są martwymi polami) i raportowanie klasy zamówieniowej o postawie obronnej platformy.

Zarządzanie false-positive. Reguły produkują alerty. Alerty produkują obciążenie SOC. Dyscyplina tuningu FP — pomiar wskaźnika FP per reguła, dopracowywanie reguł w celu redukcji szumu, wycofywanie reguł, których nie da się dostroić — jest strukturalna. SOC-i tonące w FP-ach przegapiają TP-y.

Krok 4: Inżynieria playbooków SOAR

SOAR (Security Orchestration, Automation, and Response) automatyzuje reakcję na wykryte zdarzenia. Playbook to wersjonowany, przetestowany, recenzowalny workflow, który SOAR wykonuje na alert.

Dyscyplina playbooków:

Wersjonowane w kontroli źródła. Playbooki to kod — YAML, JSON, DSL-e specyficzne dla dostawcy. Żyją w repozytorium obok reguł detekcji, są recenzowane przed wdrożeniem i wytaczają się przez ten sam proces change-control co kod aplikacyjny.

Testowane w CI. Przechwycone ślady incydentów służą jako wejścia testowe. Playbook, który nie wykonuje się poprawnie wobec przechwyconego śladu, blokuje merge.

Bramki potwierdzenia przez człowieka dla konsekwentnych akcji. SOAR może odizolować hosta, wyłączyć konto użytkownika, zablokować zakres sieciowy, zakończyć proces. Każde z tych ma konsekwencje operacyjne. Playbook wystawia proponowaną akcję i wymaga jawnego potwierdzenia człowieka; decyzja człowieka jest logowana.

Ślad audytowy dla każdej automatycznej akcji. Nawet akcje wykonujące się bez przeglądu człowieka (wzbogacenie alertu, utworzenie ticketu, lookup threat-intelligence) są logowane. Ślad audytowy jest bazą dowodową dla przeglądu po działaniu.

Ścieżki rollback. Akcja SOAR, która była błędna — odizolowany niewłaściwy host, wyłączony niewłaściwy użytkownik — musi być odwracalna. Inżynieria playbooka uwzględnia to od początku; doklejanie odwracalności później to bespoke praca per akcja.

Krok 5: Integracja cross-CERT

Cyberbezpieczeństwo obronne istnieje we wspólnocie. Krajowe CERT-y (CISA, BSI, ANSSI, CCN-CERT), wojskowo-specyficzne CSIRT-y (US-CERT, NCSC, JCDC), koalicyjne CSIRT-y (NATO NCIRC), partnerskie CSIRT-y. Platforma integruje się z tą wspólnotą dwukierunkowo.

Wzorce integracji:

Konsumpcja wywiadu przychodzącego. Advisories CERT płyną do potoku CTI (część 1) i wyzwalają aktualizacje reguł detekcji. Advisories czasowo wrażliwe (aktywna eksploatacja podatności, trwająca atrybucja kampanii) dostają priorytetową obsługę.

Wychodzące raportowanie incydentów. Potwierdzone incydenty — szczególnie te dotyczące TTP-ów państwowych lub wskaźników relewantnych koalicyjnie — płyną na zewnątrz do odpowiedniego CERT-u przez STIX/TAXII lub formalne kanały raportu incydentu. Raportowanie szanuje klauzulę: incydenty NATO SECRET idą do NCIRC, a nie do komercyjnego dostawcy.

Wspólny hunting. Okresowe współprace threat-hunting z partnerskimi CERT-ami — uruchamianie zapytań w wielu środowiskach krajowych, szukanie TTP-ów adwersarza, które wyłaniają się dopiero w agregacie. Wspólny hunting jest operacyjnie wartościowy i politycznie złożony; ślad audytowy platformy wspiera przegląd prawno-polityczny.

Udział w ćwiczeniach. Locked Shields, Cyber Coalition, Crossed Swords — ćwiczenia cyber NATO i partnerskie, które testują koordynację cross-CERT. Udział to dowód zdolności klasy zamówieniowej.

Krok 6: Cele wydajności i skali

Cele SIEM/SOAR odróżniające platformy operacyjne od prototypów:

• Ingestia logów utrzymana na tempie operacyjnym (zwykle 50K–500K zdarzeń/sekundę dla krajowego wdrożenia obronnego), z obsługą surge na 5× baseline.
• Latencja detekcji poniżej 60 sekund od przybycia zdarzenia do wygenerowania alertu dla reguł czasowo wrażliwych; poniżej 5 minut dla reguł korelacyjnie ciężkich.
• Latencja wykonania playbooka poniżej 30 sekund do przekazania pod przegląd człowieka; pełne ukończenie playbooka w ciągu minut dla ścieżek automatycznych.
• Retencja storage'u mierzona w latach dla środowisk wysokiej klauzuli; warstwowana, by zarządzać kosztem.
• Wydajność zapytań poniżej 30 sekund dla typowych zapytań analityka na danych hot; poniżej 5 minut dla zapytań cold.
• Dostępność na 99,9%+ dla komponentów hot-tier; zdegradowane działanie akceptowalne przy awariach cold-tier.

Niespełnienie tych celów jest zwykle rezultatem skrótów architektonicznych (niedoprovisionowana ingestia, źle wyrutowane indeksy, naiwne wzorce zapytań). Programy prototypujące jawnie wobec tych celów łapią skróty przed wdrożeniem operacyjnym.

Krok 7: Wybór dostawcy dla wdrożenia obronnego

Lista dostawców SIEM/SOAR wdrażalnych w obronności jest krótsza niż lista komercyjna. Kryteria:

Historia akredytacji. Dostawcy z wcześniejszą akredytacją w sieciach niejawnych NATO lub państw członkowskich mają dowody, które recenzenci akredytacji uznają za wiarygodne. Cold-start z dostawcą nieakredytowanym dodaje 12–24 miesięcy do wdrożenia.

Wdrażalność air-gapped. Wdrożenie dostawcy musi działać w środowiskach bez egress internetu na aktualizacje, kanały threat-intel czy telemetrię. Produkty cloud-only odpadają dla wyższych klauzul.

Pozycjonowanie ITAR-free dla programów europejskich. Zobacz Oprogramowanie obronne ITAR-free dla kryteriów. Wdrożenia europejskie coraz częściej preferują dostawców ITAR-free.

Przenośność treści detekcji. Wsparcie Sigma (lub porównywalny format neutralny względem dostawców) trzyma treść detekcji platformy przenośną między tranzycjami dostawców. Vendor lock-in na treści detekcji to ryzyko strategiczne.

Otwarte API. SIEM/SOAR integruje się ze wszystkim innym w stosie cyber — platformą CTI, EDR, sensorami sieciowymi, systemami tożsamości, ticketingiem. Otwarte API są nienegocjowalne.

Szczegółowe kryteria wyboru dostawcy dla oprogramowania obronnego ogólnie są w Jak wybrać dostawcę oprogramowania obronnego.

Co dalej

Część 2 zbudowała warstwę operacyjną. Architektura SIEM/SOAR per enklawa, potok agregacji logów, treść detekcji jako kod, dyscyplina playbooków SOAR, integracja cross-CERT, cele wydajnościowe, wybór dostawcy. Stos teraz wykrywa i reaguje w skali w obrębie architektury enklaw niejawnych.

Część 3 obejmuje warstwy wyspecjalizowane: obronę ICS/OT dla technologii operacyjnej, której narzędzia klasy IT nie adresują, gotowość kryminalistyki cyfrowej do analizy post-compromise oraz cross-domain solutions, które przesuwają odpowiednie dane między enklawami, jednocześnie zapobiegając przepływom niewłaściwym.