Udostępnij za pośrednictwem

Bezpieczeństwo w DevOps (DevSecOps)

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ź brzmi nie. 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 się dostać, to się dostanie..., zaakceptuj to. Co mówimy klientom: numer jeden, jesteś w walce, niezależnie od tego, czy myślisz, że jesteś, czy nie. Po drugie, prawie na pewno zostały 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 przedstawią pewne typowe argumenty, takie 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 doszło do naruszenia zabezpieczeń. 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 mogą one wystąpić.

Składniki strategii zabezpieczeń

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

Zapobieganie naruszeniom Zakładając naruszenia
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 doszło do naruszenia u Ciebie, może być trudne do przyjęcia, zwłaszcza podczas trudnych rozmów z zarządem, ale to założenie może pomóc Ci odpowiedzieć na pytania dotyczące zabezpieczeń w dogodnym dla siebie czasie. Nie chcesz rozgryźć tego wszystkiego 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ę warstwową. Gdy dojdzie do naruszenia, osoby atakujące mogą uzyskać dostęp do sieci wewnętrznych i wszystkich elementów w nich. Chociaż idealnie byłoby zatrzymać atakujących, zanim zajdzie to tak daleko, polityka zakładająca naruszenia skłania zespoły do minimalizowania narażenia w przypadku atakującego, który już dostał się do systemu.

Na koniec należy przeprowadzać okresowe oceny po naruszeniach 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 utrzymanie ich aktualności jest krytyczne. Inne są spowodowane usterkami w kodzie systemowym, które wymagają starannej analizy w celu znalezienia i naprawienia. Złe zarządzanie tajemnicami 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ć?

Przywilej 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?

  • Przechowuj tajemnice w chronionych skarbcach
  • Usuwanie kont administratorów lokalnych
  • Ogranicz SAMR
  • Ochrona poświadczeń
  • Usuwanie serwerów podwójnie przyłączonych
  • Oddzielne subskrypcje
  • Uwierzytelnianie wieloskładnikowe
  • Stacje robocze z dostępem uprzywilejowanym
  • Wykrywanie za pomocą usługi ATP i usługi Microsoft Defender for Cloud

Zarządzanie sekretami

Wszystkie tajemnice muszą być przechowywane w chronionym skarbcu. Tajne informacje obejmują:

  • Hasła, klucze i tokeny
  • Klucze konta magazynowego
  • Certificates
  • Poświadczenia używane również w współdzielonych środowiskach nieprodukcyjnych

Aby wyeliminować duplikowanie tajemnic, należy użyć hierarchii skarbców. Należy również rozważyć, w jaki sposób i kiedy uzyskuje się dostęp do danych poufnych. Niektóre są używane w czasie wdrażania podczas tworzenia konfiguracji środowiska, podczas gdy inne są dostępne w czasie wykonywania. Tajne dane w czasie wdrażania zwykle wymagają ponownego wdrożenia, aby wprowadzić nowe ustawienia, natomiast tajne dane w czasie wykonywania są dostępne w razie potrzeby i mogą być aktualizowane w dowolnym momencie.

Platformy mają bezpieczne funkcje magazynu do zarządzania tajemnicami w potokach CI/CD i środowiskach chmurowych, takich jak Azure Key Vault i GitHub Actions.

Przydatne narzędzia

  • Usługa Microsoft Defender for Cloud 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żna wykorzystać czerwony zespół do łatwego identyfikowania wektorów ataku, które są trudne do szybkiego identyfikowania.

Ć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ą oni wielokrotnie przegrywać. 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 rozwiązać wszelkie problemy, które mogą zostać wykryte podczas przepustki bezpieczeństwa. Jest to doskonałe ćwiczenie do wykonania przed podjęciem próby ataku, ponieważ zapewni ono punkt odniesienia dla wszystkich, który można będzie porównać po znalezieniu pierwszej luki w późniejszych etapach. 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 działali tak skutecznie, jak to możliwe.

Czerwony zespół powinien składać się z kilku inżynierów ds. bezpieczeństwa 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 zorientowanych na operacje, którzy mają głębokie zrozumienie dostępnych systemów i logowania. 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. Poświęć dużo czasu między rundami na wprowadzenie poprawek i uwzględnienie opinii dotyczących 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 w pełni wykorzystana.

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 analiz postincidentowych 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 wykrywania i łączenia wielu luk w zabezpieczeniach, aby osiągnąć ograniczony wpływ. Korzystając z narzędzi do monitorowania w czasie rzeczywistym, niebieski zespół powinien zacząć wychwytywać próby w czasie rzeczywistym.

Guidelines

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. Chociaż czerwona drużyna jest zachęcana do kreatywności w atakach nietechnicznych, takich jak inżynieria społeczna, nie powinna drukować fałszywych legitymacji, nękać 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 wywoływania poczucia wyobcowania lub zakłopotania u 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. Zabezpieczanie poświadczeń, luk w zabezpieczeniach i innych uzyskanych informacji krytycznych.

Rezultaty

Wszelkie poznane zagrożenia bezpieczeństwa lub wnioski powinny być udokumentowane w rejestrze prac naprawczych. 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 sprintó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 skorzystaj z niej jak najlepiej.

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 w centrum uwagi.
  • Ataki wyłudzania informacji są bardzo skuteczne dla osób atakujących i nie należy ich lekceważyć. Wpływ można ograniczyć przez ograniczenie dostępu do środowiska produkcyjnego i wymaganie uwierzytelniania dwuskładnikowego.
  • Kontrola systemu inżynieryjnego prowadzi do kontroli nad wszystkim. Pamiętaj, aby dokładnie monitorować dostęp do agenta kompilacji/wydania, kolejki, puli i definicji.
  • Praktykuj obronę w głąb, aby utrudnić atakującym. 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ć środowisku testowemu.

Dalsze kroki

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

  • Last updated on