Udostępnij za pośrednictwem

Kontrolki DevSecOps

  • Artykuł

W tym artykule opisano sposób stosowania mechanizmów kontroli zabezpieczeń w celu obsługi ciągłych praktyk zabezpieczeń SDL . Te mechanizmy kontroli zabezpieczeń są integralną częścią strategii DevSecOps obejmującej ludzi, proces i technologię. W tej dokumentacji opisano każdą kontrolkę i pokazano, jak zastosować te kontrolki do trzech profilów zabezpieczeń. Te profile spełniają typowe wymagania dotyczące zabezpieczeń dla typowych scenariuszy biznesowych w większości organizacji:

Diagram mechanizmów kontroli zabezpieczeń w porównaniu z czasem i wpływem.

Profile kontroli zabezpieczeń

W tym artykule wymieniono trzy warstwy profilów kontroli.

Minimum tymczasowe — skrócony profil zabezpieczeń dla tymczasowego stanu wyjątku do obsługi szybkiego tworzenia prototypów obciążeń o niskim ryzyku. Ten profil powinien być używany tylko w przypadku wyjątków tymczasowych, które należy zwolnić na przyspieszonej osi czasu, aby spełnić krytyczne potrzeby biznesowe. Elementy korzystające z tego profilu powinny być szybko wprowadzane do standardowego profilu.

Standardowa — zrównoważone podejście dla większości obciążeń, przez większość czasu.

Wysoki poziom zabezpieczeń — rygorystyczne zabezpieczenia obciążeń z potencjalnym dużym wpływem na bezpieczeństwo biznesowe i ludzkie.

Mechanizmy zabezpieczeń DevSecOps

Ta sekcja zawiera informacje o zalecanych mechanizmach kontroli zabezpieczeń dla każdego typu obciążenia. To odwołanie może zostać przyjęte w takiej postaci lub można je dostosować do istniejących procesów tworzenia oprogramowania i zabezpieczeń oprogramowania. Większość organizacji nie może zaimplementować wszystkich tych kontrolek od razu, jeśli nie robią jeszcze niektórych z nich. Podejście do ciągłego ulepszania jest często najlepszym podejściem: określanie priorytetów kontrolek, implementowanie pierwszej kontrolki, przechodzenie do następnej kontrolki, implementowanie jej itd. Większość organizacji powinna najpierw określić priorytety podstawowych podstaw krytycznych .

Aby uzyskać więcej informacji, zobacz Podróż DevSecOps.

Ten diagram zawiera podsumowanie mechanizmów kontroli zabezpieczeń i sposobu ich stosowania do każdego profilu zabezpieczeń obciążenia.

Kluczowe zagadnienia dotyczące planowania obejmują:

  • Przesunięcie w lewo ale sprawdź dwukrotnie — To odwołanie jest przeznaczone do wykrywania i rozwiązywania problemów tak szybko, jak to możliwe, aby umożliwić ich rozwiązanie, gdy łatwiej i tańszo rozwiązać problemy (czasami nazywane przesunięciem w lewo), ale także zakładać niepowodzenie i uwzględniać podwójne sprawdzanie w dalszej części procesu. Zawsze dokładnie sprawdzaj wszelkie mechanizmy zabezpieczeń w procesie ciągłej integracji/ciągłego wdrażania, aby uniknąć problemów, które nie są przekazywane do systemów produkcyjnych. Ta koncepcja jest zgodna z zasadami "ochrona w głębi systemu" i "bezpieczne niepowodzenie".
  • Sztuczna inteligencja (AI) — dwa główne implikacje sztucznej inteligencji to:
    • Zabezpieczanie całego kodu niezależnie od tego, czy jest napisany przez człowieka, czy generowanie sztucznej inteligencji
    • Użyj obu dla zabezpieczeń — zastosuj zarówno mechanizmy kontroli klasycznej, jak i sztucznej inteligencji jako dostępne, aby zwiększyć widoczność i kontekst dla wszelkich problemów z zabezpieczeniami (takich jak narzędzia do analizy kodu)

Kontrolki zabezpieczeń

Kontrolki są pogrupowane w etapy opracowywania, do których mają zastosowanie, oraz wspólne mechanizmy kontroli (podstawowe podstawy krytyczne), które mają zastosowanie we wszystkich etapach programowania i profilach kontroli:

Każdy z tych elementów jest zdefiniowany w następujących sekcjach:

Ustanawianie podstawowych podstaw krytycznych

Ta kontrola obsługuje ciągłą praktykę SDL 1 — ustanawianie standardów zabezpieczeń, metryk i ładu, praktyka 2 — wymaganie użycia sprawdzonych funkcji zabezpieczeń, języków i struktur oraz praktyki 10 — zapewnianie szkoleń dotyczących zabezpieczeń.

Standardowa — te kontrolki mają zastosowanie we wszystkich etapach programowania i profilach kontroli.

Zapewnianie szkolenia w zakresie zabezpieczeń

Ta kontrola koncentruje się na dostarczaniu deweloperom i zespołom ds. zabezpieczeń szkoleń w celu rozpoznawania i rozwiązywania problemów z zabezpieczeniami w cyklu projektowania. Bez szkolenia zabezpieczeń zespoły mogą przegapić podstawowe słabości zabezpieczeń, które prowadzą do naruszenia zabezpieczeń w okresie istnienia aplikacji.

W związku z tym konieczne jest zaimplementowanie szkolenia zabezpieczeń we wszystkich rolach (w tym użytkowników, deweloperów, menedżerów linii produktów, testerów i nie tylko). Każda rola musi mieć edukację na temat zagrożeń bezpieczeństwa i ich roli w zachowaniu bezpieczeństwa aplikacji. To szkolenie może mieć formę: formalnego lub na żądanie szkolenia, ćwiczeń symulacji, modelowania zagrożeń, mentoringu/doradców, mistrzów zabezpieczeń, zespołów pomocy technicznej ds. zabezpieczeń aplikacji, fioletowych działań zespołowych, podcastów, filmów wideo lub innych metod szkoleniowych.

Ostatecznie każda rola musi zrozumieć:

  • Dlaczego ważne jest, aby rozwiązać problemy z zagrożeniami bezpieczeństwa
  • Co muszą zrobić w celu zapewnienia bezpieczeństwa w swojej roli
  • Jak uczynić część zabezpieczeń ich codzienną rolą

Osoby, którzy rozumieją perspektywę osoby atakującej, ich cele i sposób, w jaki są one wyświetlane w rzeczywistych zdarzeniach bezpieczeństwa, szybko stają się sojusznikami zabezpieczeń zamiast starać się uniknąć bezpieczeństwa.

Bezpieczeństwo to niekończąca się gra, w której zagrożenia, technologia i zasoby biznesowe do ochrony są zawsze zmieniane, a aktorzy zagrożeń nigdy się nie poddają. Podejście do trenowania zabezpieczeń musi być ciągłe i stale rozwijane. Skuteczne szkolenia są zgodne z zasadami zabezpieczeń, praktykami cyklu tworzenia oprogramowania (SDL), standardami i wymaganiami dotyczącymi zabezpieczeń oprogramowania. Materiały szkoleniowe powinny pochodzić ze szczegółowych informacji pochodzących z danych i nowo dostępnych możliwości technicznych.

Mimo że bezpieczeństwo to zadanie dotyczące każdego, ważne jest, aby pamiętać, że nie każdy musi być ekspertem od zabezpieczeń ani mieć bogate doświadczenie w zakresie testów penetracyjnych. Zapewnienie, że wszyscy rozumieją podstawy zabezpieczeń i sposób ich stosowania do ich roli tworzenia zabezpieczeń w oprogramowaniu i usługach, są niezbędne. To szkolenie powinno obejmować bezpieczne korzystanie ze stacji roboczych, aplikacji, tożsamości i kont.

W szczególności deweloperzy i inżynierowie tworzący systemy nie są zwykle ekspertami ds. zabezpieczeń. Szkolenie zarówno w technicznych, jak i koncepcyjnych aspektach modelowania zagrożeń jest niezbędne, aby stały się skuteczne, dzięki czemu mogą tworzyć systemy, które są bezpieczne zgodnie z projektem. To szkolenie ma kluczowe znaczenie dla procesu modelowania zagrożeń w celu pracy na dużą skalę w organizacjach, w których deweloperzy znacznie przewyższają liczbę specjalistów ds. zabezpieczeń. Modelowanie zagrożeń musi być uważane za podstawową umiejętność inżynieryjną, w której wszyscy deweloperzy i inżynierowie muszą mieć co najmniej podstawową biegłość. W związku z tym zespoły programistyczne i inżynieryjne muszą być przeszkolone, aby być kompetentnym w modelowaniu zagrożeń w ramach dołączania i okresowych odświeżeń.

Uwzględnianie zabezpieczeń w bezbłędnych pośmiertach

Bez winy analiza postmortem jest niezwykle ważną metodą, aby zespoły mogły skutecznie i skutecznie uczyć się od błędów bez wyzwalania defensywności od członków zespołu, szukając kogoś winnego. Szkolenia dotyczące zabezpieczeń należy jawnie uwzględnić w procesie pośmiertnym bez winy, aby zapewnić zespołom maksymalizację uczenia się zabezpieczeń.

Ustanawianie standardów zabezpieczeń, metryk i ładu

Organizacje powinny ustanowić te standardy zabezpieczeń, metryki i ład, ponieważ stanowią podstawę możliwości wprowadzania innowacji. Umożliwia ona silny program zabezpieczeń, który nie tylko chroni zasoby organizacji, ale także jest zgodny z celami biznesowymi. Standardy zabezpieczeń to podstawowe wymagania i najlepsze rozwiązania dotyczące zapewniania bezpieczeństwa systemów, danych i procesów organizacji.

Te standardy powinny być mierzone i zarządzane, w tym monitorowanie zgodności oraz regularne przeglądanie i aktualizowanie ich pod kątem bieżących zagrożeń, narzędzi i innych czynników. Ten proces powinien obejmować cały cykl życia od początkowego ideowania przez zlikwidowanie aplikacji i wszystkich pomocniczych środowisk deweloperskich.

Metryki to pomiary używane do sprawdzenia, jak skuteczne są mechanizmy kontroli zabezpieczeń i procesy. Jedną z kluczowych metryk jest średni czas korygowania (MTTR) na potrzeby śledzenia, jak długo aplikacja pozostaje podatna na zagrożenia. Ten pomiar pozwala nam strategicznie inwestować w wydawanie poprawek zabezpieczeń szybciej.

Uwaga

Ta koncepcja różni się od mtTR w operacjach zabezpieczeń skoncentrowanych na czasie w celu usunięcia niepożądanego dostępu do zasobów organizacji.

Ład zabezpieczeń działa jako wskazówki dla zespołów ds. zabezpieczeń i często opiera się na strukturach i procesach używanych przez organizacje do zarządzania zabezpieczeniami informacji i kontrolowania ich. Obejmują one zasady, procedury, mechanizmy kontroli i zarządzanie ryzykiem. Metryki pomagają w kwantyfikacji narażenia na ryzyko. Bez nich organizacja może nie w pełni zrozumieć swoich luk w zabezpieczeniach i potencjalnego wpływu.

Ponieważ wymagania dotyczące zabezpieczeń mogą być nowe, możesz skorzystać z postępowego podejścia, które stopniowo zwiększa standardy kodowania do idealnego stanu. Takie podejście zapewnia zespołom czas na naukę i automatyzowanie monitorowania i kontroli.

Wymaganie użycia sprawdzonych funkcji zabezpieczeń, języków i struktur

Zdefiniuj i opublikuj listę zatwierdzonych narzędzi i skojarzonych z nimi kontroli zabezpieczeń. Korzystanie z dobrze ugruntowanych i sprawdzonych rozwiązań zabezpieczeń jest ważne, aby uniknąć typowych błędów, ponieważ tworzenie bezpiecznych rozwiązań jest bardzo trudne. Próba ponownego wynależenia rozwiązań zabezpieczeń prawie zawsze skutkuje zwiększonym ryzykiem bezpieczeństwa i marnowaniem czasu i nakładu pracy.

Upewnij się, że deweloperzy i inżynierowie korzystają z nowych funkcji i ochrony analizy zabezpieczeń. Zawsze powinny używać najnowszego kompilatora, konsolidatora, bibliotek oraz odpowiednich flag kompilatora i konsolidatora w celu wygenerowania bezpiecznych plików wykonywalnych.

Organizacje powinny zaimplementować proces przeglądu i zatwierdzania w celu zweryfikowania zabezpieczeń wszystkich zintegrowanych składników. Powinny one ustanowić zasady, aby używać tylko zatwierdzonych składników w procesach kompilacji i wdrażania, które są wymuszane i monitorowane.

Podstawowe zabezpieczenia tożsamości

Upewnij się, że użycie i integracja tożsamości są zgodne z dobrze ustalonymi najlepszymi rozwiązaniami w zakresie zabezpieczeń. Aktorzy zagrożeń często używają technik ataków tożsamości zarówno w systemach produkcyjnych, jak i w procesach programowania. Popularne powiedzenie przechwytuje to: "osoby atakujące nie włamują się, po prostu się logują".

Zabezpieczenia tożsamości mają dwie formy programowania:

  • Zabezpieczenia tożsamości dla procesu programowania — upewnij się, że wszyscy uczestnicy procesu programowania używają silnych metod uwierzytelniania do codziennej pracy i mają uprawnienia wymagane tylko do wykonywania zadań podrzędnych. Aby uzyskać więcej informacji, zobacz sekcję Identity/application access controls (Mechanizmy kontroli dostępu do tożsamości/aplikacji).
  • Zabezpieczenia tożsamości dla systemów i aplikacji — upewnij się, że systemy projektowane i budowane są zgodne z najlepszymi rozwiązaniami dotyczącymi metod uwierzytelniania i autoryzacji (i nie tworzą własnych słabych imitacji sprawdzonych i utrzymywanych systemów tożsamości).

Zastosuj zabezpieczenia tożsamości dla systemów i aplikacji, postępując zgodnie ze wskazówkami zawartymi w tych zasobach:

Standardy kryptograficzne

Stosowanie zdrowych praktyk kryptograficznych do wszystkich użycia kryptografii. Postępuj zgodnie ze wszystkimi wytycznymi opisanymi w artykule Continuous SDL Practice 4 — Define and Use cryptographic Standards (Ciągła praktyka SDL 4 — definiowanie i używanie standardów kryptograficznych).

Aby uzyskać więcej informacji, zobacz Microsoft SDL kryptograficzne zalecenia.

Zabezpieczanie środowiska projektowego

Ta kontrolka obsługuje ciągłą praktykę SDL 6 — zabezpieczanie środowiska inżynieryjnego.

Ta kontrola koncentruje się na zabezpieczaniu środowiska projektowego przy użyciu bezpiecznych stacji roboczych i zintegrowanych środowisk projektowych (IDE). Ta kontrolka wyróżnia korzyści wynikające z używania podejścia Zero Trust w cyklu projektowania oprogramowania.

W bieżącym środowisku osoby atakujące rozszerzają swoje operacje w celu kierowania maszyn deweloperów i manipulowania procesami kompilacji. Kluczowym przykładem tego ataku był ten, który doświadczył SolarWinds, gdzie atakujący wstawił złośliwą bibliotekę DLL przed ostatnimi etapami kompilacji oprogramowania. Skutecznie to backdoored aplikacji i spowodowało atak ukierunkowany, który został dystrybuowany do tysięcy klientów na całym świecie za pośrednictwem łańcucha dostaw. Aby uzyskać więcej informacji na temat ataku SolarWinds, zobacz blog firmy Microsoft Analizowanie Solorigate, naruszony plik DLL, który rozpoczął wyrafinowany cyberatak i jak usługa Microsoft Defender pomaga chronić klientów.

Niezbędne jest wzmocnienie zabezpieczeń stacji roboczych, środowisk kompilacji, tożsamości i innych systemów programistycznych w celu zapewnienia integralności opracowanych aplikacji. Nie można tego zrobić, aby osoby atakujące mogły naruszyć bezpieczeństwo aplikacji za pośrednictwem systemu zarządzania kodem źródłowym (SCM) lub stacji roboczej dewelopera.

Ta praktyka stanowi kluczową podstawę cyklu projektowania i powinna zostać ustanowiona we wszystkich profilach.

W tej praktyce należy zastosować podejście Zero Trust. W podstawowym modelu zero trust wymaga, aby każde żądanie dostępu (użytkownik, usługa lub urządzenie) było weryfikowane tak, jakby pochodziło z niezaufanej sieci, niezależnie od tego, skąd pochodzi żądanie lub jakiego zasobu uzyskuje dostęp. Ta zasada "zawsze uwierzytelniaj i autoryzuj" we wszystkich dostępnych punktach danych. Należy ograniczyć dostęp użytkowników, szczególnie uprzywilejowanych użytkowników, za pośrednictwem zasad Just-In-Time i Just-Enough-Access (JIT/JEA) oraz segmentować dostęp, aby zminimalizować ewentualne szkody w przypadku naruszenia.

Wzmocnienie zabezpieczeń środowiska projektowego można osiągnąć za pomocą różnych metod, jednak dobrym punktem wyjścia jest rozważenie stacji roboczej dewelopera. Korzystając z technologii, takich jak GitHub Codespaces lub Microsoft DevBox, przenosisz środowisko deweloperskie do aplikacji SaaS, które następnie można zarządzać za pomocą ustawień zabezpieczeń i sieci lub zasad organizacyjnych.

Aby dodatkowo zablokować stacje robocze deweloperów, możesz wydać im uprzywilejowany dostęp do stacji roboczych/stacji roboczych z bezpiecznym dostępem (PAW/SAW). Te stacje robocze pomagają zmniejszyć wektory zagrożeń i zapewnić ustandaryzowane i kontrolowane urządzenie deweloperskie.

Bezpieczny projekt

Wykonywanie modelowania zagrożeń (przegląd projektu zabezpieczeń)

Ta kontrolka obsługuje ciągłą praktykę SDL 3 — wykonywanie modelowania zagrożeń.

Ta kontrola identyfikuje słabe punkty zabezpieczeń w projekcie, które mogą spowodować zdarzenia zabezpieczeń i szkody biznesowe. Wady zabezpieczeń projektu mogą być trudne do wyeliminowania po wdrożeniu projektu, dlatego znalezienie i naprawienie tych słabości na wczesnym etapie cyklu życia jest niezwykle ważne.

Modelowanie zagrożeń służy jako proces przeglądu projektu zabezpieczeń, który integruje zabezpieczenia z projektem systemu lub aplikacji.

Modelowanie zagrożeń systematycznie identyfikuje, ocenia, ustala priorytety i ogranicza zagrożenia bezpieczeństwa w systemie oprogramowania. Takie ustrukturyzowane podejście do analizowania projektu i architektury aplikacji programowej identyfikuje potencjalne zagrożenia i luki w zabezpieczeniach na wczesnym etapie procesu programowania.

Ostatecznym celem jest zrozumienie systemu i to, co może pójść nie tak. Modelowanie zagrożeń pomaga osiągnąć ten cel, stosując głębokie zrozumienie zarówno samego systemu, jak i sposobu, w jaki potencjalny atakujący go postrzega.

Ten proces zwykle odbywa się w ramach warsztatów odnajdywania zagrożeń, w których zespół ekspertów ds. systemu i ekspertów ds. zabezpieczeń współpracuje ze sobą w celu wykrywania i dokumentowania zagrożeń. Chociaż ten proces może rozpocząć się nieformalnie, powinien szybko przekształcić się w ustrukturyzowany proces, który omawia każdy aspekt tworzonej usługi, sposób jej użycia i interfejsy systemowe.

Etapy modelowania zagrożeń to:

  1. Identyfikowanie przypadków użycia, scenariuszy i zasobów — zacznij od zrozumienia, jakie funkcje biznesowe i przypadki użycia umożliwia systemowi ocenę potencjalnego wpływu na działalność dowolnego naruszenia zabezpieczeń systemu i informowanie o kolejnych dyskusjach.
  2. Tworzenie przeglądu architektury — tworzenie wizualnego podsumowania aplikacji (lub używanie istniejącej) w celu zapewnienia jasnego zrozumienia systemu i sposobu jej działania. Omówienie powinno obejmować: mapę procesów biznesowych, składniki i podsystemy, granice zaufania, mechanizmy uwierzytelniania i autoryzacji, interfejsy zewnętrzne i wewnętrzne oraz przepływy danych między aktorami i składnikami.
  3. Identyfikowanie zagrożeń — użyj wspólnej metodologii wyliczania potencjalnych zagrożeń bezpieczeństwa, takich jak model STRIDE lub modelowanie zagrożeń OWASP.
  4. Identyfikowanie i śledzenie środków zaradczych — monitorowanie i śledzenie wykrytych wad projektu przy użyciu istniejących procesów i narzędzi programistycznych w celu zapewnienia implementacji i udokumentowania poprawek. Ten proces powinien obejmować określenie priorytetów, które środki zaradcze należy najpierw wykonać, aby zespoły spędzały czas na najważniejszych wysiłkach. Ten proces jest spowodowany ryzykiem i możesz nie mieć zasobów, aby w pełni ograniczyć wszystkie zagrożenia w pierwszym cyklu. Należy dokładnie rozważyć środki zaradcze, w tym częściowe środki zaradcze, podnieść koszt osoby atakującej w celu uzyskania najmniejszego kosztu defensywnego i zasobów. Celem zabezpieczeń jest niepowodzenie osoby atakującej, która może mieć formę całkowitego blokowania techniki ataku, wykrywania ich w celu umożliwienia reagowania obrońcy, spowalniając ich, aby dać obrońcom czas odpowiedzi, ograniczyć zakres szkód i nie tylko.

Model zagrożeń często służy jako proces edukacyjny dla wszystkich zaangażowanych osób, a także zapewnia ważny kontekst dla innych planowania, wdrażania i testowania zabezpieczeń.

Aplikacje, które obejmują korzystanie ze składników sztucznej inteligencji (AI), muszą ocenić określone typy ryzyka skojarzone ze sztuczną inteligencją, które różnią się od klasycznych aplikacji.

Twórz i analizuj modele zagrożeń, komunikując się z projektem zabezpieczeń swoich systemów, analizując te projekty pod kątem potencjalnych problemów z zabezpieczeniami przy użyciu sprawdzonej metodologii oraz sugerując środki zaradcze i zarządzając nimi w przypadku problemów z zabezpieczeniami.

Bezpieczny kod

Analiza kodu

Ta kontrolka obsługuje ciągłą praktykę SDL 7 — przeprowadzanie testów zabezpieczeń.

Ta kontrola koncentruje się na zwiększeniu bezpieczeństwa kodu podczas pisania/wprowadzania go w zintegrowanym środowisku projektowym (IDE) lub podczas ewidencjonowania kodu. Ta kontrola jest podstawą praktyk DevSecOps, ponieważ bezpośrednio rozwiązuje luki w zabezpieczeniach, które osoby atakujące regularnie wykorzystują.

Bez tej kontrolki mogą brakować luk w zabezpieczeniach, które są kodowane bezpośrednio w aplikacji przez deweloperów. Twoi deweloperzy nie są złośliwi, ale mogą nie mieć umiejętności potrzebnych do zidentyfikowania, dlaczego kodowane elementy są niezabezpieczone.

Ta kontrola jest kluczem do uzyskania korzyści związanych z produktywnością i zabezpieczeniami podejścia shift w lewo dzięki integracji narzędzi bezpośrednio ze środowiskiem IDE. Ten proces umożliwia szybkie odnajdywanie i korygowanie luk w zabezpieczeniach najwcześniej i najbardziej opłacalne. Ten proces może być stosowany wstecznie do już opracowanych aplikacji, identyfikując słabe strony zabezpieczeń i naprawiając je później (choć kosztem i trudnościami).

Ten proces zazwyczaj przyjmuje formę wtyczek IDE lub dedykowanych narzędzi do skanowania, które skanują kod przy użyciu zestawów narzędzi do testowania zabezpieczeń analizy statycznej (SAST) i dynamicznego testowania zabezpieczeń analizy (DAST).

Narzędzia SAST skanują istniejącą bazę kodu i mają pełny dostęp do kodu. Narzędzia SAST mogą identyfikować podstawowe słabości w samym kodzie. Z drugiej strony język DAST jest wykonywany w wdrożonej aplikacji. W związku z tym nie ma dostępu do kodu i jest wykonywany w celu symulowania i identyfikowania słabych stron zabezpieczeń w środowisku uruchomieniowym.

Uwaga

Aplikacje sztucznej inteligencji mają różne typy luk w zabezpieczeniach (takie jak uprzedzenia i halucynacje) niż aplikacje klasyczne i wymagają narzędzi, które koncentrują się na nich.

Kontrola jakości ma znaczenie! Kluczową kwestią podczas uruchamiania tych narzędzi jest upewnienie się, że dostrajasz je w celu zmniejszenia szumu i marnowania wysiłku z powodu wyników fałszywie dodatnich. Dostrajanie tych narzędzi zwykle wymaga specjalisty ds. zabezpieczeń z doświadczeniem dewelopera, który rozumie procesy programistyczne organizacji. Ci sami specjaliści mogą również zapewnić wskazówki dotyczące klasyfikacji i wiedzę na temat poszczególnych wykryć dla deweloperów. Mogą one pomóc w odróżnieniu wyników prawdziwie i fałszywie dodatnich, rzeczywistych problemów i fałszywych alarmów. Procesy uzyskiwania dostępu do tych ekspertów są często ściśle związane z zapewnianiem szkoleń dotyczących zabezpieczeń, takich jak programy mistrzów, zespoły pomocy technicznej ds. zabezpieczeń aplikacji itp.

Minimum tymczasowe — upewnij się, że włączono wbudowane funkcje zabezpieczeń środowiska IDE i zaimplementowaliśmy minimalny poziom skanowania SAST w repozytorium w celu zidentyfikowania luk w zabezpieczeniach w aplikacji. W rozsądnym czasie musi istnieć udokumentowany proces korygowania wykrytych problemów, chociaż standard "pasek błędów", którego błędy muszą zostać naprawione, jest ograniczony do momentu osiągnięcia przez aplikację standardowych profilów zrównoważonych lub wysokich zabezpieczeń.

Standardowa — upewnij się, że wszystkie składniki są w pełni skanowane przy użyciu wszystkich odpowiednich narzędzi SAST/DAST i identyfikowania słabych stron. Zapewnij pełne pokrycie zabezpieczeń w kodzie aplikacji. Upewnij się, że obserwujesz udokumentowany proces korygowania i masz standard "paska błędów", który odpowiada tolerancji ryzyka organizacji.

Wysoki poziom zabezpieczeń — upewnij się, że wszystkie odpowiednie aplikacje wymuszają szczegółowy i udokumentowany proces odnoszący się do wszystkich luk w zabezpieczeniach. Wymuszaj poprawki przed wszelkimi działaniami kompilacji lub wydania. Upewnij się, że postępujesz zgodnie z udokumentowanym procesem korygowania i masz bardzo restrykcyjny "pasek błędów", który odpowiada tolerancji ryzyka organizacji w przypadku obciążeń o krytycznym znaczeniu dla działania firmy.

Dostępnych jest wiele narzędzi do analizy statycznej. Zapoznaj się z listą w witrynie Microsoft Security Development Lifecycle (Cykl projektowania zabezpieczeń firmy Microsoft), aby uzyskać więcej informacji.

Zabezpieczanie potoku ciągłej integracji/ciągłego wdrażania

Łańcuch dostaw/zarządzanie zależnościami

Ta kontrola obsługuje ciągłą praktykę SDL 5 — zabezpieczanie łańcucha dostaw oprogramowania.

Ta kontrola koncentruje się na zabezpieczaniu łańcucha dostaw przy użyciu narzędzi i struktur analizy kompozycji oprogramowania (SCA), takich jak Secure Supply Chain Consumption Framework (S2C2F). Te procesy pomagają zmniejszyć ryzyko naruszenia przez kod firmy innej niż Microsoft.

W dzisiejszym środowisku większość aplikacji opiera się na oprogramowaniu typu open source (OSS) z niewielkim nadzorem lub kontrolą ze strony konsumentów tych składników. Ta kontrolka wyróżnia podstawowe strategie, techniki i technologie w celu bezpiecznego pozyskiwania, używania, używania i obsługi systemu operacyjnego. Podkreśla również zabezpieczanie zależności wewnętrznych, zapewniając pełny cykl życia, niezależnie od tego, kto kodował oprogramowanie.

Brak kontroli nad łańcuchem dostaw oprogramowania ujawnia istotne luki w zabezpieczeniach wprowadzone przez kod, który nie kontrolujesz. Notorycznie przykładem jest luka w zabezpieczeniach log4J/Log4Shell, która zezwalała na zdalne wykonywanie kodu w dowolnym systemie lub aplikacji przy użyciu tego pakietu. Takie luki w zabezpieczeniach mogą wystąpić przypadkowo lub złośliwie.

Zabezpieczanie łańcucha dostaw jest istotną częścią zapewnienia bezpiecznego cyklu projektowania i powinno być brane pod uwagę w każdym stanie profilu, chociaż każdy pojedynczy stan powinien postępować zgodnie z tym samym standardowym procesem pozyskiwania zależności.

Minimum tymczasowe — spis wszystkich zależności, aby zrozumieć wpływ luki w zabezpieczeniach systemu operacyjnego na aplikację. Ten spis można osiągnąć przy użyciu narzędzi Dependabot lub innych narzędzi analizy kompozycji oprogramowania (SCA). Te narzędzia mogą również pomóc w wygenerowaniu rachunku za oprogramowanie materiałów (SBOM).

Standardowa — analizowanie wszystkich luk w zabezpieczeniach systemu operacyjnego i automatyczne naprawianie ich za pomocą automatycznych żądań ściągnięcia. Tę kontrolkę można również osiągnąć za pomocą narzędzia Dependabot i wykresu zależności usługi GitHub/przeglądu.

Wysoki poziom zabezpieczeń — aktywnie blokuj wszystkie niezabezpieczone pakiety z lukami w zabezpieczeniach używanymi w aplikacji.

Aby dowiedzieć się więcej na temat tej kontroli i mierzenia dojrzałości zabezpieczeń systemu operacyjnego, zapoznaj się z dokumentacją dotyczącą łańcucha dostaw systemu operacyjnego i najlepszymi rozwiązaniami usługi GitHub dotyczącymi zabezpieczania cyklu projektowania.

Przegląd kodu zabezpieczeń

Ta kontrola koncentruje się na uzyskaniu kodu przeglądu przez ekspertów ds. zabezpieczeń w celu zidentyfikowania potencjalnych wad zabezpieczeń. Pomaga to znaleźć problemy z zabezpieczeniami, dla których trudno zautomatyzować wykrywanie.

Ten przegląd może być wykonywany przez: osobę równorzędną w tym samym zespole z wiedzą w zakresie zabezpieczeń aplikacji, mistrzem zabezpieczeń w organizacji, ekspertem ds. zabezpieczeń aplikacji z centralnego zespołu ds. zabezpieczeń aplikacji lub stroną zewnętrzną.

Ta recenzja musi zawsze być osobą oddzielną od dewelopera, który napisał kod. Ten przegląd należy wykonać jako osobne działanie po zakończeniu zautomatyzowanej analizy kodu.

Minimum tymczasowe — ta kontrolka jest zalecana dla tego profilu.

Standardowa — ta kontrolka jest zalecana dla tego profilu.

Wysoki poziom zabezpieczeń — ta kontrola jest wymagana dla wszystkich aplikacji o wysokim poziomie zabezpieczeń i często obejmuje wielu ekspertów.

Skanowanie poświadczeń i wpisów tajnych

Ta kontrolka obsługuje ciągłą praktykę SDL 7 — przeprowadzanie testów zabezpieczeń.

Ta kontrola koncentruje się na zmniejszeniu ryzyka związanego z kluczami uwierzytelniania i innymi wpisami tajnymi uwidocznianych w kodzie. Aktorzy zagrożeń mają wiedzę i automatyzację w celu znajdowania i wykorzystywania osadzonych wpisów tajnych w kodzie.

Najlepszym rozwiązaniem jest użycie tożsamości zarządzanych i nowoczesnych protokołów uwierzytelniania zamiast kluczy i wpisów tajnych, jeśli jest to możliwe. Chociaż używanie kluczy interfejsu API i wpisów tajnych tradycyjnie było praktyką kodowania i testowania, preferowaną metodą zawsze powinno być uwierzytelnianie oparte na tożsamościach dla zasobów ze względu na zwiększone możliwości zarządzania zabezpieczeniami i cyklem życia. Implementacja tej kontrolki ma formę używania tożsamości zarządzanych, takich jak tożsamości zarządzane dla zasobów platformy Azure.

Jeśli wymagane jest użycie wpisów tajnych, należy je zabezpieczyć za pośrednictwem całego cyklu życia, w tym tworzenia, używania, regularnego obrotu i odwoływania. Unikaj bezpośredniego używania wpisów tajnych w kodzie i przechowuj je tylko w bezpiecznym systemie magazynu kluczy/wpisów tajnych, takich jak usługa Azure Key Vault lub sprzętowy moduł zabezpieczeń (HSM), jeśli jest to konieczne. W żadnym wypadku klucze zwykłego tekstu i wpisy tajne nigdy nie powinny być przechowywane w kodzie, nawet tymczasowo! Osoby atakujące znajdą te wpisy tajne i wykorzystają je.

Ważne

Wewnętrzne repozytoria kodu źródłowego nie są bezpieczne!

Repozytoria wewnętrzne powinny podlegać tym samym wymaganiom co repozytoria publicznie, co podmioty zagrożeń często wyszukują wpisy tajne i klucze w repozytoriach po uzyskaniu dostępu do środowiska za pośrednictwem wyłudzania informacji lub innych środków. Jest to wymagane w przypadku podejścia zero trust, które zakłada naruszenie zabezpieczeń i projektuje odpowiednie mechanizmy kontroli zabezpieczeń.

Standardowa — dobra higiena wpisów tajnych jest niezbędna i wymagana we wszystkich profilach.

Uwaga

Ponieważ te wpisy tajne są znajdowane przez zespoły lub osoby atakujące, należy upewnić się, że klucz nie może być używany do uzyskiwania dostępu do zasobów (różni się w zależności od typu zasobu) oprócz modyfikowania mechanizmu na bardziej bezpieczną metodę dostępu, na przykład tożsamości zarządzane.

Więcej szczegółów i zasobów obejmują:

Uwaga

Zdecydowanie zalecamy używanie kluczy obciążenia z rozwiązaniami magazynu wpisów tajnych, takimi jak usługa Azure Key Vault.

Bezpieczny potok

Ta kontrola obsługuje ciągłą praktykę SDL 5 — zabezpieczanie łańcucha dostaw oprogramowania.

Ta kontrolka koncentruje się na zabezpieczaniu potoku DevOps i wszystkich artefaktów utworzonych podczas procesów kompilacji aplikacji.

Potoki są istotną częścią automatyzacji podstawowych powtarzalnych działań w ramach cyklu życia metodyki DevSecOps. W ciągłej integracji/ciągłego wdrażania zespół scala kod dewelopera z centralną bazą kodu zgodnie z regularnym harmonogramem i automatycznie uruchamia standardowe kompilacje i procesy testowe, które obejmują zestawy narzędzi zabezpieczeń.

Uruchamianie skryptów lub wdrażanie kodu w środowiskach produkcyjnych przy użyciu potoków może powodować unikatowe wyzwania związane z zabezpieczeniami. Upewnij się, że potoki ciągłej integracji/ciągłego wdrażania nie stają się drogami uruchamiania złośliwego kodu, zezwalają na kradzież poświadczeń lub zapewniają atakującym dowolny obszar powierzchni w celu uzyskania dostępu. Należy również upewnić się, że wdrożony jest tylko kod, który zespół zamierza wydać. Ten proces obejmuje artefakty potoków ciągłej integracji/ciągłego wdrażania, zwłaszcza artefakty, które są współużytkowane między różnymi zadaniami, które mogą być używane w ramach ataku.

Generowanie oprogramowania Bill of Materials (SBOM) powinno zostać zautomatyzowane w procesie kompilacji w celu utworzenia tego niezwykle ważnego artefaktu pochodzenia kodu bez konieczności ręcznego akcji dewelopera.

Bezpieczeństwo potoku można zapewnić, zapewniając dobrą kontrolę dostępu do zasobów używanych w potoku i regularnie walidując/aktualizując podstawowe zależności/skrypty. Należy pamiętać, że skrypty używane w potokach ciągłej integracji/ciągłego wdrażania są również kodami i powinny być traktowane w taki sam sposób, jak w przypadku innych kodów w projekcie.

Uwaga

Bezpieczeństwo potoku zależy od zabezpieczeń podstawowej infrastruktury oraz kont/tożsamości używanych do tego procesu. Aby uzyskać więcej informacji, zobacz zabezpieczanie środowiska projektowego i mechanizmów kontroli bezpiecznych operacji (Identity Identity/App Access Controls, Host/Container Controls, Network Access Controls)

Standardowa — ta kontrolka powinna być oceniana na poziomie dostępu do każdego zasobu w projekcie. Jest to wymagana kontrola na wszystkich poziomach profilu DevSecOps.

Aby dowiedzieć się więcej na temat zabezpieczeń potoku, zobacz Zabezpieczanie usługi Azure Pipelines.

Zabezpieczanie operacji

Testy penetracyjne na żywo witryny

Ta kontrolka obsługuje ciągłą praktykę SDL 7 — przeprowadzanie testów zabezpieczeń.

Muszą mieć profesjonalnych testerów penetracyjnych aplikacji, którzy próbują naruszyć bezpieczeństwo wystąpienia na żywo kompletnego obciążenia. Ten test sprawdza, czy mechanizmy kontroli zabezpieczeń obciążenia są skuteczne i spójne. Testy penetracyjne pomagają znaleźć i wyróżnić ścieżkę najmniejszego oporu, którego osoba atakująca może użyć do wykorzystania aplikacji i złamania zabezpieczeń firmy. Testy penetracyjne mogą być niezwykle cenne w odpowiednim czasie. Użyj ich po ograniczeniu taniego i łatwego wykorzystania luk w zabezpieczeniach znalezionych w poprzednich skanowaniach.

Zalecamy przeprowadzenie tego testowania na wszystkich poziomach profilów zabezpieczeń DevSecOps.

Minimum tymczasowe — zalecamy przeprowadzenie testu penetracyjnego we wszystkich aplikacjach. Ze względu na ograniczenia czasowe można zidentyfikować tylko łatwiejsze metody w aplikacji, którą może wykorzystać osoba atakująca. Zaplanuj szybkie przeniesienie tego poziomu do poziomu standardowego co najmniej.

Standardowa — w standardowym profilu zalecamy przeprowadzenie testu penetracyjnego. W takim przypadku możesz odkryć bardziej złożone luki w zabezpieczeniach ze względu na dodatkową ostrożność, która jest podejmowana na wczesnym etapie procesu programowania.

Wysoki poziom zabezpieczeń — w przypadku aplikacji biznesowych i obciążeń krytycznych wymagane jest ukończenie testu penetracyjnego. Każda luka w zabezpieczeniach w tych aplikacjach powinna być traktowana z dodatkową uwagą i troską.

Zintegruj wyniki i opinie z tych działań, aby poprawić procesy i narzędzia zabezpieczeń.

Mechanizmy kontroli dostępu do tożsamości/aplikacji

Ta kontrolka obsługuje ciągłą praktykę SDL 8 — zapewnianie zabezpieczeń platformy operacyjnej i praktyk 6 — zabezpieczanie środowiska inżynieryjnego.

Upewnij się, że są przestrzegane najlepsze rozwiązania w zakresie zabezpieczeń zarządzania tożsamościami i dostępem, w tym zabezpieczanie uprzywilejowanego dostępu , dla wszystkich elementów technicznych środowiska deweloperskiego, potoku ciągłej integracji/ciągłego wdrażania, obciążenia operacyjnego i innych systemów programistycznych. Aktorzy zagrożeń mają zaawansowane metody i automatyzację ataków na tożsamości, których często używają zarówno w systemach produkcyjnych, jak i w procesach programowania. Zarządzanie tożsamościami i dostępem jest podstawowym filarem modelu Zero Trust, który firma Microsoft zaleca.

Upewnij się, że najlepsze rozwiązania w zakresie zabezpieczeń są przestrzegane dla wszystkich systemów programistycznych i infrastruktury obsługującej je (maszyny wirtualne, kontenery, urządzenia sieciowe i inne).

Minimum tymczasowe — upewnij się, że wszyscy korzystają z uwierzytelniania wieloskładnikowego i mogą uzyskiwać dostęp tylko do systemów wymaganych do wykonywania codziennych zadań.

Standardowa — upewnij się, że składniki infrastruktury hostujące obciążenie (takie jak maszyny wirtualne, kontenery, sieć i systemy tożsamości) spełniają najlepsze rozwiązania w zakresie zabezpieczeń dotyczące zarządzania tożsamościami i dostępem, w tym zabezpieczanie uprzywilejowanego dostępu.

Wysoki poziom zabezpieczeń — zaimplementuj pełną strategię zero trust, która obejmuje uwierzytelnianie wieloskładnikowe, wykrywanie i reagowanie na zagrożenia tożsamości oraz zarządzanie upoważnieniami infrastruktury chmury (CIEM). Wykonaj model zagrożeń specyficzny dla obciążenia systemów tożsamości i składników obsługujących każde wysokie obciążenie zabezpieczeń.

Tożsamości zarządzane to bezpieczniejsza i preferowana metoda uwierzytelniania wszędzie tam, gdzie jest to możliwe. Użycie tokenów i wpisów tajnych jest mniej bezpieczne ze względu na konieczność przechowywania i pobierania ich w warstwie aplikacji. Ponadto tożsamości zarządzane są automatycznie przerzucane bez konieczności ręcznej interwencji.

Więcej szczegółów i zasobów obejmują:

Host/kontener/kontrolki środowiska

Ta kontrolka obsługuje ciągłą praktykę SDL 8 — zapewnianie zabezpieczeń platformy operacyjnej i praktyk 6 — zabezpieczanie środowiska inżynieryjnego.

Upewnij się, że najlepsze rozwiązania w zakresie zabezpieczeń są zgodne ze wszystkimi zasobami obliczeniowymi i środowiskami hostingu dla wszystkich elementów technicznych cyklu projektowania. Aktorzy zagrożeń mają zaawansowane metody i automatyzację ataków infrastruktury i punktów końcowych użytkowników, których często używają zarówno w systemach produkcyjnych, jak i w procesach programowania. Zabezpieczenia infrastruktury to podstawowy filar modelu Zero Trust, który firma Microsoft zaleca.

Ta kontrola musi obejmować wszystkie elementy cyklu projektowania i cyklu życia operacyjnego, w tym między innymi:

  • Ogólne stacje robocze i środowiska it/operacyjne
  • Dedykowane stacje robocze i środowiska deweloperskie
  • Infrastruktura potoku ciągłej integracji/ciągłego wdrażania
  • Środowiska hostingu obciążeń
  • Wszelkie inne systemy programistyczne.

Ta kontrolka obejmuje dowolny zasób, który może uruchamiać dowolny kod, w tym między innymi:

  • Hosty i maszyny wirtualne maszyn wirtualnych
  • Kontenery i infrastruktura kontenerów
  • Platformy hostingu aplikacji, skryptu i kodu
  • Subskrypcje/konta w chmurze i rejestracje
  • Stacje robocze deweloperów, użytkowników i it Administracja

Upewnij się, że stosujesz najlepsze rozwiązanie w zakresie zabezpieczeń do składników infrastruktury, w tym aktualizacji zabezpieczeń (poprawek), konfiguracji zabezpieczeń punktu odniesienia i nie tylko.

Minimum tymczasowe — stosowanie standardowych konfiguracji przedsiębiorstwa dla hostów i subskrypcji.

Standardowa — upewnij się, że infrastruktura spełnia najlepsze rozwiązania w zakresie zabezpieczeń opisane w testach porównawczych zabezpieczeń w chmurze firmy Microsoft (MCSB).

Wysoki poziom zabezpieczeń — rygorystyczne stosowanie standardów MCSB i wykonywanie modelu zagrożeń specyficznych dla obciążenia infrastruktury obsługującej każde wysokie obciążenie zabezpieczeń.

Więcej szczegółów i zasobów obejmują:

Kontrola dostępu do sieci

Ta kontrolka obsługuje ciągłą praktykę SDL 8 — zapewnianie zabezpieczeń platformy operacyjnej i praktyk 6 — zabezpieczanie środowiska inżynieryjnego.

Upewnij się, że są przestrzegane najlepsze rozwiązania w zakresie zabezpieczeń zarządzania dostępem do sieci dla wszystkich elementów technicznych środowiska projektowego, potoku ciągłej integracji/ciągłego wdrażania, środowiska obciążenia operacyjnego i innych systemów programistycznych. Aktorzy zagrożeń mają zaawansowane metody i automatyzację ataków na tożsamości, których często używają zarówno w systemach produkcyjnych, jak i w procesach programowania. Zabezpieczenia sieci to podstawowy filar modelu Zero Trust, który firma Microsoft zaleca.

Zabezpieczenia sieci powinny obejmować:

  • Ochrona sieci zewnętrznej — izolacja przed niepożądanym ruchem zewnętrznym/internetowym i ograniczeniem znanych typów ataków. Ta izolacja zazwyczaj przyjmuje formę zapory internetowej, zapory aplikacji internetowej (WAF) i rozwiązań zabezpieczeń interfejsu API.
  • Wewnętrzna ochrona sieci — izolacja przed niechcianym ruchem wewnętrznym (z innych lokalizacji sieciowych przedsiębiorstwa). Ta izolacja może używać podobnych mechanizmów kontroli jako ochrony sieci zewnętrznej i może być szczegółowa dla obciążenia lub do określonych składników i adresów IP.
  • Środki zaradcze dotyczące odmowy usługi — ochrona przed rozproszoną odmową usługi (DDoS) i innymi atakami typu "odmowa usługi".
  • Security Service Edge (SSE) — użycie mikrosegmentacji po stronie klienta w celu zapewnienia bezpiecznego dostępu bezpośrednio do zasobów, w tym zastosowania zasad Zero Trust.

Upewnij się, że najlepsze rozwiązania w zakresie zabezpieczeń są przestrzegane dla wszystkich systemów programistycznych i infrastruktury obsługującej je (maszyny wirtualne, kontenery, urządzenia sieciowe i inne).

Minimum tymczasowe — stosowanie standardowych konfiguracji przedsiębiorstwa dla obciążenia.

Standardowa — upewnij się, że wszystkie systemy mają ochronę sieci zewnętrznej, ochronę przed atakami DDoS i minimalną ochronę sieci wewnętrznej na obciążenie.

Wysoki poziom zabezpieczeń — wszystkie standardowe zabezpieczenia oraz wysoki stopień szczegółowości zabezpieczeń sieci wewnętrznej, wymuszone tunelowanie ruchu wychodzącego serwera za pośrednictwem zewnętrznych mechanizmów ochrony sieci oraz model zagrożenia specyficzne dla obciążenia infrastruktury sieciowej obsługującej każde obciążenie o wysokim poziomie zabezpieczeń.

Więcej szczegółów i zasobów obejmują:

Monitorowanie, reagowanie i odzyskiwanie

Ta kontrolka obsługuje ciągłą praktykę SDL 9 — implementowanie monitorowania zabezpieczeń i reagowania.

Upewnij się, że zespoły ds. operacji zabezpieczeń (SecOps/SOC) mają wgląd, wykrywanie zagrożeń i procedury reagowania na obciążenia (interfejsy API i aplikacje), a także infrastrukturę, która je hostuje. Upewnij się, że procesy i narzędzia między zespołami SecOps i Infrastructure/Workload umożliwiają szybkie odzyskiwanie po ataku.

Ta kontrola zapewnia bezpieczeństwo obciążenia po przejściu do środowiska produkcyjnego i aktywnego działania w organizacji. Ten proces należy zintegrować z istniejącymi funkcjami operacji zabezpieczeń, która wykrywa zdarzenia zabezpieczeń i reaguje na nie.

Monitorowanie zabezpieczeń dla niestandardowych obciążeń łączy rozwiązania rozszerzonego wykrywania i reagowania (XDR) dla typowych składników, analizując dzienniki i inne dane aplikacji w celu wykrywania i badania potencjalnych zagrożeń bezpieczeństwa. Niestandardowe dane aplikacji często obejmują: informacje o żądaniach użytkowników, aktywności aplikacji, kodach błędów, ruchu sieciowego, innych istotnych szczegółach z aplikacji, baz danych, punktów końcowych sieci i innych składników systemu.

Te dane są następnie ulepszane za pomocą szczegółowych informacji z analizy zagrożeń w czasie rzeczywistym w celu identyfikowania wzorców nietypowych zachowań, które mogą wskazywać na potencjalne próby infiltracji sieci. Po agregowaniu, skorelowaniu i normalizacji platforma XDR i Security Information and Event Management (SIEM) oferuje akcje korygowania.

Minimum tymczasowe — wdrażanie funkcji XDR w środowisku w celu monitorowania ruchu urządzeń użytkowników końcowych.

Standardowa — wdróż trasy XDR i niestandardowe wykrycia SIEM, które identyfikują nietypowe zachowanie w stosunku do ogólnego środowiska. Ten profil może obejmować wykrywanie niestandardowe dla poszczególnych obciążeń.

Wysoki poziom zabezpieczeń — standardowe mechanizmy kontroli oraz niestandardowe wykrywanie poszczególnych obciążeń w oparciu o szczegółowe informacje na temat modelowania zagrożeń obciążenia. Połącz ten profil ze sztuczną inteligencją, aby zapewnić kontekstową świadomość zaleceń dotyczących korygowania.

Następne kroki

Zastosuj te mechanizmy kontroli zabezpieczeń i dostosuj je do wymagań organizacji dotyczących tolerancji ryzyka i produktywności. Należy użyć podejścia ciągłego ulepszania, w którym stale budujesz się w kierunku idealnego stanu.

Zacznij od nadania priorytetów kontrolkom i minimalnym idealnym poziomom docelowym. Najpierw upewnij się, że masz pozytywny wpływ na zabezpieczenia i zmiany o niskim tarciu. Określ priorytety, zaimplementuj i zintegruj pierwszą kontrolkę, a następnie powtórz proces z następną kontrolką.

Należy najpierw określić priorytety kluczowych podstaw ze względu na ich szeroki pozytywny wpływ i poświadczenia i skanowanie wpisów tajnych ze względu na jego duży wpływ i częste użycie osoby atakującej.