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.
Wydawca TaigaJak 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 przekazania | Wymagane informacje |
|---|---|
| Obserwacja | Co się wydarzyło, kiedy i w jakim systemie |
| Pewność | Zweryfikowany fakt, hipoteza robocza lub nierozwiązane pytanie |
| Zasięg | Tożsamości, repozytoria, środowiska i potencjalnie dotknięte dane |
| Dowody | Chronione lokalizacje i szczegóły zebrania, bez ujawniania sekretów |
| Działania | Co się zmieniło, kto to zatwierdził i jaki był zaobserwowany wynik |
| Decyzja | Wyznaczony 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
Źródła i dalsza lektura
- NIST: Incident Response Recommendations, SP 800-61 Rev. 3 ↗
- FIRST: CSIRT Services Framework ↗
- Taiga: Shared responsibility ↗
- Taiga docs: Audit log ↗
Powiązana lektura od Taiga
Odznaczenie tej opcji usuwa wszystkie postępy zapisane w tej przeglądarce.
Postępy pozostają w tej przeglądarce. Bez konta i śledzenia.