Udostępnij za pośrednictwem

Zabezpieczenia w usłudze DevOps (DevSecOps)

  • Artykuł

Zabezpieczenia są kluczową częścią metodyki DevOps. Ale jak zespół wie, czy system jest bezpieczny? Czy naprawdę można dostarczyć całkowicie bezpieczną usługę?

Niestety, odpowiedź nie jest. DevSecOps to ciągły i ciągły wysiłek, który wymaga uwagi wszystkich w operacjach programistycznych i IT. Chociaż praca nigdy nie jest naprawdę wykonywana, praktyki, które zespoły stosują, aby zapobiec naruszeniom i obsługiwać je, mogą pomóc w tworzeniu systemów, które są tak bezpieczne i odporne, jak to możliwe.

"Zasadniczo, jeśli ktoś chce dostać się, dostaje się... zaakceptuj to. Co mówimy klientom: numer jeden, jesteś w walce, niezależnie od tego, czy myślisz, że jesteś, czy nie. Numer dwa, prawie na pewno są przeniknięte." - Michael Hayden, były dyrektor NSA i CIA

Konwersacja dotycząca zabezpieczeń

Zespoły, które nie mają formalnej strategii DevSecOps, są zachęcane do jak najszybszego rozpoczęcia planowania. Na początku może istnieć opór ze strony członków zespołu, którzy nie doceniają w pełni istniejących zagrożeń. Inni mogą nie czuć, że zespół jest wyposażony w obliczu problemu i że każda specjalna inwestycja byłaby marudnym odwróceniem uwagi od funkcji żeglugi. Jednak konieczne jest rozpoczęcie rozmowy w celu budowania konsensusu co do charakteru ryzyka, sposobu, w jaki zespół może je ograniczyć i czy zespół potrzebuje zasobów, których obecnie nie ma.

Spodziewaj się, że sceptycy doprowadzą do niektórych typowych argumentów, takich jak:

  • Jak realne jest zagrożenie? Zespoły często nie doceniają potencjalnej wartości usług i danych, za które są naliczane opłaty za ochronę.
  • Nasz zespół jest dobry, prawda? Dyskusja na temat bezpieczeństwa może być postrzegana jako wątpliwości co do zdolności zespołu do tworzenia bezpiecznego systemu.
  • Nie sądzę, że jest to możliwe. Jest to wspólny argument od młodszych inżynierów. Osoby z doświadczeniem zwykle wiedzą lepiej.
  • Nigdy nie zostało naruszone. Ale jak wiesz? Jak byś wiedział?
  • Niekończące się debaty na temat wartości. DevSecOps to poważne zobowiązanie, które może być postrzegane jako rozproszenie uwagi od pracy podstawowej funkcji. Chociaż inwestycje w zabezpieczenia powinny być zrównoważone z innymi potrzebami, nie można go zignorować.

Zmiana myślenia

Kultura DevSecOps wymaga ważnej zmiany w myślenia. Nie tylko musisz zapobiegać naruszeniom, ale także zakładać, że tak samo.

Składniki strategii zabezpieczeń

Istnieje wiele technik, które można zastosować w dążeniu do bardziej bezpiecznych systemów.

Zapobieganie naruszeniom Przy założeniu naruszeń
Modele zagrożeń Ćwiczenia gry wojennej
Przeglądy kodu Centralne monitory zabezpieczeń
Testowanie zabezpieczeń Testy penetracyjne w witrynie na żywo
Cykl projektowania zabezpieczeń (SDL)

Każdy zespół powinien mieć już co najmniej pewne praktyki w zakresie zapobiegania naruszeniom. Pisanie bezpiecznego kodu stało się coraz bardziej domyślne i istnieje wiele bezpłatnych i komercyjnych narzędzi do pomocy w analizie statycznej i innych funkcjach testowania zabezpieczeń.

Jednak wiele zespołów nie ma strategii, która zakłada, że naruszenia systemu są nieuniknione. Zakładając, że naruszenie może być trudne do przyjęcia, zwłaszcza w przypadku trudnych rozmów z zarządzaniem, ale to założenie może pomóc ci odpowiedzieć na pytania dotyczące zabezpieczeń na własny czas. Nie chcesz dowiedzieć się, jak to wszystko podczas prawdziwego zagrożenia bezpieczeństwa.

Typowe pytania, które należy przemyśleć, obejmują:

  • Jak wykryjesz atak?
  • Jak odpowiesz, jeśli wystąpi atak lub penetracja?
  • Jak można odzyskać dane po ataku, na przykład w przypadku wycieku lub naruszenia danych?

Key DevSecOps practices (Kluczowe rozwiązania DevSecOps)

Istnieje kilka typowych praktyk DevSecOps, które mają zastosowanie do praktycznie dowolnego zespołu.

Najpierw skoncentruj się na poprawie czasu średniego wykrywania i średniego czasu odzyskiwania. Te metryki wskazują, jak długo trwa wykrywanie naruszenia i jak długo trwa odzyskiwanie, odpowiednio. Można je śledzić za pośrednictwem trwających testów na żywo planów reagowania na zabezpieczenia. Podczas oceniania potencjalnych zasad poprawa tych metryk powinna być ważną kwestią.

Przećwicz ochronę w głębi systemu. Gdy dojdzie do naruszenia, osoby atakujące mogą uzyskać dostęp do sieci wewnętrznych i wszystkich elementów w nich. Chociaż byłoby to idealne, aby zatrzymać napastników, zanim stanie się tak daleko, polityka przy założeniu naruszeń napędza zespoły w celu zminimalizowania narażenia ze strony osoby atakującej, która już dostała się.

Na koniec należy przeprowadzać okresowe oceny po naruszeniu zabezpieczeń praktyk i środowisk. Po rozwiązaniu naruszenia twój zespół powinien ocenić wydajność zasad, a także ich własne przestrzeganie. Zasady są najbardziej skuteczne, gdy zespoły faktycznie ich przestrzegają. Każde naruszenie, niezależnie od tego, czy jest prawdziwe, czy praktykowane, powinno być postrzegane jako okazja do poprawy.

Strategie ograniczania zagrożeń

Istnieje zbyt wiele zagrożeń, aby je wyliczyć. Niektóre luki w zabezpieczeniach są spowodowane problemami w zależnościach, takich jak systemy operacyjne i biblioteki, więc ich aktualizowanie ma kluczowe znaczenie. Inne są spowodowane usterkami w kodzie systemowym, które wymagają starannej analizy w celu znalezienia i naprawienia. Słabe zarządzanie wpisami tajnymi jest przyczyną wielu naruszeń, podobnie jak inżynieria społeczna. Dobrym rozwiązaniem jest zastanowienie się nad różnymi rodzajami otworów zabezpieczających i tym, co oznaczają dla systemu.

Wektory ataków

Rozważmy scenariusz, w którym osoba atakująca uzyskała dostęp do poświadczeń dewelopera. Co mogą zrobić?

Privilege Atak
Czy mogą wysyłać wiadomości e-mail? Phish współpracownicy
Czy mogą uzyskiwać dostęp do innych maszyn? Zaloguj się, mimikatz, powtórz
Czy mogą modyfikować źródło Wstrzykiwanie kodu
Czy można zmodyfikować proces kompilacji/wydania? Wstrzykiwanie kodu, uruchamianie skryptów
Czy mogą oni uzyskać dostęp do środowiska testowego? Jeśli środowisko produkcyjne ma zależność od środowiska testowego, wykorzystaj je
Czy mogą oni uzyskać dostęp do środowiska produkcyjnego? Tak wiele opcji...

Jak twój zespół może bronić się przed tymi wektorami?

  • Przechowywanie wpisów tajnych w chronionych magazynach
  • Usuwanie kont administratorów lokalnych
  • Ograniczanie protokołu SAMR
  • Credential Guard
  • Usuwanie serwerów z dwoma serwerami macierzystym
  • Oddzielne subskrypcje
  • Uwierzytelnianie wieloskładnikowe
  • Stacje robocze z dostępem uprzywilejowanym
  • Wykrywanie za pomocą usługi ATP i Microsoft Defender dla Chmury

Zarządzanie wpisami tajnymi

Wszystkie wpisy tajne muszą być przechowywane w chronionym magazynie. Wpisy tajne obejmują:

  • Hasła, klucze i tokeny
  • Klucze kont magazynu
  • Certyfikaty
  • Poświadczenia używane również w udostępnionych środowiskach nieprodukcyjnych

Aby wyeliminować duplikowanie wpisów tajnych, należy użyć hierarchii magazynów. Należy również rozważyć sposób i czas uzyskiwania dostępu do wpisów tajnych. Niektóre są używane w czasie wdrażania podczas tworzenia konfiguracji środowiska, podczas gdy inne są dostępne w czasie wykonywania. Wpisy tajne w czasie wdrażania zwykle wymagają nowego wdrożenia w celu pobrania nowych ustawień, natomiast wpisy tajne czasu wykonywania są dostępne w razie potrzeby i mogą być aktualizowane w dowolnym momencie.

Platformy mają bezpieczne funkcje magazynu do zarządzania wpisami tajnymi w potokach ciągłej integracji/ciągłego wdrażania i środowiskach chmury, takich jak Azure Key Vault i GitHub Actions.

Przydatne narzędzia

  • Microsoft Defender dla Chmury doskonale nadaje się do ogólnych alertów dotyczących infrastruktury, takich jak złośliwe oprogramowanie, podejrzane procesy itp.
  • Narzędzia do analizy kodu źródłowego na potrzeby statycznego testowania zabezpieczeń aplikacji (SAST).
  • Zaawansowane zabezpieczenia usługi GitHub na potrzeby analizy i monitorowania repozytoriów.
  • Program mimikatz wyodrębnia hasła, klucze, kody pin, bilety i nie tylko z pamięci usługi podsystemu Lokalnego lsass.exeurzędu zabezpieczeń w systemie Windows. Wymaga tylko dostępu administracyjnego do maszyny lub konta z włączonym uprawnieniem debugowania.
  • BloodHound tworzy graf relacji w środowisku usługi Active Directory. Może użyć czerwonego zespołu do łatwego identyfikowania wektorów ataków, które są trudne do szybkiego zidentyfikowania.

Ćwiczenia gry wojennej

Powszechną praktyką w firmie Microsoft jest angażowanie się w ćwiczenia gry wojennej. Są to zdarzenia testowania zabezpieczeń, w których dwa zespoły mają za zadanie testowanie zabezpieczeń i zasad systemu.

Czerwony zespół pełni rolę napastnika. Próbują modelować rzeczywiste ataki w celu znalezienia luk w zabezpieczeniach. Jeśli uda im się wykorzystać jakiekolwiek luki, wykazują one również potencjalny wpływ ich naruszeń.

Niebieski zespół pełni rolę zespołu DevOps. Testują swoją zdolność do wykrywania ataków czerwonego zespołu i reagowania na nie. Pomaga to zwiększyć świadomość sytuacyjną i zmierzyć gotowość i skuteczność strategii DevSecOps.

Rozwijanie strategii gier wojennych

Gry wojenne są skuteczne w wzmacnianiu bezpieczeństwa, ponieważ motywują czerwoną drużynę do znajdowania i wykorzystywania problemów. Prawdopodobnie będzie o wiele łatwiej niż oczekiwano na początku. Zespoły, które nie próbowały aktywnie atakować własne systemy, zazwyczaj nie wiedzą o rozmiarze i ilości otworów zabezpieczających dostępnych dla atakujących. Niebieski zespół może być zdemoralizowany na początku, ponieważ będą one wielokrotnie biegać. Na szczęście system i praktyki powinny ewoluować wraz z upływem czasu, tak aby niebieski zespół konsekwentnie wygrywał.

Przygotowanie do gier wojennych

Przed rozpoczęciem gier wojennych zespół powinien dbać o wszelkie problemy, które mogą znaleźć za pośrednictwem przepustki bezpieczeństwa. Jest to doskonałe ćwiczenie do wykonania przed podjęciem próby ataku, ponieważ zapewni to środowisko odniesienia dla wszystkich, które można porównać z po znalezieniu pierwszego wykorzystania w dalszej części. Zacznij od zidentyfikowania luk w zabezpieczeniach za pomocą ręcznego przeglądu kodu i narzędzi do analizy statycznej.

Organizowanie zespołów

Czerwone i niebieskie zespoły powinny być zorganizowane przez specjalizację. Celem jest zbudowanie najbardziej zdolnych zespołów dla każdej strony, aby wykonać tak skutecznie, jak to możliwe.

Czerwony zespół powinien zawierać kilku inżynierów i deweloperów, którzy są głęboko zaznajomieni z kodem. Warto również rozszerzyć zespół o specjalistę od badań penetracyjnego, jeśli jest to możliwe. Jeśli nie ma specjalistów w firmie, wiele firm zapewnia tę usługę wraz z mentoringiem.

Niebieski zespół powinien składać się z inżynierów o poglądach operacyjnych, którzy mają głębokie zrozumienie dostępnych systemów i rejestrowania. Mają największe szanse na wykrywanie podejrzanych zachowań i reagowanie na nie.

Uruchamianie wczesnych gier wojennych

Spodziewaj się, że czerwona drużyna będzie skuteczna w pierwszych meczach wojennych. Powinny one być w stanie odnieść sukces poprzez dość proste ataki, takie jak znalezienie słabo chronionych wpisów tajnych, wstrzyknięcie kodu SQL i udane kampanie wyłudzania informacji. Zajmij dużo czasu między rundami, aby zastosować poprawki i opinie na temat zasad. Będzie to się różnić w zależności od organizacji, ale nie chcesz rozpoczynać następnej rundy, dopóki wszyscy nie będą pewni, że poprzednia runda została wydobyta dla wszystkich, co warto.

Trwające gry wojenne

Po kilku rundach czerwony zespół będzie musiał polegać na bardziej zaawansowanych technikach, takich jak skrypty między witrynami (XSS), luki w deserializacji i luki w zabezpieczeniach systemu inżynieryjnego. Wprowadzenie zewnętrznych ekspertów ds. zabezpieczeń w takich obszarach, jak usługa Active Directory, może być pomocne w celu ataku na bardziej niejasne luki. W tym czasie niebieski zespół powinien mieć nie tylko wzmocnioną platformę do obrony, ale będzie również korzystać z kompleksowego, scentralizowanego rejestrowania dla kryminalistycznych po naruszeniu zabezpieczeń.

"Obrońcy myślą na listach. Osoby atakujące myślą o grafach. Tak długo, jak to prawda, atakujący wygrają." - John Lambert (MSTIC)

W miarę upływu czasu czerwony zespół zajmie znacznie więcej czasu, aby osiągnąć cele. Gdy to zrobią, często wymaga odnajdywania i tworzenia łańcuchów wielu luk w zabezpieczeniach, aby mieć ograniczony wpływ. Korzystając z narzędzi do monitorowania w czasie rzeczywistym, niebieski zespół powinien zacząć łapać próby w czasie rzeczywistym.

Wytyczne

Gry wojenne nie powinny być free-for-all. Ważne jest, aby pamiętać, że celem jest stworzenie bardziej efektywnego systemu uruchamianego przez bardziej skuteczny zespół.

Kodeks postępowania

Oto przykładowy kodeks postępowania używany przez firmę Microsoft:

  1. Zarówno czerwone, jak i niebieskie zespoły nie zrobią szkody. Jeśli potencjalna przyczyna szkody jest znacząca, należy ją udokumentować i rozwiązać.
  2. Czerwony zespół nie powinien naruszać więcej niż to konieczne do przechwytywania zasobów docelowych.
  3. Reguły zdrowego rozsądku mają zastosowanie do ataków fizycznych. Podczas gdy czerwony zespół jest zachęcany do podejmowania kreatywnych ataków nietechnicznych, takich jak inżynieria społeczna, nie powinny drukować fałszywych znaczków, nękania ludzi itp.
  4. Jeśli atak inżynierii społecznej zakończy się powodzeniem, nie ujawniaj nazwiska osoby, która została naruszona. Lekcja może być udostępniana bez wyobcowania lub żenującego członka zespołu, z którym każdy musi kontynuować pracę.

Reguły zakontraktowania

Oto przykładowe reguły zaangażowania używane przez firmę Microsoft:

  1. Nie wpływaj na dostępność żadnego systemu.
  2. Nie należy uzyskiwać dostępu do danych klientów zewnętrznych.
  3. Nie należy znacznie osłabiać ochrony zabezpieczeń w miejscu w żadnej usłudze.
  4. Nie należy celowo wykonywać destrukcyjnych akcji względem żadnych zasobów.
  5. Sejf guard poświadczenia, luki w zabezpieczeniach i inne uzyskane informacje krytyczne.

Rezultaty

Wszelkie poznane zagrożenia bezpieczeństwa lub wnioski powinny być udokumentowane na liście prac dotyczących elementów naprawy. Zespoły powinny zdefiniować umowę dotyczącą poziomu usług (SLA), aby dowiedzieć się, jak szybko zostaną rozwiązane zagrożenia bezpieczeństwa. Poważne zagrożenia powinny być rozwiązywane tak szybko, jak to możliwe, podczas gdy drobne problemy mogą mieć termin dwóch przebiegów.

Raport powinien zostać przedstawiony całej organizacji z lekcjami wyciągniętymi i znalezionymi lukami w zabezpieczeniach. Jest to okazja do nauki dla wszystkich, więc w większości.

Wnioski zdobyte w firmie Microsoft

Firma Microsoft regularnie praktykuje gry wojenne i nauczyła się wielu lekcji po drodze.

  • Gry wojenne to skuteczny sposób na zmianę kultury DevSecOps i utrzymanie bezpieczeństwa na najwyższym poziomie umysłu.
  • Ataki wyłudzania informacji są bardzo skuteczne dla osób atakujących i nie należy ich lekceważyć. Wpływ może być zawarty przez ograniczenie dostępu do środowiska produkcyjnego i wymaganie uwierzytelniania dwuskładnikowego.
  • Kontrola systemu inżynieryjnego prowadzi do kontroli nad wszystkim. Pamiętaj, aby ściśle kontrolować dostęp do agenta kompilacji/wydania, kolejki, puli i definicji.
  • Przećwicz ochronę w głębi systemu, aby utrudnić atakom. Każda granica, którą muszą naruszyć, spowalnia je i oferuje kolejną okazję do ich złapania.
  • Nigdy nie należy przekraczać obszaru zaufania. Produkcja nigdy nie powinna ufać niczego w teście.

Następne kroki

Dowiedz się więcej na temat cyklu projektowania zabezpieczeń i metodyki DevSecOps na platformie Azure.