Ścieżka 05Lekcja 6 / 8

Powiąż dostarczanie oprogramowania z SOC i SIRT

Określ monitoring bezpieczeństwa, przekazanie incydentu, zabezpieczanie dowodów i odpowiedzialności za przywrócenie usługi. Połącz reakcję na incydenty z cyklem życia oprogramowania.

Zaawansowane12 minSprawdzono

Wydawca Jak piszemy

Czego się nauczysz

  • Odróżnij monitoring SOC od koordynacji incydentu przez SIRT.
  • Przygotuj użyteczne przekazanie incydentu bezpieczeństwa.
  • Powiąż ograniczenie skutków, przywrócenie usługi i prace naprawcze.

Określ funkcje kryjące się za nazwami

Centrum operacji bezpieczeństwa, czyli SOC, zwykle monitoruje sygnały bezpieczeństwa, analizuje alerty i eskaluje podejrzane incydenty. Zespół reagowania na incydenty bezpieczeństwa, czyli SIRT, koordynuje reakcję na takie incydenty. CSIRT to inna często używana nazwa tej funkcji.

Organizacje różnie dzielą te funkcje. Te same osoby mogą wykonywać obie. Zewnętrzny dostawca może zapewniać część usługi. Nie wnioskuj o zakresie ani uprawnieniach ze skrótu. Zapisz godziny monitoringu, ścieżki eskalacji, prawa decyzyjne i zobowiązania dotyczące reakcji.

Model CSIRT organizacji FIRST opisuje usługi, które może świadczyć zespół reagowania. NIST łączy reagowanie na incydenty z szerszym zarządzaniem ryzykiem cyberbezpieczeństwa. Użyj tych źródeł do określenia odpowiedzialności i punktów współpracy. Model FIRST, reagowanie na incydenty według NIST.

Uwzględnij wytwarzanie z AI w zakresie wykrywania

System dostarczania oprogramowania obejmuje tożsamości, repozytoria, runnery, rejestry, integracje i dane uwierzytelniające wdrożeń. Agenty dodają wywołania narzędzi i przepływy danych do dostawców modeli. Uwzględnij te granice w projekcie bezpieczeństwa.

Wybierz zdarzenia wspierające określone reguły wykrywania. Przykłady to nieoczekiwany dostęp do repozytorium, zmiana uprawnień, nietypowa publikacja artefaktów i wdrożenie przez niezatwierdzoną tożsamość. Powiąż zapisy przez znaczniki czasu, tożsamości wykonawców, identyfikatory zasobów i niezmienne skróty artefaktów, jeśli są dostępne.

Chroń te zapisy. Dostęp do audytu, retencja, jakość zegarów i błędy zbierania danych wpływają na analizę. Log wykonania zadania programistycznego i log audytowy chmury odpowiadają na różne pytania. Żaden nie jest automatycznie pełnym zapisem incydentu.

Przygotuj przekazanie przed incydentem

Pole przekazaniaWymagane informacje
ObserwacjaCo się wydarzyło, kiedy i w jakim systemie
PewnośćZweryfikowany fakt, hipoteza robocza lub nierozwiązane pytanie
ZasięgTożsamości, repozytoria, środowiska i potencjalnie dotknięte dane
DowodyChronione lokalizacje i szczegóły zebrania, bez ujawniania sekretów
DziałaniaCo się zmieniło, kto to zatwierdził i jaki był zaobserwowany wynik
DecyzjaWyznaczony właściciel reakcji, następne działanie i termin aktualizacji

Określ, kto może unieważnić token, odizolować runner, wstrzymać wdrożenie lub przywrócić usługę. Właściciele usług wyjaśniają konsekwencje operacyjne. Zespół bezpieczeństwa koordynuje analizę i ograniczanie skutków. Właściwe osoby odpowiedzialne za prywatność, prawo i biznes oceniają obowiązki zgłoszeniowe dla konkretnej sytuacji.

Wymagania zgłoszeniowe zależą od incydentu i mających zastosowanie obowiązków. Włącz właściwego decydenta wcześnie. Nie pozwól, aby podsumowanie AI podejmowało tę decyzję lub opóźniało ustaloną eskalację.

Przejdź przez fikcyjny incydent z tokenem

O 14:05 UTC SOC wykrywa odczyt nieoczekiwanego repozytorium przez tożsamość procesu budowania. O 14:08 właściciel repozytorium potwierdza, że żadne zatwierdzone zadanie nie wyjaśnia aktywności. Nadal nie wiadomo, czy kod źródłowy opuścił środowisko.

Zespół reagowania zabezpiecza zapisy audytowe i odpowiednie dowody z runnera. Uprawniony właściciel unieważnia dane uwierzytelniające i zatrzymuje podejrzaną ścieżkę wykonania. Działania są zgodne z procedurą organizacji i uwzględniają wpływ na usługę.

Usunięcie ujawnionego tokenu z pliku nie wystarczy. Dane uwierzytelniające mogą nadal działać gdzie indziej. Odtworzenie runnera również nie wystarczy, jeśli tożsamość pozostaje przejęta. Zbadaj opublikowane artefakty, dalszy dostęp i inne dane uwierzytelniające w wiarygodnym zakresie incydentu.

Przed wznowieniem dostarczania sprawdź tożsamość, runner, pochodzenie artefaktów i wymagane granice dostępu. Zapisz, co nadal pozostaje nieznane. Sam udany build nie dowodzi, że środowisko dostarczania jest godne zaufania.

Przekaż ustalenia z powrotem do zespołu inżynierskiego

Przekształć potwierdzone przyczyny w zadania z właścicielami: krótszy czas ważności danych uwierzytelniających, węższy dostęp, izolacja runnerów, zmiany wykrywania lub test regresji. Sprawdź poprawkę i ponownie przećwicz przekazanie.

Zapisy audytowe i rejestry dostarczania Taiga mogą dostarczać dowodów w udokumentowanym zakresie. Włącz je do procesu reagowania organizacji. Sprawdź granicę współdzielonej odpowiedzialności, zamiast zakładać, że uruchomienie Taiga przenosi odpowiedzialność za SOC lub SIRT. Audit log, współdzielona odpowiedzialność.

Wykonaj ćwiczenie

Dla fikcyjnego incydentu z tokenem przygotuj przekazanie: fakty, niepewności, dotknięte tożsamości, zabezpieczone dowody, możliwe ograniczenia skutków i decydenci. Nie podawaj wartości tokenu.

Pobierz arkusz (Markdown)

Sprawdź zrozumienie

SOC wykrywa nietypowe użycie tożsamości procesu budowania, ale zespół nie potrafi jeszcze potwierdzić dostępu do danych. Które przekazanie jest najbardziej przydatne?

Źródła i dalsza lektura

Powiązana lektura od Taiga