Udostępnij przez

Zabezpieczenia metodyki DevOps

Zabezpieczenia Metodyki DevOps integrują praktyki zabezpieczeń w całym cyklu życia tworzenia oprogramowania (SDLC) — od początkowego projektowania i kodowania za pośrednictwem kompilacji, testowania i wdrażania do środowiska produkcyjnego. W przeciwieństwie do tradycyjnych metod zabezpieczeń, które traktują zabezpieczenia jako ostateczną bramę, zabezpieczenia DevOps osadzają mechanizmy zabezpieczeń, zautomatyzowane testowanie i ciągłe monitorowanie na każdym etapie potoku programowania. Takie podejście uznaje, że nowoczesne dostarczanie oprogramowania opiera się na złożonych pipeline'ach CI/CD, zależnościach innych firm, infrastrukturze jako kod (Infrastructure as Code), i zautomatyzowanych wdrożeniach, z których każdy wprowadza potencjalne wektory ataków, które są aktywnie wykorzystywane przez przeciwników. Stosując zasady Zero Trust (zakładaj naruszenie, wyraźna weryfikacja) i wielowarstwowe mechanizmy obronne, zabezpieczenia DevOps zapewniają, że kod, zależności, konfiguracje infrastruktury i procesy potoków pozostają wiarygodne i odporne na naruszenia od etapu projektowania do środowiska produkcyjnego. Bez kompleksowego zabezpieczeń metodyki DevOps organizacje napotykają krytyczne zagrożenia, w tym ataki łańcucha dostaw, narażenie na poświadczenia w potokach, złośliwe wstrzyknięcie kodu, wrażliwe obrazy kontenerów i nieautoryzowane zmiany infrastruktury, które mogą ustanowić trwałe backdoory wpływające na wszystkich odbiorców podrzędnych.

Poniżej przedstawiono trzy podstawowe filary domeny zabezpieczeń usługi DevOps Security.

Zabezpiecz projekt i łańcuch dostaw: Przeprowadzaj wczesne modelowanie zagrożeń w sposób strukturalny. Chroń łańcuch dostaw za pomocą skanowania zależności i licencji, zarządzania lukami w zabezpieczeniach i generowania SBOM. Sprawdź pochodzenie i integralność wszystkich składników.

Powiązane kontrolki:

Przesuń w lewo kontrolki zabezpieczeń: Przesuń w lewo kontrolki zabezpieczeń, integrując SAST, skanowanie sekretów, skanowanie IaC i DAST do potoku ciągłej integracji/ciągłego wdrażania. Scentralizowane zarządzanie tajemnicami (np. usługa Key Vault), ograniczanie uprawnień do zmiany wdrożeń oraz ciągłe skanowanie i zabezpieczanie artefaktów (takich jak obrazy kontenerów i maszyn wirtualnych) przed wdrożeniem.

Powiązane kontrolki:

Monitorowanie i przeprowadzanie inspekcji działań metodyki DevOps: Zbieranie i przekazywanie dzienników inspekcji i zabezpieczeń metodyki DevOps do centralnej platformy analitycznej na potrzeby korelacji i odpowiedzi. Wykrywanie nieautoryzowanych zmian potoku, eskalacji uprawnień, nietypowych zatwierdzeń i wykonywania poza godzinami pracy.

Powiązane kontrolki:

DS-1: Przeprowadzanie modelowania zagrożeń

Zasada zabezpieczeń

Zaimplementuj systematyczne modelowanie zagrożeń przy użyciu metodologii STRIDE w fazie projektowania, aby zidentyfikować potencjalne zagrożenia bezpieczeństwa, ustalić priorytety zagrożeń i wdrożyć odpowiednie środki zaradcze przed rozpoczęciem opracowywania kodu. To podejście shift-left zmniejsza koszty korygowania i poprawia ogólny poziom zabezpieczeń.

Ryzyko w celu ograniczenia ryzyka

Organizacje, które nie przeprowadzają modelowania zagrożeń w fazie projektowania, działają z krytycznymi lukami, które systematycznie wykorzystują przeciwnicy. Bez systematycznej analizy zagrożeń:

  • Późne wady architektoniczne: Luki w zabezpieczeniach projektowych osadzonych wymagają kosztownej refaktoryzacji w środowisku produkcyjnym, a koszty korygowania znacznie wyższe niż rozwiązywanie problemów w fazie projektowania.
  • Niezidentyfikowane powierzchnie ataków: Wektory zagrożeń, takie jak niezabezpieczone granice zaufania, brakujące wymagania dotyczące uwierzytelniania lub nieodpowiednie zabezpieczenia przepływu danych, pozostają nieudokumentowane, dzięki czemu osoby atakujące mogą wykorzystać znane słabości, których obrońcy nie rozpoznają.
  • Niewystarczające mechanizmy kontroli zabezpieczeń: Brakujące lub nieodpowiednie mechanizmy kontroli zabezpieczeń (szyfrowanie, uwierzytelnianie, autoryzacja, rejestrowanie inspekcji) wynikają z niekompletnej analizy zagrożeń, co powoduje tworzenie luk w zabezpieczeniach w strategii dogłębnej ochrony.
  • Ślepe punkty zgodności: Wymagania prawne (PCI-DSS, HIPAA, SOX) nakazujące bezpieczną weryfikację projektu nie mogą być spełnione bez udokumentowanych modeli zagrożeń i dowodów zaradczych.
  • Akumulacja długu zabezpieczającego: Ciągłe dodatki funkcji bez modelowania zagrożeń tworzą złożone długi techniczne zabezpieczeń, co sprawia, że systemy stopniowo bardziej narażone i trudne do zabezpieczenia wstecznie.

Brak modelowania zagrożeń zwiększa prawdopodobieństwo naruszenia, wydłuża czas wykrycia i prowadzi do znacznie wyższych kosztów naprawy w porównaniu z przeciwdziałaniami na wczesnym etapie projektowania.

MITRE ATT&CK

  • Dostęp początkowy (TA0001): wykorzystanie aplikacji publicznej (T1190) wykorzystującej wady architektury w zakresie uwierzytelniania, zarządzania sesjami lub weryfikacji danych wejściowych, które mogłyby zidentyfikować modelowanie zagrożeń.
  • Eskalacja uprawnień (TA0004): nadużycie mechanizmu kontroli podniesienia uprawnień (T1548) wykorzystującego niewystarczającą separację uprawnień lub brakujące kontrole autoryzacji w architekturze systemu.
  • Uchylanie się od obrony (TA0005): osłabianie obrony (T1562) wykorzystujące brakujące rejestrowanie inspekcji, monitorowanie luk lub niewystarczającą telemetrię zabezpieczeń zaprojektowaną w systemie.

DS-1.1: Implementowanie modelowania zagrożeń opartych na metodzie STRIDE

Systematyczne modelowanie zagrożeń w fazie projektowania stanowi podstawę bezpiecznej architektury oprogramowania, identyfikując luki w zabezpieczeniach przed rozpoczęciem opracowywania. Rozwiązywanie problemów z zabezpieczeniami na etapie projektowania znacznie zmniejsza koszty korygowania i zapobiega osadzaniu błędów architektury w systemach produkcyjnych. Wczesna identyfikacja zagrożeń zapewnia, że mechanizmy kontroli zabezpieczeń są wbudowane w architekturę, a nie później zmodernizowane.

Zaimplementuj następujące podejście ustrukturyzowane w celu ustanowienia modelowania zagrożeń:

  • Ustanów systematyczną metodologię STRIDE: Ustanów systematyczne modelowanie zagrożeń jako obowiązkowe działanie fazy projektowania przy użyciu metodologii STRIDE (fałszowanie, manipulowanie, odrzucanie, ujawnianie informacji, odmowa usługi, podniesienie uprawnień). Zacznij od utworzenia diagramów przepływu danych (DFD), które mapuje składniki systemu, przepływy danych, granice zaufania i zależności zewnętrzne. Dla każdego składnika i przepływu danych systematycznie oceniaj potencjalne zagrożenia we wszystkich sześciu kategoriach STRIDE, ustalaj priorytety ryzyka na podstawie prawdopodobieństwa i wpływu oraz dokumentuj konkretne środki zaradcze przed rozpoczęciem opracowywania.

  • Użyj narzędzi do modelowania zagrożeń strukturalnych: Użyj narzędzi do modelowania zagrożeń strukturalnych, takich jak narzędzie Microsoft Threat Modeling Tool , aby zachować spójność i korzystać ze wstępnie utworzonych szablonów dla typowych wzorców architektury (aplikacji internetowych, interfejsów API, mikrousług, rozwiązań IoT). Narzędzie ułatwia tworzenie systemu plików DFD, automatyczną identyfikację zagrożeń na podstawie typów składników i przepływów danych oraz generuje zalecenia dotyczące ograniczania ryzyka z skojarzonymi mechanizmami kontroli zabezpieczeń. Przechowuj modele zagrożeń jako wersjonowane artefakty w systemie kontroli wersji wraz z dokumentacją architektury.

  • Integrowanie z przepływami pracy programowania: Integrowanie danych wyjściowych modelowania zagrożeń bezpośrednio z przepływami pracy programowania przez wyeksportowanie zidentyfikowanych zagrożeń do elementów roboczych usługi Azure DevOps z jasnymi kryteriami własności, priorytetu i akceptacji. Zaimplementuj bramy przeglądu architektury, które wymagają ukończonych modeli zagrożeń przed zatwierdzeniem projektu, i ustanów sprawdzanie żądań ściągnięcia, które wyzwalają przeglądy modelu zagrożeń po wykryciu zmian architektury. Dzięki temu analiza zagrożeń pozostaje zsynchronizowana z ewolucją systemu w całym cyklu projektowania.

DS-1.2: Automatyzowanie integracji analizy zagrożeń

Skalowanie modelowania zagrożeń w dużych organizacjach wymaga automatyzacji i możliwości rozproszonej, aby zapobiec powstawaniu wąskich gardeł w zakresie opracowywania przeglądów zabezpieczeń. Zautomatyzowane przepływy pracy identyfikacji zagrożeń osadzone w procesach inicjowania projektu i żądań ściągnięcia zapewniają spójną analizę zabezpieczeń bez ręcznej interwencji dla każdego projektu. Budowanie wiedzy na temat zabezpieczeń w zespołach programistycznych za pomocą programów umożliwiających tworzenie zrównoważonych, skalowalnych praktyk modelowania zagrożeń.

Zaimplementuj następujące możliwości automatyzacji i włączania:

  • Skalowanie za pomocą automatyzacji i włączania: Skalowanie modelowania zagrożeń w całej organizacji za pomocą automatyzacji i włączania. Osadź kwestionariusze zabezpieczeń w szablonach inicjowania projektu, które automatycznie oceniają poziom ryzyka, określają wymagania dotyczące modelowania zagrożeń i przypisują odpowiednie punkty kontrolne przeglądu zabezpieczeń na podstawie klasyfikacji danych, ekspozycji zewnętrznej i zakresu regulacyjnego. Zautomatyzuj wyzwalacze przeglądu architektury w przepływach pracy żądań ściągnięcia, które wykrywają zmiany w granicach systemu, przepływach uwierzytelniania lub logice obsługi danych, kierując takie zmiany do architektów zabezpieczeń w celu weryfikacji modelu zagrożeń.

  • Twórz możliwości rozproszone za pomocą mistrzów zabezpieczeń: Ustanów program Security Champions w celu utworzenia możliwości modelowania zagrożeń rozproszonych w zespołach programistycznych. Trenowanie mistrzów metodologii STRIDE, udostępnianie im narzędzi i szablonów modelowania zagrożeń oraz umożliwienie im ułatwiania sesji modelowania zagrożeń dla swoich zespołów. Specjaliści ds. bezpieczeństwa służą jako pierwsza linia przeglądu, eskalując złożone scenariusze do scentralizowanych zespołów zabezpieczeń, umożliwiając jednocześnie modelowanie większości zagrożeń bez wąskich gardeł.

Implementacja zautomatyzowanej analizy zagrożeń:

  • Ocena oparta na kwestionariuszu: Standardowe kwestionariusze zabezpieczeń zintegrowane z szablonami usługi Azure DevOps na potrzeby spójnej identyfikacji zagrożeń
  • Program mistrzów zabezpieczeń: Wyznaczeni mistrzowie zabezpieczeń w każdym zespole deweloperów szkolili się w zakresie modelowania zagrożeń
  • Automatyzacja przeglądu architektury: Zautomatyzowane sprawdzanie pull requestów dla aktualizacji diagramu architektury wymagających analizy modelu zagrożeń
  • Model zagrożeń jako kod: Definicje modelu zagrożeń kontrolowane przez wersję przy użyciu formatów strukturalnych (JSON/YAML) umożliwiające automatyczną analizę

Przykład implementacji

Organizacja usług finansowych doznała naruszenia danych, gdy atakujący wykorzystali wadę autoryzacji w interfejsie API płatności, który nigdy nie został zidentyfikowany podczas opracowywania, co spowodowało znaczne oszustwa transakcji i grzywny regulacyjne.

Wyzwanie: Architektura mikrousług z wieloma interfejsami API wdrożonych bez przeglądu zabezpieczeń. Zespoły programistyczne nie mają wiedzy na temat zabezpieczeń w celu identyfikowania zagrożeń. Problemy z zabezpieczeniami architektury wykryte dopiero po zdarzeniach produkcyjnych.

Podejście do rozwiązania:

  • Modelowanie zagrożeń STRIDE: Zaimplementowano narzędzie microsoft Threat Modeling Tool dla wszystkich mikrousług i punktów końcowych interfejsu API z diagramami przepływu danych przedstawiającymi architekturę i przepływy danych poufnych.
  • Program mistrzów zabezpieczeń: Wyszkoleni facylitatorzy modelowania zagrożeń w każdym zespole deweloperskim, co umożliwia projektowanie zabezpieczeń bez tworzenia wąskiego gardła dla centralnego zespołu ds. bezpieczeństwa.
  • Automatyczna integracja przepływu pracy: Zintegrowano przeglądy modeli zagrożeń w przepływach pracy żądań ściągnięcia Azure DevOps, które wymagają zatwierdzenia zabezpieczeń przy zmianach architektury.

Wynik: Zidentyfikowano liczne problemy z zabezpieczeniami przed wdrożeniem uniemożliwiające potencjalne naruszenia. Znacznie zmniejszono luki w zabezpieczeniach w środowisku produkcyjnym. Przeglądy zabezpieczeń dodawały minimalny czas do cyklu rozwoju.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS 4: 6.3.1, 6.3.2, 12.3.1
  • Kontrolki CIS w wersji 8.1: 14.2, 14.3
  • NIST CSF v2.0: ID.RA-3, PR.IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: Zabezpieczanie łańcucha dostaw oprogramowania

Zasada zabezpieczeń

Zaimplementuj zerowe zaufanie dla zależności, sprawdzając pochodzenie, integralność i stan zabezpieczeń wszystkich składników innych firm przed integracją. Ciągłe skanowanie zależności pod kątem luk w zabezpieczeniach, utrzymywanie kompleksowego rachunku oprogramowania za materiały (SBOM) i wymuszanie automatycznych aktualizacji zabezpieczeń w celu zminimalizowania obszaru ataków łańcucha dostaw.

Ryzyko w celu ograniczenia ryzyka

Ataki łańcucha dostaw oprogramowania stanowią krytyczne zagrożenia, ponieważ przeciwnicy wykorzystują relacje zaufania między organizacjami i składnikami innych firm w celu osiągnięcia powszechnego wpływu przy minimalnym nakładzie pracy. Bez kompleksowego bezpieczeństwa łańcucha dostaw:

  • Złośliwe zależności: Przeciwnicy wstrzykują tylne drzwi do popularnych bibliotek typu open source (ataki typu SolarWinds) lub tworzą pakiety z błędami typograficznymi, które wykonują złośliwy kod podczas instalacji lub w trakcie działania.
  • Wrażliwe biblioteki innych firm: Znane CVE w zależnościach (Log4Shell, Heartbleed, luki w Struts) pozostają niezałatane przez tygodnie lub miesiące z powodu braku widoczności i zautomatyzowanego zarządzania lukami w zabezpieczeniach.
  • Naruszone artefakty kompilacji: Osoby atakujące modyfikują skompilowane pliki binarne, obrazy kontenerów lub pakiety wdrożeniowe podczas przechowywania lub przesyłania, iniekując złośliwe oprogramowanie, które pomija przegląd kodu źródłowego.
  • Ataki pomyłek zależności: Złośliwi aktorzy przekazują pakiety do publicznych repozytoriów o nazwach pasujących do wewnętrznych pakietów prywatnych, wykorzystując logikę rozpoznawania menedżera pakietów w celu zastąpienia złośliwego kodu.
  • Ryzyko zależności przechodnich: Luki w zabezpieczeniach w pośrednich zależnościach (zależności zależności) mogą pozostać niewidoczne bez przeprowadzenia głębokiej analizy drzewa zależności i generowania SBOM.
  • Brak weryfikacji pochodzenia: Brak weryfikacji kryptograficznej umożliwia ataki polegające na zamianie legalnych pakietów na złośliwe wersje.

Kompromitacja łańcucha dostaw umożliwia szeroki wpływ, trwałe tylne furtki w zaufanych bibliotekach oraz wysoką skuteczność unikania wykrycia dzięki wiarygodnemu wyglądowi.

MITRE ATT&CK

  • Dostęp początkowy (TA0001): kompromitacja łańcucha dostaw (T1195.001) poprzez naruszenie zabezpieczeń zależności oprogramowania i narzędzi programistycznych, aby uzyskać początkowy przyczółek w środowiskach docelowych, oraz zaufane relacje (T1199) wykorzystując zaufanie między organizacjami a dostawcami oprogramowania innych firm w celu dostarczania złośliwych aktualizacji.
  • Wykonanie (TA0002): interpreter poleceń i skryptów (T1059) wykonujący złośliwy kod osadzony w skryptach instalacji zależności lub punktach zaczepienia po instalacji.
  • Trwałość (TA0003): kompromitacja plików binarnych oprogramowania klienckiego (T1554) poprzez osadzanie backdoorów w skompilowanych bibliotekach, które utrzymują się w aplikacjach po aktualizacjach.

DS-2.1: Implementowanie skanowania zależności i zarządzania nimi

Kompleksowe zarządzanie zabezpieczeniami zależności zapobiega atakom łańcucha dostaw dzięki zachowaniu wglądu we wszystkie składniki innych firm, ciągłego monitorowania luk w zabezpieczeniach i automatyzowania procesów korygowania. Nowoczesne aplikacje opierają się na setkach lub tysiącach zależności (bezpośrednich i przejściowych), dzięki czemu ręczne oceny zabezpieczeń są niemożliwe i tworzą rozległą powierzchnię ataków za pośrednictwem bibliotek podatnych na zagrożenia. Automatyczne skanowanie zależności przy użyciu ciągłego monitorowania zapewnia organizacjom wykrywanie i korygowanie luk w zabezpieczeniach przed wykorzystaniem.

Ustanów ciągłe zabezpieczenia zależności za pomocą tych podstawowych możliwości:

  • Ustanów kompleksową widoczność i generowanie SBOM: Ustanów ciągłe zarządzanie bezpieczeństwem zależności, z trzema kluczowymi funkcjonalnościami: kompleksową widocznością, automatycznym wykrywaniem luk w zabezpieczeniach oraz proaktywnym usuwaniem zagrożeń. Zacznij od wygenerowania pełnych spisów zależności, które mapują zarówno bezpośrednie zależności (jawnie zadeklarowane w manifestach pakietów) i zależności przechodnie (zależności zależności) we wszystkich repozytoriach. Obsługa oprogramowania Bill of Materials (SBOM) w formatach branżowych (SPDX, CycloneDX) w celu zapewnienia zgodności z przepisami i gotowości reagowania na zdarzenia.

  • Zaimplementuj automatyczne skanowanie luk w zabezpieczeniach i korygowanie: Zaimplementuj automatyczne skanowanie luk w zabezpieczeniach, które stale monitoruje zależności względem krajowej bazy danych luk w zabezpieczeniach (NVD), bazy danych doradczych usługi GitHub i porad dotyczących zabezpieczeń specyficznych dla języka. Skonfiguruj alerty w czasie rzeczywistym, gdy nowe CVE są ujawniane wpływające na stos zależności, przy użyciu routingu opartego na ważności dla odpowiednich zespołów. Włącz automatyczne funkcje aktualizacji zabezpieczeń, które generują żądania pull z aktualizacjami wersji zależności, obejmując testowanie zgodności i inteligentne rozwiązywanie konfliktów scalania, aby zmniejszyć obciążenie ręcznego korygowania.

  • Integrowanie walidacji zabezpieczeń z przepływami pracy programowania: Integrowanie weryfikacji zabezpieczeń zależności bezpośrednio z przepływami pracy programowania za pomocą przeglądów żądań ściągnięcia, które automatycznie oceniają wpływ zmian zależności flagujących nowe zależności ze znanymi lukami w zabezpieczeniach, problemami ze zgodnością licencji lub podejrzanymi cechami (literówki, brak reputacji osoby odpowiedzialnej za utrzymanie). Ustanów punkty zatwierdzania dla zmian zależności wysokiego ryzyka i wymuś zasady zabraniające scalania zależności z krytycznymi lukami w zabezpieczeniach z chronionymi gałęziami.

  • Rozszerzanie widoczności do środowisk produkcyjnych: Rozszerzanie widoczności poza kod źródłowy do wdrożonych środowisk przy użyciu narzędzi takich jak Microsoft Defender for Cloud DevOps Security w celu skorelowania zależności kodu z uruchomionymi obciążeniami, identyfikowania ścieżek ataków za pośrednictwem łańcuchów zależności i określania priorytetów korygowania na podstawie rzeczywistej ekspozycji produkcyjnej, a nie samego ryzyka teoretycznego. Narzędzia takie jak GitHub Advanced Security zapewniają kompleksową wizualizację grafów zależności, automatyczne aktualizacje oparte na narzędziu Dependabot oraz obsługę niestandardowych wzorców luk w zabezpieczeniach dla zastrzeżonych ekosystemów pakietów.

Przykład implementacji

Organizacja opieki zdrowotnej wykryła złośliwy pakiet npm w aplikacji produkcyjnej, która od miesięcy eksfiltrowała dane pacjentów. Badanie wykazało obszerne zależności podatne na zagrożenia ze znanymi CVE, w tym lukę krytyczną Log4Shell.

Wyzwanie: Tysiące zależności w setkach repozytoriów bez wglądu w luki w zabezpieczeniach ani złośliwych pakietów. Ręczne przeglądy zależności zajmowały tygodnie dla każdej aplikacji. Audyt regulacyjny zidentyfikował krytyczne luki w łańcuchu dostaw.

Podejście do rozwiązania:

  • Automatyczne zarządzanie lukami w zabezpieczeniach: Włączono usługę GitHub Advanced Security z Dependabotem skanującym zależności i automatycznie tworzącym żądania ściągnięcia na potrzeby aktualizacji zabezpieczeń.
  • Przejrzystość łańcucha dostaw: Zaimplementowano narzędzie SBOM firmy Microsoft generujące zestawienie materiałów w formacie SPDX w celu zapewnienia zgodności z przepisami i reagowania na zdarzenia.
  • Weryfikacja pakietu: Skonfigurowano usługę Azure Artifacts z weryfikacją podpisu i przypięciem zależności uniemożliwiającym ataki pomyłek i nieautoryzowanym zastępowaniem pakietów.
  • Monitorowanie zabezpieczeń metodyki DevOps: Wdrożono usługę Microsoft Defender for Cloud DevOps Security na potrzeby śledzenia kodu do chmury.

Wynik: Wykryto i szybko skorygowano rozległe zależności podatne na zagrożenia. Zapobieżono wielu incydentom złośliwych pakietów za pośrednictwem automatycznej weryfikacji. Osiągnięto zgodność z przepisami za pomocą kompleksowej dokumentacji SBOM.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS 4: 6.2.4, 6.3.2, 6.3.3
  • Kontrole CIS w wersji 8.1: 16.1, 16.2, 16.11
  • NIST CSF v2.0: ID.SC-2, ID.SC-4, DE.CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: Zabezpieczanie infrastruktury DevOps

Zasada zabezpieczeń

Zaimplementuj wielowarstwową ochronę dla infrastruktury kompilacji poprzez kompleksowe zarządzanie sekretami, kontrolę dostępu do pipeline'ów z bramkami zatwierdzania, bezpieczną konfigurację agenta kompilacji oraz ciągłe monitorowanie. Wyeliminuj zakodowane na stałe poświadczenia i wymuś dostęp z najmniejszymi uprawnieniami, aby chronić integralność procesu tworzenia i wdrażania oprogramowania.

Ryzyko w celu ograniczenia ryzyka

Niezabezpieczona infrastruktura DevOps tworzy krytyczne luki w zabezpieczeniach, które są wykorzystywane przez przeciwników w celu naruszenia całego łańcucha dostarczania oprogramowania. Bez kompleksowych zabezpieczeń infrastruktury:

  • Naruszone potoki CI/CD: Osoby atakujące uzyskują dostęp do potoków kompilacji za pośrednictwem skradzionych poświadczeń, wykorzystywania luk w zabezpieczeniach lub dostępu niejawnego, umożliwiając iniekcję kodu, manipulowanie artefaktami lub wdrożeniami, co wpływa na wszystkich odbiorców końcowych.
  • Uwidocznione wpisy tajne w dziennikach kompilacji i artefaktach: Na sztywno zapisane poświadczenia, klucze API, certyfikaty i parametry połączenia wyciekają przez logi potoków, komunikaty o błędach lub skompilowane artefakty, zapewniając atakującym bezpośredni dostęp do środowisk produkcyjnych.
  • Nieautoryzowane modyfikacje potoku: Brak kontroli zmian i przepływów pracy zatwierdzania umożliwia złośliwym użytkownikom modyfikowanie definicji potoków, wprowadzanie złośliwych kroków kompilacji lub zmienianie konfiguracji wdrożenia bez wykrycia.
  • Niewystarczające mechanizmy kontroli dostępu: Nadmiernie permissywne przypisania ról i brak rozdzielenia obowiązków umożliwiają przenoszenie boczne, eskalację uprawnień i trwały establishment dostępu w infrastrukturze DevOps.
  • Niezabezpieczeni agenci kompilacji: Niezałatane, nieprawidłowo skonfigurowane lub skompromitowane agenci budowy zapewniają atakującym trwały dostęp do środowiska kompilacji oraz potencjalne punkty zaczepienia w sieciach produkcyjnych.
  • Brakujące dzienniki inspekcji: Nieodpowiednie rejestrowanie i monitorowanie działań metodyki DevOps uniemożliwia wykrywanie nieautoryzowanego dostępu, podejrzanych modyfikacji lub zagrożeń wewnętrznych.

Naruszenie infrastruktury umożliwia osobom atakującym wprowadzanie kodu w źródle, pomijanie zaufanych potoków i wpływanie na każdą aplikację podrzędną.

MITRE ATT&CK

  • Dostęp początkowy (TA0001): prawidłowe konta (T1078) uzyskane przy użyciu skradzionych poświadczeń lub sekretów jednostki usługi do uzyskania dostępu do platform i potoków DevOps.
  • Trwałość (TA0003): manipulowanie kontami (T1098) tworzenie jednostek usługi backdoor, osobistych tokenów dostępu lub kluczy SSH w celu utrzymania dostępu.
  • Dostęp poświadczeń (TA0006): niezabezpieczone poświadczenia (T1552.001) zbierające wpisy tajne z dzienników potoku, zmiennych środowiskowych lub plików konfiguracji.
  • Uchylanie się od obrony (TA0005): osłabianie zabezpieczeń (T1562) poprzez wyłączanie kroków skanowania zabezpieczeń, rejestrowanie audytu lub bramy zatwierdzania w definicjach potoku.

DS-3.1: Implementowanie zarządzania sekretami dla pipeline'ów

Scentralizowane zarządzanie tajnymi danymi eliminuje ekspozycję poświadczeń w potokach DevOps przez usunięcie umieszczonych na stałe tajnych danych z kodu, plików konfiguracji i definicji potoku. Poświadczenia osadzone w potokach YAML, zmiennych środowiskowych lub repozytoriach stanowią główny wektor ataku prowadzący do kompromitacji potoku, umożliwiając atakującym, którzy uzyskają dostęp do repozytoriów lub dzienników, wyodrębnienie poświadczeń produkcyjnych. Implementowanie kryptograficznie chronionego przechowywania tajnych danych z dynamicznym pobieraniem i wzorcami dostępu just-in-time zapobiega kradzieży poświadczeń przy zachowaniu wydajności operacyjnej.

Skonfiguruj zarządzanie sekretami za pomocą następujących mechanizmów kontroli zabezpieczeń.

  • Wyeliminuj wbudowane na stałe poświadczenia za pomocą scentralizowanego magazynu: Wyeliminowanie wbudowanych na stałe poświadczeń z definicji pipeline’u i kodu źródłowego przez scentralizowanie wszystkich sekretów w dedykowanej infrastrukturze zarządzania tajemnicami przy użyciu mechanizmów kontroli dostępu kryptograficznego i kompleksowych dzienników audytowych. Ustal zasadę, że sekrety nigdy nie mogą być przechowywane w plikach YAML potoków, zmiennych środowiskowych widocznych w logach ani w plikach konfiguracyjnych w repozytoriach — są głównymi wektorami ujawnienia poświadczeń w środowiskach DevOps.

  • Konfigurowanie dynamicznego pobierania wpisów tajnych przy użyciu tożsamości zarządzanych: Zaimplementuj scentralizowany magazyn wpisów tajnych przy użyciu rozwiązań, takich jak usługa Azure Key Vault , która zapewnia zaszyfrowany magazyn wpisów tajnych, szczegółowe zasady dostępu, automatyczne rotację wpisów tajnych i kompleksowe rejestrowanie inspekcji. Skonfiguruj potoki, aby dynamicznie pobierać tajne dane w czasie wykonywania poprzez bezpieczne połączenia usług zamiast osadzania ich w definicjach potoków. Użyj tożsamości zarządzanych (managed identities) lub federacji tożsamości obciążenia (workload identity federation), aby uwierzytelnić dostęp potoku do magazynów tajemnic, eliminując potrzebę trwałych poświadczeń głównych usługi, które same stają się celem kradzieży.

  • Wymuszaj dostęp just-in-time z bramami zatwierdzania: Stosuj wzorce dostępu do tajnych danych typu just-in-time, w których tajne dane są pobierane tylko wtedy, gdy są potrzebne, a ich dostęp jest automatycznie odwoływany po zakończeniu przetwarzania potoku, aby zminimalizować czas narażenia poświadczeń. Zaimplementuj ograniczenia dostępu oparte na czasie i wymagaj autoryzacji wielu osób (bram zatwierdzania) do uzyskania dostępu potoku do tajemnic produkcyjnych, aby zapewnić, że żadne jedno skompromitowane konto nie będzie mogło uzyskać dostępu do poufnych poświadczeń bez dodatkowej weryfikacji.

  • Ustanów warstwowe mechanizmy kontroli dostępu do infrastruktury: Ustanów warstwowe mechanizmy kontroli dostępu dla infrastruktury DevOps: ogranicz prawa do modyfikacji potoków dla personelu zatwierdzonego przez dział bezpieczeństwa, wymuszaj uprawnienia specyficzne dla środowiska wymagające zatwierdzenia wdrożeń produkcyjnych, zaimplementuj ograniczenia na poziomie repozytorium dla połączeń usługowych zapobiegające bezpośredniemu dostępowi potoków do tajnych danych poza ich zamierzonym zakresem i wdroż zabezpieczone, samodzielnie hostowane agentów kompilacji z izolacją sieciową dla poufnych obciążeń. Zintegruj skanowanie zabezpieczeń infrastruktury jako kod (IaC) w potokach w celu zapobiegania wdrażaniu nieprawidłowo skonfigurowanych zasobów, które mogą ujawniać tajne dane lub tworzyć nieautoryzowane ścieżki dostępu.

Przykład implementacji

Organizacja zajmująca się handlem detalicznym padła ofiarą naruszenia, gdy atakujący użyli skradzionych poświadczeń zasadniczej usługi znalezionych w logach potokowych, narażając na ujawnienie miliony rekordów klientów.

Wyzwanie: Parametry połączenia bazy danych i klucze interfejsu API zakodowane na stałe w zmiennych potoku. Nadmiernie swobodne uprawnienia pipeline’u pozwoliły dowolnemu deweloperowi na wdrożenie do środowiska produkcyjnego. Naruszenie zabezpieczeń agenta kompilacji zapewnia trwały dostęp do infrastruktury.

Podejście do rozwiązania:

  • Scentralizowane zarządzanie tajemnicami: Zaimplementowano integrację z Azure Key Vault, eliminując twardo zakodowane tajemnice z pipeline'ów. Skonfigurowano uwierzytelnianie przy użyciu tożsamości zarządzanej, co eliminuje ryzyko ujawnienia poświadczeń.
  • Mechanizmy kontroli dostępu do potoku: Ustanowiono bramy zatwierdzania i uprawnienia specyficzne dla środowiska przy użyciu środowisk Usługi Azure DevOps wymagających zatwierdzenia przez zespół ds. zabezpieczeń dla wdrożeń produkcyjnych.
  • Agenci kompilacji ze wzmocnionymi zabezpieczeniami: Wdrożono własnych agentów ze wzmocnionymi zabezpieczeniami i izolacją sieci na potrzeby wrażliwych obciążeń przetwarzających dane regulowane.
  • Skanowanie zabezpieczeń infrastruktury: Zintegrowana walidacja zabezpieczeń dla szablonów ARM i konfiguracji Terraform zapobiegająca wdrażaniu błędnych konfiguracji.

Wynik: Wyeliminowano dane tajne z dzienników potoków, co uniemożliwia kradzież poświadczeń. Wyeliminowano nieautoryzowane wdrożenia produkcyjne. Wykryto i zablokowano błędy konfiguracji infrastruktury przed wdrożeniem.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS 4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • Kontrolki CIS w wersji 8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF v2.0: PR.AC-4, PR.DS-5, DE.CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Integrowanie statycznych testów zabezpieczeń aplikacji (SAST)

Zasada zabezpieczeń

Zaimplementuj kompleksowe zautomatyzowane testowanie zabezpieczeń za pomocą wielu wyspecjalizowanych skanerów statycznych testów zabezpieczeń aplikacji (SAST) zintegrowanych z każdym procesem kompilacji. Zastosuj pokrycie wielu skanerów w celu kompleksowego wykrywania, przeprowadź skanowanie tajnych wpisów z zabezpieczeniem przed wypychaniem i wdroż analizę kodu semantycznego w celu identyfikacji i blokowania luk w zabezpieczeniach, zanim dotrą do produkcji.

Ryzyko w celu ograniczenia ryzyka

Luki w zabezpieczeniach na poziomie kodu, które umykają wykryciu podczas opracowywania, tworzą trwałe słabości, które systematycznie wykorzystują przeciwnicy. Bez kompleksowej integracji SAST:

  • Luki w zabezpieczeniach polegających na wstrzyknięciu: Wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami (XSS), wstrzyknięcie poleceń i wady iniekcji LDAP umożliwiają osobom atakującym manipulowanie logiką aplikacji, wyodrębnianie poufnych danych lub wykonywanie dowolnego kodu.
  • Zakodowane na stałe poświadczenia: Deweloperzy przypadkowo zatwierdzają hasła, klucze interfejsu API, certyfikaty i parametry połączenia z repozytoriami kodu źródłowego, zapewniając osobom atakującym bezpośredni dostęp do systemów produkcyjnych i danych.
  • Niezabezpieczone implementacje kryptograficzne: Słabe algorytmy szyfrowania (DES, MD5), zakodowane na stałe klucze szyfrowania, nieprawidłowe wektory inicjowania lub niewystarczająca długość klucza narusza poufność i integralność danych.
  • Przepełnienie buforu i uszkodzenie pamięci: Niebezpieczne operacje pamięci w aplikacjach C/C++ umożliwiają dowolne wykonywanie kodu, eskalację uprawnień i ataki typu "odmowa usługi".
  • Wady logiki biznesowej: Pomijanie uwierzytelniania, luki autoryzacji, warunki współzawodnictwa i niewystarczająca weryfikacja danych wejściowych umożliwiają eskalację przywilejów, oszustwa i nieautoryzowany dostęp.
  • Błędy konfiguracji infrastruktury jako kodu (IaC): Niezabezpieczone narzędzia Terraform, szablony usługi ARM lub manifesty platformy Kubernetes wdrażają infrastrukturę podatną na zagrożenia z nadmiernym dostępem, brakiem szyfrowania lub uwidocznionymi punktami końcowymi zarządzania.

W braku zautomatyzowanego SAST, luki w zabezpieczeniach gromadzą się jako dług techniczny, wydłużają czas zalegania i stają się kosztowne do usunięcia w produkcji.

MITRE ATT&CK

  • Dostęp początkowy (TA0001): wykorzystanie aplikacji dostępnej publicznie (T1190) poprzez luki w zabezpieczeniach iniekcji lub obejścia uwierzytelniania w kodzie aplikacji.
  • Wykonanie (TA0002): wykorzystanie do wykonania po stronie klienta (T1203) poprzez luki w zabezpieczeniach po stronie klienta, takie jak XSS lub niezabezpieczona deserializacja.
  • Dostęp poświadczeń (TA0006): poświadczenia z magazynów haseł (T1555) wyodrębniające zakodowane na stałe poświadczenia z kodu źródłowego, plików konfiguracji lub skompilowanych plików binarnych.
  • Eskalacja uprawnień (TA0004): wykorzystanie eskalacji uprawnień (T1068) wykorzystujące przepełnienie buforu lub uszkodzenie pamięci w celu uzyskania podwyższonego poziomu dostępu.

DS-4.1: Implementacja potoku SAST wieloskanerowego

Kompleksowe testowanie zabezpieczeń aplikacji statycznych zintegrowane z każdą kompilacją zapewnia wczesne wykrywanie luk w zabezpieczeniach na poziomie kodu przed dotarciem do środowisk produkcyjnych. Nowoczesne aplikacje używają różnych języków, struktur i infrastruktury jako kodu wymagającego wyspecjalizowanych analizatorów — żaden pojedynczy skaner nie wykrywa wszystkich klas luk w zabezpieczeniach. Wielowarstwowe strategie SAST, które łączą wyspecjalizowane narzędzia z automatycznym uruchamianiem i bramami jakości, zapewniają szerokie pokrycie oraz dostarczają deweloperom natychmiastową informację zwrotną po wykryciu problemów z bezpieczeństwem.

Zaimplementuj zautomatyzowane testowanie zabezpieczeń przy użyciu następujących składników:

  • Zaimplementuj strategię skanowania wielowarstwowego: Osadzanie zautomatyzowanych testów zabezpieczeń aplikacji statycznych w każdej kompilacji w celu wykrywania luk w zabezpieczeniach przed dotarciem kodu do środowiska produkcyjnego. Zaimplementuj wielowarstwową strategię SAST, która łączy wiele wyspecjalizowanych skanerów — żadne pojedyncze narzędzie nie wykrywa wszystkich klas luk w zabezpieczeniach, dlatego kompleksowe pokrycie wymaga analizatorów specyficznych dla języka (Python, JavaScript, C/C++), skanerów infrastruktury jako kodu (Terraform, szablonów ARM, manifestów Kubernetes), wykrywania tajnych danych i semantycznej analizy kodu w celu identyfikacji złożonych luk w zabezpieczeniach związanych z przepływem danych.

  • Konfigurowanie automatycznego wykonywania za pomocą bram kontrolnych jakości: Skonfiguruj skanowanie SAST, aby było wykonywane automatycznie przy każdym zatwierdzeniu i żądaniu połączenia, oferując deweloperom natychmiastową informację zwrotną na temat problemów z zabezpieczeniami, gdy kontekst kodu jest świeży. Ustanów bramy jakości oparte na stopniu ważności, które blokują scalanie lub wdrożenia po wykryciu krytycznych lub wysokich luk w zabezpieczeniach, uniemożliwiając podatnemu kodowi przechodzenie przez ciąg. Skonfiguruj skanery, aby generowały wyniki w standardowych formatach (SARIF), co umożliwia spójne śledzenie luk w zabezpieczeniach, deduplikację pomiędzy narzędziami oraz integrację ze scentralizowanymi panelami kontrolnymi zabezpieczeń.

  • Wdrażanie skanowania tajemnic z ochroną przy wypychaniu: Zaimplementuj wyspecjalizowane skanowanie tajemnic przy użyciu ochrony przy wypychaniu, które zapobiega zatwierdzaniu przez deweloperów poświadczeń, kluczy API, certyfikatów lub tokenów, zatrzymując tajemnice podczas zatwierdzania w repozytoriach, zamiast odkrywania ich podczas audytów tygodnie później. Obsługa zarówno standardowych wzorców wpisów tajnych (kluczy platformy AWS, tokenów platformy Azure, łańcuchów połączeń baz danych), jak i niestandardowych wzorców specyficznych dla organizacji dotyczących zastrzeżonych mechanizmów uwierzytelniania. Po wykryciu wpisów tajnych podaj natychmiastowe wskazówki dotyczące korygowania, w tym procedury rotacji poświadczeń i bezpieczne alternatywy.

  • Użyj analizy kodu semantycznego w celu uzyskania złożonych luk w zabezpieczeniach: Wdróż narzędzia do analizy kodu semantycznego, takie jak GitHub CodeQL , które wykonują analizę głębokiego przepływu danych, aby zidentyfikować złożone luki w zabezpieczeniach niewidoczne dla skanerów pasujących do wzorców, takie jak wstrzyknięcie kodu SQL za pomocą wielu wywołań funkcji, pomijanie uwierzytelniania w logice biznesowej lub niezabezpieczone łańcuchy deserializacji. Twórz niestandardowe zapytania zabezpieczeń dostosowane do struktur organizacji, wymagań dotyczących zabezpieczeń i typowych wzorców luk w zabezpieczeniach zidentyfikowanych w retrospektywach zdarzeń. Integracja wyników SAST bezpośrednio do przepływów pracy deweloperów za pomocą komentarzy pull request z określonymi numerami wierszy, wyjaśnieniami dotyczącymi luk w zabezpieczeniach i zaleceniami dotyczącymi ich korygowania.

  • Orkiestruj z ujednoliconymi platformami: Ujednolicone platformy SAST, takie jak Microsoft Security DevOps Extension, mogą orkiestrować wiele wyspecjalizowanych skanerów (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) za pomocą jednego zadania potoku, standaryzując zarządzanie konfiguracją i agregując wyniki w heterogenicznych ekosystemach narzędzi.

Przykład implementacji

Dostawca SaaS doznał ataku polegający na wstrzyknięciu kodu SQL, który ujawnia setki tysięcy rekordów klientów. Analiza po zdarzeniu ujawniła obszerne luki w zabezpieczeniach na poziomie kodu, w tym zakodowane na stałe poświadczenia i wady iniekcji, które istniały przez wiele miesięcy.

Wyzwanie: Ręczne przeglądy kodu przechwytywały tylko niewielką część luk w zabezpieczeniach. Deweloperzy nie trenowali zabezpieczeń, aby zidentyfikować wady iniekcji i słabości kryptograficzne. Brak zautomatyzowanego skanowania przed wdrożeniem produkcyjnym.

Podejście do rozwiązania:

  • Multi-skaner SAST: Wdrożono rozszerzenie DevOps zabezpieczeń firmy Microsoft przy użyciu narzędzi CodeQL, ESLint i Bandit, zapewniających kompleksowy zakres ochrony w różnych językach programowania i typach luk w zabezpieczeniach.
  • Ochrona wpisów tajnych: Zaimplementowano usługę GitHub Advanced Security z funkcją skanowania wpisów tajnych i ochrony wypychającej uniemożliwiającej ujawnienie poświadczeń w zatwierdzeniach.
  • Analiza semantyczna: Skonfigurowano bibliotekę GitHub CodeQL z niestandardowymi zapytaniami dotyczącymi luk w zabezpieczeniach logiki biznesowej i wzorcami zabezpieczeń specyficznymi dla platformy.
  • Bramy zabezpieczeń: Ustanowione punkty kontrolne w usłudze Azure Pipelines blokują wdrażanie wyników o wysokiej istotności.

Wynik: Szybko zidentyfikowano i skorygowano rozległe luki w zabezpieczeniach. Zapobiegło krytycznym wadom bezpieczeństwa przed wdrożeniem do produkcji. Znacznie zmniejszono zadłużenie zabezpieczeń.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS 4: 6.3.2, 6.4.1, 11.3.1
  • CIS Controls w wersji 8.1: 16.3, 16.6
  • NIST CSF v2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Integrowanie dynamicznego testowania zabezpieczeń aplikacji (DAST)

Zasada zabezpieczeń

Zaimplementuj kompleksowe dynamiczne testowanie zabezpieczeń w środowiskach przedprodukcyjnych za pomocą skanowania zabezpieczeń kontenerów pod kątem konteneryzowanych obciążeń, zautomatyzowanego testowania penetracyjnego dla aplikacji internetowych i interfejsów programowania aplikacji (API) oraz wyspecjalizowanego testowania na potrzeby uwierzytelniania, autoryzacji i zarządzania sesjami. Walidacja środowiska uruchomieniowego identyfikuje słabości konfiguracji i luki w zabezpieczeniach integracji, których nie można wykryć w analizie statycznej.

Ryzyko w celu ograniczenia ryzyka

Luki w zabezpieczeniach środowiska uruchomieniowego niewidoczne dla analizy statycznej tworzą krytyczne luki w zabezpieczeniach wykorzystywane przez przeciwników po wdrożeniu aplikacji. Bez kompleksowego DAST:

  • Wady konfiguracji wdrożenia: Nieprawidłowo skonfigurowani dostawcy uwierzytelniania, zbyt liberalne ustawienia CORS, słabe konfiguracje TLS lub brakujące nagłówki zabezpieczeń (CSP, HSTS, X-Frame-Options) mogą umożliwić ataki, które nie mogą być wykryte przez przegląd źródła.
  • Luki w zabezpieczeniach interfejsu API: Interfejsy API REST i GraphQL z obejściami uwierzytelniania, niepowodzeniami autoryzacji, nadmierną ekspozycją na dane, brakiem ograniczania szybkości lub niezabezpieczonymi odwołaniami do obiektów (IDOR) umożliwiają nieautoryzowany dostęp i wyodrębnianie danych.
  • Obejścia uwierzytelniania i autoryzacji: Wady zarządzania sesjami, przepływy resetowania haseł, implementacja uwierzytelniania wieloskładnikowego lub logika kontroli dostępu opartej na rolach umożliwiają eskalację uprawnień i przejęcie konta.
  • Luki w zabezpieczeniach zarządzania sesjami: Przewidywalne tokeny, niewystarczające egzekwowanie limitu czasu, luki w zabezpieczeniach utrwalenia sesji lub brak unieważnienia tokenu umożliwiają przejęcie sesji i kradzież poświadczeń.
  • Problemy z zabezpieczeniami specyficznymi dla środowiska: Punkty integracji z bazami danych, kolejkami komunikatów, zewnętrznymi interfejsami API lub usługami innych firm wprowadzają luki w zabezpieczeniach środowiska uruchomieniowego niewidoczne w programach programistycznych lub izolowanych testach.
  • Wady logiki biznesowej: Warunki wyścigu, luki związane z manipulacją stanem, nieprawidłowa walidacja danych wejściowych w złożonych przepływach pracy lub problemy z integralnością transakcji stają się furtką do oszustw i manipulacji danymi.

DAST weryfikuje zachowanie uruchomieniowe, konfigurację środowiska oraz zabezpieczenia integracji, zapewniając zakres, którego analiza statyczna nie może pokryć.

MITRE ATT&CK

  • Dostęp początkowy (TA0001): wykorzystanie aplikacji publicznej (T1190) przy użyciu obejść uwierzytelniania, wad iniekcji lub niezabezpieczonych punktów końcowych interfejsu API wykrytych za pomocą testowania środowiska uruchomieniowego.
  • Dostęp do poświadczeń (TA0006): brute force (T1110) wykorzystujący brakujące ograniczenia szybkości, słabe polityki haseł lub przewidywalne tokeny sesji wykryte podczas DAST.
  • Eskalacja uprawnień (TA0004): wykorzystanie prawidłowych kont (T1078) do pomijania autoryzacji lub luk w zabezpieczeniach manipulacji rolami w wdrożonych aplikacjach.
  • Kolekcja (TA0009): dane z repozytoriów informacji (T1213) wyodrębniające poufne dane poprzez nadmierne odpowiedzi interfejsu API, przechodzenie po katalogach lub luki w zabezpieczeniach związane z niezabezpieczonym bezpośrednim odwołaniem do obiektu.
  • Eksfiltracja (TA0010): eksfiltracja za pośrednictwem usługi internetowej (T1567) wykorzystująca luki zabezpieczeń interfejsu API w celu wyodrębniania danych na dużą skalę bez wykrywania.

DS-5.1: Implementacja zautomatyzowanego DAST w środowisku przedprodukcyjnym

Dynamiczne testowanie zabezpieczeń aplikacji weryfikuje mechanizmy kontroli zabezpieczeń w uruchomionych aplikacjach, odnajdując luki w zabezpieczeniach środowiska uruchomieniowego, których analiza statyczna nie może wykryć. Podczas gdy SAST analizuje kod źródłowy, DAST testuje wdrożone aplikacje, korzystając z konfiguracji przypominających środowisko produkcyjne, aby zidentyfikować problemy specyficzne dla wdrożenia, takie jak błędy w konfiguracji uwierzytelniania, wady autoryzacji i luki w zabezpieczeniach integracji, które ujawniają się tylko w środowiskach operacyjnych. Zautomatyzowany DAST w fazie przedprodukcyjnej zapewnia weryfikację bezpieczeństwa przed dostępem klientów, przy jednoczesnym testowaniu realistycznych scenariuszy ataku na zintegrowane systemy.

Zaimplementuj walidację zabezpieczeń środowiska uruchomieniowego za pomocą następujących funkcji:

  • Uzupełnij SAST za pomocą walidacji środowiska uruchomieniowego: Uzupełnij analizę statyczną dzięki dynamicznym testom zabezpieczeń aplikacji, które weryfikują zabezpieczenia w uruchomionych aplikacjach z konfiguracjami przypominającymi środowisko produkcyjne. Podczas gdy SAST identyfikuje luki w zabezpieczeniach w kodzie źródłowym, daST wykrywa problemy ze środowiskiem uruchomieniowym niewidoczne dla statycznej analizy: słabe strony konfiguracji wdrożenia (nieprawidłowo skonfigurowanych dostawców uwierzytelniania, permissywne zasady CORS, brakujące nagłówki zabezpieczeń), luki w zabezpieczeniach integracji specyficzne dla środowiska (zabezpieczenia połączeń z bazą danych, autoryzacja interfejsu API w wdrożonych kontekstach) i luki w zabezpieczeniach logiki biznesowej, które manifestują się tylko w realistycznych warunkach operacyjnych.

  • Wdróż w środowiskach stagingowych przypominających środowisko produkcyjne: Wdróż skanowanie DAST w środowiskach przedwdrożeniowych, które dublują architekturę produkcyjną, topologię sieci, zależności zewnętrzne i parametry konfiguracji. Automatyczne wykonywanie testów DAST powinno być wyzwalane podczas wdrażania do środowiska testowego, systematycznego testowania przepływów uwierzytelnienia, granic uprawnień, zarządzania sesjami, walidacji danych wejściowych, zabezpieczeń interfejsu API i obsługi błędów w realistycznych schematach obciążenia i użycia. Sprawdza to, czy mechanizmy kontroli zabezpieczeń działają prawidłowo, gdy są zintegrowane z systemami zewnętrznymi przypominającymi środowisko produkcyjne (dostawcy tożsamości, bazy danych, kolejki komunikatów, interfejsy API innych firm).

  • Zaimplementuj monitorowanie środowiska uruchomieniowego dla kontenerów: W przypadku obciążeń konteneryzowanych zaimplementuj monitorowanie zabezpieczeń ciągłego środowiska uruchomieniowego, które łączy skanowanie obrazów przed wdrożeniem z analizą behawioralną po wdrożeniu. Skanuj obrazy kontenerów pod kątem znanych luk w zabezpieczeniach przed wdrożeniem, a następnie monitoruj uruchomione kontenery pod kątem nietypowych połączeń sieciowych, nieautoryzowanego wykonywania procesu, modyfikacji systemu plików i prób eskalacji uprawnień. Profilowanie normalnego zachowania obciążenia platformy Kubernetes w celu wykrywania odchyleń wskazujących na kompromitację oraz ciągła ocena konfiguracji kontenerów względem testów porównawczych CIS i najlepszych praktyk w zakresie bezpieczeństwa.

  • Skoncentruj się na powierzchniach ataków wysokiego ryzyka: Skoncentruj wyspecjalizowane działania DAST na powierzchniach ataków wysokiego ryzyka: interfejsy API REST i GraphQL (testowanie obejść uwierzytelniania, niepowodzenia autoryzacji, luki typu injection, nadmierne ujawnienie danych, niezabezpieczone odwołania do obiektów), uwierzytelnianie i zarządzanie sesjami (weryfikowanie zabezpieczeń tokenu, wymuszanie limitu czasu, funkcjonalność wylogowywania, przepływy resetowania haseł, uwierzytelnianie wieloskładnikowe) i przepływy pracy logiki biznesowej (testowanie warunków wyścigu, manipulacja stanem, problemy z integralnością transakcji). Ustanów procesy korelacji SAST/DAST, które łączą wyniki z obu podejść, priorytetyzując luki w zabezpieczeniach potwierdzone zarówno przez analizę statyczną, jak i dynamiczną jako najwyższego ryzyka.

  • Korzystanie ze zintegrowanych platform: W przypadku środowisk konteneryzowanych usługa Microsoft Defender for Containers zapewnia zintegrowaną ocenę luk w zabezpieczeniach środowiska uruchomieniowego, profilowanie obciążeń i możliwości wykrywania zagrożeń w całym cyklu życia kontenera.

Przykład implementacji

Organizacja handlu elektronicznego odkryła obejście uwierzytelniania w interfejsie API płatności, umożliwiając nieautoryzowane rabaty. Usługa SAST przegapiła wadę konfiguracji środowiska uruchomieniowego, która manifestowała się tylko w wdrożonych środowiskach z zewnętrznymi dostawcami uwierzytelniania.

Wyzwanie: Usługa SAST wykryła luki w zabezpieczeniach kodu, ale pominęła problemy z konfiguracją w czasie wykonywania oraz błędy autoryzacji API. Konfiguracja wdrożenia produkcyjnego różniła się od konfiguracji rozwojowej, co spowodowało luki w zabezpieczeniach niewidoczne dla analizy statycznej.

Podejście do rozwiązania:

  • Automatyczne skanowanie DAST: Wdrożono OWASP ZAP w środowiskach przedprodukcyjnych, testując aplikacje o konfiguracjach zbliżonych do produkcyjnych.
  • Ochrona środowiska uruchomieniowego kontenera: Zaimplementowano usługę Microsoft Defender for Containers na potrzeby monitorowania zabezpieczeń środowiska uruchomieniowego i oceny luk w zabezpieczeniach.
  • Testowanie zabezpieczeń interfejsu API: Skonfigurowano wyspecjalizowane testowanie interfejsu API sprawdzania poprawności uwierzytelniania, autoryzacji i walidacji danych we wdrożonych punktach końcowych REST i GraphQL.
  • Korelacja SAST/DAST: Utworzono przepływy pracy korelacji luk w zabezpieczeniach łączące statyczne i dynamiczne wyniki na potrzeby kompleksowej weryfikacji zabezpieczeń.

Wynik: Wykryte luki w zabezpieczeniach środowiska uruchomieniowego pominięte przez narzędzia SAST, w tym obejścia mechanizmów uwierzytelniania i wady autoryzacyjne API. Zapobieganie incydentom bezpieczeństwa dzięki detekcji przedprodukcyjnej.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS 4: 6.4.2, 11.3.2
  • Kontrole CIS w wersji 8.1: 16.7, 16.8
  • NIST CSF v2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: Zabezpieczanie cyklu życia obciążenia

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: DS-6.

Zasada zabezpieczeń

Zaimplementuj niezmienną infrastrukturę z kompleksowymi zabezpieczeniami obrazów za pomocą rejestrów kontenerów i skanowania zabezpieczeń pod kątem obciążeń kontenerów, zarządzania złotymi obrazami i zautomatyzowanego tworzenia obciążeń maszyn wirtualnych oraz ciągłego skanowania luk w zabezpieczeniach za pomocą zautomatyzowanej kwarantanny. Zweryfikuj podpisy kryptograficzne, zachowaj minimalne obrazy podstawowe i wymuś standardy zabezpieczeń w całym cyklu życia zadania.

Ryzyko w celu ograniczenia ryzyka

Niezabezpieczone zarządzanie cyklem życia obciążenia umożliwia atakom narażonym lub naruszonym artefaktom dotarcie do środowiska produkcyjnego, tworząc trwałe wektory ataków, które systematycznie wykorzystują osoby atakujące. Bez kompleksowych zabezpieczeń obciążeń:

  • Obrazy maszyn wirtualnych w środowisku produkcyjnym: Nieskonfigurowane punkty odniesienia systemu operacyjnego lub nieprawidłowo skonfigurowane złote obrazy propagują słabe strony na wszystkich wdrożonych maszynach wirtualnych.
  • Niezałatane podatne obrazy podstawowe: Kontenery oparte na bazach dotkniętych lukami CVE (Log4Shell, Heartbleed, OpenSSL) narażają obciążenia na wykorzystanie i umożliwiają ucieczkę.
  • Przestarzałe wrażliwe artefakty: Obrazy i pakiety pozostawione bez skanowania akumulują CVEs, rozszerzając powierzchnię ataków.
  • Niewystarczająca weryfikacja obrazu: Brak podpisywania kryptograficznego i walidacji pochodzenia umożliwia przeciwnikom zastępowanie wiarygodnych obrazów z naruszonymi wersjami zawierającymi backdoors lub malware.
  • Zbyt rozbudowany obszar ataku: Obrazy kontenerów zawierające niepotrzebne pakiety, narzędzia programistyczne lub narzędzia do debugowania zwiększają podatność na ataki i dają atakującym dodatkowe narzędzia do wykorzystywania.
  • Brakujące punkty odniesienia zabezpieczeń: Obrazy maszyn wirtualnych i kontenerów wdrożone bez zgodności testów porównawczych CIS, wzmacniania zabezpieczeń lub minimalnej konfiguracji uprawnień tworzą luki umożliwiające wykorzystanie luk w zabezpieczeniach w głębi systemu.

Naruszone artefakty stają się trwałymi wektorami ataków, przyczyniają się do ruchu bocznego i wydają się wiarygodne obrońcom.

MITRE ATT&CK

  • Dostęp początkowy (TA0001): wykorzystanie aplikacji publicznej (T1190) korzystającej z luk w zabezpieczeniach kontenerów aplikacji lub usług internetowych.
  • Wykonanie (TA0002): wdrożenie kontenera (T1610) wdrażającego złośliwe kontenery, które wydają się legalne z powodu niewystarczającej weryfikacji obrazów.
  • Eskalacja uprawnień (TA0004): ucieczka do hosta (T1611) wykorzystująca luki w zabezpieczeniach kontenera w celu przerwania izolacji kontenera i naruszenia zabezpieczeń systemu hosta.
  • Ruch poprzeczny (TA0008): wykorzystywanie usług zdalnych (T1210) przestawiających się między podatnymi na zagrożenia maszynami wirtualnymi lub kontenerami wdrożonym z obrazów, których bezpieczeństwo zostało naruszone.

DS-6.1: Implementowanie zabezpieczeń obrazu kontenera

Obrazy kontenerów i maszyn wirtualnych reprezentują krytyczne powierzchnie ataków wymagające kompleksowych mechanizmów kontroli zabezpieczeń w całym cyklu życia. Podatne na zagrożenia obrazy podstawowe propagują słabe strony dla każdego wdrożonego wystąpienia, co wzmacnia wpływ na infrastrukturę. Traktowanie artefaktów związanych z obciążeniem z tymi samymi rygorami bezpieczeństwa co kod źródłowy, w tym skanowanie, podpisywanie i bezpieczne przechowywanie, gwarantuje, że organizacje wdrażają tylko zweryfikowane, wiarygodne obrazy, jednocześnie uniemożliwiając atakującym wykorzystanie znanych luk w zabezpieczeniach lub podmianę złośliwych obrazów.

Zabezpieczanie artefaktów obciążenia za pomocą następujących rozwiązań:

  • Ustanów zasady niezmiennej infrastruktury: Traktuj obrazy kontenerów i maszyny wirtualne jako kluczowe artefakty, które wymagają takiego samego rygoru bezpieczeństwa jak kod źródłowy – podatne obrazy bazowe mogą propagować luki we wszystkich wdrożonych instancjach. Ustanów niezmienne zasady infrastruktury, w których artefakty obciążenia są tworzone raz, skanowane kompleksowo, podpisane kryptograficznie i wdrażane bez modyfikacji, aby zapewnić spójność i możliwość śledzenia w całym cyklu życia.

  • Używaj minimalnych obrazów podstawowych z kompilacjami wieloetapowymi: W przypadku obciążeń kontenerów zaimplementuj zabezpieczenia obrazów warstwowych, począwszy od minimalnych obrazów bazowych zawierających tylko podstawowe składniki środowiska uruchomieniowego, co znacznie zmniejsza powierzchnię ataków w porównaniu z pełnymi obrazami systemu operacyjnego. Kompilacje wieloetapowe umożliwiają oddzielenie zależności czasowych budowy od obrazów środowiska uruchomieniowego poprzez kompilowanie i budowanie w funkcjonalnie rozbudowanych obrazach, a następnie kopiowanie tylko końcowych artefaktów do minimalnych obrazów środowiska uruchomieniowego, usuwanie narzędzi deweloperskich, menedżerów pakietów oraz zależności kompilacyjnych, które zwiększają ryzyko narażenia na luki w zabezpieczeniach, dostarczając atakującym narzędzia do wykorzystania.

  • Integracja automatycznego skanowania z zasadami kwarantanny: Zintegruj automatyczne skanowanie luk w zabezpieczeniach w pipeline budowania obrazów, które skanuje każdy obraz przed zapisaniem w rejestrze, sprawdzając je w stosunku do kompleksowych baz danych CVE i stale ponownie skanując przechowywane obrazy w miarę ujawniania się nowych luk. Zaimplementuj zasady automatycznej kwarantanny, które uniemożliwiają wdrażanie obrazów z lukami w zabezpieczeniach krytycznych lub o wysokiej ważności, a przepływy pracy wyjątków wymagają zatwierdzenia przez zespół ds. zabezpieczeń i udokumentowania akceptacji ryzyka. Ustanów zasady odświeżania obrazu podstawowego za pomocą zautomatyzowanych wyzwalaczy potoków, aktywowanych po wydaniu poprawek zabezpieczeń, aby obrazy nie gromadziły CVE w czasie.

  • Wymuszanie podpisywania kryptograficznego i weryfikacji: Egzekwuj integralność obrazu poprzez podpisywanie kryptograficzne i weryfikację na każdym etapie: podpisuj obrazy podczas kompilacji, weryfikuj podpisy przed wdrożeniem i automatycznie odrzucaj obrazy, które są niepodpisane lub naruszone. Zapobiega to atakom polegającym na zastępowaniu wiarygodnych obrazów kompromitowanymi wersjami zawierającymi tylne furtki. Przechowuj obrazy w zabezpieczonych rejestrach kontenerów z kontrolą dostępu do sieci (prywatne punkty końcowe, integracja sieci wirtualnej), polityki dostępu oparte na rolach, które ograniczają, kto może przeprowadzać operacje wypychania/ściągania obrazów oraz kompleksowe rejestrowanie audytów wszystkich operacji rejestru.

  • Zachowaj złote obrazy ze wzmocnionymi zabezpieczeniami dla maszyn wirtualnych: W przypadku obciążeń maszyn wirtualnych utrzymuj scentralizowane repozytoria złotych obrazów ze zgodnymi ze standardami CIS obrazami podstawowymi o wzmocnionych zabezpieczeniach, które są regularnie aktualizowane poprawkami zabezpieczeń i poddawane walidacji zgodności. Zaimplementuj zautomatyzowane potoki tworzenia obrazów, które zawierają aktualizacje zabezpieczeń, usuwają niepotrzebne usługi, wymuszają konfiguracje z najmniejszymi uprawnieniami i generują świeże obrazy zgodnie ze zdefiniowanymi harmonogramami zamiast stosowania poprawek do działających systemów.

  • Korzystanie ze zintegrowanych platform zabezpieczeń: Rozwiązania takie jak Usługa Azure Container Registry z integracją usługi Microsoft Defender for Containers zapewniają automatyczne skanowanie, przepływy pracy kwarantanny, zaufanie do zawartości i replikację w wielu regionach z spójnymi zasadami zabezpieczeń.

Przykład implementacji

Organizacja logistyczna wdrożyła aplikację kontenera z niezałatanym obrazem podstawowym zawierającym krytyczną lukę umożliwiającą zdalne wykonanie kodu. Osoby atakujące wykorzystały lukę w zabezpieczeniach wkrótce po wdrożeniu, co narusza dane wysyłkowe.

Wyzwanie: Wiele obrazów kontenerów bez skanowania pod kątem podatności. Obrazy utworzone kilka miesięcy temu zgromadziły wiele CVE, wśród których występują krytyczne luki w zabezpieczeniach. Żadna weryfikacja nie uniemożliwiała zastępowania złośliwych obrazów.

Podejście do rozwiązania:

  • Zabezpieczenie rejestru kontenerów: Zaimplementowano usługę Azure Container Registry z skanowaniem luk w zabezpieczeniach, umieszczając obrazy o wysokim poziomie zagrożenia w kwarantannie przed wdrożeniem.
  • Obrazy maszyn wirtualnych o wzmocnionych zabezpieczeniach: Wdrożono Azure Shared Image Gallery z obrazami maszyn wirtualnych zgodnymi ze standardem CIS do zastosowań wymagających regulacji.
  • Ochrona środowiska uruchomieniowego: Skonfigurowano usługę Microsoft Defender for Containers na potrzeby ciągłego wykrywania zagrożeń i monitorowania dryfu.
  • Integralność artefaktu: Ustanowiono podpisywanie kryptograficzne i weryfikację zapewniającą autentyczność obrazu w całym cyklu życia.

Wynik: Zablokowane obrazy podatne na zagrożenia z wdrożenia produkcyjnego. Znacznie zmniejszono liczbę CVE kontenera przypadających na obraz. Zapobiegano atakom polegającym na zastępowaniu obrazów za pomocą weryfikacji podpisu.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS 4: 6.2.4, 6.3.3, 11.3.1
  • Kontrole CIS w wersji 8.1: 4.1, 7.3, 7.4
  • NIST CSF v2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: Implementowanie rejestrowania i monitorowania metodyki DevOps

Zasada zabezpieczeń

Zaimplementuj kompleksowe rejestrowanie działań DevOps poprzez strumieniowanie danych audytu z integracją z scentralizowanymi platformami zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM) w celu analizy bezpieczeństwa, wykrywania zagrożeń w czasie rzeczywistym i automatycznego reagowania. Ustanów analizę behawioralną, wykrywanie anomalii i metryki zabezpieczeń, aby umożliwić szybką reakcję na zdarzenia i zachować ślady inspekcji zgodności.

Ryzyko w celu ograniczenia ryzyka

Niewystarczające rejestrowanie i monitorowanie w środowisku DevOps tworzy krytyczne ślepe punkty, które przeciwnicy wykorzystują do działania w sposób niewykryty, utrwalania swojej obecności oraz wykradania poufnego kodu lub danych uwierzytelniających. Bez kompleksowej widoczności:

  • Niewykryte naruszenia zabezpieczeń potoku: Atakujący modyfikują potoki CI/CD, aby wstrzykiwać złośliwy kod, eksfiltrować tajemnice lub tworzyć tylne drzwi bez wywoływania alertów ze względu na brak lub niewystarczające rejestrowanie audytu.
  • Zagrożenia niejawne modyfikujące kod lub infrastrukturę: Złośliwe wewnętrzne lub naruszone konta nieautoryzowane wprowadzają nieautoryzowane zmiany w kodzie źródłowym, definicjach infrastruktury lub konfiguracjach wdrożenia bez wykrywania.
  • Brak kompleksowych śladów inspekcji: Brak szczegółowych dzienników aktywności uniemożliwia prowadzenie dochodzeń kryminalistycznych, ocenę wpływu i analizę przyczyn źródłowych podczas incydentów bezpieczeństwa, co wydłuża czas odkrycia i zwiększa wpływ naruszeń.
  • Opóźniona odpowiedź na zdarzenia: Średni czas wykrywania (MTTD) rozciąga się od godzin do tygodni, gdy zespoły ds. zabezpieczeń nie mają alertów w czasie rzeczywistym, wykrywania anomalii i zautomatyzowanej korelacji zdarzeń zabezpieczeń metodyki DevOps.
  • Błędy inspekcji zgodności: Wymagania prawne (SOX, PCI-DSS, HIPAA, ISO 27001) nakazujące kompleksowe dzienniki inspekcji, śledzenie zmian i rejestrowanie dostępu nie mogą być spełnione bez scentralizowanego monitorowania DevOps.
  • Ślepota na eskalację uprawnień: Nieautoryzowane podniesienie uprawnień, tworzenie kont backdoor lub modyfikacja kontroli dostępu pozostają niewykryte bez analizy behawioralnej i monitorowania uprawnień.

Luki rejestrowania ukrywają złośliwe zmiany w procesach pipeline’ów, eskalację uprawnień i utrzymywane próby dostępu w ścieżkach rozwoju z wysokimi uprawnieniami.

MITRE ATT&CK

  • Uchylanie się od obrony (TA0005): osłabienie obrony (T1562) wyłączanie rejestrowania inspekcji, skanowania zabezpieczeń lub agentów monitorowania do działania w ślepych miejscach, a usuwanie wskaźników (T1070) czyszczenie dzienników inspekcji lub historii wykonania potoku w celu ukrycia złośliwych działań.
  • Trwałość (TA0003): manipulowanie kontem (T1098) poprzez tworzenie dodatkowych głównych obiektów usługi, osobistych tokenów dostępu lub kluczy SSH bez wykrycia.
  • Kolekcjonowanie (TA0009): dane z repozytoriów informacji (T1213) obejmujące eksfiltrację kodu źródłowego, tajnych informacji lub własności intelektualnej za pomocą dostępu do potoku.
  • Dostęp do poświadczeń (TA0006): niezabezpieczone poświadczenia (T1552) pozyskiwanie ujawnionych tajnych informacji z dzienników potoku lub historii wykonania.

DS-7.1: Implementowanie rejestrowania inspekcji dla platform DevOps

Platformy DevOps z uprzywilejowanym dostępem do infrastruktury produkcyjnej i poufnym kodem źródłowym wymagają kompleksowego monitorowania zabezpieczeń w celu wykrywania działań niepożądanych i zagrożeń wewnętrznych. Luki w rejestrowaniu inspekcji umożliwiają złośliwym aktorom działanie niewykryte przez dłuższy czas, podczas gdy scentralizowana agregacja dzienników umożliwia korelację z szerszymi telemetriami zabezpieczeń, które ujawniają zaawansowane łańcuchy ataków. Analiza behawioralna w czasie rzeczywistym identyfikuje podejrzane wzorce niewidoczne w izolowanych zdarzeniach, przekształcając nieprzetworzone dane inspekcji na analizę zabezpieczeń z możliwością działania.

Ustanów kompleksowe monitorowanie zabezpieczeń metodyki DevOps za pomocą następujących funkcji:

  • Przechwyć kompleksowe działania związane z zabezpieczeniami: Ustaw kompleksowe logowanie audytów, które przechwytuje wszystkie działania DevOps związane z zabezpieczeniami: uwierzytelnianie i autoryzację użytkownika, zatwierdzanie kodu źródłowego i operacje na gałęziach, tworzenie i modyfikacje potoków, wykonywanie wdrożeń, dostęp do tajnych danych, zmiany uprawnień, tworzenie głównej usługi oraz akcje administracyjne. Platformy DevOps mają uprzywilejowany dostęp do infrastruktury produkcyjnej, a luki w rejestrowaniu kodu o charakterze poufnym umożliwiają przeciwnikom i złośliwym insiderom działanie niewykrytych przez dłuższy czas.

  • Przekazywanie dzienników do scentralizowanego rozwiązania SIEM w czasie rzeczywistym: Przekazywanie dzienników inspekcji w czasie rzeczywistym do scentralizowanych platform SIEM, a nie poleganie na natywnym przechowywaniu platformy DevOps (zazwyczaj 90 dni), włączeniu długoterminowej analizy kryminalistycznej, raportowania zgodności i korelacji z zdarzeniami zabezpieczeń z innych systemów. Przesyłanie strumieniowe dzienników do centrów operacji zabezpieczeń za pomocą standardowych protokołów (/azure Event Hubs, syslog) w formatach strukturalnych (JSON), które umożliwiają automatyczne analizowanie, analizowanie i zgłaszanie alertów bez ręcznego przeglądania dzienników.

  • Wdrażanie analizy behawioralnej i wykrywania anomalii: Zaimplementuj analizę behawioralną i wykrywanie anomalii na danych inspekcji DevOps, aby zidentyfikować podejrzane wzorce niewidoczne w poszczególnych zdarzeniach: modyfikacje potoków po godzinach, nietypowy dostęp do poufnych repozytoriów, szybkie eskalacje uprawnień, tworzenie zasobu głównego usługi, a także podejrzane wdrożenia, wykonania potoków z nieoczekiwanych lokalizacji lub nietypowe wzorce dostępu do danych tajnych. Ustanów wzorcowe profile zachowania dla użytkowników i usług, powiadamiając o znaczących odchyleniach statystycznych, które mogą wskazywać na zagrożenia kompromitacji lub wewnętrzne.

  • Skonfiguruj automatyczne alerty dla działań wysokiego ryzyka: Skonfiguruj automatyczne alerty dla działań wysokiego ryzyka z natychmiastowym powiadomieniem dla zespołów ds. zabezpieczeń: błędy wdrażania produkcyjnego, modyfikacje potoku w chronionych gałęziach, nowe tworzenie głównego obiektu usługi, zdarzenia podniesienia uprawnień, wyłączone kroki skanowania zabezpieczeń, zmiany konfiguracji przekazywania dziennika inspekcji lub próby dostępu do tajemnic z nieautoryzowanych potoków. Zaimplementuj eskalację opartą na krytyczności, aby alerty krytyczne docierały natychmiast do centrum operacji bezpieczeństwa, podczas gdy rutynowe zdarzenia są grupowane do analizy.

  • Integracja z szerszymi telemetriami zabezpieczeń: Integrowanie dzienników inspekcji devOps z szerszymi danymi telemetrycznymi zabezpieczeń na platformach SIEM w celu korelacji z wykrywaniem punktów końcowych, zabezpieczeniami sieci, zdarzeniami tożsamości i źródłami analizy zagrożeń. Umożliwia to wykrywanie zaawansowanych łańcuchów ataków, w których kompromis DevOps jest jednym z etapów operacji wielofazowych, na przykład korelując wyłudzone poświadczenia z kolejnymi modyfikacjami potoku i nietypowym aprowizowaniem zasobów w chmurze.

  • Korzystanie ze zintegrowanych platform SIEM: Platformy, takie jak Azure DevOps Audit Streaming z integracją z usługą Microsoft Sentinel, zapewniają przekazywanie dzienników w czasie rzeczywistym, wstępnie utworzone reguły wykrywania zagrożeń DevOps, raporty zabezpieczeń na potrzeby badania oraz automatyzację reakcji.

Przykład implementacji

Organizacja produkcyjna wykryła wewnętrzne zagrożenie, gdy były wykonawca zmodyfikował potok CI/CD, wstrzykując kod backdoor do aplikacji produkcyjnej. Incydent pozostał niewykryty przez wiele miesięcy z powodu niewystarczającego rejestrowania inspekcji.

Wyzwanie: Brak scentralizowanego rejestrowania działań metodyki DevOps. Modyfikacje potoku i zmiany dostępu uprzywilejowanego zostały niemonitorowane. Śledztwo kryminalistyczne utrudniane przez brak ścieżek audytowych. Inspekcja zgodności nie powiodła się z powodu niewystarczającego śledzenia zmian.

Podejście do rozwiązania:

  • Scentralizowane rejestrowanie inspekcji: Włączono przesyłanie strumieniowe zdarzeń inspekcji Azure DevOps Audit Streaming do Microsoft Sentinel w celu analizy zabezpieczeń i długoterminowego przechowywania.
  • Analiza behawioralna: Wdrożono wykrywanie anomalii identyfikujące niezwykłe wzorce dostępu, nocne modyfikacje pipeline'ów oraz eskalacje uprawnień wskazujące na zagrożenia wewnętrzne.
  • Automatyczne alerty: Skonfigurowano alerty dotyczące podejrzanych działań, w tym nieautoryzowanych wdrożeń produkcyjnych i routingu tworzenia jednostki usługi do operacji zabezpieczeń.
  • Raportowanie zgodności: Utworzono automatyczne generowanie dzienników inspekcji spełniające wymagania prawne z kompleksowym śledzeniem zmian.

Wynik: Szybko wykryto i zapobiegano kolejnym nieautoryzowanym modyfikacjom pipeline'u. Znacznie skrócony czas badania zdarzeń z kompleksowymi śladami inspekcji. Osiągnięto zgodność z udokumentowanymi zarządzaniem zmianami.

Poziom krytyczny

Powinien mieć.

Mapowanie kontrolek

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS 4: 10.2.1, 10.2.2, 10.3.4
  • CIS Controls w wersji 8.1: 8.2, 8.5, 8.11
  • NIST CSF v2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on