Monitorowanie bezpieczeństwa w chmurze

Przenoszenie danych i aplikacji do chmury stanowi nowe wyzwanie dla korporacyjnych SOC, które nie zawsze są gotowe do monitorowania infrastruktury innych osób. Według Netoskope przeciętne przedsiębiorstwo (podobno w USA) korzysta z 1246 różnych usług chmurowych, czyli o 22% więcej niż rok temu. 1246 usług w chmurze!!! 175 z nich dotyczy usług HR, 170 związanych jest z marketingiem, 110 z zakresu komunikacji, a 76 z finansów i CRM. Cisco korzysta „tylko” z 700 zewnętrznych usług chmurowych. Więc jestem trochę zdezorientowany tymi liczbami. Ale w każdym razie problem nie leży w nich, ale w tym, że chmura zaczyna być dość aktywnie wykorzystywana przez coraz większą liczbę firm, które chciałyby mieć takie same możliwości monitorowania infrastruktury chmurowej, jak we własnej sieci. I ta tendencja rośnie – wg według Amerykańskiej Izby Obrachunkowej Do 2023 roku w Stanach Zjednoczonych zostanie zamkniętych 1200 centrów danych (6250 zostało już zamkniętych). Ale przejście do chmury to nie tylko „przeniesienie naszych serwerów do zewnętrznego dostawcy”. Nowa architektura IT, nowe oprogramowanie, nowe procesy, nowe ograniczenia… Wszystko to niesie ze sobą istotne zmiany w pracy nie tylko IT, ale także bezpieczeństwa informacji. A jeśli dostawcy nauczyli się jakoś radzić sobie z zapewnieniem bezpieczeństwa samej chmury (na szczęście jest sporo rekomendacji), to z monitorowaniem bezpieczeństwa informacji w chmurze, szczególnie na platformach SaaS, pojawiają się spore trudności, o których będziemy mówić.

Załóżmy, że Twoja firma przeniosła część swojej infrastruktury do chmury... Stop. Nie w ten sposób. Jeśli infrastruktura została przeniesiona, a Ty dopiero teraz zastanawiasz się, jak będziesz ją monitorować, to już przegrałeś. O ile nie jest to Amazon, Google lub Microsoft (i wtedy z zastrzeżeniami), prawdopodobnie nie będziesz miał zbyt wielu możliwości monitorowania swoich danych i aplikacji. Dobrze, jeśli masz możliwość pracy z kłodami. Czasami dane o zdarzeniach związanych z bezpieczeństwem będą dostępne, ale nie będziesz mieć do nich dostępu. Np. Office 365. Jeżeli posiadasz najtańszą licencję E1 to zdarzenia bezpieczeństwa nie są dla Ciebie w ogóle dostępne. Jeśli posiadasz licencję E3, Twoje dane są przechowywane tylko przez 90 dni i tylko jeśli posiadasz licencję E5, czas trwania logów jest dostępny przez rok (jednak ma to również swoje niuanse związane z koniecznością osobnego zażądać szeregu funkcji do pracy z logami od pomocy technicznej Microsoft). Nawiasem mówiąc, licencja E3 jest znacznie słabsza pod względem funkcji monitorujących niż korporacyjna Exchange. Aby osiągnąć ten sam poziom, potrzebujesz licencji E5 lub dodatkowej licencji Advanced Compliance, co może wymagać dodatkowych pieniędzy, które nie zostały uwzględnione w Twoim modelu finansowym związanym z przejściem na infrastrukturę chmurową. A to tylko jeden z przykładów niedoceniania zagadnień związanych z monitorowaniem bezpieczeństwa informacji w chmurze. W tym artykule, nie udając kompletnego, chcę zwrócić uwagę na pewne niuanse, które należy wziąć pod uwagę przy wyborze dostawcy chmury z punktu widzenia bezpieczeństwa. A na końcu artykułu zostanie podana lista kontrolna, którą warto wypełnić, zanim uznamy, że kwestia monitorowania bezpieczeństwa informacji w chmurze została rozwiązana.

Istnieje kilka typowych problemów prowadzących do incydentów w środowiskach chmurowych, na które służby bezpieczeństwa informacji nie mają czasu zareagować lub w ogóle ich nie dostrzegają:

• Dzienniki zabezpieczeń nie istnieją. To dość powszechna sytuacja, zwłaszcza wśród początkujących graczy na rynku rozwiązań chmurowych. Nie należy jednak od razu z nich rezygnować. Mali gracze, szczególnie krajowi, są bardziej wrażliwi na wymagania klientów i mogą szybko wdrożyć niektóre wymagane funkcje, zmieniając zatwierdzony plan działania dla swoich produktów. Tak, to nie będzie odpowiednik GuardDuty od Amazona czy moduł „Proactive Protection” od Bitrix, ale przynajmniej coś.
• Bezpieczeństwo informacji nie wie, gdzie przechowywane są logi i nie ma do nich dostępu. Tutaj konieczne jest podjęcie negocjacji z dostawcą usług chmurowych – być może przekaże taką informację, jeśli uzna klienta za ważnego. Ale generalnie nie jest dobrze, gdy dostęp do kłód zapewniany jest „na podstawie specjalnej decyzji”.
• Zdarza się również, że dostawca chmury posiada logi, ale zapewniają one ograniczony monitoring i rejestrację zdarzeń, które nie są wystarczające do wykrycia wszystkich incydentów. Na przykład możesz otrzymywać tylko logi zmian na stronie internetowej lub logi prób uwierzytelnienia użytkowników, ale nie inne zdarzenia, takie jak ruch sieciowy, co ukryje przed tobą całą warstwę zdarzeń charakteryzujących próby włamania się do twojej infrastruktury chmurowej.
• Logi istnieją, ale dostęp do nich jest trudny do zautomatyzowania, co wymusza ich monitorowanie nie w sposób ciągły, ale według harmonogramu. A jeśli nie możesz automatycznie pobrać logów, to pobranie logów na przykład w formacie Excel (jak w przypadku wielu krajowych dostawców rozwiązań chmurowych) może nawet doprowadzić do niechęci ze strony służb bezpieczeństwa informacji korporacyjnych do majstrowania przy nich.
• Brak monitorowania logów. Jest to być może najbardziej niejasna przyczyna występowania incydentów związanych z bezpieczeństwem informacji w środowiskach chmurowych. Wydaje się, że istnieją logi i można zautomatyzować dostęp do nich, ale nikt tego nie robi. Dlaczego?

Wspólna koncepcja bezpieczeństwa w chmurze

Przejście na chmurę to zawsze poszukiwanie równowagi pomiędzy chęcią utrzymania kontroli nad infrastrukturą, a przekazaniem jej w bardziej profesjonalne ręce dostawcy chmury, który specjalizuje się w jej utrzymaniu. W dziedzinie bezpieczeństwa w chmurze należy szukać tej równowagi również. Co więcej, w zależności od zastosowanego modelu świadczenia usług chmurowych (IaaS, PaaS, SaaS) bilans ten będzie cały czas inny. W każdym razie musimy pamiętać, że wszyscy dostawcy usług chmurowych kierują się dziś tzw. modelem wspólnej odpowiedzialności i wspólnego bezpieczeństwa informacji. Za pewne rzeczy odpowiada chmura, za inne odpowiada klient, umieszczając w chmurze swoje dane, swoje aplikacje, swoje maszyny wirtualne i inne zasoby. Nierozsądnością byłoby oczekiwać, że przechodząc na chmurę przerzucimy całą odpowiedzialność na dostawcę. Ale nierozsądne jest również samodzielne budowanie całego bezpieczeństwa podczas przenoszenia się do chmury. Wymagana jest równowaga, która będzie zależała od wielu czynników: – strategii zarządzania ryzykiem, modelu zagrożenia, mechanizmów bezpieczeństwa dostępnych dla dostawcy chmury, ustawodawstwa itp.

Na przykład za klasyfikację danych przechowywanych w chmurze zawsze odpowiada klient. Dostawca chmury lub zewnętrzny usługodawca może mu pomóc jedynie narzędziami, które pomogą oznaczyć dane w chmurze, zidentyfikować naruszenia, usunąć dane naruszające prawo lub zamaskować je w taki czy inny sposób. Z drugiej strony za bezpieczeństwo fizyczne zawsze odpowiada dostawca chmury, którym nie może on dzielić się z klientami. Ale wszystko, co znajduje się pomiędzy danymi a infrastrukturą fizyczną, jest właśnie przedmiotem dyskusji w tym artykule. Na przykład za dostępność chmury odpowiada dostawca, a za skonfigurowanie reguł zapory sieciowej lub włączenie szyfrowania odpowiada klient. W tym artykule postaramy się przyjrzeć, jakie mechanizmy monitorowania bezpieczeństwa informacji udostępniają dziś różni popularni dostawcy usług chmurowych w Rosji, jakie są cechy ich wykorzystania i kiedy warto zainteresować się zewnętrznymi rozwiązaniami nakładkowymi (np. Cisco E- mail Security), które poszerzają możliwości Twojej chmury pod kątem cyberbezpieczeństwa. W niektórych przypadkach, zwłaszcza jeśli realizujesz strategię wielu chmur, nie będziesz miał innego wyjścia, jak skorzystać z zewnętrznych rozwiązań do monitorowania bezpieczeństwa informacji w kilku środowiskach chmurowych jednocześnie (na przykład Cisco CloudLock lub Cisco Stealthwatch Cloud). Cóż, w niektórych przypadkach zdasz sobie sprawę, że wybrany (lub narzucony Ci dostawca chmury) w ogóle nie oferuje żadnych możliwości monitorowania bezpieczeństwa informacji. Jest to nieprzyjemne, ale też niemałe, gdyż pozwala odpowiednio ocenić poziom ryzyka związanego z pracą z tą chmurą.

Cykl życia monitorowania bezpieczeństwa w chmurze

Aby monitorować bezpieczeństwo chmur, z których korzystasz, masz tylko trzy możliwości:

• polegaj na narzędziach dostarczonych przez Twojego dostawcę chmury,
• korzystać z rozwiązań firm trzecich, które będą monitorować wykorzystywane przez Ciebie platformy IaaS, PaaS lub SaaS,
• zbuduj własną infrastrukturę monitorowania w chmurze (tylko dla platform IaaS/PaaS).

Zobaczmy, jakie funkcje ma każda z tych opcji. Najpierw jednak musimy zrozumieć ogólne ramy, które będą stosowane podczas monitorowania platform chmurowych. Wyróżniłbym 6 głównych elementów procesu monitorowania bezpieczeństwa informacji w chmurze:

• Przygotowanie infrastruktury. Określenie niezbędnych aplikacji i infrastruktury do gromadzenia zdarzeń ważnych dla bezpieczeństwa informacji w magazynie.
• Kolekcja. Na tym etapie zdarzenia bezpieczeństwa są agregowane z różnych źródeł w celu późniejszej transmisji w celu przetwarzania, przechowywania i analizy.
• Leczenie. Na tym etapie dane są przekształcane i wzbogacane w celu ułatwienia późniejszej analizy.
• Składowanie. Komponent ten odpowiada za krótkoterminowe i długoterminowe przechowywanie zebranych przetworzonych i surowych danych.
• Analiza. Na tym etapie masz możliwość wykrywania incydentów i reagowania na nie automatycznie lub ręcznie.
• Raportowanie. Ten etap pozwala na sformułowanie kluczowych wskaźników dla interesariuszy (zarządu, audytorów, dostawcy chmury, klientów itp.), które pomagają nam podjąć określone decyzje, np. o zmianie dostawcy czy wzmocnieniu bezpieczeństwa informacji.

Zrozumienie tych elementów pozwoli Ci w przyszłości szybko zdecydować, co możesz wziąć od swojego dostawcy, a co będziesz musiał zrobić sam lub przy zaangażowaniu zewnętrznych konsultantów.

Wbudowane usługi w chmurze

Pisałem już powyżej, że wiele usług chmurowych nie zapewnia obecnie żadnych możliwości monitorowania bezpieczeństwa informacji. Generalnie nie przywiązują dużej wagi do tematu bezpieczeństwa informacji. Na przykład jedna z popularnych rosyjskich usług przesyłania raportów do agencji rządowych przez Internet (nie będę konkretnie wymieniać jej nazwy). Cała część poświęcona bezpieczeństwu tej usługi skupia się wokół wykorzystania certyfikowanego CIPF. Sekcja bezpieczeństwa informacji innej krajowej usługi chmurowej do elektronicznego zarządzania dokumentami nie jest inna. Mówi o certyfikatach klucza publicznego, certyfikowanej kryptografii, eliminacji podatności sieciowych, ochronie przed atakami DDoS, stosowaniu zapór sieciowych, kopiach zapasowych, a nawet regularnych audytach bezpieczeństwa informacji. Nie ma jednak ani słowa o monitorowaniu, ani o możliwości uzyskania dostępu do zdarzeń związanych z bezpieczeństwem informacji, które mogą zainteresować klientów tego usługodawcy.

Ogólnie rzecz biorąc, sposób, w jaki dostawca chmury opisuje kwestie bezpieczeństwa informacji na swojej stronie internetowej i w swojej dokumentacji, pozwala zrozumieć, jak poważnie podchodzi do tej kwestii. Na przykład, jeśli czytasz instrukcje dotyczące produktów „Moje Biuro”, nie ma tam w ogóle ani słowa o bezpieczeństwie, ale w dokumentacji osobnego produktu „Moje Biuro”. KS3”, mający na celu ochronę przed nieuprawnionym dostępem, zwykle znajduje się lista punktów 17. rzędu FSTEC, które wdraża „Moje biuro.KS3”, ale nie opisano, w jaki sposób to realizuje i, co najważniejsze, jak to zrobić zintegrować te mechanizmy z bezpieczeństwem informacji korporacyjnych. Być może taka dokumentacja istnieje, ale nie znalazłem jej w domenie publicznej, na stronie „Moje Biuro”. Chociaż może po prostu nie mam dostępu do tych tajnych informacji?..

W przypadku Bitrixa sytuacja jest znacznie lepsza. Dokumentacja opisuje formaty dzienników zdarzeń oraz, co ciekawe, dziennika włamań, który zawiera zdarzenia związane z potencjalnymi zagrożeniami dla platformy chmurowej. Stamtąd możesz wyciągnąć adres IP, nazwę użytkownika lub gościa, źródło zdarzenia, godzinę, agenta użytkownika, typ zdarzenia itp. To prawda, że ​​​​możesz pracować z tymi zdarzeniami albo z panelu sterowania samej chmury, albo przesyłać dane w formacie MS Excel. Obecnie trudno jest zautomatyzować pracę z logami Bitrix i część pracy będziesz musiał wykonać ręcznie (przesłanie raportu i załadowanie go do SIEM). Ale jeśli przypomnimy sobie, że jeszcze stosunkowo niedawno nie było takiej możliwości, to jest to ogromny postęp. Jednocześnie zaznaczę, że wielu zagranicznych dostawców usług chmurowych oferuje podobną funkcjonalność „dla początkujących” – albo spójrz oczami na logi przez panel sterowania, albo wgraj dane do siebie (jednak większość przesyła dane w formacie . csv, a nie Excel).

Nie biorąc pod uwagę opcji braku logów, dostawcy usług w chmurze zazwyczaj oferują trzy opcje monitorowania zdarzeń związanych z bezpieczeństwem – pulpity nawigacyjne, przesyłanie danych i dostęp do API. To pierwsze wydaje się rozwiązywać wiele problemów, ale nie jest to do końca prawdą – jeśli masz kilka magazynów, musisz przełączać się między wyświetlającymi je ekranami, tracąc ogólny obraz. Ponadto dostawca chmury raczej nie zapewni Ci możliwości korelacji zdarzeń związanych z bezpieczeństwem i ogólnej analizy ich pod kątem bezpieczeństwa (zwykle masz do czynienia z surowymi danymi, które musisz sam zrozumieć). Są wyjątki i porozmawiamy o nich dalej. Na koniec warto zadać sobie pytanie, jakie zdarzenia rejestruje Twój dostawca chmury, w jakim formacie i jak mają się one do Twojego procesu monitorowania bezpieczeństwa informacji? Na przykład identyfikacja i uwierzytelnianie użytkowników i gości. Ten sam Bitrix pozwala na podstawie tych zdarzeń zarejestrować datę i godzinę zdarzenia, nazwę użytkownika lub gościa (jeśli posiadasz moduł „Web Analytics”), obiekt, do którego uzyskano dostęp i inne elementy typowe dla strony internetowej . Jednak usługi bezpieczeństwa informacji korporacyjnych mogą potrzebować informacji o tym, czy użytkownik uzyskał dostęp do chmury z zaufanego urządzenia (na przykład w sieci firmowej zadanie to realizuje Cisco ISE). A co powiecie na tak proste zadanie jak funkcja geo-IP, która pomoże ustalić, czy konto użytkownika usługi chmurowej zostało skradzione? I nawet jeśli dostawca chmury Ci to zapewni, to nie wystarczy. Ten sam Cisco CloudLock nie tylko analizuje geolokalizację, ale wykorzystuje do tego uczenie maszynowe i analizuje dane historyczne dla każdego użytkownika oraz monitoruje różne anomalie w próbach identyfikacji i uwierzytelnienia. Tylko MS Azure ma podobną funkcjonalność (jeśli posiadasz odpowiednią subskrypcję).

Jest jeszcze jedna trudność – ponieważ dla wielu dostawców usług chmurowych monitorowanie bezpieczeństwa informacji to nowy temat, z którym dopiero zaczynają się mierzyć, ciągle coś zmieniają w swoich rozwiązaniach. Dziś mają jedną wersję API, jutro inną, pojutrze trzecią. Na to też trzeba się przygotować. Podobnie jest z funkcjonalnością, która może ulec zmianie, co należy uwzględnić w swoim systemie monitorowania bezpieczeństwa informacji. Na przykład Amazon początkowo miał osobne usługi monitorowania zdarzeń w chmurze – AWS CloudTrail i AWS CloudWatch. Następnie pojawiła się osobna usługa monitorowania zdarzeń związanych z bezpieczeństwem informacji – AWS GuardDuty. Po pewnym czasie Amazon uruchomił nowy system zarządzania Amazon Security Hub, który obejmuje analizę danych otrzymanych od GuardDuty, Amazon Inspector, Amazon Macie i kilku innych. Innym przykładem jest narzędzie do integracji dzienników Azure z SIEM – AzLog. Było aktywnie wykorzystywane przez wielu dostawców SIEM, aż w 2018 roku Microsoft ogłosił zaprzestanie jego rozwoju i wsparcia, co postawiło wielu klientów korzystających z tego narzędzia z problemem (o tym, jak go rozwiązano, porozmawiamy później).

Dlatego uważnie monitoruj wszystkie funkcje monitorowania oferowane przez Twojego dostawcę usług w chmurze. Możesz też polegać na zewnętrznych dostawcach rozwiązań, którzy będą pośrednikami pomiędzy Twoim SOC a chmurą, którą chcesz monitorować. Tak, będzie drożej (choć nie zawsze), ale całą odpowiedzialność przerzucisz na ramiona kogoś innego. A może nie wszystko?.. Przypomnijmy sobie koncepcję wspólnego bezpieczeństwa i zrozummy, że niczego nie możemy przesunąć – będziemy musieli niezależnie zrozumieć, w jaki sposób różni dostawcy chmury zapewniają monitorowanie bezpieczeństwa informacyjnego Twoich danych, aplikacji, maszyn wirtualnych i innych zasobów hostowane w chmurze. I zaczniemy od tego, co Amazon oferuje w tej części.

Przykład: Monitoring bezpieczeństwa informacji w IaaS w oparciu o AWS

Tak, tak, rozumiem, że Amazon nie jest najlepszym przykładem ze względu na to, że jest to serwis amerykański i można go zablokować w ramach walki z ekstremizmem i rozpowszechnianiem informacji zabronionych w Rosji. Ale w tej publikacji chciałbym tylko pokazać, jak różne platformy chmurowe różnią się możliwościami monitorowania bezpieczeństwa informacji i na co należy zwrócić uwagę przenosząc swoje kluczowe procesy do chmur z punktu widzenia bezpieczeństwa. Cóż, jeśli niektórzy z rosyjskich twórców rozwiązań chmurowych nauczą się czegoś przydatnego dla siebie, to będzie świetnie.

Pierwszą rzeczą, którą należy powiedzieć, jest to, że Amazon nie jest fortecą nie do zdobycia. Jego klientom regularnie zdarzają się różne zdarzenia. Na przykład z Deep Root Analytics skradziono nazwiska, adresy, daty urodzenia i numery telefonów 198 milionów wyborców. Izraelska firma Nice Systems ukradła 14 milionów rekordów abonentów Verizon. Jednak wbudowane możliwości AWS pozwalają wykryć szeroką gamę incydentów. Na przykład:

• wpływ na infrastrukturę (DDoS)
• kompromis węzła (wstrzyknięcie polecenia)
• naruszenie konta i nieautoryzowany dostęp
• nieprawidłowa konfiguracja i luki w zabezpieczeniach
• niezabezpieczone interfejsy i API.

Rozbieżność ta wynika z faktu, że jak ustaliliśmy powyżej, za bezpieczeństwo danych Klienta odpowiada sam Klient. A jeśli nie zadał sobie trudu włączenia mechanizmów ochronnych i nie włączył narzędzi monitorujących, to o zdarzeniu dowie się dopiero z mediów lub od swoich klientów.

Do identyfikacji incydentów można wykorzystać szeroką gamę różnych usług monitorujących opracowanych przez firmę Amazon (choć często są one uzupełniane narzędziami zewnętrznymi, takimi jak osquery). Zatem w AWS wszystkie działania użytkownika są monitorowane, niezależnie od tego, w jaki sposób są przeprowadzane - poprzez konsolę zarządzającą, linię poleceń, SDK lub inne usługi AWS. Wszystkie zapisy aktywności każdego konta AWS (w tym nazwa użytkownika, akcja, usługa, parametry aktywności i wynik) oraz wykorzystanie interfejsu API są dostępne za pośrednictwem AWS CloudTrail. Możesz przeglądać te zdarzenia (takie jak logowania do konsoli AWS IAM) z konsoli CloudTrail, analizować je za pomocą Amazon Athena lub „zlecać” je zewnętrznym rozwiązaniom, takim jak Splunk, AlienVault itp. Same dzienniki AWS CloudTrail są umieszczane w Twoim zasobniku AWS S3.

Dwie inne usługi AWS zapewniają szereg innych ważnych możliwości monitorowania. Po pierwsze, Amazon CloudWatch to usługa monitorowania zasobów i aplikacji AWS, która między innymi pozwala identyfikować różne anomalie w Twojej chmurze. Wszystkie wbudowane usługi AWS, takie jak Amazon Elastic Compute Cloud (serwery), Amazon Relational Database Service (bazy danych), Amazon Elastic MapReduce (analiza danych) i 30 innych usług Amazon, korzystają z Amazon CloudWatch do przechowywania swoich dzienników. Programiści mogą korzystać z otwartego interfejsu API Amazon CloudWatch, aby dodawać funkcję monitorowania logów do niestandardowych aplikacji i usług, co pozwala im rozszerzyć zakres analizy zdarzeń w kontekście bezpieczeństwa.

Po drugie, usługa VPC Flow Logs umożliwia analizę ruchu sieciowego wysyłanego lub odbieranego przez Twoje serwery AWS (zewnętrznie lub wewnętrznie), a także pomiędzy mikroserwisami. Kiedy jakiekolwiek zasoby AWS VPC wchodzą w interakcję z siecią, dzienniki przepływu VPC rejestrują szczegółowe informacje o ruchu sieciowym, w tym źródłowy i docelowy interfejs sieciowy, a także adresy IP, porty, protokół, liczbę bajtów i liczbę pakietów, które piła. Osoby doświadczone w bezpieczeństwie sieci lokalnej rozpoznają to jako analogiczne do wątków Przepływy netto, które mogą być tworzone przez przełączniki, routery i zapory klasy korporacyjnej. Logi te są ważne dla celów monitorowania bezpieczeństwa informacji, ponieważ w odróżnieniu od zdarzeń dotyczących działań użytkowników i aplikacji, pozwalają również nie przeoczyć interakcji sieciowych w środowisku wirtualnej chmury prywatnej AWS.

Podsumowując, te trzy usługi AWS – AWS CloudTrail, Amazon CloudWatch i VPC Flow Logs – razem zapewniają dość dokładny wgląd w wykorzystanie konta, zachowania użytkowników, zarządzanie infrastrukturą, aktywność aplikacji i usług oraz aktywność sieciową. Można je wykorzystać na przykład do wykrycia następujących anomalii:

• Próby przeskanowania witryny, wyszukiwania backdoorów, wyszukiwania luk w zabezpieczeniach poprzez serie „błędów 404”.
• Ataki polegające na wstrzykiwaniu (na przykład wstrzykiwaniu SQL) poprzez serie „500 błędów”.
• Znane narzędzia ataku to sqlmap, nikto, w3af, nmap itp. poprzez analizę pola User Agent.

Amazon Web Services opracowało także inne usługi służące celom cyberbezpieczeństwa, które pozwalają rozwiązać wiele innych problemów. Na przykład AWS ma wbudowaną usługę audytu polityk i konfiguracji - AWS Config. Ta usługa zapewnia ciągły audyt zasobów AWS i ich konfiguracji. Weźmy prosty przykład: załóżmy, że chcesz się upewnić, że hasła użytkowników są wyłączone na wszystkich serwerach i że dostęp jest możliwy tylko w oparciu o certyfikaty. AWS Config ułatwia sprawdzenie tego w przypadku wszystkich serwerów. Istnieją inne zasady, które można zastosować do serwerów w chmurze: „Żaden serwer nie może używać portu 22”, „Tylko administratorzy mogą zmieniać reguły zapory ogniowej” lub „Tylko użytkownik Ivashko może tworzyć nowe konta użytkowników i może to robić. Dzieje się to tylko we wtorki. " Latem 2016 roku rozszerzono usługę AWS Config o automatyzację wykrywania naruszeń opracowanych polityk. Reguły konfiguracyjne AWS to zasadniczo ciągłe żądania konfiguracji usług Amazon, z których korzystasz, które generują zdarzenia w przypadku naruszenia odpowiednich zasad. Na przykład zamiast okresowo uruchamiać zapytania konfiguracji AWS w celu sprawdzenia, czy wszystkie dyski na serwerze wirtualnym są zaszyfrowane, można zastosować reguły konfiguracji AWS do ciągłego sprawdzania dysków serwera, aby upewnić się, że ten warunek jest spełniony. I co najważniejsze, w kontekście tej publikacji wszelkie naruszenia generują zdarzenia, które mogą być analizowane przez służbę bezpieczeństwa informacji.

AWS ma także swój odpowiednik tradycyjnych rozwiązań bezpieczeństwa informacji korporacyjnych, które również generują zdarzenia bezpieczeństwa, które można i należy analizować:

• Wykrywanie włamań - AWS GuardDuty
• Kontrola wycieków informacji - AWS Macie
• EDR (choć trochę dziwnie mówi o punktach końcowych w chmurze) - AWS Cloudwatch + rozwiązania osquery open source lub GRR
• Analiza Netflow - AWS Cloudwatch + AWS VPC Flow
• Analiza DNS - AWS Cloudwatch + AWS Route53
• AD - Usługa katalogowa AWS
• Zarządzanie kontem — AWS IAM
• Logowanie jednokrotne — logowanie jednokrotne AWS
• analiza bezpieczeństwa - Inspektor AWS
• zarządzanie konfiguracją - AWS Config
• WAF – AWS WAF.

Nie będę szczegółowo opisywał wszystkich usług Amazona, które mogą okazać się przydatne w kontekście bezpieczeństwa informacji. Najważniejsze jest, aby zrozumieć, że wszystkie mogą generować zdarzenia, które możemy i powinniśmy analizować w kontekście bezpieczeństwa informacji, wykorzystując w tym celu zarówno wbudowane możliwości samego Amazona, jak i rozwiązania zewnętrzne, np. SIEM, które mogą przenoś zdarzenia związane z bezpieczeństwem do swojego centrum monitorowania i tam je analizuj wraz ze zdarzeniami z innych usług w chmurze lub z infrastruktury wewnętrznej, obwodowej lub urządzeń mobilnych.

W każdym razie wszystko zaczyna się od źródeł danych, które dostarczają informacji o zdarzeniach związanych z bezpieczeństwem informacji. Źródła te obejmują między innymi:

• CloudTrail — wykorzystanie interfejsu API i działania użytkownika
• Zaufany Doradca – kontrola bezpieczeństwa pod kątem najlepszych praktyk
• Config - inwentaryzacja i konfiguracja kont oraz ustawień usług
• Logi przepływu VPC - połączenia z interfejsami wirtualnymi
• IAM - usługa identyfikacji i uwierzytelniania
• Dzienniki dostępu ELB — moduł równoważenia obciążenia
• Inspektor - podatności aplikacji
• S3 - przechowywanie plików
• CloudWatch — aktywność aplikacji
• SNS to usługa powiadamiania.

Amazon oferując tak szeroki wachlarz źródeł zdarzeń i narzędzi do ich generowania, ma bardzo ograniczone możliwości analizy zebranych danych w kontekście bezpieczeństwa informacji. Będziesz musiał niezależnie przestudiować dostępne dzienniki, szukając w nich odpowiednich wskaźników kompromisu. AWS Security Hub, który niedawno uruchomił Amazon, ma na celu rozwiązanie tego problemu, stając się chmurowym SIEM dla AWS. Ale jak dotąd jest dopiero na początku swojej podróży i jest ograniczony zarówno liczbą źródeł, z którymi współpracuje, jak i innymi ograniczeniami narzuconymi przez architekturę i subskrypcje samego Amazona.

Przykład: Monitorowanie bezpieczeństwa informacji w IaaS w oparciu o Azure

Nie chcę wdawać się w długą dyskusję na temat tego, który z trzech dostawców usług w chmurze (Amazon, Microsoft czy Google) jest lepszy (zwłaszcza, że ​​każdy z nich nadal ma swoją specyfikę i nadaje się do rozwiązywania własnych problemów); Skupmy się na możliwościach monitorowania bezpieczeństwa informacji, jakie zapewniają te odtwarzacze. Trzeba przyznać, że Amazon AWS był jednym z pierwszych w tym segmencie i dlatego posunął się najdalej w zakresie swoich funkcji bezpieczeństwa informacji (choć wielu przyznaje, że są one trudne w obsłudze). Nie oznacza to jednak, że zignorujemy możliwości, jakie dają nam Microsoft i Google.

Produkty Microsoftu zawsze wyróżniały się „otwartością” i na Azure sytuacja wygląda podobnie. Na przykład, jeśli AWS i GCP zawsze wychodzą z koncepcji „co nie jest dozwolone, jest zabronione”, wówczas Azure ma dokładnie odwrotne podejście. Przykładowo podczas tworzenia sieci wirtualnej w chmurze i maszyny wirtualnej w niej wszystkie porty i protokoły są domyślnie otwarte i dozwolone. Dlatego będziesz musiał poświęcić nieco więcej wysiłku na wstępną konfigurację systemu kontroli dostępu w chmurze firmy Microsoft. A to również nakłada na Ciebie bardziej rygorystyczne wymagania w zakresie monitorowania aktywności w chmurze Azure.

AWS ma osobliwość związaną z tym, że monitorując swoje zasoby wirtualne, jeśli są one zlokalizowane w różnych regionach, wówczas masz trudności z połączeniem wszystkich zdarzeń i ich ujednoliconą analizą, aby wyeliminować te, które musisz uciekać się do różnych sztuczek, takich jak Stwórz własny kod dla AWS Lambda, który będzie transportował zdarzenia pomiędzy regionami. Na platformie Azure nie ma tego problemu — mechanizm dziennika aktywności śledzi całą aktywność w całej organizacji bez ograniczeń. To samo dotyczy AWS Security Hub, który został niedawno opracowany przez Amazon w celu skonsolidowania wielu funkcji bezpieczeństwa w ramach jednego centrum bezpieczeństwa, ale tylko w obrębie jego regionu, co jednak nie ma znaczenia dla Rosji. Azure posiada własne Centrum Bezpieczeństwa, które nie jest ograniczone regionalnymi ograniczeniami, zapewniając dostęp do wszystkich funkcji bezpieczeństwa platformy chmurowej. Co więcej, dla różnych lokalnych zespołów może zapewnić własny zestaw możliwości ochronnych, w tym zarządzanych przez nie zdarzeń związanych z bezpieczeństwem. AWS Security Hub wciąż jest na dobrej drodze do upodobnienia się do Azure Security Center. Ale warto dorzucić jeszcze szczyptę maści – z Azure można wycisnąć sporo z tego, co zostało wcześniej opisane w AWS, ale najwygodniej jest to zrobić tylko w przypadku Azure AD, Azure Monitor i Azure Security Center. Wszystkie pozostałe mechanizmy zabezpieczeń platformy Azure, w tym analiza zdarzeń związanych z bezpieczeństwem, nie są jeszcze zarządzane w najwygodniejszy sposób. Problem częściowo rozwiązuje API, które przenika wszystkie usługi Microsoft Azure, jednak będzie to wymagało od Ciebie dodatkowego wysiłku w zakresie integracji Twojej chmury z Twoim SOC i obecności wykwalifikowanych specjalistów (właściwie jak w przypadku każdego innego SIEM-a współpracującego z chmurą Pszczoła). Niektóre SIEMy, o czym będzie mowa później, obsługują już Azure i potrafią zautomatyzować zadanie jego monitorowania, ale ma to też swoje własne trudności – nie wszystkie są w stanie zebrać wszystkie logi, jakie posiada Azure.

Zbieranie i monitorowanie zdarzeń w Azure realizowane jest za pomocą usługi Azure Monitor, która jest głównym narzędziem gromadzenia, przechowywania i analizowania danych w chmurze Microsoft oraz jej zasobach – repozytoriach Git, kontenerach, maszynach wirtualnych, aplikacjach itp. Wszystkie dane zbierane przez Azure Monitor podzielone są na dwie kategorie – metryki, zbierane w czasie rzeczywistym i opisujące kluczowe wskaźniki wydajności chmury Azure oraz logi, zawierające dane zorganizowane w rekordy charakteryzujące określone aspekty aktywności zasobów i usług Azure. Ponadto za pomocą interfejsu API modułu zbierającego dane usługa Azure Monitor może zbierać dane z dowolnego źródła REST w celu tworzenia własnych scenariuszy monitorowania.

Oto kilka źródeł zdarzeń zabezpieczeń oferowanych przez platformę Azure i do których można uzyskać dostęp za pośrednictwem Azure Portal, interfejsu wiersza polecenia, programu PowerShell lub interfejsu API REST (a niektóre tylko za pośrednictwem interfejsu API Azure Monitor/Insight):

• Dzienniki aktywności — ten dziennik odpowiada na klasyczne pytania „kto”, „co” i „kiedy” dotyczące dowolnej operacji zapisu (PUT, POST, DELETE) na zasobach w chmurze. Zdarzenia związane z dostępem do odczytu (GET) nie są uwzględniane w tym dzienniku, podobnie jak wiele innych.
• Dzienniki diagnostyczne - zawierają dane dotyczące operacji na konkretnym zasobie objętym Twoją subskrypcją.
• Raportowanie usługi Azure AD — zawiera zarówno aktywność użytkownika, jak i aktywność systemu związaną z zarządzaniem grupami i użytkownikami.
• Dziennik zdarzeń systemu Windows i Linux Syslog - zawiera zdarzenia z maszyn wirtualnych hostowanych w chmurze.
• Metryki — zawiera dane telemetryczne dotyczące wydajności i stanu usług i zasobów w chmurze. Mierzone co minutę i zapisywane. w ciągu 30 dni.
• Dzienniki przepływu grupy zabezpieczeń sieci - zawierają dane o zdarzeniach związanych z bezpieczeństwem sieci, zebrane przy wykorzystaniu usługi Network Watcher oraz monitorowania zasobów na poziomie sieci.
• Logi Magazynowe - zawiera zdarzenia związane z dostępem do magazynów.

Do monitorowania można używać zewnętrznych SIEM lub wbudowanego Azure Monitor i jego rozszerzeń. O systemach zarządzania zdarzeniami związanymi z bezpieczeństwem informacji porozmawiamy później, ale na razie zobaczmy, co sam Azure oferuje nam do analizy danych w kontekście bezpieczeństwa. Głównym ekranem zawierającym wszystkie informacje związane z zabezpieczeniami w Azure Monitor jest pulpit nawigacyjny zabezpieczeń i inspekcji log Analytics (wersja bezpłatna obsługuje ograniczoną ilość magazynu zdarzeń tylko przez jeden tydzień). Ten pulpit nawigacyjny jest podzielony na 5 głównych obszarów, które wizualizują podsumowujące statystyki tego, co dzieje się w środowisku chmury, z którego korzystasz:

• Domeny bezpieczeństwa – kluczowe wskaźniki ilościowe związane z bezpieczeństwem informacji – liczba incydentów, liczba węzłów zhakowanych, węzłów niezałatanych, zdarzeń związanych z bezpieczeństwem sieci itp.
• Godne uwagi problemy — wyświetla liczbę i wagę aktywnych problemów związanych z bezpieczeństwem informacji
• Wykrycia — wyświetla wzorce ataków zastosowanych przeciwko Tobie
• Analiza zagrożeń — wyświetla informacje geograficzne o zewnętrznych węzłach, które Cię atakują
• Typowe zapytania dotyczące bezpieczeństwa - typowe zapytania, które pomogą Ci lepiej monitorować bezpieczeństwo informacji.

Rozszerzenia Azure Monitor obejmują Azure Key Vault (ochrona kluczy kryptograficznych w chmurze), Malware Assessment (analiza ochrony przed złośliwym kodem na maszynach wirtualnych), Azure Application Gateway Analytics (analiza m.in. logów firewalla w chmurze) itp. . Narzędzia te, wzbogacone o pewne zasady przetwarzania zdarzeń, pozwalają na wizualizację różnych aspektów działania usług chmurowych, w tym bezpieczeństwa, oraz identyfikację pewnych odchyleń od działania. Ale, jak to często bywa, każda dodatkowa funkcjonalność wymaga odpowiedniej płatnej subskrypcji, co będzie wymagało od Ciebie odpowiednich inwestycji finansowych, które musisz zaplanować z wyprzedzeniem.

Platforma Azure ma wiele wbudowanych funkcji monitorowania zagrożeń, które są zintegrowane z usługami Azure AD, Azure Monitor i Azure Security Center. Wśród nich na przykład wykrywanie interakcji maszyn wirtualnych ze znanymi złośliwymi adresami IP (dzięki obecności integracji z usługami Threat Intelligence firmy Microsoft), wykrywanie złośliwego oprogramowania w infrastrukturze chmury poprzez odbieranie alarmów od maszyn wirtualnych hostowanych w chmurze, hasło ataki typu „zgadywanie” na maszyny wirtualne, luki w konfiguracji systemu identyfikacji użytkowników, logowanie do systemu z anonimizatorów lub zainfekowanych węzłów, wycieki kont, logowanie do systemu z nietypowych lokalizacji itp. Platforma Azure jest obecnie jednym z niewielu dostawców usług w chmurze oferujących wbudowane funkcje analizy zagrożeń w celu wzbogacenia zebranych zdarzeń związanych z bezpieczeństwem informacji.

Jak wspomniano powyżej, funkcjonalność bezpieczeństwa i w efekcie generowane przez nią zdarzenia bezpieczeństwa nie są dostępne jednakowo dla wszystkich użytkowników, ale wymagają określonej subskrypcji obejmującej potrzebną funkcjonalność, która generuje odpowiednie zdarzenia do monitorowania bezpieczeństwa informacji. Przykładowo część opisanych w poprzednim akapicie funkcji monitorowania anomalii na kontach dostępna jest wyłącznie w licencji premium P2 na usługę Azure AD. Bez tego, podobnie jak w przypadku AWS, będziesz musiał „ręcznie” analizować zebrane zdarzenia bezpieczeństwa. Ponadto, w zależności od rodzaju licencji usługi Azure AD, nie wszystkie zdarzenia będą dostępne do analizy.

W Azure Portal możesz zarządzać zarówno zapytaniami wyszukiwania dotyczącymi interesujących Cię dzienników, jak i konfigurować pulpity nawigacyjne w celu wizualizacji kluczowych wskaźników bezpieczeństwa informacji. Dodatkowo można tam wybrać rozszerzenia Azure Monitor, które pozwalają rozszerzyć funkcjonalność logów Azure Monitor i uzyskać głębszą analizę zdarzeń z punktu widzenia bezpieczeństwa.

Jeśli potrzebujesz nie tylko możliwości pracy z logami, ale kompleksowego centrum bezpieczeństwa dla swojej platformy chmurowej Azure, w tym zarządzania polityką bezpieczeństwa informacji, to możesz mówić o konieczności pracy z Azure Security Center, którego większość przydatnych funkcji są dostępne za jakieś pieniądze np. wykrywanie zagrożeń, monitorowanie poza Azure, ocena zgodności itp. (w wersji darmowej masz jedynie dostęp do oceny bezpieczeństwa i zaleceń dotyczących eliminacji zidentyfikowanych problemów). Konsoliduje wszystkie zagadnienia związane z bezpieczeństwem w jednym miejscu. Tak naprawdę możemy mówić o wyższym poziomie bezpieczeństwa informacji niż zapewnia Ci Azure Monitor, ponieważ w tym przypadku dane gromadzone w całej Twojej fabryce chmurowej są wzbogacane przy użyciu wielu źródeł, takich jak Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , Outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) i Microsoft Security Response Center (MSRC), na które nakładane są różne wyrafinowane algorytmy uczenia maszynowego i analizy behawioralnej, co docelowo powinno poprawić skuteczność wykrywania i reagowania na zagrożenia .

Azure ma też swój własny SIEM – pojawił się na początku 2019 roku. Jest to Azure Sentinel, który opiera się na danych z Azure Monitor i może się z nim także integrować. zewnętrzne rozwiązania bezpieczeństwa (np. NGFW czy WAF), których lista stale się powiększa. Ponadto, dzięki integracji interfejsu Microsoft Graph Security API, masz możliwość podłączenia własnych kanałów Threat Intelligence do Sentinel, co wzbogaca możliwości analizowania incydentów w chmurze Azure. Można argumentować, że Azure Sentinel to pierwszy „natywny” SIEM, który pojawił się u dostawców usług chmurowych (ten sam Splunk czy ELK, który można hostować w chmurze, np. AWS, wciąż nie jest rozwijany przez tradycyjnych dostawców usług chmurowych). Azure Sentinel i Security Center można by nazwać SOC dla chmury Azure i można by się do nich ograniczyć (z pewnymi zastrzeżeniami), jeśli nie posiadałeś już żadnej infrastruktury i przeniosłeś wszystkie swoje zasoby obliczeniowe do chmury i byłaby to chmura Microsoft Azure.

Ponieważ jednak wbudowane możliwości Azure (nawet jeśli posiadasz subskrypcję Sentinel) często nie wystarczą do celów monitorowania bezpieczeństwa informacji i integrowania tego procesu z innymi źródłami zdarzeń bezpieczeństwa (zarówno chmurowymi, jak i wewnętrznymi), istnieje konieczność eksportowania zebranych danych do systemów zewnętrznych, do których może należeć SIEM. Odbywa się to zarówno za pomocą API, jak i za pomocą specjalnych rozszerzeń, które obecnie oficjalnie są dostępne tylko dla następujących SIEM-ów - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight i ELK. Do niedawna takich SIEM-ów było więcej, jednak od 1 czerwca 2019 roku Microsoft zaprzestał wspierania narzędzia Azure Log Integration Tool (AzLog), które u zarania istnienia Azure i przy braku normalnej standaryzacji pracy z logami (Azure Monitora jeszcze nie było) umożliwiły łatwą integrację zewnętrznego SIEM z chmurą Microsoft. Teraz sytuacja się zmieniła i Microsoft rekomenduje platformę Azure Event Hub jako główne narzędzie integracji z innymi SIEM. Wiele z nich już wdrożyło taką integrację, ale należy zachować ostrożność — mogą nie przechwytywać wszystkich dzienników Azure, ale tylko niektóre (zajrzyj do dokumentacji swojego SIEM).

Kończąc krótką wycieczkę po Azure, chcę dać ogólną rekomendację dotyczącą tej usługi w chmurze - zanim powiesz cokolwiek na temat funkcji monitorowania bezpieczeństwa informacji na Azure, powinieneś je bardzo dokładnie skonfigurować i przetestować, czy działają zgodnie z opisem w dokumentacji i zgodnie z konsultanci powiedzieli Ci Microsoft (i mogą mieć odmienne poglądy na temat funkcjonalności funkcji Azure). Jeśli masz środki finansowe, możesz wycisnąć z Azure wiele przydatnych informacji w zakresie monitorowania bezpieczeństwa informacji. Jeśli Twoje zasoby są ograniczone, wówczas podobnie jak w przypadku AWS będziesz musiał polegać wyłącznie na własnych siłach i surowych danych, które dostarcza Ci Azure Monitor. I pamiętaj, że wiele funkcji monitorowania kosztuje i lepiej wcześniej zapoznać się z polityką cenową. Przykładowo za darmo możesz przechowywać 31 dni danych do maksymalnie 5 GB na klienta - przekroczenie tych wartości będzie wymagało wypłacenia dodatkowych pieniędzy (około 2 $+ za przechowywanie każdego dodatkowego GB od klienta i 0,1 $ za przechowywanie 1 GB w każdym dodatkowym miesiącu). Praca z telemetrią i metrykami aplikacji może również wymagać dodatkowych środków, a także praca z alertami i powiadomieniami (pewny limit jest dostępny za darmo, co może nie wystarczyć na Twoje potrzeby).

Przykład: Monitoring bezpieczeństwa informacji w IaaS w oparciu o Google Cloud Platform

Google Cloud Platform wygląda jak dziecko w porównaniu do AWS i Azure, ale jest to częściowo dobre. W odróżnieniu od AWS, który stopniowo zwiększał swoje możliwości, w tym także bezpieczeństwa, mając problemy z centralizacją; GCP, podobnie jak Azure, jest znacznie lepiej zarządzany centralnie, co ogranicza liczbę błędów i czas wdrażania w całym przedsiębiorstwie. Z punktu widzenia bezpieczeństwa GCP, co dziwne, znajduje się pomiędzy AWS i Azure. Posiada również jedną rejestrację na wydarzenie dla całej organizacji, jednak jest ona niekompletna. Część funkcji jest jeszcze w fazie beta, ale stopniowo ten mankament powinien zostać wyeliminowany, a GCP stanie się bardziej dojrzałą platformą pod kątem monitorowania bezpieczeństwa informacji.

Głównym narzędziem do rejestrowania zdarzeń w GCP jest Stackdriver Logging (podobny do Azure Monitor), który pozwala zbierać zdarzenia z całej infrastruktury chmurowej (a także z AWS). Z punktu widzenia bezpieczeństwa w GCP każda organizacja, projekt lub folder ma cztery dzienniki:

• Aktywność Admina - zawiera wszystkie zdarzenia związane z dostępem administracyjnym, np. utworzeniem maszyny wirtualnej, zmianą praw dostępu itp. Dziennik ten jest zapisywany zawsze, niezależnie od Państwa chęci, i przechowuje jego dane przez 400 dni.
• Dostęp do danych - zawiera wszystkie zdarzenia związane z pracą z danymi przez użytkowników chmury (tworzenie, modyfikacja, odczyt itp.). Domyślnie ten dziennik nie jest zapisywany, ponieważ jego objętość rośnie bardzo szybko. Z tego powodu jego trwałość wynosi tylko 30 dni. Poza tym nie wszystko jest napisane w tym czasopiśmie. Nie są do niego zapisywane np. zdarzenia związane z zasobami, które są publicznie dostępne dla wszystkich użytkowników lub które są dostępne bez logowania do GCP.
• Zdarzenie systemowe - zawiera zdarzenia systemowe niezwiązane z użytkownikami lub działania administratora, który zmienia konfigurację zasobów chmury. Jest zawsze zapisywany i przechowywany przez 400 dni.
• Przejrzystość dostępu to unikalny przykład dziennika rejestrującego wszystkie działania pracowników Google (ale jeszcze nie w przypadku wszystkich usług GCP), którzy uzyskują dostęp do Twojej infrastruktury w ramach swoich obowiązków służbowych. Dziennik ten jest przechowywany przez 400 dni i nie jest dostępny dla każdego klienta GCP, ale tylko po spełnieniu szeregu warunków (wsparcie na poziomie Gold lub Platinum lub obecność 4 ról określonego typu w ramach wsparcia korporacyjnego). Podobna funkcja dostępna jest także np. w Office 365 – Lockbox.

Przykład dziennika: Przejrzystość dostępu

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Dostęp do tych logów jest możliwy na kilka sposobów (w podobny sposób, jak omówiono wcześniej Azure i AWS) - poprzez interfejs Log Viewer, poprzez API, poprzez Google Cloud SDK lub poprzez stronę Aktywność Twojego projektu, dla którego interesują się wydarzeniami. W ten sam sposób można je wyeksportować do rozwiązań zewnętrznych w celu dodatkowej analizy. To drugie odbywa się poprzez eksport logów do magazynu BigQuery lub Cloud Pub/Sub.

Oprócz Stackdriver Logging platforma GCP oferuje również funkcję Stackdriver Monitoring, która umożliwia monitorowanie kluczowych wskaźników (wydajność, MTBF, ogólny stan itp.) usług i aplikacji w chmurze. Przetworzone i zwizualizowane dane mogą ułatwić znalezienie problemów w Twojej infrastrukturze chmurowej, także w kontekście bezpieczeństwa. Należy jednak zaznaczyć, że ta funkcjonalność nie będzie zbyt bogata w kontekście bezpieczeństwa informacji, ponieważ dziś GCP nie ma odpowiednika tego samego AWS GuardDuty i nie jest w stanie zidentyfikować złych wśród wszystkich zarejestrowanych zdarzeń (Google opracowało Event Threat Detection, ale jest wciąż w fazie rozwoju w wersji beta i jest zbyt wcześnie, aby mówić o jego użyteczności). Stackdriver Monitoring mógłby zostać wykorzystany jako system wykrywania anomalii, które następnie byłyby badane w celu znalezienia przyczyn ich wystąpienia. Jednak biorąc pod uwagę brak na rynku personelu wykwalifikowanych w zakresie bezpieczeństwa informacji GCP, zadanie to wydaje się obecnie trudne.

Warto też podać listę niektórych modułów bezpieczeństwa informacji, które można zastosować w ramach Twojej chmury GCP, a które są podobne do tego, co oferuje AWS:

• Cloud Security Command Center jest odpowiednikiem AWS Security Hub i Azure Security Center.
• Cloud DLP - Automatyczne wykrywanie i edycja (np. maskowanie) danych hostowanych w chmurze przy użyciu ponad 90 predefiniowanych polityk klasyfikacji.
• Cloud Scanner to skaner znanych podatności (XSS, Flash Injection, niezałatane biblioteki itp.) w App Engine, Compute Engine i Google Kubernetes.
• Cloud IAM — kontroluj dostęp do wszystkich zasobów GCP.
• Cloud Identity — zarządzaj kontami użytkowników, urządzeń i aplikacji GCP z jednej konsoli.
• Cloud HSM - ochrona kluczy kryptograficznych.
• Cloud Key Management Service - zarządzanie kluczami kryptograficznymi w GCP.
• Kontrola usług VPC — utwórz bezpieczny obwód wokół zasobów GCP, aby chronić je przed wyciekami.
• Klucz bezpieczeństwa Titan - ochrona przed phishingiem.

Wiele z tych modułów generuje zdarzenia bezpieczeństwa, które można wysłać do pamięci BigQuery w celu analizy lub eksportu do innych systemów, w tym SIEM. Jak wspomniano powyżej, GCP jest platformą aktywnie rozwijającą się, a Google pracuje obecnie nad szeregiem nowych modułów bezpieczeństwa informacji dla swojej platformy. Wśród nich znajdują się Event Threat Detection (dostępne teraz w wersji beta), które skanuje logi Stackdrivera w poszukiwaniu śladów nieautoryzowanej aktywności (analogicznie do GuardDuty w AWS) czy Policy Intelligence (dostępne w wersji alfa), które pozwolą Ci opracować inteligentne polityki dla dostęp do zasobów GCP.

Zrobiłem krótki przegląd wbudowanych możliwości monitorowania w popularnych platformach chmurowych. Ale czy masz specjalistów, którzy potrafią pracować z „surowymi” logami dostawcy IaaS (nie każdy jest gotowy na zakup zaawansowanych możliwości AWS, Azure lub Google)? Ponadto wielu zna powiedzenie „ufaj, ale sprawdzaj”, które w dziedzinie bezpieczeństwa jest bardziej prawdziwe niż kiedykolwiek. Jak bardzo ufasz wbudowanym możliwościom dostawcy usług w chmurze, który wysyła Ci zdarzenia związane z bezpieczeństwem informacji? Jak bardzo w ogóle skupiają się na bezpieczeństwie informacji?

Czasami warto przyjrzeć się nakładkowym rozwiązaniom do monitorowania infrastruktury chmurowej, które mogą stanowić uzupełnienie wbudowanych zabezpieczeń chmurowych, a czasem takie rozwiązania są jedyną możliwością uzyskania wglądu w bezpieczeństwo Twoich danych i aplikacji hostowanych w chmurze. Ponadto są po prostu wygodniejsze, ponieważ przejmują na siebie wszystkie zadania związane z analizą niezbędnych logów generowanych przez różne usługi chmurowe od różnych dostawców usług chmurowych. Przykładem takiego rozwiązania nakładkowego jest Cisco Stealthwatch Cloud, które koncentruje się na jednym zadaniu – monitorowaniu anomalii bezpieczeństwa informacji w środowiskach chmurowych, obejmujących nie tylko Amazon AWS, Microsoft Azure i Google Cloud Platform, ale także chmury prywatne.

Przykład: monitorowanie bezpieczeństwa informacji za pomocą chmury Stealthwatch

AWS zapewnia elastyczną platformę obliczeniową, ale ta elastyczność ułatwia firmom popełnianie błędów prowadzących do problemów z bezpieczeństwem. A model bezpieczeństwa informacji współdzielonych tylko się do tego przyczynia. Uruchamianie oprogramowania w chmurze z nieznanymi lukami (znane można zwalczyć np. za pomocą AWS Inspector lub GCP Cloud Scanner), słabymi hasłami, błędną konfiguracją, insiderami itp. A wszystko to ma odzwierciedlenie w zachowaniu zasobów chmury, które może monitorować Cisco Stealthwatch Cloud, czyli system monitorowania bezpieczeństwa informacji i wykrywania ataków. chmury publiczne i prywatne.

Jedną z kluczowych funkcji Cisco Stealthwatch Cloud jest możliwość modelowania jednostek. Dzięki niemu możesz stworzyć model oprogramowania (czyli symulację w czasie zbliżonym do rzeczywistego) każdego z zasobów chmury (nie ma znaczenia, czy jest to AWS, Azure, GCP czy coś innego). Mogą one obejmować serwery i użytkowników, a także typy zasobów specyficzne dla środowiska chmury, takie jak grupy zabezpieczeń i grupy automatycznego skalowania. Modele te wykorzystują jako dane wejściowe ustrukturyzowane strumienie danych dostarczane przez usługi w chmurze. Na przykład w przypadku AWS będą to dzienniki przepływu VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda i AWS IAM. Modelowanie encji automatycznie odkrywa rolę i zachowanie dowolnych Twoich zasobów (można mówić o profilowaniu całej aktywności w chmurze). Role te obejmują urządzenie mobilne z systemem Android lub Apple, serwer Citrix PVS, serwer RDP, bramę pocztową, klienta VoIP, serwer terminali, kontroler domeny itp. Następnie stale monitoruje ich zachowanie, aby określić, kiedy pojawia się ryzykowne lub zagrażające bezpieczeństwu zachowanie. Możesz zidentyfikować odgadywanie haseł, ataki DDoS, wycieki danych, nielegalny dostęp zdalny, aktywność złośliwego kodu, skanowanie pod kątem luk w zabezpieczeniach i inne zagrożenia. Przykładowo tak wygląda wykrycie próby zdalnego dostępu z kraju nietypowego dla Twojej organizacji (Korea Południowa) do klastra Kubernetes przez SSH:

A tak wygląda rzekomy wyciek informacji z bazy Postgress do kraju, z którym nie mieliśmy wcześniej do czynienia:

Wreszcie tak wygląda zbyt wiele nieudanych prób SSH z Chin i Indonezji z zewnętrznego urządzenia zdalnego:

Załóżmy też, że instancja serwera w VPC zgodnie z zasadami nigdy nie będzie miejscem zdalnego logowania. Załóżmy dalej, że na tym komputerze doszło do zdalnego logowania z powodu błędnej zmiany w zasadach reguł zapory. Funkcja Entity Modeling wykryje i zgłosi to działanie („Niezwykły dostęp zdalny”) w czasie zbliżonym do rzeczywistego i wskaże konkretne wywołanie interfejsu API AWS CloudTrail, Azure Monitor lub GCP Stackdriver Logging API (w tym między innymi nazwę użytkownika, datę i godzinę) ), co spowodowało zmianę zasady ITU. Następnie informacje te można przesłać do SIEM w celu analizy.

Podobne możliwości są zaimplementowane w dowolnym środowisku chmurowym obsługiwanym przez Cisco Stealthwatch Cloud:

Modelowanie jednostek to unikalna forma automatyzacji bezpieczeństwa, która może odkryć nieznany wcześniej problem z Twoimi ludźmi, procesami lub technologią. Pozwala na przykład wykryć m.in. problemy bezpieczeństwa takie jak:

• Czy ktoś odkrył backdoora w oprogramowaniu, którego używamy?
• Czy w naszej chmurze znajduje się oprogramowanie lub urządzenie strony trzeciej?
• Czy autoryzowany użytkownik nadużywa swoich uprawnień?
• Czy wystąpił błąd konfiguracji, który umożliwił zdalny dostęp lub inne niezamierzone użycie zasobów?
• Czy doszło do wycieku danych z naszych serwerów?
• Czy ktoś próbował się z nami połączyć z nietypowej lokalizacji geograficznej?
• Czy nasza chmura jest zainfekowana złośliwym kodem?

Wykryte zdarzenie związane z bezpieczeństwem informacji może zostać przesłane w formie odpowiedniego biletu do Slack, Cisco Spark, systemu zarządzania incydentami PagerDuty, a także przesłane do różnych SIEM-ów, m.in. Splunk czy ELK. Podsumowując, możemy powiedzieć, że jeśli Twoja firma korzysta ze strategii wielu chmur i nie ogranicza się do jednego dostawcy usług w chmurze, możliwości monitorowania bezpieczeństwa informacji opisane powyżej, to korzystanie z Cisco Stealthwatch Cloud jest dobrym rozwiązaniem, aby uzyskać ujednolicony zestaw monitorowania możliwości dla wiodących graczy w chmurze – Amazon, Microsoft i Google. Najciekawsze jest to, że jeśli porównamy ceny Stealthwatch Cloud z zaawansowanymi licencjami na monitorowanie bezpieczeństwa informacji w AWS, Azure czy GCP, może się okazać, że rozwiązanie Cisco będzie nawet tańsze niż wbudowane możliwości Amazona, Microsoftu i rozwiązania Google. To paradoksalne, ale prawdziwe. Im więcej chmur i ich możliwości wykorzystasz, tym bardziej oczywista będzie zaleta skonsolidowanego rozwiązania.

Ponadto Stealthwatch Cloud może monitorować chmury prywatne wdrożone w Twojej organizacji, na przykład w oparciu o kontenery Kubernetes lub monitorując przepływy Netflow lub ruch sieciowy odbierany poprzez dublowanie w sprzęcie sieciowym (nawet produkowanym w kraju), danych AD lub serwerach DNS i tak dalej. Wszystkie te dane zostaną wzbogacone o informacje z Threat Intelligence zebrane przez Cisco Talos, największą na świecie pozarządową grupę badaczy zagrożeń cyberbezpieczeństwa.

Dzięki temu możesz wdrożyć ujednolicony system monitorowania zarówno chmur publicznych, jak i hybrydowych, z których może korzystać Twoja firma. Zebrane informacje można następnie przeanalizować za pomocą wbudowanych możliwości Stealthwatch Cloud lub przesłać do Twojego SIEM (domyślnie obsługiwane są Splunk, ELK, SumoLogic i kilka innych).

Na tym zakończymy pierwszą część artykułu, w której dokonałem przeglądu wbudowanych i zewnętrznych narzędzi monitorowania bezpieczeństwa informacji platform IaaS/PaaS, które pozwalają nam szybko wykrywać i reagować na incydenty występujące w środowiskach chmurowych, które wybrało nasze przedsiębiorstwo. W drugiej części będziemy kontynuować temat i przyjrzymy się możliwościom monitorowania platform SaaS na przykładzie Salesforce i Dropbox, a także postaramy się wszystko podsumować i złożyć w całość, tworząc ujednolicony system monitorowania bezpieczeństwa informacji dla różnych dostawców chmury.

Źródło: www.habr.com