Zespoły ds. zabezpieczeń, role i funkcje
W tym artykule opisano role zabezpieczeń wymagane do zabezpieczeń w chmurze oraz funkcje, które wykonują, związane z infrastrukturą i platformami chmury. Te role ułatwiają zapewnienie, że zabezpieczenia są częścią każdego etapu cyklu życia chmury, od programowania do operacji i ciągłego ulepszania.
Uwaga
Przewodnik Cloud Adoption Framework dla platformy Azure koncentruje się na infrastrukturze i platformach w chmurze, które obsługują wiele obciążeń. Aby uzyskać wskazówki dotyczące zabezpieczeń poszczególnych obciążeń, zobacz wskazówki dotyczące zabezpieczeń w strukturze Azure Well-Architected Framework.
W zależności od rozmiaru organizacji i innych czynników role i funkcje omówione w tym artykule mogą być spełnione przez osoby, które wykonują wiele funkcji (ról), a nie przez jedną osobę lub zespół. Przedsiębiorstwa i duże organizacje mają zwykle większe zespoły z bardziej wyspecjalizowanymi rolami, podczas gdy mniejsze organizacje mają tendencję do konsolidacji wielu ról i funkcji wśród mniejszej liczby osób. Określone obowiązki dotyczące zabezpieczeń różnią się również w zależności od platform technicznych i usług używanych przez organizację.
Niektóre zadania zabezpieczeń będą wykonywane bezpośrednio przez zespoły technologiczne i zespoły ds. chmury. Inne mogą być wykonywane przez wyspecjalizowane zespoły ds. zabezpieczeń, które działają wspólnie z zespołami technologicznymi. Niezależnie od rozmiaru i struktury organizacji osoby biorące udział w projekcie muszą mieć jasne zrozumienie zadań związanych z zabezpieczeniami, które należy wykonać. Każdy musi również pamiętać o wymaganiach biznesowych i tolerancji ryzyka bezpieczeństwa organizacji, aby mogli podejmować dobre decyzje dotyczące usług w chmurze, które uwzględniają i równoważą zabezpieczenia jako kluczowe wymaganie.
Skorzystaj ze wskazówek w tym artykule, aby ułatwić zrozumienie określonych funkcji, które zespoły i role wykonują, oraz sposób interakcji różnych zespołów w celu pokrycia całej organizacji zabezpieczeń w chmurze.
Przekształcanie ról zabezpieczeń
Role architektury zabezpieczeń, inżynierii i operacji przechodzą znaczącą transformację ich obowiązków i procesów. (Ta transformacja jest podobna do transformacji opartej na chmurze ról infrastruktury i platformy). Ta transformacja roli zabezpieczeń została oparta na wielu czynnikach:
Ponieważ narzędzia zabezpieczeń stają się coraz bardziej oparte na modelu SaaS, mniej trzeba projektować, implementować, testować i obsługiwać infrastruktury narzędzi zabezpieczeń. Te role nadal muszą obsługiwać pełny cykl życia konfigurowania usług i rozwiązań w chmurze (w tym ciągłego ulepszania), aby zapewnić spełnienie wymagań dotyczących zabezpieczeń.
Uznanie, że bezpieczeństwo jest zadaniem wszystkich osób, napędza bardziej wspólne i dojrzałe podejście, które umożliwia zespołom ds. zabezpieczeń i technologii współpracę:
Zespoły inżynierów technicznych są odpowiedzialny za zapewnienie efektywnego stosowania środków zabezpieczeń do swoich obciążeń. Ta zmiana zwiększa zapotrzebowanie na kontekst i wiedzę ze strony zespołów ds. zabezpieczeń na temat skutecznego i efektywnego spełnienia tych zobowiązań.
Zespoły ds. zabezpieczeń przenoszą się z roli kontroli jakości (nieco niepożądanej) do roli, która umożliwia zespołom technicznym: uczynienie bezpiecznej ścieżki najprostszą ścieżką. Zespoły ds. zabezpieczeń zmniejszają problemy i bariery przy użyciu automatyzacji, dokumentacji, szkolenia i innych strategii.
Zespoły ds. zabezpieczeń coraz częściej rozszerzają swoje umiejętności, aby przyjrzeć się problemom z zabezpieczeniami w wielu technologiach i systemach. Dotyczą one całego cyklu życia osoby atakującej, zamiast skupiać się na wąskich obszarach technicznych (na przykład zabezpieczenia sieci, zabezpieczenia punktów końcowych, zabezpieczenia aplikacji i zabezpieczenia chmury). Fakt, że platformy w chmurze ściśle integrują różne technologie, wzmacnia tę potrzebę opracowywania umiejętności.
Zwiększony współczynnik zmian zarówno technologii, jak i usług w chmurze w chmurze zabezpieczeń wymaga ciągłej aktualizacji procesów zabezpieczeń w celu efektywnego synchronizowania ryzyka i zarządzania nim.
Zagrożenia bezpieczeństwa teraz niezawodnie pomijają mechanizmy kontroli zabezpieczeń oparte na sieci, dlatego zespoły ds. zabezpieczeń muszą przyjąć podejście Zero Trust obejmujące tożsamość, zabezpieczenia aplikacji, zabezpieczenia punktu końcowego, zabezpieczenia chmury, ciągłą integrację/ciągłe wdrażanie, edukację użytkowników i inne mechanizmy kontroli.
Wdrożenie procesów DevOps/DevSecOps wymaga zwiększenia elastyczności ról zabezpieczeń w celu natywnego zintegrowania zabezpieczeń z wynikowym przyspieszonym cyklem projektowania rozwiązań.
Omówienie ról i zespołów
Poniższe sekcje zawierają wskazówki dotyczące tego, które zespoły i role zwykle wykonują kluczowe funkcje zabezpieczeń w chmurze (gdy te funkcje są obecne w organizacji). Należy zamapować istniejące podejście, wyszukać luki i ocenić, czy organizacja może i powinna inwestować w celu rozwiązania tych luk.
Role, które wykonują zadania zabezpieczeń, obejmują następujące role.
Dostawca usług w chmurze
Zespoły infrastruktury/platformy (architektura, inżynieria i operacje)
Zespoły ds. architektury zabezpieczeń, inżynierii i zarządzania stanem:
Architekci zabezpieczeń i inżynierowie (zabezpieczenia danych, zarządzanie tożsamościami i dostępem ( IAM), zabezpieczenia sieci, serwery i zabezpieczenia kontenerów, zabezpieczenia aplikacji i DevSecOps)
Inżynierowie zabezpieczeń oprogramowania (zabezpieczenia aplikacji)
Zarządzanie stanem (zarządzanie zarządzanie lukami w zabezpieczeniach/zarządzanie obszarem ataków)
Operacje zabezpieczeń (SecOps/SOC):
Analitycy klasyfikacji (warstwa 1)
Analitycy badania (warstwa 2)
Wyszukiwanie zagrożeń
Analiza zagrożeń
Inżynieria wykrywania
Nadzór nad zabezpieczeniami, ryzyko i zgodność (GRC)
Szkolenia i świadomość zabezpieczeń
Niezwykle ważne jest zapewnienie, że wszyscy rozumieją swoją rolę w zakresie zabezpieczeń i sposobu pracy z innymi zespołami. Ten cel można osiągnąć, dokumentując procesy zabezpieczeń między zespołami i wspólny model odpowiedzialności dla zespołów technicznych. Dzięki temu można uniknąć ryzyka i strat związanych z lukami w zakresie pokrycia oraz z nakładających się wysiłków. Pomaga to również uniknąć typowych błędów (antywzorzec), takich jak zespoły wybierające słabe rozwiązania uwierzytelniania i kryptografii, a nawet próbujące utworzyć własne.
Uwaga
Model wspólnej odpowiedzialności jest podobny do modelu odpowiedzialnego, odpowiedzialnego, konsultowanego, świadomego (RACI). Model wspólnej odpowiedzialności pomaga zilustrować wspólne podejście do tego, kto podejmuje decyzje i jakie zespoły muszą wykonać, aby współpracować dla konkretnych elementów i wyników.
Dostawca usług w chmurze
Dostawcy usług w chmurze są skutecznie wirtualnymi członkami zespołu, którzy zapewniają funkcje zabezpieczeń i możliwości podstawowej platformy w chmurze. Niektórzy dostawcy usług w chmurze udostępniają również funkcje zabezpieczeń i możliwości, których zespoły mogą używać do zarządzania stanem zabezpieczeń i zdarzeniami. Aby uzyskać więcej informacji na temat działania dostawców usług w chmurze, zobacz Model wspólnej odpowiedzialności w chmurze.
Wielu dostawców usług w chmurze udostępnia informacje na temat praktyk zabezpieczeń i mechanizmów kontroli po żądaniu lub za pośrednictwem portalu, takiego jak portal zaufania usług firmy Microsoft.
Zespoły infrastruktury/platformy (architektura, inżynieria i operacje)
Zespoły ds. architektury infrastruktury/platformy, inżynierii i operacji implementują i integrują mechanizmy kontroli zabezpieczeń, prywatności i zgodności w chmurze w środowiskach infrastruktury chmury i platformy (między serwerami, kontenerami, siecią, tożsamością i innymi składnikami technicznymi).
Role inżynieryjne i operacyjne mogą skupiać się głównie na systemach w chmurze lub ciągłej integracji i ciągłego wdrażania (CI/CD) lub mogą działać w pełnym zakresie chmury, ciągłej integracji/ciągłego wdrażania, lokalnych i innych infrastruktur i platform.
Te zespoły są odpowiedzialne za spełnienie wszystkich wymagań dotyczących dostępności, skalowalności, zabezpieczeń, prywatności i innych wymagań dotyczących usług w chmurze organizacji hostujących obciążenia biznesowe. Współpracują one ze swoimi ekspertami w zakresie bezpieczeństwa, ryzyka, zgodności i prywatności, aby zwiększyć wyniki, które łączą i równoważą wszystkie te wymagania.
Zespoły ds. architektury zabezpieczeń, inżynierii i stanu
Zespoły ds. zabezpieczeń współpracują z rolami infrastruktury i platformy (i innymi), aby ułatwić tłumaczenie strategii zabezpieczeń, zasad i standardów na architektury, rozwiązania i wzorce projektowe. Zespoły te koncentrują się na umożliwieniu sukcesu zespołów ds. zabezpieczeń w chmurze, oceniając i wpływając na bezpieczeństwo infrastruktury oraz procesów i narzędzi używanych do zarządzania nimi. Poniżej przedstawiono niektóre typowe zadania wykonywane przez zespoły ds. zabezpieczeń dla infrastruktury:
Architekci zabezpieczeń i inżynierowie dostosowują zasady zabezpieczeń, standardy i wytyczne dotyczące środowisk chmury do projektowania i implementowania mechanizmów kontroli we współpracy z ich odpowiednikami infrastruktury/platformy. Architekci zabezpieczeń i inżynierowie pomagają w wielu różnych elementach, w tym:
Dzierżawy/subskrypcje. Architekci zabezpieczeń i inżynierowie współpracują z architektami infrastruktury i inżynierami i architektami dostępu (tożsamości, sieci, aplikacji i innych), aby pomóc w ustanowieniu konfiguracji zabezpieczeń dla dzierżaw, subskrypcji i kont w różnych dostawcach chmury (które są monitorowane przez zespoły zarządzania stanem zabezpieczeń).
IAM. Architekci dostępu (tożsamość, sieć, aplikacja i inne osoby) współpracują z inżynierami tożsamości i zespołami ds. operacji i infrastruktury/platform w celu projektowania, implementowania i obsługi rozwiązań do zarządzania dostępem. Te rozwiązania chronią przed nieautoryzowanym użyciem zasobów biznesowych organizacji, umożliwiając autoryzowanym użytkownikom śledzenie procesów biznesowych w celu łatwego i bezpiecznego uzyskiwania dostępu do zasobów organizacji. Zespoły te pracują nad rozwiązaniami, takimi jak katalogi tożsamości i rozwiązania logowania jednokrotnego, uwierzytelnianie bez hasła i uwierzytelnianie wieloskładnikowe (MFA), oparte na ryzyku rozwiązania dostępu warunkowego, tożsamości obciążeń, tożsamości uprzywilejowanych/zarządzania dostępem (PIM/PAM), infrastruktury chmury i zarządzania upoważnieniami (CIEM) i nie tylko. Te zespoły współpracują również z inżynierami sieci i operacjami w celu projektowania, implementowania i obsługi rozwiązań brzegowych (SSE) usług zabezpieczeń. Zespoły ds. obciążeń mogą korzystać z tych funkcji, aby zapewnić bezproblemowy i bardziej bezpieczny dostęp do poszczególnych składników obciążeń i aplikacji.
Bezpieczeństwo danych. Architekci zabezpieczeń i inżynierowie współpracują z architektami danych i inżynierami sztucznej inteligencji, aby pomóc zespołom infrastruktury/platformy w ustanowieniu podstawowych funkcji zabezpieczeń danych dla wszystkich danych i zaawansowanych funkcji, które mogą służyć do klasyfikowania i ochrony danych w poszczególnych obciążeniach. Aby uzyskać więcej informacji na temat podstawowych zabezpieczeń danych, zobacz test porównawczy ochrony danych zabezpieczeń firmy Microsoft. Aby uzyskać więcej informacji na temat ochrony danych w poszczególnych obciążeniach, zobacz Wskazówki dotyczące dobrze zaprojektowanej struktury.
Zabezpieczenia sieci. Architekci zabezpieczeń i inżynierowie współpracują z architektami sieci i inżynierami , aby pomóc zespołom infrastruktury/platformy w ustanawianiu podstawowych funkcji zabezpieczeń sieci, takich jak łączność z chmurą (linie prywatne/dzierżawione), strategie dostępu zdalnego i rozwiązania, zapory ruchu przychodzącego i wychodzącego, zapory aplikacji internetowych (WAFs) i segmentacja sieci. Te zespoły współpracują również z architektami tożsamości, inżynierami i operacjami w celu projektowania, implementowania i obsługi rozwiązań SSE. Zespoły ds. obciążeń mogą korzystać z tych możliwości, aby zapewnić dyskretną ochronę lub izolację poszczególnych składników obciążenia i aplikacji.
Serwery i zabezpieczenia kontenerów. Architekci zabezpieczeń i inżynierowie współpracują z architektami infrastruktury i inżynierami , aby pomóc zespołom infrastruktury/platformy w ustanowieniu podstawowych funkcji zabezpieczeń dla serwerów, maszyn wirtualnych, kontenerów, orkiestracji/zarządzania, ciągłej integracji/ciągłego wdrażania i powiązanych systemów. Zespoły te ustanawiają procesy odnajdywania i spisu, konfiguracje punktów odniesienia zabezpieczeń/testów porównawczych, procesy konserwacji i stosowania poprawek, listy dozwolonych plików binarnych plików wykonywalnych, obrazów szablonów, procesów zarządzania i nie tylko. Zespoły ds. obciążeń mogą również korzystać z tych podstawowych funkcji infrastruktury w celu zapewnienia zabezpieczeń serwerów i kontenerów dla poszczególnych składników obciążeń i aplikacji.
Podstawy zabezpieczeń oprogramowania (na potrzeby zabezpieczeń aplikacji i metodyki DevSecOps). Architekci zabezpieczeń i inżynierowie współpracują z inżynierami ds. zabezpieczeń oprogramowania, aby pomóc zespołom ds. infrastruktury/platformy w tworzeniu możliwości zabezpieczeń aplikacji, które mogą być używane przez poszczególne obciążenia, skanowanie kodu, narzędzia do rozliczania materiałów (SBOM, software bill of materials), narzędzia WAFs i skanowanie aplikacji. Aby uzyskać więcej informacji na temat sposobu ustanawiania cyklu projektowania zabezpieczeń (SDL, Security Development Lifecycle). Aby uzyskać więcej informacji na temat korzystania z tych funkcji przez zespoły obciążeń, zobacz wskazówki dotyczące cyklu życia tworzenia zabezpieczeń w strukturze dobrze zaprojektowanej architektury.
Inżynierowie ds. zabezpieczeń oprogramowania oceniają kod, skrypty i inną zautomatyzowaną logikę używaną do zarządzania infrastrukturą, w tym infrastrukturą jako kodem (IaC), przepływami pracy ciągłej integracji/ciągłego wdrażania oraz innymi niestandardowymi narzędziami lub aplikacjami. Inżynierowie ci powinni być zaangażowani w ochronę formalnego kodu w skompilowanych aplikacjach, skryptach, konfiguracjach platform automatyzacji oraz wszelkich innych formach kodu wykonywalnego lub skryptu, który może umożliwić osobom atakującym manipulowanie operacją systemu. Ta ocena może wiązać się z po prostu przeprowadzeniem analizy modelu zagrożeń systemu lub może obejmować przegląd kodu i narzędzia do skanowania zabezpieczeń. Aby uzyskać więcej informacji na temat ustanawiania języka SDL, zobacz wskazówki dotyczące rozwiązań SDL.
Zarządzanie stanem (zarządzanie lukami w zabezpieczeniach/ zarządzanie obszarem ataków) to zespół ds. zabezpieczeń operacyjnych, który koncentruje się na włączaniu zabezpieczeń dla zespołów ds. operacji technicznych. Zarządzanie stanem ułatwia tym zespołom określanie priorytetów i implementowanie mechanizmów kontroli w celu blokowania lub eliminowania technik ataków. Zespoły zarządzania stanem współpracują ze wszystkimi zespołami ds. operacji technicznych (w tym zespołami w chmurze) i często pełnią rolę podstawowych środków zrozumienia wymagań dotyczących zabezpieczeń, wymagań dotyczących zgodności i procesów ładu.
Zarządzanie stanem często służy jako centrum doskonałości (CoE) dla zespołów ds. infrastruktury zabezpieczeń, podobnie jak inżynierowie oprogramowania często służą jako centrum zabezpieczeń zespołów programistycznych. Typowe zadania dla tych zespołów obejmują następujące zadania.
Monitorowanie stanu zabezpieczeń. Monitoruj wszystkie systemy techniczne przy użyciu narzędzi do zarządzania stanem, takich jak Microsoft Security Exposure Management, Zarządzanie uprawnieniami Microsoft Entra, luka w zabezpieczeniach firmy Microsoft i narzędzia EASM (External Attack Surface Management) i narzędzia CIEM oraz niestandardowe narzędzia i pulpity nawigacyjne dotyczące stanu zabezpieczeń. Ponadto zarządzanie stanem wykonuje analizę w celu zapewnienia szczegółowych informacji przez:
Przewidywanie wysoce prawdopodobnych i szkodliwych ścieżek ataków. Osoby atakujące "myślą w grafach" i szukają ścieżek do systemów o znaczeniu krytycznym dla działania firmy, łącząc wiele zasobów i luk w zabezpieczeniach w różnych systemach (na przykład naruszenie zabezpieczeń punktów końcowych użytkownika, a następnie przechwycenie poświadczeń administratora przy użyciu skrótu/biletu, a następnie uzyskanie dostępu do danych krytycznych dla działania firmy). Zespoły zarządzania stanem współpracują z architektami i inżynierami ds. zabezpieczeń, aby odkryć i ograniczyć te ukryte zagrożenia, które nie zawsze pojawiają się na listach technicznych i raportach.
Przeprowadzanie ocen zabezpieczeń w celu przeglądu konfiguracji systemu i procesów operacyjnych w celu uzyskania dokładniejszego zrozumienia i szczegółowych informacji poza danymi technicznymi z narzędzi do stanu zabezpieczeń. Oceny te mogą mieć formę nieformalnych rozmów odnajdywania lub formalnych ćwiczeń modelowania zagrożeń.
Pomoc w określaniu priorytetów. Pomóż zespołom technicznym aktywnie monitorować swoje zasoby i ustalać priorytety pracy nad zabezpieczeniami. Zarządzanie stanem pomaga w kontekście ograniczania ryzyka, uwzględniając wpływ ryzyka na bezpieczeństwo (informowany przez doświadczenie, raporty dotyczące zdarzeń operacji zabezpieczeń i inne źródła analizy zagrożeń, analizy biznesowej i inne źródła) oprócz wymagań dotyczących zgodności z zabezpieczeniami.
Trenowanie, mentor i mistrz. Zwiększ wiedzę na temat zabezpieczeń i umiejętności zespołów inżynierów technicznych dzięki szkoleniu, mentoringowi i nieformalnym transferowi wiedzy. Role zarządzania stanem mogą również współpracować z gotowością organizacji / szkoleniami i szkoleniami w zakresie edukacji w zakresie zabezpieczeń i zaangażowania w formalne szkolenia w zakresie zabezpieczeń oraz konfigurowania zabezpieczeń w zespołach technicznych, które inkluzują i edukują swoich rówieśników w zakresie zabezpieczeń.
Identyfikowanie luk i ambasadorów poprawek. Zidentyfikuj ogólne trendy, luki procesów, luki narzędzi i inne szczegółowe informacje na temat ryzyka i środków zaradczych. Role zarządzania stanem współpracują i komunikują się z architektami zabezpieczeń i inżynierami w celu opracowywania rozwiązań, tworzenia przypadków finansowania rozwiązań i pomocy w opracowywaniu poprawek.
Koordynowanie operacji zabezpieczeń (SecOps). Pomoc zespołom technicznym w pracy z rolami SecOps, takimi jak zespoły ds. inżynierii wykrywania i wyszukiwania zagrożeń. Ta ciągłość we wszystkich rolach operacyjnych pomaga zapewnić, że wykrycia są wdrożone i prawidłowo zaimplementowane, dane zabezpieczeń są dostępne do badania zdarzeń i wyszukiwania zagrożeń, procesy są w miejscu współpracy i nie tylko.
Podaj raporty. Udostępnianie terminowych i dokładnych raportów dotyczących zdarzeń zabezpieczeń, trendów i metryk wydajności starszym kierownictwu i uczestnikom projektu w celu zaktualizowania procesów ryzyka organizacyjnego.
Zespoły zarządzania stanem często ewoluują z istniejących ról zarządzanie lukami w zabezpieczeniach oprogramowania w celu rozwiązania pełnego zestawu funkcjonalnych, konfiguracji i typów luk w zabezpieczeniach operacyjnych opisanych w modelu referencyjnym Open Group Zero Trust Model. Każdy typ luki w zabezpieczeniach może zezwalać nieautoryzowanym użytkownikom (w tym osobom atakującym) na przejęcie kontroli nad oprogramowaniem lub systemami, umożliwiając im spowodowanie szkód w zasobach biznesowych.
Luki w zabezpieczeniach funkcjonalnych występują w projekcie lub implementacji oprogramowania. Mogą one zezwalać na nieautoryzowaną kontrolę nad oprogramowaniem, którego dotyczy problem. Te luki w zabezpieczeniach mogą być wadami oprogramowania opracowanego przez własne zespoły lub wad w oprogramowaniu komercyjnym lub open source (zwykle śledzonym przez identyfikator typowych luk w zabezpieczeniach i ekspozycji).
Luki w zabezpieczeniach konfiguracji to błędne konfiguracje systemów, które umożliwiają nieautoryzowany dostęp do funkcji systemu. Te luki w zabezpieczeniach można wprowadzać podczas bieżących operacji, nazywanych również dryfem konfiguracji. Można je również wprowadzić podczas początkowego wdrażania i konfiguracji oprogramowania i systemów lub przez słabe wartości domyślne zabezpieczeń od dostawcy. Do powszechnych przykładów należą:
Oddzielone obiekty, które umożliwiają nieautoryzowany dostęp do elementów, takich jak rekordy DNS i członkostwo w grupach.
Nadmierne role administracyjne lub uprawnienia do zasobów.
Używanie słabszego protokołu uwierzytelniania lub algorytmu kryptograficznego, który ma znane problemy z zabezpieczeniami.
Słabe konfiguracje domyślne lub domyślne hasła.
Luki w zabezpieczeniach operacyjnych są słabe w standardowych procesach operacyjnych i praktykach, które umożliwiają nieautoryzowany dostęp lub kontrolę systemów. Oto kilka przykładów:
Administratorzy korzystający z kont udostępnionych zamiast własnych kont indywidualnych do wykonywania zadań uprzywilejowanych.
Korzystanie z konfiguracji "browse-up", które tworzą ścieżki podniesienia uprawnień, które mogą być nadużywane przez osoby atakujące. Ta luka w zabezpieczeniach występuje, gdy konta administracyjne z wysokimi uprawnieniami logują się do urządzeń i stacji roboczych użytkowników o niższym zaufaniu (takich jak standardowe stacje robocze i urządzenia należące do użytkownika), czasami za pośrednictwem serwerów przesiadkowych, które nie skutecznie ograniczają tych zagrożeń. Aby uzyskać więcej informacji, zobacz Zabezpieczanie uprzywilejowanego dostępu i urządzeń z dostępem uprzywilejowanym.
Operacje zabezpieczeń (SecOps/SOC)
Zespół SecOps jest czasami nazywany usługą Security Operations Center (SOC). Zespół SecOps koncentruje się na szybkim znalezieniu i usunięciu niepożądanego dostępu do zasobów organizacji. Współpracują one w ścisłej współpracy z zespołami ds. operacji technologicznych i inżynierów. Role SecOps mogą współdziałać ze wszystkimi technologiami w organizacji, w tym tradycyjnymi technologiami IT, technologią operacyjną (OT) i Internetem rzeczy (IoT). Poniżej przedstawiono role SecOps, które najczęściej wchodzą w interakcje z zespołami w chmurze:
Analitycy klasyfikacji (warstwa 1). Reaguje na wykrywanie zdarzeń pod kątem dobrze znanych technik ataków i postępuje zgodnie z udokumentowanymi procedurami, aby szybko je rozwiązać (lub w razie potrzeby eskalować je do analityków badania). W zależności od zakresu i poziomu dojrzałości secOps może to obejmować wykrywanie i alerty z poczty e-mail, rozwiązań ochrony przed złośliwym kodem punktu końcowego, usług w chmurze, wykrywania sieci lub innych systemów technicznych.
Analitycy badania (warstwa 2). Odpowiada na badania incydentów o większej złożoności i większej ważności, które wymagają większej doświadczenia i wiedzy (poza dobrze udokumentowanymi procedurami rozwiązywania problemów). Ten zespół zwykle bada ataki przeprowadzane przez aktywnych przeciwników i ataki, które mają wpływ na wiele systemów. Współpracuje ona z zespołami ds. operacji technologicznych i inżynierów w celu zbadania zdarzeń i ich rozwiązania.
Wyszukiwanie zagrożeń. Aktywnie wyszukuje ukryte zagrożenia w obrębie majątku technicznego, które unikały standardowych mechanizmów wykrywania. Ta rola korzysta z zaawansowanych analiz i badań opartych na hipotezach.
Analiza zagrożeń. Zbiera i rozpowszechnia informacje o osobach atakujących i zagrożeniach dla wszystkich uczestników projektu, w tym firmy, technologii i bezpieczeństwa. Zespoły analizy zagrożeń przeprowadzają badania, dzielą się swoimi wynikami (formalnie lub nieformalnie) i rozpowszechniają je wśród różnych uczestników projektu, w tym do zespołu ds. zabezpieczeń w chmurze. Ten kontekst zabezpieczeń pomaga tym zespołom zwiększyć odporność usług w chmurze na ataki, ponieważ korzystają z rzeczywistych informacji o ataku w projekcie, implementacji, testowaniu i operacji oraz ciągłym ulepszaniu.
Inżynieria wykrywania. Tworzy niestandardowe wykrywanie ataków i dostosowuje wykrywanie ataków udostępniane przez dostawców i szerszą społeczność. Te niestandardowe wykrywanie ataków uzupełniają wykrywanie udostępniane przez dostawcę w przypadku typowych ataków, które są często spotykane w narzędziach rozszerzonego wykrywania i reagowania (XDR) oraz niektórych narzędzi do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM). Inżynierowie wykrywania współpracują z zespołami ds. zabezpieczeń w chmurze, aby zidentyfikować możliwości projektowania i implementowania wykrywania, danych wymaganych do ich obsługi oraz procedur reagowania/odzyskiwania na potrzeby wykrywania.
Nadzór nad zabezpieczeniami, ryzyko i zgodność
Zarządzanie zabezpieczeniami, ryzyko i zgodność (GRC) to zestaw wzajemnie powiązanych dyscyplin, które integrują pracę techniczną zespołów ds. zabezpieczeń z celami i oczekiwaniami organizacji. Te role i zespoły mogą być hybrydą dwóch lub większej liczby dyscyplin lub mogą być rolami dyskretnymi. Zespoły w chmurze wchodzą w interakcje z każdą z tych dziedzin w trakcie cyklu życia technologii w chmurze:
Dyscyplina ładu to podstawowa funkcja, która koncentruje się na zapewnieniu, że organizacja konsekwentnie wdraża wszystkie aspekty zabezpieczeń. Zespoły ds. ładu koncentrują się na prawach decyzyjnych (którzy podejmują decyzje) i strukturach procesów, które łączą się z zespołami i kierują nimi. Bez skutecznego ładu organizacja ze wszystkimi odpowiednimi mechanizmami kontroli, zasadami i technologią nadal może zostać naruszona przez osoby atakujące, które znalazły obszary, w których zamierzone zabezpieczenia nie są wdrażane dobrze, w pełni lub w ogóle.
Dyscyplina zarządzania ryzykiem koncentruje się na zapewnieniu, że organizacja skutecznie ocenia, rozumie i zmniejsza ryzyko. Role zarządzania ryzykiem współpracują z wieloma zespołami w całej organizacji, aby utworzyć wyraźną reprezentację ryzyka organizacji i zachować ją na bieżąco. Ponieważ wiele krytycznych usług biznesowych może być hostowanych na infrastrukturze i platformach w chmurze, zespoły ds. chmury i ryzyka muszą współpracować w celu oceny ryzyka organizacyjnego i zarządzania nim. Ponadto bezpieczeństwo łańcucha dostaw koncentruje się na zagrożeniach związanych z zewnętrznymi dostawcami, składnikami open source i partnerami.
Dyscyplina zgodności zapewnia zgodność systemów i procesów z wymaganiami prawnymi i zasadami wewnętrznymi. Bez tej dyscypliny organizacja może być narażona na ryzyko związane z niezgodnością z zobowiązaniami zewnętrznymi (grzywny, odpowiedzialność, utrata przychodów z niezdolności do działania na niektórych rynkach i nie tylko). Wymagania dotyczące zgodności zwykle nie mogą nadążyć za szybkością ewolucji osoby atakującej, ale są one jednak ważnym źródłem wymagań.
Wszystkie trzy z tych dyscyplin działają we wszystkich technologiach i systemach w celu kierowania wynikami organizacyjnymi we wszystkich zespołach. Wszystkie trzy polegają również na kontekście uzyskanym od siebie i znacznie korzystają z bieżących danych o wysokiej wierności na zagrożeniach, biznesie i środowisku technologicznym. Te dyscypliny opierają się również na architekturze, aby wyrazić możliwą do działania wizję, którą można zaimplementować, a także edukacji w zakresie zabezpieczeń i zasad w celu ustanowienia reguł i kierowania zespołami za pośrednictwem wielu codziennych decyzji.
Zespoły inżynieryjne i operacyjne w chmurze mogą współpracować z rolami zarządzania stanem , zespołami ds. zgodności i inspekcji , architekturą zabezpieczeń i inżynierią lub głównymi rolami dyrektora ds. zabezpieczeń informacji (CISO) w tematach GRC.
Edukacja i zasady dotyczące zabezpieczeń
Organizacje muszą mieć pewność, że wszystkie role mają podstawowe umiejętności w zakresie zabezpieczeń i wskazówki dotyczące tego, co mają robić w odniesieniu do zabezpieczeń i jak to zrobić. Aby osiągnąć ten cel, potrzebne jest połączenie pisemnej polityki i edukacji. Edukacja dla zespołów w chmurze może być nieformalnym mentorowaniem przez specjalistów ds. zabezpieczeń, którzy pracują bezpośrednio z nimi, lub może to być formalny program z udokumentowanym programem nauczania i wyznaczonymi mistrzami zabezpieczeń.
W większej organizacji zespoły ds. zabezpieczeń współpracują z rolą gotowości organizacji/ szkolenia i edukacji w zakresie zabezpieczeń oraz zaangażowania w formalne szkolenia w zakresie zabezpieczeń i tworzenia mistrzów zabezpieczeń w zespołach technicznych w celu informowania swoich rówieśników o bezpieczeństwie.
Edukacja dotycząca zabezpieczeń i zasady muszą pomóc każdemu z nich zrozumieć:
Dlaczego. Pokaż każdą rolę, dlaczego bezpieczeństwo jest dla nich ważne i ich cele w kontekście ich obowiązków związanych z rolą. Jeśli ludzie nie rozumieją wyraźnie, dlaczego bezpieczeństwo ma dla nich znaczenie, ocenią to jako nieistotne i przejdziemy do czegoś innego.
Co. Podsumuj zadania zabezpieczeń, które muszą wykonać w języku, który już rozumie. Jeśli ludzie nie wiedzą, co są proszeni o zrobienie, zakładają, że bezpieczeństwo nie jest dla nich ważne lub istotne i przejdź do czegoś innego.
Jak. Upewnij się, że każda rola ma jasne instrukcje dotyczące stosowania wskazówek dotyczących zabezpieczeń w ich roli. Jeśli ludzie nie wiedzą, jak faktycznie wykonać to, co są monitowane (na przykład serwery poprawek, określić, czy link jest linkiem wyłudzania informacji, zgłosić komunikat prawidłowo, przejrzeć kod lub wykonać model zagrożenia), nie powiedzie się i przejdzie do czegoś innego.
Przykładowy scenariusz: typowe współdziałanie między zespołami
Gdy organizacja wdraża i operacjonalizuje zaporę aplikacji internetowej, kilka zespołów ds. zabezpieczeń musi współpracować w celu zapewnienia efektywnego wdrażania, zarządzania i integracji z istniejącą infrastrukturą zabezpieczeń. Oto jak współdziałanie między zespołami może wyglądać w organizacji zabezpieczeń przedsiębiorstwa:
- Planowanie i projektowanie
- Zespół ds. ładu identyfikuje potrzebę zwiększenia zabezpieczeń aplikacji internetowych i przydziela budżet zapory aplikacji internetowej.
- Architekt zabezpieczeń sieci projektuje strategię wdrażania zapory aplikacji internetowej, zapewniając, że bezproblemowo integruje się z istniejącymi mechanizmami kontroli zabezpieczeń i jest zgodny z architekturą zabezpieczeń organizacji.
- Implementacja
- Inżynier zabezpieczeń sieci wdraża zaporę aplikacji internetowej zgodnie z projektem architekta, konfigurując go w celu ochrony określonych aplikacji internetowych i umożliwia monitorowanie.
- Inżynier zarządzania dostępem i tożsamościami konfiguruje mechanizmy kontroli dostępu, zapewniając, że tylko autoryzowany personel może zarządzać zaporą aplikacji internetowej.
- Monitorowanie i zarządzanie
- Zespół zarządzający stanem zawiera instrukcje dotyczące soC konfigurowania monitorowania i alertów zapory aplikacji internetowej oraz konfigurowania pulpitów nawigacyjnych w celu śledzenia aktywności zapory aplikacji internetowej.
- Zespoły inżynierów analizy zagrożeń i wykrywania zagrożeń pomagają opracowywać plany reagowania na zdarzenia obejmujące zaporę aplikacji internetowej i przeprowadzać symulacje w celu przetestowania tych planów.
- Zgodność i zarządzanie ryzykiem
- Oficer ds. zarządzania zgodnością i ryzykiem przegląda wdrożenie zapory aplikacji internetowej, aby upewnić się, że spełnia ona wymagania prawne i przeprowadza okresowe inspekcje.
- Inżynier ds. zabezpieczeń danych zapewnia, że zasady rejestrowania i ochrony danych zapory aplikacji internetowej są zgodne z przepisami dotyczącymi prywatności danych.
- Ciągłe ulepszanie i szkolenie
- Inżynier DevSecOps integruje zarządzanie zaporą aplikacji internetowej z potokiem ciągłej integracji/ciągłego wdrażania, zapewniając, że aktualizacje i konfiguracje są zautomatyzowane i spójne.
- Specjalista ds . edukacji i zaangażowania w zakresie zabezpieczeń opracowuje i dostarcza programy szkoleniowe, aby zapewnić, że wszyscy odpowiedni pracownicy rozumieją sposób efektywnego korzystania z zapory aplikacji internetowej i zarządzania nią.
- Członek zespołu ds. ładu w chmurze przegląda procesy wdrażania zapory aplikacji internetowej i zarządzania nimi, aby upewnić się, że są one zgodne z zasadami i standardami organizacji.
Dzięki efektywnej współpracy te role zapewniają prawidłowe wdrażanie zapory aplikacji internetowej, a także ciągłe monitorowanie, zarządzanie i ulepszanie w celu ochrony aplikacji internetowych organizacji przed zmieniającymi się zagrożeniami.