0Pricing
Cyber Security Academy · Lekcja

Zasady Detection-as-Code

Traktowanie mechanizmów wykrywania jak oprogramowania

Zasady Detection-as-Code to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Dlaczego Detection-as-Code

Detection-as-Code (DaC) stosuje zasady inżynierii oprogramowania do detekcji bezpieczeństwa. Zamiast ręcznie edytować reguły w konsoli SIEM, analitycy przechowują detekcje jako pliki tekstowe w systemie kontroli wersji i wdrażają je za pośrednictwem potoku.

Korzyści są konkretne:

  • Łatwe do zrecenzowania zmiany za pośrednictwem pull requestów
  • Powtarzalne wdrożenia w różnych środowiskach
  • Testowalna logika przed wdrożeniem do produkcji
  • Audytowalna historia tego, kto, co i dlaczego zmienił

Detekcja staje się artefaktem, który można porównywać, wycofywać i analizować tak jak każdy inny kod.

Detekcje jako wersjonowane pliki

Każda detekcja jest przechowywana jako samodzielny plik, zazwyczaj w formacie YAML lub w języku zapytań dostawcy, i zatwierdzana w repozytorium Git. Układ repozytorium odzwierciedla sposób organizacji zakresu pokrycia detekcjami.

Typowa struktura rozdziela reguły według platformy i taktyki:

detections/
  windows/
    credential_access/
      lsass_memory_dump.yml
    execution/
      suspicious_powershell.yml
  cloud/
    aws/
      root_account_usage.yml
tests/
  windows/
    lsass_memory_dump_test.yml

Przegląd pull requestów

Każda nowa lub zmodyfikowana detekcja przechodzi przez pull request. Drugi inżynier sprawdza logikę, ryzyko fałszywych alarmów i mapowanie ATT&CK przed scaleniem.

Osoby dokonujące przeglądu zadają następujące pytania:

  • Czy logika odpowiada opisanemu zagrożeniu?
  • Jaka prawidłowa aktywność może to wywołać?
  • Czy poziom ważności i odwołanie do ATT&CK są poprawne?
  • Czy istnieją testy obejmujące rzeczywiste i fałszywe trafienia?

W ten sposób można wykryć błędy, które przeoczyłby samotny analityk edytujący SIEM o drugiej w nocy.

Walidacja w CI

Potok ciągłej integracji uruchamia się automatycznie przy każdym pushu. Wymusza spełnienie bramek jakości, zanim reguła będzie mogła zostać scalona.

Typowe etapy CI w repozytorium opartym na Sigma:

# .github/workflows/validate.yml (excerpt)
steps:
  - name: Lint Sigma syntax
    run: sigma check ./detections
  - name: Validate against schema
    run: sigma check --validators all ./detections
  - name: Run unit tests
    run: pytest tests/

Automatyczne wdrażanie

Po scaleniu zadanie wdrażania konwertuje przenośne reguły na docelowy język zapytań i przesyła je do SIEM lub EDR za pośrednictwem API.

W przypadku Sigma zazwyczaj uruchamia się konwerter, taki jak sigma convert, z backendem odpowiadającym używanej platformie (Splunk, Elastic, Microsoft Sentinel). Następnie potok przesyła wygenerowane zapisane wyszukiwania lub reguły analityczne.

Nikt nie wkleja ręcznie zapytań do konsoli. Stan wdrożenia zawsze odpowiada zawartości main.

sigma convert -t splunk -p splunk_windows \
  detections/windows/execution/suspicious_powershell.yml

Testowanie detekcji

Detekcja bez testów jest tylko domysłem. DaC łączy każdą regułę z danymi testowymi: próbkami logów, które powinny uruchomić detekcję (rzeczywiste trafienia), oraz nieszkodliwymi próbkami, które nie powinny jej uruchomić (fałszywe trafienia).

Testy są uruchamiane w CI, dlatego zmiana, która narusza pokrycie lub ponownie wprowadza szum, nie przejdzie procesu budowania przed scaleniem. To najważniejszy element zapewniający pewność podczas refaktoryzacji reguł na dużą skalę.

test:
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 javascript:...' }
    expected: match
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 shell32.dll,Control_RunDLL' }
    expected: no_match

Metadane reguł i cykl życia

Metadane należy traktować jako element pierwszoplanowy. Każda detekcja zapisuje swój status w miarę dojrzewania w cyklu życia:

  • experimental — nowo napisana, poddawana ścisłemu monitorowaniu
  • test — działająca, ale jeszcze nieuznawana za wystarczająco wiarygodną do generowania alertów
  • stable — sprawdzona, z niskim wskaźnikiem fałszywych alarmów
  • deprecated — zastąpiona lub wycofana

Śledzenie statusu w pliku pozwala świadomie podnosić, obniżać i wycofywać reguły zamiast pozwalać, by nieaktualna logika pozostawała w produkcji.

Przenośność między backendami

Kluczową korzyścią DaC jest jednokrotne zapisanie logiki detekcji raz w formacie niezależnym od dostawcy, a następnie skompilowanie jej do wielu backendów. Sigma jest de facto standardem detekcji opartych na logach.

Ten sam plik reguły może być kierowany do SPL Splunk, Lucene/EQL Elastic, KQL Microsoft Sentinel i innych backendów za pomocą mapowań pól właściwych dla potoku. Nie trzeba przepisywać tej samej koncepcji pięć razy ani uzależniać się od jednego dostawcy.

sigma convert -t elasticsearch rule.yml
sigma convert -t microsoft365defender rule.yml
sigma convert -t splunk rule.yml

Potoki mapowania pól

Różne źródła logów różnie nazywają te same dane. Zdarzenie tworzenia procesu w Sysmon używa pola Image; log zabezpieczeń Windows może używać pola NewProcessName. Potoki przetwarzania wypełniają tę lukę.

Potoki przekształcają ogólne nazwy pól Sigma na dokładne nazwy pól występujące w używanych danych, dzięki czemu jedna reguła logiczna poprawnie mapuje się na dowolny schemat przyjmowany przez SIEM. Centralne utrzymywanie potoków oznacza, że zmianę schematu obsługuje się raz, a nie w każdej regule.

sigma convert -t splunk -p sysmon rule.yml

Środowiska i promocja

Podobnie jak kod aplikacji, detekcje przechodzą przez środowiska, zanim trafią do produkcji. Typowy przepływ prowadzi z dev przez staging do prod.

  • Dev — tworzenie detekcji i uruchamianie testów jednostkowych w CI
  • Staging — wdrażanie na kopii rzeczywistej telemetrii w trybie audytu
  • Prod — promowanie po osiągnięciu akceptowalnego wskaźnika fałszywych alarmów

Promocja jest celowym, poddanym przeglądowi krokiem powiązanym ze statusem cyklu życia reguły, a nie przypadkowym skutkiem scalania. Takie etapowe wdrażanie odzwierciedla dyscyplinę „najpierw alert, potem blokada” stosowaną w przypadku detekcji działających inline.

Pokrycie i metryki

Ponieważ detekcje są kodem, można programowo mierzyć pokrycie. Należy powiązać każdą regułę z technikami MITRE ATT&CK i generować mapę cieplną pokazującą, co jest objęte pokryciem, a co nie.

Warto śledzić w czasie następujące metryki:

  • Liczba pokrytych technik w porównaniu z ich łączną liczbą w modelu zagrożeń
  • Współczynnik fałszywych alarmów dla każdej reguły
  • Średni czas od pomysłu na regułę do wdrożenia na produkcji
  • Liczba reguł w każdym statusie cyklu życia

Liczby te przekształcają tworzenie detekcji z opartego na anegdotach w zarządzany program.

Szybki test

Sprawdź swoją znajomość podstaw Detection-as-Code.

Podsumowanie

Detection-as-Code wnosi rygor inżynierii oprogramowania do procesu tworzenia detekcji:

  • Reguły są przechowywane jako wersjonowane pliki w Git
  • Zmiany przechodzą przegląd w pull requestach
  • CI automatycznie wykonuje linting, walidację i testy
  • Scalone reguły są wdrażane za pośrednictwem pipeline'u, dzięki czemu środowisko produkcyjne pozostaje zsynchronizowane z gałęzią main
  • Testy chronią przed fałszywymi alarmami i regresjami
  • Przenośność (Sigma + pipeline'y) pozwala kierować jedną regułę do wielu backendów
  • Metadane, cykl życia i metryki sprawiają, że detekcje stają się zarządzanym programem

Następnie napisze Pan/Pani przenośne reguły za pomocą Sigma.

Często zadawane pytania

Czy lekcja „Zasady Detection-as-Code” jest bezpłatna?

Tak — pełny tekst „Zasady Detection-as-Code” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Zasady Detection-as-Code”?

Traktowanie mechanizmów wykrywania jak oprogramowania Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Zasady Detection-as-Code”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Zasady Detection-as-Code
  2. Pisanie reguł Sigma
  3. Mapowanie na MITRE ATT&CK
  4. Testowanie i dostrajanie mechanizmów wykrywania
← Powrót do Cyber Security Academy