Cyberbezpieczeństwo obronne to cyberbezpieczeństwo korporacyjne z trzema mnożnikami — przeciwnicy będący podmiotami państwowymi, topologia sieci enklaw niejawnych i sprzężenie z technologią operacyjną. Platformy, które sprawdzają się w tym kontekście, są budowane od modelu zagrożeń w górę: aktywa skatalogowane według klauzuli i krytyczności, threat intelligence płynący przez potoki STIX/TAXII, wykrywanie i reagowanie nawarstwione na tym fundamencie. Platformy, które upadają, powstały przez przemalowanie komercyjnego oprogramowania bezpieczeństwa etykietą obronną. Ta czteroczęściowa seria pokazuje, jak zrobić to dobrze. Część 1 obejmuje fundament.
Ramy architektoniczne znajdują się w Kompletnym przewodniku po cyberbezpieczeństwie dla obronności. Seria budowy C2 w Budowa systemu C2 od zera opisuje platformę, której ten stos cyber broni; seria interoperacyjności NATO w Implementacja interoperacyjności NATO krok po kroku wyznacza kontekst koalicyjnej wymiany danych.
Krok 1: Zbuduj jawny model zagrożeń
Cyberbezpieczeństwo obronne, które nie zaczyna od jawnego modelu zagrożeń, to cyberbezpieczeństwo obronne broniące się przed fikcją. Model zagrożeń dokumentuje, przed kim platforma się broni, co ci przeciwnicy potrafią i czego chcą. Każda kolejna decyzja architektoniczna odnosi się do modelu.
Komponenty modelu zagrożeń klasy obronnej:
- Aktorzy zagrożeń. Przeciwnicy państwowi (z atrybucjami do konkretnych państw tam, gdzie kontekst operacyjny to uzasadnia), grupy powiązane z państwem, aktorzy kryminalni, insiderzy, wektory kompromitacji łańcucha dostaw. Każdy aktor ma profile motywu, możliwości i cierpliwości.
- Taktyki przeciwnika. Mapowanie MITRE ATT&CK to wspólny język; trzymaj się go od pierwszego sprintu. Konkretne TTP (taktyki, techniki, procedury), które platforma antycypuje.
- Cele przeciwnika. Rozpoznanie, persistencja, lateral movement, eksfiltracja danych, zakłócenie operacyjne, przygotowanie kinetyczne. Różne cele wymagają różnych postaw obronnych.
- Powierzchnia ataku. Punkty wejścia sieciowego, zależności łańcucha dostaw, powierzchnie skierowane na człowieka (phishing, inżynieria społeczna), interfejsy technologii operacyjnej.
- Założone możliwości przeciwnika. Wykorzystywanie zero-dayów, customowe implanty, zdolność do przechwytu sygnałowego, tolerancja na długi dwell-time. Inżynieria obronna platformy skalowana jest do tych możliwości, a nie do poziomu komercyjno-kryminalnego.
- Zagrożenia poza zakresem. Wyliczone jawnie: bezpieczeństwo fizyczne centrum danych, bezpieczeństwo elektromagnetyczne poza standardową praktyką, zagrożenia obsługiwane przez inne części architektury bezpieczeństwa. Zakresowanie zapobiega rozlewaniu się obrony w nieskończoność.
Model zagrożeń to żywy dokument, wersjonowany w repozytorium obok kodu źródłowego, przeglądany przez liderów bezpieczeństwa i inżynierii. To artefakt klasy zamówieniowej, o który recenzenci akredytacji pytają w pierwszej kolejności.
Krok 2: Inwentarz aktywów z klauzulami i krytycznością
Stos cyber broni konkretnych aktywów. Ich katalogowanie jest niewdzięczne i przesądzające — programy, które pomijają inwentarz aktywów, bronią się przed niewłaściwym przeciwnikiem i niewłaściwą powierzchnią ataku.
Katalog aktywów zawiera dla każdego aktywa:
- Identyfikator aktywa i nazwę przyjazną. Stabilne, czytelne dla człowieka, śledzone w całym łańcuchu narzędzi bezpieczeństwa.
- Typ aktywa. System, baza danych, segment sieci, usługa aplikacyjna, wagi modelu, zbiór danych treningowych, sterownik technologii operacyjnej.
- Poziom klauzuli. NATO RESTRICTED, NATO SECRET, COSMIC TOP SECRET, krajowe odpowiedniki. Poziom kształtuje wszystko po stronie downstream.
- Kompartmenty i releasability. Według konwencji STANAG 4774 (zobacz Część 3 serii interoperacyjności NATO).
- Poziom krytyczności. Krytyczne dla misji, niezbędne dla misji, wspierające misję, administracyjne. Różne poziomy uzasadniają różne postawy obronne.
- Właścicielstwo. Organizacja odpowiedzialna za eksploatację i bezpieczeństwo aktywa.
- Enklawa sieciowa. Która niejawna lub jawna sieć obsługuje aktywo.
- Zależności. Od jakich innych aktywów zależy to aktywo; co zależy od niego.
Katalog jest automatyzowany tam, gdzie to możliwe (integracja CMDB, skanowanie dyskryminacyjne tam, gdzie dozwolone) i kurowany tam, gdzie automatyzacja zawodzi (aktywa technologii operacyjnej często wymagają ręcznego katalogowania). Żywy dokument, wersjonowany, fundament wszystkiego, co następuje.
Krok 3: Ustanów potok CTI
Cyber Threat Intelligence to warstwa, która nadaje wykrywaniu sens. Surowe wskaźniki płynące na wejściu, skontekstualizowane dane o zagrożeniach płynące przez, użyteczny wywiad płynący na wyjściu do łańcucha narzędzi wykrywania i reagowania. Architektura potoku ma znaczenie tak samo duże jak wejścia.
Etapy potoku:
Pozyskiwanie. Wiele typów kanałów: feedy STIX/TAXII od komercyjnych dostawców, biuletyny partnerskich CSIRT, alerty krajowych CERT, bazy podatności (NVD, alerty producentów), źródła OSINT. Każdy feed ma własny format, uwierzytelnianie i model zaufania.
Normalizacja. Konwersja wejść do kanonicznej reprezentacji CTI — obiekty STIX 2.1 (wskaźniki, malware, podmioty zagrożeń, kampanie, wzorce ataku). Normalizacja jest jednokierunkowa; konsumenci widzą tylko formę kanoniczną. Szczegółowa inżynieria platformy CTI jest w Platformach CTI dla obronności.
Deduplikacja i korelacja. Ten sam wskaźnik może pojawić się w pięciu feedach. Deduplikuj agresywnie. Koreluj wskaźniki dzielące kontekst — ten sam podmiot zagrożeń, ta sama kampania, ten sam wzorzec ataku — w złożone pakiety wywiadowcze.
Wzbogacanie. Dodaj kontekst, którego surowe feedy nie zawierają: scoring pewności, mapowanie MITRE ATT&CK, scoring trafności względem inwentarza aktywów, wytyczne obsługi klauzul, tagi releasability.
Dystrybucja. Wypchnij do SIEM/SOAR dla reguł wykrywania, do EDR dla blocklist endpointów, do narzędzi bezpieczeństwa sieci dla filtrowania ruchu, do zespołów threat-hunt jako wejście badawcze, do operacyjnego stosu fuzyjnego, gdzie obserwacje cyber wchodzą do obrazu multi-INT (zobacz Potok fuzyjny, Część 3).
Krok 4: Implementacja STIX/TAXII
STIX (Structured Threat Information Expression) to model danych dla cyber threat intelligence. TAXII (Trusted Automated Exchange of Intelligence Information) to protokół transportowy. Razem są lingua franca wymiany CTI między organizacjami obronnymi a komercyjnymi dostawcami threat intelligence.
Realia implementacji:
Najpierw strona konsumenta. Większość programów obronnych konsumuje STIX/TAXII od komercyjnych dostawców (Mandiant, Recorded Future, CrowdStrike, MITRE) i partnerskich CSIRT. Klient TAXII 2.x po stronie konsumenta jest dobrze zrozumiany i wykonalny.
Walidacja schematu na granicy. Każdy przychodzący obiekt STIX jest walidowany względem schematu przed dalszym przetwarzaniem. Wejście niepoprawne jest logowane i odrzucane. Naruszenia schematu były wykorzystywane jako wektory wstrzyknięć; ścisła walidacja to obrona strukturalna.
Scoring pewności. Obiekty STIX mają pola pewności. Używaj ich. Wskaźnik o wysokiej pewności od dostawcy i wskaźnik o niskiej pewności pochodzący z OSINT są obsługiwane inaczej w downstreamowym potoku wykrywania.
Strona dostawcy wybiórczo. Programy, które dzielą się wywiadem z partnerami — koalicyjne CSIRT, udział w ISAC, dzielenie się wewnątrz-na-zewnątrz przy reagowaniu na incydenty — implementują endpointy dostawcy TAXII. Implementacja jest cięższa niż po stronie konsumenta i wymaga dyscypliny obsługi klauzul z Części 3 tej serii.
Krok 5: Potok OSINT z różnorodnością źródeł
Wywiad ze źródeł otwartych to wartościowe wejście CTI. Media społecznościowe, strony paste, strony wycieków ransomware, fora techniczne, alerty bezpieczeństwa producentów, wiadomości. OSINT-owe wykrycie ataku na siły lub infrastrukturę partnera to wywiad o wartości operacyjnej, na którym feedy producentów często mają opóźnienie.
Wzorzec potoku OSINT:
Różnorodność źródeł. Żadne pojedyncze źródło nie dominuje. Wiele źródeł zmniejsza bias pojedynczego feeda i szybciej ujawnia fałszywe trafienia.
Pewność według źródła. Każde źródło ma skalibrowany score pewności oparty na historycznej trafności. Domniemany wskaźnik na anonimowym forum jest obsługiwany inaczej niż potwierdzony wskaźnik w alercie krajowego CERT.
Atrybucja i cytowanie. Każdy wskaźnik pochodzący z OSINT niesie URL źródła, znacznik czasu migawki i notatkę analityka. Bez proweniencji wskaźnik nie przeżyje przeglądu i nie może być propagowany do partnerów koalicyjnych.
Bariery prawne i etyczne. Pozyskiwanie OSINT z mediów społecznościowych ma ograniczenia prawne różniące się między jurysdykcjami. Polityka pozyskiwania OSINT platformy jest udokumentowana, zrecenzowana przez prawników i egzekwowana w kodzie. Szczegółowe potraktowanie jest w Monitoring zagrożeń OSINT dla obronności.
Kluczowy wniosek: Potok CTI to warstwa, która zamienia generyczne oprogramowanie bezpieczeństwa w obronę klasy obronnej. SIEM bez CTI łapie zagrożenia commodity. SIEM wzbogacony o CTI istotne dla zagrożeń państwowych łapie zagrożenia, przed którymi platforma rzeczywiście się broni. Inwestycja w infrastrukturę CTI to decyzja o najwyższej dźwigni w stosie cyber.
Krok 6: Cyber jako dyscyplina fuzyjna
Nowoczesne cyberbezpieczeństwo obronne traktuje obserwacje cyber jako kolejną dyscyplinę wywiadowczą obok SIGINT, IMINT, ELINT. Wyjścia stosu cyber wpływają do operacyjnego potoku fuzyjnego; wyjścia operacyjnego potoku fuzyjnego wzbogacają podejmowanie decyzji cyber. Integracja jest dwukierunkowa.
Wzorzec architektoniczny:
Zdarzenia cyber jako obserwacje. Potwierdzone kompromitacje, wykrycia prób ataku, atrybuowane kampanie — każde z nich staje się obserwacją w kanonicznym schemacie track-u, otagowaną metadanymi dyscypliny cyber. Szczegółowy wzorzec jest w Budowa obronnego potoku fuzyjnego, Część 3.
Wzbogacenie CTI dla tracków domeny fizycznej. Gdy wskaźnik cyber sugeruje aktywność przeciwnika w lokalizacji geograficznej, wskaźnik wzbogaca track domeny fizycznej w obrazie operacyjnym. Punkt zbioru SIGINT współzlokalizowany z potwierdzoną kompromitacją cyber staje się trackiem o wyższym priorytecie dla operatora.
Współdzielona maszyneria klauzul. Etykiety klauzul na danych cyber płyną przez to samo wiązanie STANAG 4774/4778 co dane domeny fizycznej. Kompartmenty i releasability specyficzne dla cyber działają obok szerszego systemu klauzul.
Krok 7: Struktura repozytorium dla kodu cyber
Kod stosu cyber jest wrażliwy — niepoprawne zmiany mogą wyłączyć wykrywanie, przegapić kompromitacje lub ujawnić materiał niejawny. Dyscyplina repozytorium ogranicza ryzyko.
Struktura, która działa:
cyber/threat-model/— wersjonowane dokumenty modelu zagrożeń, mapowania MITRE ATT&CK, klasyfikacje poziomów aktywów.cyber/asset-inventory/— katalog z Kroku 2, łączący automatyzację odkrywania i ręczną kurację.cyber/cti/feeds/— konfiguracje feedów, reguły normalizacji per źródło, polityki deduplikacji.cyber/cti/enrichment/— potoki wzbogacania, reguły scoringu pewności, scoring trafności względem aktywów.cyber/detection-rules/— treść wykrywania SIEM (reguły Sigma, formaty specyficzne dla producentów), wersjonowana, testowana w CI względem przechwyconych danych zdarzeń.cyber/playbooks/— playbooki reagowania SOAR, testowane w CI, recenzowane przez kierownictwo bezpieczeństwa przed wdrożeniem.cyber/forensics/— narzędzia zbierania i analizy, procedury łańcucha dowodowego.cyber/ADRs/— Architecture Decision Records dla znaczących wyborów architektury cyber.
Co dalej
Część 1 zbudowała fundament. Jawny model zagrożeń, inwentarz aktywów z klauzulami, potok CTI pozyskujący STIX/TAXII i OSINT, integracja cyber jako dyscypliny fuzyjnej, dyscyplina repozytorium. Stos cyber ma teraz trzeźwe spojrzenie na to, przed czym się broni, czego broni i skąd pochodzi jego wywiad.
Część 2 implementuje warstwę operacyjną: SIEM i SOAR zaprojektowane dla enklaw niejawnych, integracja cross-CERT, dyscyplina automatycznych playbooków, praktyczne realia, które odróżniają operacyjny cyber od cyber z PowerPointa.