Zagadnienia dotyczące operacji zabezpieczeń w chmurze

Zespoły ds. cyberbezpieczeństwa często składają się z różnych funkcji. Zazwyczaj mogą to być między innymi Zarządzanie, Ryzyko i Zgodność (GRC), Architektura Bezpieczeństwa, Ubezpieczenie i Operacje Bezpieczeństwa.

Każda funkcja ma swoje własne specyficzne zadania, ale działa w kierunku wspólnego celu – współpracy z resztą firmy i pomagania zespołom w bezpiecznym wysyłaniu i uruchamianiu obciążeń.

W tym artykule autorzy skupią się na roli funkcji operacji bezpieczeństwa (SecOps), a w szczególności na kwestiach, na które należy zwrócić uwagę przy wyborze najbardziej odpowiedniego modelu operacyjnego dla przedsiębiorstwa i środowiska. Staje się to szczególnie ważne, gdy Twoja organizacja zaczyna dostosowywać i obsługiwać więcej obciążeń w chmurze.

Zespoły operacyjne, które zarządzają procesami biznesowymi, są podstawą organizacji – torują drogę do efektywnego prowadzenia biznesu i zapewniają solidne zrozumienie, które codzienne procesy okazują się skuteczne. Zazwyczaj procesy te są definiowane w ramach standardowych procedur operacyjnych (SOP), znanych również jako runbooki lub podręczniki, a funkcje biznesowe są wokół nich scentralizowane – pomyśl o zasobach ludzkich, księgowości, IT i tak dalej. Dotyczy to również cyberbezpieczeństwa i SecOps, które zazwyczaj sprawują nadzór operacyjny nad bezpieczeństwem całej organizacji.

Zespoły przyjmują model operacyjny, który z natury skłania się ku delegowaniu własności zabezpieczeń podczas skalowania i opracowywania obciążeń w chmurze. Pojawienie się tego rodzaju delegowania może spowodować, że ponownie ocenisz obecnie obsługiwany model, a kiedy to zrobisz, ważne jest, aby zrozumieć, jaki wynik próbujesz osiągnąć. Chcesz mieć możliwość szybkiego reagowania i rozwiązywania problemów związanych z bezpieczeństwem. Chcesz pomóc zespołom aplikacji podejmować własne decyzje dotyczące bezpieczeństwa. Chcesz również mieć scentralizowany wgląd w stan zabezpieczeń swojej organizacji. Ten ostatni cel jest kluczem do określenia, gdzie istnieją możliwości udoskonalenia narzędzi lub procesów, które mogą usprawnić działanie wielu zespołów.

Trzy sposoby projektowania modelu operacyjnego dla SecOps są następujące:

• Scentralizowany – bardziej tradycyjny model, w którym SecOps jest odpowiedzialny za identyfikowanie i korygowanie zdarzeń związanych z bezpieczeństwem w całej firmie. Może to również obejmować przegląd ogólnych ustaleń dotyczących stanu bezpieczeństwa w firmie, takich jak poprawki i problemy z konfiguracją zabezpieczeń.
• Zdecentralizowany – odpowiedzialność za reagowanie na zdarzenia związane z bezpieczeństwem i usuwanie skutków tych zdarzeń w całej firmie została przekazana właścicielom aplikacji i poszczególnym jednostkom biznesowym i nie ma centralnej funkcji operacyjnej. Zazwyczaj nadal będzie istniała nadrzędna funkcja zarządzania bezpieczeństwem, która zajmuje się bardziej polityką lub zasadami.
• Hybrydowy – połączenie obu podejść, w którym SecOps nadal ponosi odpowiedzialność za identyfikowanie i organizowanie reakcji na zdarzenia związane z bezpieczeństwem, podczas gdy odpowiedzialność za środki zaradcze spoczywa na właścicielach aplikacji i poszczególnych jednostkach biznesowych.

Jak wynika z powyższych opisów, główna różnica między różnymi modelami polega na zespole odpowiedzialnym za działania naprawcze i reagowanie. Za pomocą tego artykułu autorzy omówią korzyści i kwestie związane z każdym modelem.

Strategie i modele operacyjne, o których mowa, skupią się na roli SecOps i organizacji działających w chmurze. Warto zauważyć, że te modele operacyjne nie dotyczą żadnej konkretnej technologii ani dostawcy chmury. Każdy model ma swoje zalety i wyzwania, które należy wziąć pod uwagę; Ogólnie rzecz biorąc, należy dążyć do przyjęcia modelu operacyjnego, który zapewnia najlepsze wyniki biznesowe, jednocześnie zarządzając ryzykiem i zapewniając ścieżkę ciągłego doskonalenia.

Tło: model scentralizowany

Jak można się spodziewać, najbardziej znanym i dobrze rozumianym modelem operacyjnym SecOps jest model scentralizowany. Tradycyjnie SecOps rozwijał się stopniowo od pracowników ds. bezpieczeństwa wewnętrznego, którzy bardzo dobrze rozumieją w większości statyczną infrastrukturę lokalną i zasoby korporacyjne, takie jak laptopy pracowników, serwery i bazy danych.

W ten sposób centralizacja zapewnia organizacjom znany model operacyjny i strukturę. Z biegiem czasu działanie w tym modelu w całej branży umożliwiło zespołom opracowanie niezawodnych SOP dla typowych zdarzeń związanych z bezpieczeństwem. Analitycy, którzy zajmują się tymi incydentami, dobrze rozumieją infrastrukturę, środowisko i kroki niezbędne do rozwiązania incydentów. Każdy incydent daje możliwość aktualizacji SPO i dzielenia się tą wiedzą i wyciągniętymi wnioskami z szerszą branżą. Ten ciągły cykl informacji zwrotnych przynosi korzyści zespołom SecOps od wielu lat.

Gdy wystąpią problemy z zabezpieczeniami, zrozumienie podziału odpowiedzialności między różnymi zespołami w tym modelu jest niezwykle ważne dla szybkiego rozwiązania i naprawy. Macierz przypisania odpowiedzialności, znana również jako model RACI, ma zdefiniowane role – świadomy, odpowiedzialny, konsultowany i poinformowany. Wykorzystanie takiego modelu pomoże dopasować każdego pracownika, dział i jednostkę biznesową, tak aby byli świadomi swojej roli i punktów kontaktowych, gdy wystąpią problemy i będą mogli korzystać ze zdefiniowanych podręczników, aby szybko reagować na incydenty.

Presja może okazać się wysoka podczas zdarzenia związanego z bezpieczeństwem, a incydenty związane z systemami produkcyjnymi mają dodatkową wagę. Zazwyczaj w modelu scentralizowanym zdarzenia związane z bezpieczeństwem wpływają do centralnej kolejki, którą monitoruje analityk bezpieczeństwa. Powszechnym podejściem jest Security Operations Center (SOC), w którym zdarzenia z wielu źródeł są wyświetlane na ekranach, a także wyzwalają aktywność w kolejce. Incydenty związane z bezpieczeństwem są rozpatrywane przez doświadczony zespół, który jest dobrze zorientowany w SOP i rozumie, jak ważna jest wrażliwość czasowa podczas radzenia sobie z takimi incydentami. Ponadto scentralizowany zespół SecOps zwykle działa w modelu 24/7, co można osiągnąć, mając zespoły w wielu strefach czasowych lub z pomocą MSSP (Managed Security Service Provider). Niezależnie od wybranej strategii posiadanie doświadczonych analityków bezpieczeństwa zajmujących się incydentami związanymi z bezpieczeństwem jest wielką korzyścią, ponieważ doświadczenie pomaga zapewnić skuteczne i dokładne rozwiązywanie problemów.

Tak więc, z zaprezentowanym kontekstem i tłem – jak wygląda scentralizowany SOC, gdy działa w chmurze, i jakie są jego wyzwania? Sprawdźmy.

Scentralizowany SOC w chmurze: zalety

Dostawcy chmury oferują wiele rozwiązań i możliwości dla SOC, które działają w modelu scentralizowanym. Możesz na przykład monitorować ogólny stan bezpieczeństwa chmury w swojej organizacji, co pozwala na przeprowadzanie testów porównawczych kluczowych wskaźników wydajności (KPI), zarówno wewnętrznych, jak i branżowych. Może to następnie pomóc Twojej organizacji w ukierunkowaniu inicjatyw bezpieczeństwa, szkoleń i świadomości na obszary o niższych ocenach.

Koordynacja, automatyzacja i reagowanie na zagrożenia (SOAR) to wyrażenie powszechnie używane w branży zabezpieczeń, a chmura odblokowuje tę możliwość. Połączenie natywnych i zewnętrznych usług i rozwiązań bezpieczeństwa z automatyzacją ułatwia szybkie rozwiązywanie incydentów związanych z bezpieczeństwem. Zastosowanie SOAR oznacza, że analitycy faktycznie analizują tylko te incydenty, które wymagają interwencji człowieka. Po przeprowadzeniu dochodzenia, jeśli można wprowadzić automatyzację tego alertu, jest ona szybko stosowana. Posiadanie centralnego miejsca do automatyzacji alertów pomaga organizacji w spójnym i ustrukturyzowanym podejściu do reagowania na zdarzenia związane z bezpieczeństwem i daje analitykom więcej czasu na skupienie się na działaniach takich jak „polowanie” na potencjalne zagrożenia.

Ponadto takie operacje polowania na zagrożenia wymagają centralnego jeziora danych bezpieczeństwa lub podobnej technologii. W rezultacie zespół SecOps pomaga w centralizacji danych w całej firmie, co jest tradycyjną funkcją cyberbezpieczeństwa.

Scentralizowany SOC w chmurze: względy organizacyjne

Niektóre wskaźniki KPI, z których zwykle korzystałby tradycyjny SOC, to czas do wykrycia (TTD), czas do potwierdzenia (TTA) i czas do rozwiązania (TTR). Były to dobre wskaźniki, które menedżerowie SecOps mogą wykorzystać do zrozumienia i porównania skuteczności zespołu SecOps, zarówno wewnętrznie, jak i w porównaniu z branżowymi wzorcami porównawczymi. W jaki sposób Twoja organizacja zaczyna korzystać z szerokiego zakresu dostępnego w chmurze, jak zmienia się to w kluczowych wskaźnikach wydajności, które musisz śledzić? Jak wspomniano wcześniej, chmura ułatwia śledzenie wskaźników KPI dzięki zwiększonej widoczności śladu chmury – chociaż należy ocenić tradycyjne wskaźniki KPI, aby zrozumieć, czy nadal ma sens ich stosowanie. Niektóre dodatkowe wskaźniki KPI, które należy wziąć pod uwagę, to wskaźniki pokazujące rosnącą automatyzację, ograniczenie dostępu ludzi i ogólną poprawę stanu bezpieczeństwa.

Organizacje powinny rozważyć czynniki skalowania dla procesów operacyjnych i możliwości w scentralizowanym modelu SOC. Gdy korzyści z zastosowania chmury zostaną zrealizowane, organizacje zazwyczaj agresywnie rozszerzają i skalują swój ślad w chmurze. Dla scentralizowanego zespołu SecOps może to spowodować wymagającą batalię między szerszym biznesem, który chce się rozwijać, a SOC, który potrzebuje zdolności do pełnego zrozumienia problemów w środowisku i reagowania na nie. Na przykład większość organizacji opracuje mały dowód zasady (POC), aby zaprezentować nowe architektury i ich zalety, a te POC mogą stać się dostępne jako plany do wykorzystania przez szerszą organizację. Po wdrożeniu nowych planów scentralizowany zespół SecOps powinien wdrożyć i polegać na swoich możliwościach automatyzacji, aby zweryfikować, czy istnieją prawidłowe procesy ostrzegania, monitorowania i operacyjne.

Decentralizacja: cała własność z zespołami aplikacji

Przenoszenie lub projektowanie obciążeń w chmurze zapewnia organizacjom wiele korzyści, takich jak zwiększona szybkość i elastyczność, wbudowane zabezpieczenia natywne oraz możliwość globalnego uruchomienia w ciągu kilku minut. Przyglądając się zdecentralizowanemu modelowi, jednostki biznesowe powinny włączyć praktyki do swoich potoków programistycznych, aby skorzystać z możliwości bezpieczeństwa chmury. Nazywa się to czasem podejściem przesunięcia w lewo lub podejściem DevSecOps – polegającym zasadniczo na wbudowaniu najlepszych praktyk w zakresie bezpieczeństwa w każdą część procesu programowania i tak wcześnie, jak to możliwe.

Umieszczenie własności funkcji SecOps na jednostkach biznesowych i właścicielach aplikacji może przynieść pewne korzyści. Jedną z natychmiastowych korzyści jest to, że zespoły tworzące aplikacje i architektury mają wiedzę z pierwszej ręki i kontekstową świadomość swoich produktów. Ta wiedza ma kluczowe znaczenie w przypadku wystąpienia zdarzeń związanych z bezpieczeństwem, ponieważ zrozumienie oczekiwanego zachowania i przepływu informacji obciążeń pomaga w szybkim korygowaniu i rozwiązywaniu problemów. Praca zespołów nad incydentami związanymi z bezpieczeństwem w sposób najlepiej dopasowany do ich procesów operacyjnych może również przyspieszyć działania naprawcze.

Decentralizacja: względy organizacyjne

Rozważając podejście zdecentralizowane, należy wziąć pod uwagę kilka kwestii organizacyjnych:

Dedykowani analitycy bezpieczeństwa w ramach centralnej funkcji SecOps codziennie zajmują się incydentami związanymi z bezpieczeństwem; studiują branżę, uważnie przyglądają się nadchodzącym zagrożeniom, a także są dobrze zorientowani w sytuacjach wysokiego napięcia. Decentralizacja może spowodować utratę spójnego, zrównoważonego środowiska, które oferują podczas incydentu związanego z bezpieczeństwem. Osadzenie mistrzów bezpieczeństwa, którzy mają doświadczenie w branży, w każdej jednostce biznesowej może pomóc zapewnić, że bezpieczeństwo jest uwzględniane przez cały cykl rozwoju i że incydenty są rozwiązywane tak szybko, jak to możliwe.

Informacje kontekstowe i analiza przyczyn źródłowych z przeszłych incydentów to kluczowe punkty danych. Posiadanie scentralizowanego zespołu SecOps znacznie ułatwia uzyskanie szerokiego wglądu w kwestie bezpieczeństwa dotyczące całej organizacji, co poprawia zdolność odbierania sygnału z jednej jednostki biznesowej i zastosowania go w innych częściach organizacji, aby zrozumieć, czy są one również wrażliwe i pomóc chronić organizację w przyszłości.

Całkowite zdecentralizowanie odpowiedzialności SecOps może spowodować utratę tych korzyści. Jak wspomniano wcześniej, skuteczna komunikacja i środowisko do udostępniania danych są kluczem do sprawdzenia, czy wyciągnięte wnioski są udostępniane między jednostkami biznesowymi – jednym ze sposobów na osiągnięcie tego efektywnego udostępniania wiedzy może być utworzenie Cloud Center of Excellence (CCoE). CCoE pomaga w udostępnianiu informacji na szeroką skalę, ale minimalizacja przekazywania zespołowego zapewniana przez scentralizowaną funkcję SecOps jest silnym mechanizmem organizacyjnym gwarantującym spójność.

Tradycyjnie w modelu scentralizowanym SOC zapewnia całodobowy dostęp do aplikacji i krytycznych funkcji biznesowych, co może wymagać dużej liczby pracowników ochrony. W zdecentralizowanym modelu nadal istnieje potrzeba działania 24 godziny na dobę, 7 dni w tygodniu, a konieczność zapewnienia takiej możliwości w każdym zespole aplikacji lub jednostce biznesowej może zwiększyć koszty, jednocześnie utrudniając udostępnianie informacji. W modelu zdecentralizowanym wyższy poziom automatyzacji procesów organizacyjnych może pomóc zmniejszyć liczbę ludzi potrzebnych do całodobowej obsługi.

Łączenie modeli: podejście hybrydowe

Większość organizacji ostatecznie w taki czy inny sposób stosuje hybrydowy model operacyjny. Model ten łączy w sobie zalety modelu scentralizowanego i zdecentralizowanego, z jasnym podziałem odpowiedzialności i własności pomiędzy jednostkami biznesowymi i centralną funkcją SecOps.

Ten najlepszy scenariusz z obu światów można podsumować stwierdzeniem „globalny monitoring, lokalna reakcja”. Oznacza to, że zespół SecOps i szerzej pojęta funkcja cyberbezpieczeństwa kieruje całą organizacją w zakresie najlepszych praktyk bezpieczeństwa i zabezpieczeń, jednocześnie zachowując przejrzystość w zakresie raportowania, zgodności i zrozumienia stanu bezpieczeństwa całej organizacji. Tymczasem lokalne jednostki biznesowe dysponują narzędziami, wiedzą i doświadczeniem, które pozwalają im samodzielnie korygować zdarzenia związane z bezpieczeństwem w ich aplikacjach.

W tym modelu hybrydowym dzielisz delegację własności na dwie części. Po pierwsze, zdolność operacyjna w zakresie bezpieczeństwa jest własnością centralną. Ta scentralizowana zdolność opiera się na partnerstwie między zespołami aplikacji a organizacją bezpieczeństwa za pośrednictwem CCoE. Daje to korzyści wynikające ze spójności, wiedzy o narzędziach i wniosków wyciągniętych z wcześniejszych incydentów związanych z bezpieczeństwem. Po drugie, rozwiązywanie codziennych zdarzeń związanych z bezpieczeństwem i ustalanie stanu bezpieczeństwa jest delegowane do jednostek biznesowych. Daje to osobom znajdującym się najbliżej problemu biznesowego możliwość samodzielnego doskonalenia usług w sposób, który najlepiej pasuje do sposobu pracy tego zespołu, czy to poprzez ChatOps i automatyzację, czy też za pomocą narzędzi dostępnych w chmurze. Przykładami typów zdarzeń, które można delegować do rozwiązania, są elementy takie jak stosowanie poprawek, problemy z konfiguracją i zdarzenia związane z bezpieczeństwem specyficzne dla obciążenia. Ważne jest, aby zapewnić tym zespołom dobrze zdefiniowaną ścieżkę eskalacji do centralnej organizacji ds. bezpieczeństwa w przypadku problemów wymagających specjalistycznej wiedzy z zakresu bezpieczeństwa, takich jak kryminalistyka lub inne dochodzenia.

RACI jest szczególnie ważny, gdy pracujesz w tym modelu hybrydowym. Upewnienie się, że istnieje jasny zestaw obowiązków między jednostkami biznesowymi a zespołem SecOps, ma kluczowe znaczenie dla uniknięcia nieporozumień w przypadku wystąpienia incydentów bezpieczeństwa.

Podsumowanie

Chmura daje możliwość odblokowania nowych możliwości dla Twojej organizacji. Większe bezpieczeństwo, szybkość i elastyczność to tylko niektóre z korzyści, jakie można uzyskać, przenosząc obciążenia do chmury. Tradycyjny scentralizowany model SecOps oferuje spójne podejście do wykrywania zagrożeń i reagowania na nie w Twojej organizacji. Decentralizacja reakcji zapewnia zespołom aplikacyjnym bezpośredni kontakt z konsekwencjami ich decyzji projektowych, co może przyspieszyć wprowadzanie ulepszeń. Model hybrydowy, w którym zespoły ds. aplikacji są odpowiedzialne za rozwiązywanie problemów, może skrócić czas rozwiązywania problemów, uwalniając SecOps do kontynuowania pracy. Hybrydowy model operacyjny uzupełnia możliwości chmury i umożliwia właścicielom aplikacji i jednostkom biznesowym pracę w sposób, który najlepiej im odpowiada, przy zachowaniu wysokiego poziomu bezpieczeństwa w całej organizacji.

Niezależnie od tego, który model operacyjny i strategię zdecydujesz się przyjąć, ważne jest, aby pamiętać o podstawowych zasadach, do których powinieneś dążyć:

• Umożliwiaj skuteczne zarządzanie ryzykiem w całej firmie;
• Zwiększaj świadomość bezpieczeństwa i osadzaj mistrzów bezpieczeństwa tam, gdzie to możliwe;
• Podczas skalowania utrzymuj widoczność zdarzeń związanych z bezpieczeństwem w całej organizacji;
• Pomóż właścicielom aplikacji i jednostkom biznesowym pracować w najlepszy dla nich sposób;
• Współpracuj z właścicielami aplikacji i jednostkami biznesowymi, aby zrozumieć cyberkrajobraz.

Chmura oferuje wiele korzyści dla Twojej firmy, a Twoja organizacja zajmująca się bezpieczeństwem pomaga zespołom bezpiecznie wysyłać i działać. To zaufanie doprowadzi do zrealizowanej produktywności i ciągłych innowacji – co jest dobre zarówno dla wewnętrznych zespołów, jak i Twoich klientów.

źródło: AWS