Integrowanie modelowania zagrożeń z usługą DevOps
Ten post jest autorstwa Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez i Ben Hanson
Wprowadzenie
Modelowanie zagrożeń to ważna metoda zabezpieczeń, która pomaga identyfikować i ustalać priorytety najważniejszych środków zaradczych dotyczących ryzyka dla aplikacji lub systemu. Ten dokument zawiera pewne refleksje na temat sposobu, w jaki można efektywniej i wydajniej wdrażać modelowanie zagrożeń, integrować je z nowoczesnymi metodologiami i narzędziami Metodyki DevOps oraz skupiać się na wartości udostępnianej wszystkim różnym podmiotom zaangażowanym w cykl projektowania oprogramowania.
Czy ten papier jest dla Ciebie?
Ten dokument jest wynikiem pracy małego zespołu ekspertów ds. zabezpieczeń i modelowania zagrożeń firmy Microsoft oraz zawiera dane wejściowe i pomysły niektórych z najbardziej znanych ekspertów spoza firmy Microsoft. Próbuje rozwiązać proste, ale pilne pytanie: co powinniśmy zrobić, aby upewnić się, że używany przez nas proces modelowania zagrożeń został zaktualizowany do nowoczesnych wymagań narzuconych przez metodologie Agile i metodykę DevOps, aby zapewnić wymaganą wartość przy najniższym koszcie?
Jeśli jesteś właścicielem produktu, członkiem zespołu ds. zabezpieczeń lub po prostu deweloperem, który rozważa wdrożenie modelowania zagrożeń w ramach cyklu projektowania, ten dokument jest przeznaczony dla Ciebie.
Analogicznie, jeśli już przyjęto modelowanie zagrożeń, nadal możesz znaleźć praktyczne pomysły na ulepszenie procesu.
Niemniej jednak dokument ma na celu wprowadzenie pomysłów na ulepszenie bieżących procesów lub pomyślne wdrożenie modelowania zagrożeń w ramach procesu DevOps. Nie wprowadza konkretnych narzędzi ani produktów, nawet jeśli mamy nadzieję zobaczyć te pomysły zaimplementowane przez niektóre narzędzia lub produkty w przyszłości. W związku z tym nie znajdziesz tutaj anonsów nowych narzędzi ani wersji zapoznawczych nadchodzących funkcji.
Dlaczego modelowanie zagrożeń jest ważne?
Modelowanie zagrożeń to jedno z podstawowych podejść do bezpiecznego projektowania rozwiązań programowych. Dzięki modelowaniu zagrożeń analizujesz wektory ataków i opracowujesz akcje w celu zmniejszenia ryzyka spowodowanego tymi atakami. Odpowiednio zrobione modelowanie zagrożeń jest doskonałym składnikiem dowolnego procesu zarządzania ryzykiem. Może również pomóc zmniejszyć koszty, identyfikując i naprawiając problemy projektowe na wczesnym etapie. Stare badanie firmy NIST oszacowało, że koszt rozwiązania problemu projektowego w kodzie produkcyjnym będzie około 40 razy wyższy niż naprawa go w fazie projektowania. Pozwala również zaoszczędzić na ponoszeniu kosztów z powodu zdarzeń zabezpieczeń w przypadku ewentualnych problemów z projektowaniem. Należy wziąć pod uwagę, że raport kosztu naruszenia danych z 2022 r. z IBM Security i Ponemon Institute szacuje średni koszt naruszenia danych na 4,35 mln USD. Dla tak zwanych Mega Breaches, z udziałem kompromisu ponad 50 milionów rekordów, średni koszt osiągnie 387 milionów dolarów!
Modelowanie zagrożeń to pierwsze działanie, które można wykonać, aby zabezpieczyć rozwiązanie, ponieważ działa w projekcie rozwiązania. Ta cecha sprawia, że jest to najbardziej efektywna praktyka zabezpieczeń, którą można zastosować do SDLC.
Firma Microsoft ma długą historię modelowania zagrożeń. W 1999 r. dwóch (wówczas) pracowników firmy Microsoft, Loren Kohnfelder i Praerit Garg, napisało dokument " Zagrożenia dla naszych produktów". W tym dokumencie przedstawiono podejście STRIDE, synonim procesu modelowania zagrożeń firmy Microsoft.
Modelowanie zagrożeń to proces ewolucyjny
Modelowanie zagrożeń nie jest procesem statycznym; rozwija się wraz ze zmianą potrzeb i technologii.
Ataki łańcucha dostaw, takie jak ostatnie ukierunkowane na SolarWinds , pokazują potrzebę pokrycia z modelowaniem zagrożeń więcej scenariuszy niż samo rozwiązanie, w tym programowanie i wdrażanie.
Luki w zabezpieczeniach typu open source, takie jak ostatnio używane w usłudze Log4j , wykazały potrzebę uzupełnienia bieżącego podejścia opartego na wdrożeniu narzędzi analizy kompozycji oprogramowania w celu skanowania pod kątem wrażliwych składników przez zaprojektowanie rozwiązania w defensywie w celu ograniczenia jego narażenia.
Zastosowanie nowych technologii, takich jak Machine Edukacja, wprowadza nowe wektory ataków, które muszą być zrozumiałe i kontrolowane. Rozważmy na przykład możliwość odtwarzania złośliwie spreparowanych dźwięków niesłyszalnych przez ludzkie uszy, aby spowodować wykonanie poleceń przez usługi sztucznej inteligencji, jak opisano w temacie https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.
W firmie Microsoft różne grupy produktów praktykują różne warianty modelowania zagrożeń na podstawie określonych wymagań dotyczących zabezpieczeń. Każdy wariant ma na celu zagwarantowanie odpowiedniego poziomu bezpieczeństwa dla scenariuszy, do których jest stosowany, ale to, co "odpowiednie" oznacza zmiany w zależności od konkretnego kontekstu.
Na przykład zabezpieczanie systemu Windows różni się od zabezpieczania usług Azure Cognitive Services, ponieważ te systemy mają bardzo różne rozmiary i cechy. Kluczowym aspektem modelowania zagrożeń jest równoważenie kosztów względem tolerancji ryzyka dla aplikacji. Chociaż może to prowadzić do podjęcia decyzji o całkowitej unikaniu modelowania zagrożeń w niektórych scenariuszach, jest ona tak skuteczna, gdy zostanie prawidłowo wykonana, że możemy zalecić wdrożenie jej tylko dla dowolnej inicjatywy IT, w tym projektów tworzenia oprogramowania i wdrażania infrastruktury.
Znaczenie skupienia się na zwrotach z inwestycji
Ostatnie kilka lat odnotowało stały wzrost zainteresowania modelowaniem zagrożeń jako kluczowy proces tworzenia oprogramowania. Jest to spowodowane wykładniczym wzrostem ataków na infrastrukturę i rozwiązania. Inicjatywy takie jak zalecany minimalny standard NIST dla dostawcy lub weryfikacji kodu dla deweloperów i manifest modelowania zagrożeń dodatkowo zwiększyły zapotrzebowanie na to, że obecne podejścia wykazały pewne limity. Na przykład wyniki modelowania zagrożeń są bardzo zależne od przyjętego procesu i od tego, kto wykonuje model zagrożenia. W związku z tym istnieje obawa o coraz spójnie wyższą jakość z doświadczenia.
Ale co oznacza jakość modelowania zagrożeń? Dla nas model zagrożenia jakości musi mieć następujące cechy:
Musi zidentyfikować środki zaradcze, działania, które można wykonać, aby zmniejszyć potencjalne straty wynikające z ataków. Możliwość działania oznacza, że te środki zaradcze muszą być dobrze zdefiniowane, co oznacza, że uzyskasz wystarczającą ilość informacji, aby je zaimplementować, a następnie przetestować implementację. Oznacza to również, że muszą one być udostępniane w celu umożliwienia łatwego użycia przez zespół programistyczny. W przypadku metodyki DevOps i metodyki Agile oznacza to, że istnieje łatwa ścieżka do importowania środków zaradczych do listy prac.
Dla każdego środki zaradcze należy zidentyfikować jego stan. Niektóre środki zaradcze są nowe, a inne już istnieją. Model zagrożeń musi rozpoznać, co już istnieje, i skupić się na bieżącym ryzyku, aby zidentyfikować, jak poprawić sytuację.
Musi wyraźnie określić, dlaczego każde ograniczenie ryzyka jest wymagane przez połączenie go z odpowiednimi zagrożeniami.
Ponadto środki zaradcze mają względną siłę dla każdego zagrożenia. Na przykład szyfrowanie TLS może być silnym ograniczeniem ryzyka ujawnienia danych podczas przesyłania, a jednocześnie może to być niemal całkowite ograniczenie ryzyka fałszowania serwera.
Zagrożenia muszą być wiarygodne, dobrze zdefiniowane i specyficzne dla rozwiązania.
Zagrożenia muszą mieć skojarzona ważność, która powinna uwzględniać zarówno ich prawdopodobieństwo, jak i wpływ. Ważność musi być rozsądna i idealnie bezstronna.
Powinno być możliwe uzyskanie kompleksowego wglądu w ryzyko i sposoby ich rozwiązania. Ten pogląd odegrałby kluczową rolę w prowadzeniu znaczącej rozmowy z zespołem ds. zabezpieczeń i osobami podejmującymi decyzje biznesowe, co pozwoliłoby nam ukryć niepotrzebne złożoności.
Ta lista zawiera już ważną koncepcję: modelowanie zagrożeń może zapewnić wartość wielu ról zaangażowanych w cykl życia oprogramowania, ale każda rola ma różne potrzeby i wymagania. Na przykład deweloperzy muszą otrzymywać jasne informacje o tym, co muszą zaimplementować, oraz o tym, jak sprawdzić, czy zaimplementowane przez nich działania zachowują się zgodnie z oczekiwaniami. Z drugiej strony zespół ds. zabezpieczeń jest zwykle zaniepokojony ogólnym bezpieczeństwem ekosystemu infrastruktury i aplikacji należących do organizacji; w związku z tym muszą otrzymywać informacje umożliwiające podjęcie decyzji, czy system w zakresie jest wystarczająco bezpieczny i spełnia wymagania dotyczące zgodności. Wreszcie, właściciele produktów i osoby podejmujące decyzje biznesowe muszą zrozumieć, co jest konieczne, aby ryzyko akceptowalne dla organizacji.
Takie różne potrzeby wymagają udostępnienia różnych widoków modelu zagrożeń, z których każdy koncentruje się na konkretnym scenariuszu użycia.
Typowy problem z modelowaniem zagrożeń polega na tym, że im bardziej się uda, tym trudniej jest niewielu dostępnych ekspertów pokryć zapotrzebowanie, jednocześnie zapewniając wysoką jakość oczekiwaną z tego doświadczenia. W niektórych przypadkach jakość może mieć negatywny wpływ na jakość. Wszystko jest dobre, dopóki modelowanie zagrożeń przestanie zapewniać znaczącą wartość w porównaniu z inwestycją. Ten problem ma wpływ na więcej niż kilka organizacji. Istnieje już kilka raportów osób podejmujących decyzje biznesowe, które zaczynają kwestionować modelowanie zagrożeń, ponieważ nie przyniesie znaczącej wartości kosztów.
Z wartością odwołujemy się do wartości biznesowej, która jest możliwością dostarczania informacji potrzebnych do zrozumienia ryzyka reprezentowanego przez system w zakresie i napędzania znaczącego procesu decyzyjnego w celu wybrania odpowiednich środków zaradczych do wdrożenia. Ponadto wartość jest również związana z dostarczaniem prawidłowych informacji deweloperom i testerom. Wreszcie wartość jest związana z komunikowaniem ryzyka resztowego ze wszystkimi zaangażowanymi stronami. Możemy na przykład zmierzyć wartość, mierząc wpływ procesu modelowania zagrożeń. Załóżmy, że mierzymy ogólne ryzyko dla rozwiązania, przypisując liczbę do ważności zidentyfikowanej dla każdego zagrożenia. W takim przypadku oczekujemy, że ogólne ryzyko spadnie wraz z upływem czasu na efekt modelu zagrożeń. Jeśli ogólne ryzyko pozostaje stałe lub wzrasta, możemy mieć problem. Im stromy spadek, tym większy wpływ modelu zagrożenia. Oczywiście model zagrożenia nie będzie kontrolować wdrożonych środków zaradczych. Właściciel produktu jest odpowiedzialny za podjęcie decyzji o tym, co należy zaimplementować. Jednak zaletą powiązania skuteczności modelu zagrożeń z rzeczywistą implementacją środków zaradczych jest zwiększenie wpływu na rzeczywiste bezpieczeństwo rozwiązania, co zmniejsza ryzyko, że model zagrożeń pozostaje teoretycznym ćwiczeniem.
Zamiast tego koszt jest związany z działaniami niezbędnymi do wykonania samego modelu zagrożeń, który jest wymagany przez wszystkie zaangażowane strony do utworzenia modelu zagrożeń i omówienia go.
To pytanie brzmi: czy możemy zdefiniować proces modelowania zagrożeń skoncentrowany na maksymalizacji wartości biznesowej i zminimalizowaniu kosztów?
Znaczenie metodyki DevOps
Podkreśliliśmy już, jak ważne jest zapewnienie, że modelowanie zagrożeń jest cenną praktyką zintegrowaną z procesem DevOps. Oznacza to, że proces musi być dostępny dla wszystkich członków zespołu, zazwyczaj przez uproszczenie i automatyzację. Co najważniejsze, skupienie się na modelowaniu zagrożeń dla metodyki DevOps oznacza, że musimy upewnić się, że środowisko jest głęboko zintegrowane z istniejącymi procesami DevOps.
Modelowanie zagrożeń nie powinno stać się jeszcze kolejnym obciążeniem, ale zamiast tegopowinno to być elementem zawartości ułatwiającym wywoływanie i zbieranie wymagań dotyczących zabezpieczeń, projektowanie bezpiecznych rozwiązań, dołączanie działań do wybranego narzędzia Task & Bug Tracking oraz ocenę pozostałego ryzyka ze względu na bieżący i przyszły stan rozwiązania.
Wyrównanie do metodyki DevOps
Możemy stosować różne techniki, aby dopasować modelowanie zagrożeń do bieżącej praktyki DevOps.
Zagrożenia i środki zaradcze
Najpierw musimy skoncentrować proces modelowania zagrożeń na tym, co należy zrobić. Zagrożenia, które są wzorcami ataków i sposobem ich wprowadzania, są niezbędne, aby wyjaśnić, dlaczego zespół musi zaimplementować kontrolę zabezpieczeń. Są one również czynnikiem określania, kiedy należy wdrożyć środki zaradcze. Mimo to prawdziwym celem jest określenie, co należy zrobić: środki zaradcze. W związku z tym podejście musi prowadzić do szybkiej identyfikacji wymaganych środków zaradczych i musi poinformować proces decyzyjny, aby ułatwić określenie, co należy zrobić i kiedy. Głównym elementem tego procesu decyzyjnego jest posiadanie wybranych środków zaradczych na liście prac, aby były one częścią standardowego procesu. W idealnym przypadku narzędzie do modelowania zagrożeń i narzędzie do śledzenia błędów i zadań powinny być synchronizowane w celu odzwierciedlenia aktualizacji stanu ograniczania ryzyka w modelu zagrożeń. Pozwoliłoby to na dynamiczne i automatyczne zmianę ryzyka resztowego, co ma kluczowe znaczenie dla wspierania świadomych decyzji w ramach zwykłych choreografii przyjętej metodologii Agile, takiej jak spotkanie planowania przebiegu.
Co możesz zrobić dzisiaj?
Jako ekspert ds. modelowania zagrożeń należy zapewnić zaimplementowanie procesu modelowania zagrożeń, który umożliwia wyraźne zidentyfikowanie akcji i dołączenie ich do wybranego zadania i śledzenia błędów. Jednym ze sposobów może być wdrożenie jednego z wielu narzędzi do modelowania zagrożeń, które może zautomatyzować ten proces.
Jako deweloper należy skoncentrować się na mechanizmach kontroli zabezpieczeń, które są identyfikowane w razie potrzeby. Proces powinien zostać zaprojektowany w taki sam sposób, w jaki oczekujesz, że otrzymasz inne działania.
Funkcje, scenariusze użytkowników i zadania
Stwierdziliśmy już, że środki zaradcze stanowią najważniejszy artefakt wygenerowany przez model zagrożenia dotyczący integracji metodyki DevOps. Dlatego ważne jest, aby jasno zdefiniować typ obiektów utworzonych z tych środków zaradczych w wybranym narzędziu Do śledzenia zadań i usterek. Niektóre środki zaradcze mogą trwać dłużej niż przebieg. W związku z tym najlepszym rozwiązaniem może być utworzenie ich jako funkcji. Ale wiele z tych elementów jest łatwiejszych i można je zaimplementować w jednym przebiegu; w związku z tym można je przedstawić jako scenariusze lub zadania użytkownika. Generowanie różnych typów elementów roboczych może być możliwe, ale może to spowodować skomplikowany proces, który może prowadzić do błędów i nieporozumień. Z tego powodu wydaje się bardziej praktyczne, aby trzymać się jednego typu elementu roboczego. Biorąc pod uwagę, że środki zaradcze mogą być traktowane jako elementy podrzędne historii użytkownika, można rozważyć reprezentowanie ich jako zadania, co oznacza złagodzenie wymogu wykonania określonego typu elementu roboczego w jednym przebiegu.
Co możesz zrobić dzisiaj?
Upewnij się, że środki zaradcze zidentyfikowane przez model zagrożeń są reprezentowane na liście prac. Zidentyfikuj sposób, aby wyraźnie je przedstawić.
Scenariusze użytkownika
Środki zaradcze nie są jedynymi artefaktami częścią modelu zagrożeń, które mogą i powinny być dostosowane do elementów dostępnych w narzędziu Do śledzenia zadań i usterek. Na przykład możesz również reprezentować zagrożenia. Ten cel można osiągnąć, rozszerzając historie użytkowników poprzez dodanie klauzuli WITHOUT do zwykłego "Jako [kim jestem] chcę [co chcę] tak, abym mógł [zrobić coś]." Na przykład: "Jako użytkownik chcę zapłacić kartą kredytową, abym mógł kupić niektóre towary bez kradzieży karty kredytowej". Klauzula WITHOUT może być mapowana na co najmniej jedno zagrożenie, a czasami może wyrazić wymagania dotyczące zabezpieczeń. Dzięki zapewnieniu, że to dopasowanie między klauzulami zagrożenia i WITHOUT jest jawne w modelu zagrożeń, możemy zapewnić, że możliwe zagrożenia zostaną odzwierciedlone i uwzględnione przez zespół, ponieważ są one uwzględniane jako część historii użytkowników. Możesz również użyć tej relacji, aby zamapować każde wymaganie zabezpieczeń zidentyfikowane jako część scenariuszy użytkownika na co najmniej zagrożenie.
Miło wiedzieć
Klauzula WITHOUT nie jest oryginalną ideą zespołu, który wyprodukował tę stronę. Nie jesteśmy pewni, kto po raz pierwszy go wprowadził, ale jesteśmy wdzięczni za to, kto przyszedł z tym pomysłem.
Rysunek 1. Dopasowywanie wymagań
Na przykład na poprzedniej ilustracji przedstawiono następujące sytuacje:
Zagrożenie A jest połączone z scenariuszem użytkownika 1 za pośrednictwem klauzuli WITHOUT 1.
Zagrożenie B jest połączone z scenariuszem użytkownika 2 za pośrednictwem klauzuli WITHOUT 2.
Zagrożenie B jest również połączone z scenariuszem użytkownika 3. Ale scenariusz użytkownika 3 nie jest przypisany do żadnej klauzuli WITHOUT. Dlaczego? Reprezentuje potencjalną anomalię, którą należy zbadać.
Zagrożenie B jest również połączone z scenariuszem użytkownika 1. Nie jest jeszcze jasne, czy powinniśmy zezwolić na używanie historii użytkowników połączonych z więcej niż jednym zagrożeniem.
Zagrożenie C jest połączone z scenariuszem użytkownika 4, który jest skojarzony z BEZ 3 i 4. Nie jest jeszcze jasne, czy powinniśmy zezwolić na posiadanie więcej niż jednej klauzuli WITHOUT.
Zagrożenie D nie jest połączone z żadną historią użytkownika. Czy brakuje artykułu użytkownika, czy klauzuli WITHOUT?
Scenariusz użytkownika 5 jest połączony z klauzulą WITHOUT, ale nie ma skojarzonego zagrożenia. Czy brakuje zagrożenia, czy po prostu łącza między historią użytkownika a zagrożeniem?
Rzadko identyfikujemy wymagania dotyczące zabezpieczeń w ramach modelu zagrożeń. W związku z tym klauzula WITHOUT wprowadza możliwość dalszej integracji środowiska przez rozszerzenie modeli zagrożeń z wymaganiami dotyczącymi zabezpieczeń i połączenie ich z powiązanymi scenariuszami użytkownika. Takie podejście odgrywałoby znaczącą rolę w ewolucji środowiska modelowania zagrożeń z powodu powtarzania oceny w miarę upływu czasu, aby stać się narzędziem do projektowania zabezpieczeń dla metodyki DevOps.
Co możesz zrobić dzisiaj?
Zacznij używać klauzuli WITHOUT w scenariuszach użytkownika.
Mapuj zagrożenia, które identyfikujesz na scenariusze użytkowników, z klauzulami WITHOUT i na odwrót.
Zintegrowane środowisko
Ten sam pomysł można zastosować do innych scenariuszy. Na przykład model zagrożeń może połączyć wymagania dotyczące zabezpieczeń z artefaktami wewnątrz samego modelu zagrożeń — takimi jak zagrożenia i środki zaradcze — oraz te w narzędziu Śledzenie śledzenia błędów i śledzenia usterek. Na przykład wymóg wdrożenia monitorowania w celu identyfikowania ataków w toku powinien zostać zamapowany na wszystkie te środki zaradcze związane z monitorowaniem, a następnie do odpowiednich artefaktów w narzędziu Do śledzenia zadań i błędów. W związku z tym łatwo byłoby zidentyfikować sytuacje, w których nie zrealizowano wymagania dotyczącego zabezpieczeń: w rzeczywistości nie byłoby to związane z czymkolwiek.
Możesz użyć tych samych łączy między artefaktami w narzędziu Task & Bug Tracking oraz zagrożeniami i środki zaradcze zidentyfikowane przez model zagrożeń, aby ułatwić ustalanie priorytetów działań zabezpieczeń. Zabezpieczenia są zwykle wdrażane ostatnio, czasami w celu rozwiązania reaktywnych luk w zabezpieczeniach zidentyfikowanych przez niektóre narzędzie lub test penetracyjny. Wręcz przeciwnie, najbardziej skuteczne byłoby wdrożenie środków zaradczych wraz z powiązanymi scenariuszami lub funkcjami użytkowników. Dlaczego poczekaj na zaimplementowanie mechanizmów kontroli w celu zabezpieczenia szczegółów karty kredytowej, kiedy należy je zaimplementować wraz z powiązanymi funkcjami płatności? Model zagrożeń powinien wyróżnić te relacje i zapewnić prosty sposób określenia podczas implementowania niektórych funkcji podczas przebiegu wymaga implementacji niektórych powiązanych funkcji zabezpieczeń. Te informacje mogą być używane, na przykład podczas spotkania planowania przebiegu, aby uzyskać znaczącą dyskusję i prowadzić do świadomej priorytetyzacji. Mechanizm jest prosty. Załóżmy, że właściciel produktu dla projektu, nad który pracujemy, decyduje się zaplanować historię użytkownika na potrzeby następnego przebiegu. Ta historia użytkownika ma klauzulę WITHOUT, która jest powiązana z zagrożeniem. Model zagrożeń identyfikuje kilka środków zaradczych dla tego samego zagrożenia. W związku z tym możemy od razu stwierdzić, że powinniśmy określić priorytety co najmniej jednego zidentyfikowanego ograniczenia ryzyka.
Rysunek 2. Ustalanie priorytetów zabezpieczeń
Na przykład na powyższym obrazie widać, że historia użytkownika 1 jest połączona z zagrożeniem 1, co z kolei jest powiązane z ograniczeniem ryzyka A i B. W związku z tym powinniśmy również rozważyć wdrożenie jednego lub obu tych środków zaradczych.
Co możesz zrobić dzisiaj?
Połącz scenariusze użytkowników z klauzulami WITHOUT z elementami roboczymi odpowiadającymi wybranym zaradczem przy użyciu modelu zagrożeń jako odwołania. Podczas planowania następnego przebiegu pamiętaj, aby określić priorytety połączonych działań zabezpieczeń podczas implementowania jednego z tych scenariuszy użytkownika z klauzulami WITHOUT.
Integracja w celu wyróżnienia niezgodności
Gdy zaczniemy myśleć o tym, jak możemy połączyć artefakty komponujące model zagrożenia z tymi w narzędziu Do śledzenia zadań i usterek, łatwiej będzie zidentyfikować możliwości poprawy jakości obu tych elementów. Kluczem jest wykorzystanie ich relacji w celu wyróżnienia rozbieżności i wykorzystania informacji obecnych w jednym, aby uzupełnić, zintegrować i interpretować, co jest obecne w drugiej. Jak wspomniano powyżej, możesz to zrobić bez znaczącego wpływu na to, jak działa już zespół. Wynika to z faktu, że podejście opiera się na istniejących informacjach i tworzy relacje między różnymi obiektami w różnych światach. W związku z tym model zagrożeń stałby się źródłem prawdy dla bezpieczeństwa rozwiązania. Jednocześnie lista prac jest stale zgodna ze stanem rozwiązania.
Co możesz zrobić dzisiaj?
Regularnie sprawdzaj, czy nie ma niezamapowanych zagrożeń ani scenariuszy użytkowników z klauzulami WITHOUT.
Modelowanie zagrożeń i operacje
Wszystkie te pomysły koncentrują się głównie na stronie opracowywania metodyki DevOps. Czy możemy zrobić coś, aby ulepszyć operacje? Uważamy, że tak. Na przykład byłoby możliwe użycie modelowania zagrożeń jako narzędzia do ułatwienia analizy głównej przyczyny, ponieważ zapewnia kompleksowy widok systemu z perspektywy zabezpieczeń, a tym samym może zapewnić lepsze zrozumienie skutków niektórych ataków. Aby to osiągnąć, konieczne byłoby zintegrowanie modelu zagrożeń z istniejącymi kanałami informacyjnymi z wybranych narzędzi do monitorowania. To podejście może stanowić uzupełnienie wybranego rozwiązania SIEM.
Innym pomysłem na integrowanie modelowania zagrożeń z operacjami jest użycie pierwszego do opracowania sposobu, w jaki ten ostatni może się zdarzyć. Przykładem jest projekt zdarzeń dla rozwiązania. Modelowanie zagrożeń identyfikuje możliwe ataki i możemy użyć tej wiedzy, aby zidentyfikować zdarzenia, które rozwiązanie w zakresie może podnieść, gdy te ataki kończą się niepowodzeniem. Jeśli wykonasz ścisłą walidację danych wejściowych, złośliwy atakujący będzie potrzebował kilku prób przed powodzeniem. Początkowo próby kończą się niepowodzeniem, a jeden z nich ostatecznie się powiedzie. Podnosząc zdarzenia dla każdego błędu i wyzwalając alerty po osiągnięciu pewnego progu, możesz wykryć ataki i podjąć działania w celu ich skorygowania. Te sytuacje są rzadko wykrywane, jeśli ograniczasz się do monitorowania infrastruktury. W związku z tym konieczne jest uwzględnienie zdarzeń niestandardowych, które zespół musi zaprojektować i zaimplementować, zanim soC będzie mógł je wykorzystać.
Co więcej, ten ostatni może nie wiedzieć zbyt wiele o rozwiązaniu. W związku z tym soC może nie być w stanie określić, jak reagować, gdy walidacja danych wejściowych zakończy się niepowodzeniem. Niestety, w przypadku wystąpienia naruszenia danych konieczne jest szybkie reagowanie w celu zmniejszenia bezpośrednich szkód oraz prawdopodobieństwa i jednostki ewentualnych kar.
Dlatego musimy zaplanować z wyprzedzeniem to, co należy monitorować, w jakich warunkach możemy mieć problem i co zrobić, gdy tak się stanie. Najlepszym sposobem zidentyfikowania tych zdarzeń jest poleganie na modelu zagrożeń. W związku z tym warto wykorzystać go do generowania ustandaryzowanych artefaktów w celu przeprowadzenia i przyspieszenia implementacji niezbędnych konfiguracji w celu umożliwienia monitorowania i inspekcji oraz ułatwienia reagowania na zdarzenia.
Co możesz zrobić dzisiaj?
Aktywnie używaj modelu zagrożeń do identyfikowania zdarzeń, które można zgłaszać dla każdego zagrożenia. Te zdarzenia mogą być dostarczane przez infrastrukturę lub coś, co aplikacja musi zgłosić. Uwzględnij elementy robocze na liście prac, aby upewnić się, że te zdarzenia są implementowane.
Aktywnie współpracuj z zespołami ds. operacji i zabezpieczeń, w tym z zespołem SOC, aby upewnić się, że zdarzenia są używane do zgłaszania alertów i identyfikowania zdarzeń zabezpieczeń.
Wpływ na zwrot z inwestycji
Możesz się zastanawiać, dlaczego te techniki mogą pozytywnie wpłynąć na zwrot z inwestycji w modelowanie zagrożeń. Z naszego punktu widzenia mają kluczowe znaczenie dla zwiększenia wartości modelowania zagrożeń dla zespołów DevOps. Problem, który widzieliśmy wielokrotnie, polega na tym, że te zespoły postrzegają bezpieczeństwo jako koszt zapewniający ograniczoną wartość i wymagają znacznie nieprzewidzianej pracy. Czasami nie jest jasne, dlaczego powinni inwestować tak wiele czasu, aby naprawić bezpieczeństwo. W rezultacie zabezpieczenia stają się problemem, a nie szansą. Modelowanie zagrożeń może przezwyciężyć te problemy, ponieważ zapewnia powody implementacji zabezpieczeń. Ponadto można go uruchomić na wczesnym etapie procesu programowania i uniknąć błędów projektowych, które mogą kosztować drogo, jeśli nie zostanie wykryte wkrótce. Powyższe techniki mają na celu lepszą integrację modelowania zagrożeń z usługą DevOps. Dzięki temu osoby podejmujące decyzje biznesowe i deweloperzy postrzegają modelowanie zagrożeń jako naturalne uzupełnienie procesu programowania i operacji. W związku z tym wartość otrzymana przez wdrożenie modelowania zagrożeń zwiększa się, a jej koszty spadają z powodu integracji z różnymi narzędziami, które są już używane.
Upraszczanie pracy dla osób modelujących zagrożenia
Innym ważnym aspektem niezbędnym do poprawy zwrotu z inwestycji w modelowanie zagrożeń jest zmniejszenie kosztów i zwiększenie liczby osób, które mogą je dostarczyć przy zachowaniu bardziej jednorodnych poziomów jakości.
Istnieje wiele prób rozwiązania problemu niedoboru właściwych ludzi. Niektóre z nich są oparte na aktywnym zaangażowaniu całego zespołu DevOps w ćwiczeniu modelowania zagrożeń. Chodzi o zidentyfikowanie lidera inicjatywy, czyli kogoś, kto ma pośrednią wiedzę na temat procesu, ale niekoniecznie jest ekspertem i prowadzi dyskusję wśród innych członków zespołu. Takie podejście jest aktywnie zatwierdzane przez sygnatariuszy manifestu modelowania zagrożeń.
Zgadzamy się, że takie podejście pozwala uzyskać dobrą wartość i stanowi poprawę obecnej sytuacji. Zapewnia również dobre szczegółowe informacje i umożliwia zespołowi rozwijanie kultury zabezpieczeń. Niemniej jednak nie jest bez wad, ponieważ obejmuje tylko kilka kwestii, pomijając wiele. Stwarza to problem spójności, ponieważ byłoby zbyt łatwe, aby zejść dziurę królika i tracić cenny czas na problemy pomocnicze, brakuje ważnych. Doświadczenie lidera odgrywałoby znaczącą rolę w zapobieganiu takim sytuacjom. Ponadto takie podejście wymaga dużo czasu od wszystkich członków zespołu w celu omówienia każdego problemu.
Z tego powodu nawet spędzenie kilku godzin na przebieg w tym ćwiczeniu może stanowić znaczną inwestycję. Każdy wie, że większość zespołów ma tendencję do marnowania czasu na duże spotkania z udziałem wszystkich, a te sesje modelowania zagrożeń nie stanowią wyjątku. Mimo to takie podejście jest doskonałe dla małych produktów, w których zespół składa się z kilku starszych członków.
Inne podejście
Biorąc pod uwagę ograniczenia poprzedniego podejścia, wolimy ograniczyć liczbę spotkań, ich długość i liczbę uczestników. W związku z tym odpowiedzialność modelera zagrożeń byłaby bardziej znacząca: nie tylko prowadzić wywiady, ale także tworzyć i utrzymywać sam model zagrożeń. Takie podejście wymaga bardziej znaczących kompetencji i wiedzy fachowej. Osoby modelające zagrożenia mogą być reprezentowane przez mistrzów zabezpieczeń lub przez członków wewnętrznego zespołu ds. zabezpieczeń. Większość organizacji poszłaby na pierwszy, ponieważ zespół ds. zabezpieczeń jest zwykle w pełni zarezerwowany.
Mistrzowie zabezpieczeń są członkami zespołów DevOps, których szczególnym zainteresowaniem jest bezpieczeństwo. Nie są ekspertami w żaden sposób, ale mają podstawową wiedzę i gotowość do poprawy stanu bezpieczeństwa swojego zespołu. Chodzi o utworzenie uprzywilejowanego połączenia między mistrzami zabezpieczeń a wewnętrznym zespołem ds. zabezpieczeń, tak aby pierwsza z nich mogła pomóc swoim zespołom w wykonywaniu odpowiednich czynności, podczas gdy zespół ds. zabezpieczeń może zmniejszyć swoje obciążenie. Dzięki modelowaniu zagrożeń mistrzowie zabezpieczeń będą pełnić rolę modelatorów zagrożeń, a wewnętrzny zespół ds. zabezpieczeń będzie miał obowiązek kierować nimi i przeglądać swoją pracę.
Co możesz zrobić dzisiaj?
Zbadaj możliwość wdrożenia programu Security Champions i wykorzystania go w celu dalszego wzmocnienia cyklu życia bezpiecznego programowania oprogramowania.
Rola baza wiedzy
Znaczący problem z modelowaniem zagrożeń polega na upewnieniu się, że jakość środowiska i wartość zespołu DevOps jest wysoka niezależnie od tego, kto wykonuje model zagrożeń. Wraz z mistrzami bezpieczeństwa ten problem staje się jeszcze bardziej pilny. Chodzi o rozwiązanie tego problemu, aby zapewnić baza wiedzy w celu napędzania tworzenia modelu zagrożeń. Bazy wiedzy dotyczące modelowania zagrożeń to pakiety informacji o określonym kontekście: zawierają definicję jednostek związanych z tym kontekstem, możliwe wzorce ataków dla tych jednostek oraz standardowe środki zaradcze, które można zastosować. Bazy wiedzy umożliwiają organizacji uzyskanie lepszych i bardziej spójnych wyników, ponieważ reprezentują materiały referencyjne, które kierują modelerami zagrożeń w sposób preskrypcyjny. Bazy wiedzy powinny mieć reguły, które pozwalają nam automatycznie stosować zagrożenia i środki zaradcze w systemie. Dzięki tej automatyzacji możemy przezwyciężyć fakt, że niektórzy modelujący zagrożenia mogą nie mieć doświadczenia wymaganego do ustalenia, czy należy zastosować zagrożenie, czy też skuteczne jest ograniczenie ryzyka.
Bazy wiedzy nie są nowym pomysłem: wiele bieżących narzędzi do modelowania zagrożeń już je obsługuje w jakiejś formie. Ale wiele bieżących implementacji ma znaczące wady. Na przykład powinno być możliwe łatwe utrzymywanie baza wiedzy. Ich łatwość utrzymania jest problemem, który jest nadal nierozwiązany. Na przykład nie jest łatwo zidentyfikować najlepsze źródła informacji, które mają być używane do ich tworzenia. Ponadto konserwacja jest zwykle ręczna. Tworzenie i konserwacja baza wiedzy powinny być obowiązkiem wewnętrznego zespołu ds. zabezpieczeń organizacji. Mamy nadzieję, że firmy zaczną dostarczać baza wiedzy dla najbardziej typowych narzędzi do modelowania zagrożeń, aby w przyszłości podnieść niektóre obciążenia ze strony swoich klientów. Te baza wiedzy powinny być elastyczne do wspierania i ułatwiania ich wdrażania nawet przez najbardziej dojrzałe organizacje, które muszą dostosować wspomniane baza wiedzy do swoich praktyk, polityki i przepisów.
Co możesz zrobić dzisiaj?
Rozważ możliwość poświęcania części wysiłku scentralizowanego zespołu ds. zabezpieczeń na opracowywanie baza wiedzy, które mogą być używane przez różne zespoły deweloperskie w celu przyspieszenia modelowania zagrożeń.
Korzystanie z baza wiedzy
Innym problemem z baza wiedzy jest to, że czasami są one zbyt skomplikowane do spożycia. Wiele z nich stara się być kompleksowe, w tym istotne i mniej krytyczne problemy. Niestety, nie wszystkie z nich są wymagane przez wszystkie systemy. Chcesz przyjąć prostsze podejście, gdy analizowane systemy są małe i nie obsługują poufnych danych. Wręcz przeciwnie, warto bardziej szczegółowo pracować, jeśli system jest złożony i przetwarza dane osobowe i dane o wysokiej wartości biznesowej. W związku z tym należy zastosować różne wersje wiedzy w zależności od kontekstu lub oznaczyć niektóre wzorce ataków i skojarzone środki zaradcze jako "TOP". W rezultacie osoby modelające zagrożenia będą mogły zdecydować, czy chcą mieć kompleksowe środowisko, czy łatwo przejść i zminimalizować wymaganą pracę.
Mówiąc o wydajności, konieczne jest zapewnienie, że działania są usprawnione i zautomatyzowane tak samo, jak to możliwe, aby zmniejszyć wymaganą ilość pracy. Uważamy, że słodkie miejsce do wykonania modelu zagrożeń średniego rozmiaru rozwiązania powinno być 1 dzień pracy dla modelera zagrożeń. Takie wyniki są możliwe tylko wtedy, gdy wybrane narzędzie zapewnia akceleratory, aby umożliwić ograniczenie wymaganego czasu. Jeśli na przykład narzędzie stosuje 20 różnych typów środków zaradczych w 100 różnych miejscach, a użytkownik jest proszony o określenie ich stanu dla każdego z nich, byłoby to 5 razy bardziej wydajne, koncentrując się na pierwszej zamiast drugiej. Wybrane narzędzie powinno zapewnić tę możliwość, jednocześnie udzielając możliwości wykonania bardziej szczegółowej pracy, jeśli jest to wymagane.
Co możesz zrobić dzisiaj?
Jeśli używane obecnie baza wiedzy nie obsługują pojęcia "TOP" zagrożeń i środków zaradczych, rozważ możliwość usunięcia tego, co rzadko jest konieczne lub przydatne, aby umożliwić skupienie się tylko na tym, co naprawdę ma znaczenie.
Czasami problem polega na tym, że przyjęte baza wiedzy próbują być ogólne i obejmować wiele scenariuszy. Możesz poprawić sytuację, specjalizując się w nich.
Zadawanie właściwych pytań
Podczas naszej analizy rozważyliśmy możliwość użycia narzędzia do obsługi struktury pytań w celu prowadzenia pierwszych faz analizy. Zauważyliśmy, że większość niedoświadczonych modelatorów zagrożeń nie może zadać odpowiednich pytań, aby uzyskać informacje wymagane do ich analizy. Niektórzy z naszych ekspertów wykazali, że istnieje możliwość określenia pewnych kluczowych pytań na podstawie diagramu systemowego w zakresie. Te pytania można nawet stosować automatycznie, przy użyciu niektórych reguł generowania. Problem polega na tym, że takie podejście może nie dostarczyć wartości, którą wydaje się obiecać. Byłoby to spowodowane tym, że musisz zrozumieć uzasadnienie każdego pytania. W przeciwnym razie nie można ocenić odpowiedzi i określić, czy jest ona zadowalająca. Mimo to automatyczne generowanie pytań może stanowić znaczącą wartość dla mniej ekspertów modelujących zagrożenia, poprawiając ich zrozumienie systemów w zakresie.
Co możesz zrobić dzisiaj?
Przyjęcie ustrukturyzowanego podejścia do zadawania pytań. Na przykład nasz zespół miał dobre wyniki, przyjmując narzędzie Microsoft STRIDE jako odwołanie. Możesz to zrobić, pytając o każdy składnik pytań dotyczących rozwiązania, takich jak:
Fałszowanie: jak składnik uwierzytelnia się w usługach i zasobach, których używa?
Manipulowanie: czy składnik weryfikuje odbierane komunikaty? Czy walidacja jest luźna czy ścisła?
Odrzucenie: czy składnik rejestruje interakcje w dzienniku inspekcji?
Ujawnienie informacji: czy ruch przychodzący i wychodzący składnik jest szyfrowany? Jakie protokoły i algorytmy są dozwolone?
Odmowa usługi: czy składnik jest skonfigurowany w wysokiej dostępności? Czy jest on chroniony przed atakami DDoS?
Podniesienie uprawnień: czy użytkownicy mają przypisane najmniej wymagane uprawnienia? Czy rozwiązanie miesza kod przeznaczony dla zwykłych użytkowników z tym dla użytkowników o wysokich uprawnieniach?
Techniki takie jak ten można nauczyć i można je ulepszyć z doświadczeniem. W związku z tym ważne jest zaimplementowanie podejścia ciągłego Edukacja przeznaczonego do zbierania informacji i rozpowszechniania ich w organizacji.
Wpływ na zwrot z inwestycji
Najwięcej pomysłów można zidentyfikować w celu poprawy wydajności środowiska modelowania zagrożeń, jego jakości i ostatecznie zwiększenia zwrotu z inwestycji. Należy jednak wziąć pod uwagę ciągły proces, który powinien być skierowany do ciągłego ulepszania praktyki.
Wnioski
Modelowanie zagrożeń to doskonała metodologia poprawy bezpieczeństwa organizacji. W przypadku poprawnego wykonania może zapewnić wartość bardzo rozsądnego kosztu. Zidentyfikowaliśmy już różne techniki, które mogą okazać się niezbędne do poprawy wartości modelowania zagrożeń w celu zabezpieczenia nowoczesnych rozwiązań, w tym:
Dopasuj model zagrożeń do praktyki DevOps według
Skupienie się na ograniczeniach ryzyka
Łączenie środków zaradczych z historiami użytkowników
Wyróżnianie rozbieżności między modelem zagrożeń a listą prac
Korzystanie z modelu zagrożeń w celu zapewnienia bardziej kompleksowego monitorowania i inspekcji pod kątem zabezpieczeń
Upraszczanie tworzenia modeli zagrożeń i zwiększanie spójności wyników
Polegaj na mistrzach zabezpieczeń
Wdrażanie baza wiedzy w celu zautomatyzowania identyfikacji zagrożeń i środków zaradczych
Tworzenie lepszych baza wiedzy
Podaj platformę pytań obsługiwaną przez automatyzację
Mam nadzieję, że niektóre z nich można już znaleźć w wybranym narzędziu do modelowania zagrożeń. Inne zostaną uwzględnione w przyszłości. Wiemy, że maksymalizacja zwrotu z inwestycji w modelowanie zagrożeń jest długoterminowym wysiłkiem, który wymaga odpowiedzi, których jeszcze nie mamy. Wiemy również, że niektóre pytania są nadal nieznane. Ten dokument powinien dostarczyć pewną żywność do przemyślenia i miejmy nadzieję, że pomoże Ci to poprawić sposób modelowania zagrożeń. Mamy nadzieję, że może to być latarnia morska dla ciebie i nas, i że będzie przydatne, aby kierować nasze wysiłki na nadchodzących latach.