Cloud Security Monitoring

Premještanje podataka i aplikacija u oblak predstavlja novi izazov za korporativne SOC-ove, koji nisu uvijek spremni za praćenje infrastrukture drugih ljudi. Prema Netoskope-u, prosječno preduzeće (izgleda u SAD) koristi 1246 različitih usluga u oblaku, što je 22% više nego prije godinu dana. 1246 cloud servisa!!! Od toga 175 odnosi se na HR usluge, 170 na marketing, 110 na oblast komunikacija i 76 na finansije i CRM. Cisco koristi “samo” 700 eksternih usluga u oblaku. Tako da sam malo zbunjen ovim brojevima. No, u svakom slučaju, problem nije u njima, već u činjenici da oblak počinje prilično aktivno koristiti sve veći broj kompanija koje bi željele imati iste mogućnosti za praćenje cloud infrastrukture kao u vlastitoj mreži. I ovaj trend raste – prema prema Američkoj računskoj komori Do 2023. 1200 data centara će biti zatvoreno u Sjedinjenim Državama (6250 je već zatvoreno). Ali prelazak na oblak nije samo „premjestimo naše servere na vanjskog provajdera“. Nova IT arhitektura, novi softver, novi procesi, nova ograničenja... Sve to donosi značajne promjene u radu ne samo IT, već i informacione sigurnosti. A ako su se provajderi naučili nekako nositi s osiguravanjem sigurnosti samog oblaka (srećom ima puno preporuka), onda s nadzorom sigurnosti informacija u oblaku, posebno na SaaS platformama, postoje značajne poteškoće, o kojima ćemo govoriti.

Recimo da je vaša kompanija premjestila dio svoje infrastrukture u oblak... Stani. Ne na ovaj način. Ako je infrastruktura prebačena, a vi tek sada razmišljate kako ćete je nadzirati, onda ste već izgubili. Osim ako se radi o Amazonu, Googleu ili Microsoftu (i onda sa rezervacijama), vjerovatno nećete imati puno mogućnosti da nadgledate svoje podatke i aplikacije. Dobro je ako vam se pruži prilika da radite sa logovima. Ponekad će podaci o sigurnosnim događajima biti dostupni, ali nećete imati pristup njima. Na primjer, Office 365. Ako imate najjeftiniju E1 licencu, tada vam sigurnosni događaji uopće nisu dostupni. Ako imate E3 licencu, vaši podaci se pohranjuju samo 90 dana, a samo ako imate E5 licencu, trajanje dnevnika je dostupno godinu dana (međutim, i to ima svoje nijanse vezane za potrebu odvojenog zatražite brojne funkcije za rad sa zapisnicima od Microsoft podrške). Inače, E3 licenca je mnogo slabija u smislu funkcija praćenja od korporativne Exchange. Da biste postigli isti nivo, potrebna vam je E5 licenca ili dodatna licenca za naprednu usklađenost, što može zahtijevati dodatni novac koji nije uračunat u vaš finansijski model za prelazak na infrastrukturu oblaka. A ovo je samo jedan primjer potcjenjivanja problema vezanih za nadzor sigurnosti informacija u oblaku. U ovom članku, ne pretvarajući se da je potpun, želim skrenuti pažnju na neke nijanse koje treba uzeti u obzir pri odabiru provajdera u oblaku sa sigurnosne točke gledišta. I na kraju članka će biti data kontrolna lista koju vrijedi popuniti prije nego što se uzme u obzir da je riješeno pitanje nadzora informacione sigurnosti u oblaku.

Postoji nekoliko tipičnih problema koji dovode do incidenata u okruženjima u oblaku, na koje službe informacijske sigurnosti nemaju vremena da odgovore ili ih uopće ne vide:

• Sigurnosni zapisnici ne postoje. Ovo je prilično česta situacija, posebno među početnicima na tržištu rješenja u oblaku. Ali ne treba odmah odustati od njih. Mali igrači, posebno domaći, osjetljiviji su na zahtjeve kupaca i mogu brzo implementirati neke potrebne funkcije promjenom odobrene mape puta za svoje proizvode. Da, ovo neće biti analog GuardDuty-a iz Amazona ili modula „Proaktivna zaštita” iz Bitrixa, ali barem nešto.
• Informaciona sigurnost ne zna gdje su zapisnici pohranjeni ili im nema pristupa. Ovdje je potrebno ući u pregovore s pružateljem usluga u oblaku - možda će on dati takve informacije ako smatra da je klijent za njega značajan. Ali generalno, nije baš dobro kada je pristup evidencijama omogućen „posebnom odlukom“.
• Dešava se i da cloud provajder ima logove, ali oni omogućavaju ograničeno praćenje i snimanje događaja, koji nisu dovoljni za otkrivanje svih incidenata. Na primjer, možete primati samo zapisnike promjena na web stranici ili zapisnike pokušaja autentifikacije korisnika, ali ne i druge događaje, na primjer, o mrežnom prometu, koji će sakriti od vas cijeli sloj događaja koji karakteriziraju pokušaje hakovanja vaše infrastrukture oblaka .
• Dnevnici postoje, ali pristup im je teško automatizirati, što ih prisiljava da se ne prate kontinuirano, već po rasporedu. A ako ne možete automatski da preuzimate dnevnike, onda preuzimanje dnevnika, na primjer, u Excel formatu (kao kod brojnih domaćih dobavljača rješenja u oblaku), može čak dovesti do nevoljnosti službe korporativne informacione sigurnosti da se pozabavi njima.
• Nema praćenja dnevnika. Ovo je možda i najnejasniji razlog za pojavu incidenata u informacionoj bezbednosti u cloud okruženjima. Čini se da evidencije postoje i moguće je automatizirati pristup njima, ali to niko ne radi. Zašto?

Zajednički koncept sigurnosti u oblaku

Prelazak na oblak uvijek je potraga za ravnotežom između želje da se zadrži kontrola nad infrastrukturom i prenošenja u profesionalnije ruke provajdera oblaka koji je specijaliziran za njeno održavanje. I u oblasti sigurnosti u oblaku, ovaj balans se također mora tražiti. Štoviše, ovisno o korištenom modelu isporuke usluge u oblaku (IaaS, PaaS, SaaS), ova ravnoteža će biti različita cijelo vrijeme. U svakom slučaju, moramo imati na umu da svi provajderi oblaka danas slijede model zajedničke odgovornosti i zajedničke sigurnosti informacija. Oblak je odgovoran za neke stvari, a za druge je odgovoran klijent, stavljajući svoje podatke, svoje aplikacije, svoje virtuelne mašine i druge resurse u oblak. Bilo bi nepromišljeno očekivati ​​da ćemo odlaskom u oblak svu odgovornost prebaciti na provajdera. Ali takođe nije mudro sami izgraditi svu sigurnost kada prelazite na oblak. Potreban je balans, koji će zavisiti od mnogih faktora: - strategije upravljanja rizikom, modela pretnji, sigurnosnih mehanizama koji su dostupni provajderu oblaka, zakonodavstva, itd.

Na primjer, klasifikacija podataka koji se nalaze u oblaku uvijek je odgovornost kupca. Provajder u oblaku ili eksterni pružalac usluga može mu pomoći samo alatima koji će pomoći u označavanju podataka u oblaku, identifikaciji kršenja, brisanju podataka koji krše zakon ili maskiranju na ovaj ili onaj način. S druge strane, fizička sigurnost je uvijek odgovornost provajdera oblaka, koju ne može dijeliti s klijentima. Ali sve što je između podataka i fizičke infrastrukture upravo je predmet rasprave u ovom članku. Na primjer, dostupnost oblaka je odgovornost provajdera, a postavljanje pravila zaštitnog zida ili omogućavanje enkripcije je odgovornost klijenta. U ovom članku pokušaćemo da pogledamo koje mehanizme nadzora bezbednosti informacija danas pružaju razni popularni provajderi oblaka u Rusiji, koje su karakteristike njihove upotrebe i kada se isplati obratiti pažnju na eksterna rešenja za preklapanje (na primer, Cisco E- mail Security) koji proširuju mogućnosti vašeg oblaka u smislu sajber sigurnosti. U nekim slučajevima, posebno ako slijedite multi-cloud strategiju, nećete imati izbora osim da koristite vanjska rješenja za nadzor sigurnosti informacija u nekoliko okruženja u oblaku odjednom (na primjer, Cisco CloudLock ili Cisco Stealthwatch Cloud). Pa, u nekim slučajevima shvatit ćete da dobavljač oblaka kojeg ste odabrali (ili vam ga nametnuli) uopće ne nudi mogućnosti nadzora sigurnosti informacija. Ovo je neprijatno, ali ne i malo, jer vam omogućava da adekvatno procenite nivo rizika koji je povezan sa radom sa ovim oblakom.

Životni ciklus nadgledanja sigurnosti u oblaku

Za praćenje sigurnosti oblaka koje koristite, imate samo tri opcije:

• oslanjajte se na alate koje pruža vaš provajder oblaka,
• koristiti rješenja trećih strana koja će pratiti IaaS, PaaS ili SaaS platforme koje koristite,
• izgradite vlastitu infrastrukturu za praćenje oblaka (samo za IaaS/PaaS platforme).

Pogledajmo koje karakteristike ima svaka od ovih opcija. Ali prvo, moramo razumjeti opći okvir koji će se koristiti prilikom praćenja cloud platformi. Istaknuo bih 6 glavnih komponenti procesa nadzora sigurnosti informacija u oblaku:

• Priprema infrastrukture. Određivanje potrebnih aplikacija i infrastrukture za prikupljanje događaja važnih za sigurnost informacija u skladište.
• Kolekcija. U ovoj fazi, sigurnosni događaji se agregiraju iz različitih izvora za naknadni prijenos radi obrade, skladištenja i analize.
• Tretman. U ovoj fazi, podaci se transformišu i obogaćuju kako bi se olakšala kasnija analiza.
• Skladištenje. Ova komponenta je odgovorna za kratkoročno i dugoročno skladištenje prikupljenih obrađenih i neobrađenih podataka.
• Analiza. U ovoj fazi imate mogućnost otkrivanja incidenata i reagovanja na njih automatski ili ručno.
• Izvještavanje. Ova faza pomaže da se formulišu ključni indikatori za zainteresovane strane (menadžment, revizori, provajderi u oblaku, klijenti, itd.) koji nam pomažu da donesemo određene odluke, na primer, menjamo dobavljača ili jačamo bezbednost informacija.

Razumijevanje ovih komponenti će vam omogućiti da u budućnosti brzo odlučite šta možete uzeti od svog provajdera, a šta ćete morati da uradite sami ili uz angažovanje spoljnih konsultanata.

Ugrađene usluge u oblaku

Već sam gore napisao da mnoge usluge u oblaku danas ne pružaju nikakve mogućnosti praćenja sigurnosti informacija. Općenito, ne posvećuju mnogo pažnje temi informacione sigurnosti. Na primjer, jedna od popularnih ruskih usluga za slanje izvještaja vladinim agencijama putem interneta (neću posebno spominjati njegovo ime). Cijeli dio o sigurnosti ove usluge vrti se oko korištenja certificiranog CIPF-a. Odjeljak o sigurnosti informacija drugog domaćeg servisa u oblaku za elektronsko upravljanje dokumentima nije ništa drugačiji. Govori o certifikatima javnog ključa, certificiranoj kriptografiji, eliminaciji web ranjivosti, zaštiti od DDoS napada, korištenju zaštitnih zidova, sigurnosnih kopija, pa čak i redovnim revizijama sigurnosti informacija. Ali, nema ni riječi o praćenju, kao ni o mogućnosti pristupa informacijskim sigurnosnim događajima koji mogu biti od interesa za klijente ovog provajdera.

Općenito, po načinu na koji dobavljač oblaka opisuje probleme sigurnosti informacija na svojoj web stranici iu svojoj dokumentaciji, možete razumjeti koliko ozbiljno shvata ovaj problem. Na primjer, ako čitate priručnike za proizvode „Moja kancelarija“, nema ni riječi o sigurnosti, već u dokumentaciji za poseban proizvod „Moj ured. KS3”, dizajniran za zaštitu od neovlaštenog pristupa, postoji uobičajeni spisak tačaka 17. reda FSTEC-a, koje “My Office.KS3” implementira, ali nije opisano kako to implementira i, što je najvažnije, kako se integrisati ove mehanizme sa korporativnom informacionom bezbednošću. Možda takva dokumentacija postoji, ali je nisam našao u javnom domenu, na web stranici „Moja kancelarija“. Iako možda jednostavno nemam pristup ovim tajnim informacijama?..

Za Bitrix je situacija mnogo bolja. Dokumentacija opisuje formate dnevnika događaja i, zanimljivo, dnevnika upada, koji sadrži događaje vezane za potencijalne prijetnje platformi u oblaku. Odatle možete izvući IP, ime korisnika ili gosta, izvor događaja, vrijeme, korisnički agent, tip događaja itd. Istina, s ovim događajima možete raditi ili sa kontrolne ploče samog oblaka ili prenijeti podatke u MS Excel formatu. Sada je teško automatizirati rad s Bitrix logovima i dio posla ćete morati obaviti ručno (prebacivanje izvještaja i njegovo učitavanje u vaš SIEM). Ali ako se prisjetimo da relativno nedavno takva prilika nije postojala, onda je ovo veliki napredak. Istovremeno, želio bih napomenuti da mnogi strani provajderi oblaka nude sličnu funkcionalnost "za početnike" - ili gledajte zapisnike svojim očima kroz kontrolnu ploču ili prenesite podatke sebi (međutim, većina podataka prenosi u . csv formatu, a ne Excel).

Ne uzimajući u obzir opciju bez zapisivanja, dobavljači u oblaku obično vam nude tri opcije za praćenje sigurnosnih događaja - nadzorne ploče, prijenos podataka i pristup API-ju. Čini se da prvi rješava mnoge probleme umjesto vas, ali to nije sasvim tačno - ako imate nekoliko časopisa, morate se prebacivati ​​između ekrana na kojima se prikazuju, čime se gubi ukupna slika. Osim toga, malo je vjerovatno da će vam pružatelj usluga u oblaku pružiti mogućnost povezivanja sigurnosnih događaja i općenito analiziranja sa sigurnosne točke gledišta (obično imate posla sa sirovim podacima, koje morate sami razumjeti). Postoje izuzeci i o njima ćemo dalje. Na kraju, vrijedi se zapitati koje događaje snima vaš provajder u oblaku, u kojem formatu i kako odgovaraju vašem procesu nadzora sigurnosti informacija? Na primjer, identifikacija i autentifikacija korisnika i gostiju. Isti Bitrix vam omogućava, na osnovu ovih događaja, da zabilježite datum i vrijeme događaja, ime korisnika ili gosta (ako imate modul “Web Analytics”), objekt kojem se pristupa i druge elemente tipične za web stranicu. . Ali korporativnim službama za sigurnost informacija možda će biti potrebne informacije o tome da li je korisnik pristupio oblaku sa pouzdanog uređaja (na primjer, u korporativnoj mreži ovaj zadatak implementira Cisco ISE). Što je s tako jednostavnim zadatkom kao što je geo-IP funkcija, koja će pomoći da se utvrdi da li je korisnički račun usluge u oblaku ukraden? Čak i ako vam ga pruža dobavljač u oblaku, to nije dovoljno. Isti Cisco CloudLock ne analizira samo geolokaciju, već za to koristi mašinsko učenje i analizira istorijske podatke za svakog korisnika i prati različite anomalije u pokušajima identifikacije i autentifikacije. Samo MS Azure ima sličnu funkcionalnost (ako imate odgovarajuću pretplatu).

Postoji još jedna poteškoća – budući da je za mnoge cloud provajdere nadzor sigurnosti informacija nova tema kojom se tek počinju baviti, oni stalno nešto mijenjaju u svojim rješenjima. Danas imaju jednu verziju API-ja, sutra drugu, prekosutra treću. Takođe morate biti spremni na ovo. Isto važi i za funkcionalnost, koja se može promeniti, što se mora uzeti u obzir u vašem sistemu za nadzor bezbednosti informacija. Na primjer, Amazon je u početku imao zasebne usluge praćenja događaja u oblaku — AWS CloudTrail i AWS CloudWatch. Tada se pojavio poseban servis za praćenje događaja u sigurnosti informacija - AWS GuardDuty. Nakon nekog vremena, Amazon je pokrenuo novi sistem upravljanja, Amazon Security Hub, koji uključuje analizu podataka primljenih od GuardDuty, Amazon Inspector, Amazon Macie i nekoliko drugih. Drugi primjer je alat za integraciju Azure dnevnika sa SIEM-om - AzLog. Aktivno su ga koristili mnogi SIEM dobavljači, sve dok Microsoft nije 2018. godine objavio prestanak njegovog razvoja i podrške, što je mnoge klijente koji su koristili ovaj alat suočilo s problemom (o tome kako je riješen kasnije).

Stoga pažljivo pratite sve funkcije nadzora koje vam nudi vaš provajder u oblaku. Ili se oslonite na eksterne dobavljače rješenja koji će djelovati kao posrednici između vašeg SOC-a i oblaka koji želite pratiti. Da, biće skuplje (iako ne uvek), ali ćete svu odgovornost prebaciti na tuđa pleća. Ili ne sve?.. Prisjetimo se koncepta zajedničke sigurnosti i shvatimo da ne možemo ništa promijeniti - morat ćemo samostalno razumjeti kako različiti provajderi u oblaku obezbjeđuju praćenje informacione sigurnosti vaših podataka, aplikacija, virtuelnih mašina i drugih resursa hostovan u oblaku. I počećemo s onim što Amazon nudi u ovom dijelu.

Primjer: Nadgledanje sigurnosti informacija u IaaS-u zasnovano na AWS-u

Da, da, razumijem da Amazon nije najbolji primjer zbog činjenice da je ovo američki servis i da se može blokirati u sklopu borbe protiv ekstremizma i širenja informacija zabranjenih u Rusiji. Ali u ovoj publikaciji bih samo želio pokazati koliko se različite platforme u oblaku razlikuju u svojim mogućnostima praćenja sigurnosti informacija i na šta biste trebali obratiti pažnju kada prenosite svoje ključne procese u oblake sa sigurnosne tačke gledišta. Pa, ako neki od ruskih programera cloud rješenja nauče nešto korisno za sebe, onda će to biti sjajno.

Prvo što treba reći je da Amazon nije neprobojna tvrđava. Njegovim klijentima se redovno dešavaju razni incidenti. Na primjer, imena, adrese, datumi rođenja i telefonski brojevi 198 miliona glasača ukradeni su iz Deep Root Analytics. Izraelska kompanija Nice Systems ukrala je 14 miliona zapisa Verizona pretplatnika. Međutim, ugrađene mogućnosti AWS-a omogućavaju vam da otkrijete širok spektar incidenata. Na primjer:

• uticaj na infrastrukturu (DDoS)
• kompromis čvora (injekcija naredbe)
• kompromitovanje računa i neovlašteni pristup
• neispravna konfiguracija i ranjivosti
• nesigurna sučelja i API-ji.

Ovo odstupanje je zbog činjenice da je, kako smo gore saznali, sam kupac odgovoran za sigurnost podataka korisnika. A ako se nije potrudio da uključi zaštitne mehanizme i nije uključio alate za praćenje, onda će o incidentu saznati samo iz medija ili od svojih klijenata.

Za identifikaciju incidenata, možete koristiti širok spektar različitih usluga praćenja koje je razvio Amazon (iako su one često dopunjene vanjskim alatima kao što je osquery). Dakle, u AWS-u se prate sve radnje korisnika, bez obzira na to kako se izvode – preko upravljačke konzole, komandne linije, SDK-a ili drugih AWS servisa. Svi zapisi aktivnosti svakog AWS naloga (uključujući korisničko ime, radnju, uslugu, parametre aktivnosti i rezultat) i korištenje API-ja dostupni su putem AWS CloudTrail-a. Možete pogledati ove događaje (kao što su prijave na AWS IAM konzolu) sa CloudTrail konzole, analizirati ih koristeći Amazon Athena ili ih „outsources“ eksternim rješenjima kao što su Splunk, AlienVault, itd. Sami AWS CloudTrail dnevnici se postavljaju u vašu AWS S3 korpu.

Dvije druge AWS usluge pružaju niz drugih važnih mogućnosti praćenja. Prvo, Amazon CloudWatch je usluga praćenja AWS resursa i aplikacija koja vam, između ostalog, omogućava da identificirate različite anomalije u vašem oblaku. Sve ugrađene AWS usluge, kao što su Amazon Elastic Compute Cloud (serveri), Amazon Relational Database Service (baze podataka), Amazon Elastic MapReduce (analiza podataka) i 30 drugih Amazonovih usluga, koriste Amazon CloudWatch za pohranu svojih dnevnika. Programeri mogu koristiti otvoreni API iz Amazon CloudWatch da dodaju funkcionalnost praćenja dnevnika prilagođenim aplikacijama i uslugama, omogućavajući im da prošire opseg analize događaja unutar sigurnosnog konteksta.

Drugo, VPC Flow Logs usluga vam omogućava da analizirate mrežni saobraćaj koji šalju ili primaju vaši AWS serveri (eksterno ili interno), kao i između mikroservisa. Kada bilo koji od vaših AWS VPC resursa stupi u interakciju s mrežom, VPC Flow Logs bilježi detalje o mrežnom prometu, uključujući izvorni i odredišni mrežni interfejs, kao i IP adrese, portove, protokol, broj bajtova i broj paketa koje vidio. Oni koji imaju iskustva sa sigurnošću lokalne mreže prepoznat će ovo kao analogno nitima NetFlow, koje mogu kreirati prekidači, ruteri i zaštitni zidovi preduzeća. Ovi zapisnici su važni za potrebe praćenja sigurnosti informacija jer, za razliku od događaja o akcijama korisnika i aplikacija, oni vam također omogućavaju da ne propustite mrežne interakcije u AWS virtuelnom privatnom oblaku.

Ukratko, ove tri AWS usluge — AWS CloudTrail, Amazon CloudWatch i VPC Flow Logs — zajedno pružaju prilično moćan uvid u korištenje vašeg naloga, ponašanje korisnika, upravljanje infrastrukturom, aktivnost aplikacija i usluga i mrežnu aktivnost. Na primjer, mogu se koristiti za otkrivanje sljedećih anomalija:

• Pokušaji skeniranja stranice, traženje backdoor-a, traženje ranjivosti kroz nizove „404 greške“.
• Injekcioni napadi (na primjer, SQL injekcija) kroz rafale od "500 grešaka".
• Poznati alati za napad su sqlmap, nikto, w3af, nmap, itd. kroz analizu polja User Agent.

Amazon Web Services je također razvio druge usluge u svrhu sajber sigurnosti koje vam omogućavaju rješavanje mnogih drugih problema. Na primjer, AWS ima ugrađenu uslugu za reviziju politika i konfiguracija - AWS Config. Ova usluga pruža kontinuiranu reviziju vaših AWS resursa i njihovih konfiguracija. Uzmimo jednostavan primjer: Recimo da želite biti sigurni da su korisničke lozinke onemogućene na svim vašim serverima i da je pristup moguć samo na osnovu certifikata. AWS Config olakšava provjeru ovoga za sve vaše servere. Postoje i druga pravila koja se mogu primijeniti na vaše servere u oblaku: “Nijedan server ne može koristiti port 22”, “Samo administratori mogu promijeniti pravila firewall-a” ili “Samo korisnik Ivashko može kreirati nove korisničke račune, a to može učiniti samo utorkom. " U ljeto 2016. godine, usluga AWS Config je proširena kako bi automatizirala otkrivanje kršenja razvijenih politika. AWS Config Rules su u suštini kontinuirani zahtjevi za konfiguraciju za Amazonove usluge koje koristite, a koji generiraju događaje ako se krše odgovarajuća pravila. Na primjer, umjesto povremenog pokretanja AWS Config upita kako bi se provjerilo da li su svi diskovi na virtuelnom serveru šifrirani, AWS Config pravila se mogu koristiti za kontinuiranu provjeru diskova servera kako bi se osiguralo da je ovaj uslov ispunjen. I, što je najvažnije, u kontekstu ove publikacije, svako kršenje generira događaje koje vaša služba za sigurnost informacija može analizirati.

AWS takođe ima svoj ekvivalent tradicionalnim korporativnim rešenjima za bezbednost informacija, koja takođe generišu bezbednosne događaje koje možete i treba da analizirate:

• Detekcija upada - AWS GuardDuty
• Kontrola curenja informacija - AWS Macie
• EDR (iako malo čudno govori o krajnjim tačkama u oblaku) - AWS Cloudwatch + open source osquery ili GRR rješenja
• Netflow analiza - AWS Cloudwatch + AWS VPC Flow
• DNS analiza - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Upravljanje nalogom - AWS IAM
• SSO - AWS SSO
• sigurnosna analiza - AWS Inspector
• upravljanje konfiguracijom - AWS Config
• WAF - AWS WAF.

Neću detaljno opisivati ​​sve Amazonove usluge koje mogu biti korisne u kontekstu informacione sigurnosti. Glavno je shvatiti da svi oni mogu generirati događaje koje možemo i trebamo analizirati u kontekstu informacione sigurnosti, koristeći u tu svrhu i ugrađene mogućnosti samog Amazona i eksterna rješenja, na primjer, SIEM, koji može odnesite sigurnosne događaje u svoj centar za nadzor i tamo ih analizirajte zajedno sa događajima iz drugih usluga u oblaku ili iz interne infrastrukture, perimetra ili mobilnih uređaja.

U svakom slučaju, sve počinje od izvora podataka koji vam pružaju događaje o sigurnosti informacija. Ovi izvori uključuju, ali nisu ograničeni na:

• CloudTrail - Upotreba API-ja i radnje korisnika
• Pouzdani savjetnik - sigurnosna provjera u odnosu na najbolje prakse
• Konfiguracija - inventar i konfiguracija naloga i podešavanja servisa
• VPC Flow Logs - veze sa virtuelnim interfejsima
• IAM - usluga identifikacije i autentifikacije
• ELB Access Logs - Load Balancer
• Inspektor - ranjivosti aplikacija
• S3 - pohrana datoteka
• CloudWatch - Aktivnost aplikacije
• SNS je servis za obavještavanje.

Amazon, iako nudi takav niz izvora događaja i alata za njihovo generiranje, vrlo je ograničen u svojoj sposobnosti da analizira prikupljene podatke u kontekstu sigurnosti informacija. Morat ćete samostalno proučiti dostupne dnevnike, tražeći relevantne pokazatelje kompromisa u njima. AWS Security Hub, koji je Amazon nedavno pokrenuo, ima za cilj da riješi ovaj problem tako što će postati cloud SIEM za AWS. Ali za sada je tek na početku svog puta i ograničen je i brojem izvora s kojima radi i drugim ograničenjima uspostavljenim arhitekturom i pretplatama samog Amazona.

Primjer: Nadgledanje sigurnosti informacija u IaaS baziranom na Azureu

Ne želim da ulazim u dugu raspravu o tome koji je od tri cloud provajdera (Amazon, Microsoft ili Google) bolji (pogotovo što svaki od njih ipak ima svoje specifične specifičnosti i pogodan je za rješavanje vlastitih problema); Hajde da se fokusiramo na mogućnosti praćenja bezbednosti informacija koje ovi igrači pružaju. Mora se priznati da je Amazon AWS bio jedan od prvih u ovom segmentu i samim tim je najdalje odmakao u pogledu funkcija sigurnosti informacija (iako mnogi priznaju da su teške za korištenje). Ali to ne znači da ćemo zanemariti mogućnosti koje nam pružaju Microsoft i Google.

Microsoftovi proizvodi oduvijek su se odlikovali svojom „otvorenošću“, a u Azureu je situacija slična. Na primjer, ako AWS i GCP uvijek polaze od koncepta „ono što nije dozvoljeno je zabranjeno“, onda Azure ima potpuno suprotan pristup. Na primjer, kada kreirate virtuelnu mrežu u oblaku i virtuelnu mašinu u njoj, svi portovi i protokoli su otvoreni i dozvoljeni prema zadanim postavkama. Stoga ćete morati uložiti malo više truda na početno postavljanje sistema kontrole pristupa u oblaku iz Microsofta. A to vam također nameće strože zahtjeve u pogledu aktivnosti nadgledanja u Azure oblaku.

AWS ima posebnost povezanu sa činjenicom da kada nadgledate svoje virtuelne resurse, ako se nalaze u različitim regionima, onda imate poteškoća u kombinovanju svih događaja i njihove objedinjene analize, da biste eliminisali koje morate da pribegnete raznim trikovima, kao npr. Kreirajte vlastiti kod za AWS Lambda koji će prenositi događaje između regija. Azure nema ovaj problem – njegov mehanizam evidencije aktivnosti prati sve aktivnosti u cijeloj organizaciji bez ograničenja. Isto se odnosi i na AWS Security Hub, koji je nedavno razvio Amazon za konsolidaciju mnogih sigurnosnih funkcija unutar jednog sigurnosnog centra, ali samo unutar svog regiona, što, međutim, nije relevantno za Rusiju. Azure ima svoj sigurnosni centar, koji nije vezan regionalnim ograničenjima, pružajući pristup svim sigurnosnim karakteristikama platforme u oblaku. Štaviše, za različite lokalne timove može da obezbedi sopstveni skup zaštitnih sposobnosti, uključujući bezbednosne događaje kojima oni upravljaju. AWS Security Hub je još uvijek na putu da postane sličan Azure Security Center. Ali vrijedi dodati muhu - iz Azurea možete istisnuti mnogo onoga što je prethodno opisano u AWS-u, ali to je najpogodnije učiniti samo za Azure AD, Azure Monitor i Azure Security Center. Svim drugim Azure sigurnosnim mehanizmima, uključujući analizu sigurnosnih događaja, još se ne upravlja na najprikladniji način. Problem je djelimično riješen API-jem koji prožima sve Microsoft Azure servise, ali to će zahtijevati dodatni napor od vas da integrišete svoj oblak sa vašim SOC-om i prisustvo kvalifikovanih stručnjaka (zapravo, kao i sa bilo kojim drugim SIEM-om koji radi sa cloud API-ji). Neki SIEM-ovi, o kojima će biti riječi kasnije, već podržavaju Azure i mogu automatizirati zadatak njegovog praćenja, ali ima i svoje poteškoće - ne mogu svi prikupiti sve zapise koje Azure ima.

Prikupljanje i praćenje događaja u Azure-u obezbjeđuje se korištenjem usluge Azure Monitor, koja je glavni alat za prikupljanje, pohranjivanje i analizu podataka u Microsoft oblaku i njegovim resursima – Git repozitorijumima, kontejnerima, virtuelnim mašinama, aplikacijama itd. Svi podaci koje prikuplja Azure Monitor podijeljeni su u dvije kategorije – metrike, koje se prikupljaju u realnom vremenu i opisuju ključne pokazatelje performansi Azure oblaka, i logove, koji sadrže podatke organizovane u zapise koji karakterišu određene aspekte aktivnosti Azure resursa i usluga. Osim toga, koristeći Data Collector API, usluga Azure Monitor može prikupljati podatke iz bilo kojeg REST izvora kako bi izgradila vlastite scenarije nadgledanja.

Evo nekoliko izvora sigurnosnih događaja koje vam Azure nudi i kojima možete pristupiti putem Azure Portala, CLI-a, PowerShell-a ili REST API-ja (a nekima samo preko Azure Monitor/Insight API-ja):

• Dnevnici aktivnosti – ovaj dnevnik odgovara na klasična pitanja „ko“, „šta“ i „kada“ u vezi sa bilo kojom operacijom pisanja (PUT, POST, DELETE) na resursima u oblaku. Događaji koji se odnose na pristup za čitanje (GET) nisu uključeni u ovaj dnevnik, kao i brojni drugi.
• Dijagnostički zapisi - sadrže podatke o operacijama sa određenim resursom uključenim u vašu pretplatu.
• Azure AD izvještavanje - sadrži i aktivnosti korisnika i sistemske aktivnosti vezane za upravljanje grupama i korisnicima.
• Windows Event Log i Linux Syslog - sadrži događaje sa virtuelnih mašina hostovanih u oblaku.
• metrika – sadrži telemetriju o performansama i zdravstvenom statusu vaših usluga i resursa u oblaku. Mjeri se svake minute i pohranjuje. u roku od 30 dana.
• Evidencija toka grupe za mrežnu sigurnost - sadrži podatke o događajima mrežne sigurnosti prikupljene korištenjem usluge Network Watcher i praćenje resursa na nivou mreže.
• Storage Logs - sadrži događaje vezane za pristup skladišnim objektima.

Za praćenje možete koristiti eksterne SIEM-ove ili ugrađeni Azure Monitor i njegove ekstenzije. Kasnije ćemo govoriti o sistemima za upravljanje događajima sigurnosti informacija, ali za sada da vidimo šta nam sam Azure nudi za analizu podataka u kontekstu sigurnosti. Glavni ekran za sve što je u vezi sa bezbednošću u Azure Monitoru je Log Analytics Security and Audit Dashboard (besplatna verzija podržava ograničenu količinu skladištenja događaja za samo jednu nedelju). Ova kontrolna ploča podijeljena je na 5 glavnih područja koja vizualiziraju zbirnu statistiku onoga što se događa u cloud okruženju koje koristite:

• Sigurnosni domeni - ključni kvantitativni indikatori koji se odnose na sigurnost informacija - broj incidenata, broj kompromitovanih čvorova, nezakrpljenih čvorova, mrežni sigurnosni događaji itd.
• Značajni problemi - prikazuje broj i važnost aktivnih pitanja sigurnosti informacija
• Detekcije - prikazuje obrasce napada koji se koriste protiv vas
• Threat Intelligence - prikazuje geografske informacije o vanjskim čvorovima koji vas napadaju
• Uobičajeni sigurnosni upiti - tipični upiti koji će vam pomoći da bolje nadgledate svoju sigurnost informacija.

Azure Monitor ekstenzije uključuju Azure Key Vault (zaštita kriptografskih ključeva u oblaku), Malware Assessment (analiza zaštite od zlonamjernog koda na virtuelnim mašinama), Azure Application Gateway Analytics (analiza, između ostalog, dnevnika zaštitnog zida u oblaku) itd. . Ovi alati, obogaćeni određenim pravilima za obradu događaja, omogućavaju vam da vizualizujete različite aspekte aktivnosti cloud servisa, uključujući sigurnost, i identifikujete određena odstupanja od rada. Ali, kao što se često dešava, svaka dodatna funkcionalnost zahtijeva odgovarajuću plaćenu pretplatu, što će od vas zahtijevati odgovarajuća finansijska ulaganja koja morate unaprijed planirati.

Azure ima niz ugrađenih mogućnosti praćenja prijetnji koje su integrirane u Azure AD, Azure Monitor i Azure Security Center. Među njima, na primjer, otkrivanje interakcije virtualnih mašina s poznatim zlonamjernim IP adresama (zbog prisustva integracije sa Threat Intelligence servisima iz Microsofta), otkrivanje zlonamjernog softvera u infrastrukturi oblaka primanjem alarma od virtualnih mašina koje se nalaze u oblaku, lozinka pogađanje napada” na virtuelne mašine, ranjivosti u konfiguraciji sistema za identifikaciju korisnika, prijavljivanje u sistem sa anonimizatora ili zaraženih čvorova, curenje naloga, prijavljivanje u sistem sa neobičnih lokacija itd. Azure je danas jedan od rijetkih dobavljača u oblaku koji vam nudi ugrađene mogućnosti Threat Intelligence za obogaćivanje prikupljenih događaja sigurnosti informacija.

Kao što je gore spomenuto, sigurnosna funkcionalnost i, kao rezultat toga, sigurnosni događaji koje ona generiše nisu dostupni svim korisnicima podjednako, već zahtijevaju određenu pretplatu koja uključuje funkcionalnost koja vam je potrebna, a koja generiše odgovarajuće događaje za praćenje sigurnosti informacija. Na primjer, neke od funkcija opisanih u prethodnom paragrafu za praćenje anomalija na nalozima dostupne su samo u P2 premium licenci za Azure AD uslugu. Bez toga ćete, kao u slučaju AWS-a, morati „ručno“ analizirati prikupljene sigurnosne događaje. Takođe, u zavisnosti od tipa licence Azure AD, neće svi događaji biti dostupni za analizu.

Na Azure portalu možete upravljati i upitima za pretragu za zapisnike koji vas zanimaju i postaviti nadzorne ploče za vizualizaciju ključnih indikatora sigurnosti informacija. Osim toga, tamo možete odabrati proširenja Azure Monitora, koja vam omogućavaju da proširite funkcionalnost dnevnika Azure Monitora i dobijete dublju analizu događaja sa sigurnosne tačke gledišta.

Ako vam je potrebna ne samo sposobnost rada sa zapisnicima, već i sveobuhvatan sigurnosni centar za vašu Azure cloud platformu, uključujući upravljanje politikama sigurnosti informacija, tada možete razgovarati o potrebi rada s Azure sigurnosnim centrom, od kojih većina korisnih funkcija dostupni su za nešto novca, na primjer, otkrivanje prijetnji, praćenje izvan Azurea, procjena usklađenosti itd. (u besplatnoj verziji imate pristup samo bezbednosnoj proceni i preporukama za otklanjanje identifikovanih problema). Objedinjuje sva sigurnosna pitanja na jednom mjestu. Zapravo, možemo govoriti o višem nivou sigurnosti informacija nego što vam Azure Monitor pruža, budući da se u ovom slučaju podaci prikupljeni u vašoj tvornici oblaka obogaćuju korištenjem mnogih izvora, kao što su 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 kojima su postavljeni različiti sofisticirani algoritmi za mašinsko učenje i analitiku ponašanja, što bi u konačnici trebalo poboljšati efikasnost otkrivanja prijetnji i odgovora na njih .

Azure ima i svoj SIEM - pojavio se početkom 2019. Ovo je Azure Sentinel, koji se oslanja na podatke iz Azure Monitora i može se integrirati s njim. vanjska sigurnosna rješenja (na primjer, NGFW ili WAF), čija se lista stalno povećava. Osim toga, kroz integraciju Microsoft Graph Security API-ja, imate mogućnost da povežete svoje vlastite Threat Intelligence feedove na Sentinel, što obogaćuje mogućnosti za analizu incidenata u vašem Azure oblaku. Može se tvrditi da je Azure Sentinel prvi „nativni“ SIEM koji se pojavio od dobavljača usluga u oblaku (isti Splunk ili ELK, koji se mogu hostirati u oblaku, na primjer, AWS, još uvijek nisu razvijeni od strane tradicionalnih pružatelja usluga u oblaku). Azure Sentinel i Security Center mogli bi se nazvati SOC za Azure oblak i mogli bi biti ograničeni na njih (uz određene rezerve) ako više nemate nikakvu infrastrukturu i prenijeli ste sve svoje računarske resurse u oblak i to bi bio Microsoft cloud Azure.

Ali budući da ugrađene mogućnosti Azurea (čak i ako imate pretplatu na Sentinel) često nisu dovoljne za potrebe praćenja sigurnosti informacija i integracije ovog procesa s drugim izvorima sigurnosnih događaja (i oblaka i internih), postoji potrebno je eksportirati prikupljene podatke u eksterne sisteme, u koje može biti uključen SIEM. To se radi i korištenjem API-ja i pomoću posebnih ekstenzija, koje su trenutno službeno dostupne samo za sljedeće SIEM-ove - Splunk (Azure Monitor dodatak za Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight i ELK. Donedavno je takvih SIEM-ova bilo više, ali od 1. juna 2019. Microsoft je prestao podržavati Azure Log Integration Tool (AzLog), koji je u osvit postojanja Azurea i u nedostatku normalne standardizacije rada sa logovima (Azure Monitor još nije ni postojao) olakšala je integraciju eksternog SIEM-a sa Microsoft oblakom. Sada se situacija promijenila i Microsoft preporučuje Azure Event Hub platformu kao glavni alat za integraciju za druge SIEM-ove. Mnogi su već implementirali takvu integraciju, ali budite oprezni - možda neće uhvatiti sve Azure evidencije, već samo neke (pogledajte u dokumentaciji za vaš SIEM).

Završavajući kratak izlet u Azure, želio bih dati opću preporuku o ovoj usluzi u oblaku - prije nego što kažete bilo šta o funkcijama nadzora sigurnosti informacija u Azureu, trebali biste ih vrlo pažljivo konfigurirati i testirati da rade kako je napisano u dokumentaciji i kao što su vam konsultanti rekli iz Microsofta (i oni mogu imati različite poglede na funkcionalnost Azure funkcija). Ako imate finansijska sredstva, možete iz Azurea izvući mnogo korisnih informacija u smislu nadzora sigurnosti informacija. Ako su vaši resursi ograničeni, tada ćete se, kao u slučaju AWS-a, morati osloniti samo na vlastitu snagu i sirove podatke koje vam Azure Monitor pruža. I zapamtite da mnoge funkcije nadzora koštaju novac i bolje je unaprijed se upoznati s politikom cijena. Na primjer, besplatno možete pohraniti 31 dan podataka do maksimalno 5 GB po korisniku - prekoračenje ovih vrijednosti zahtijevat će od vas da izdvojite dodatni novac (približno 2 USD za pohranjivanje svakog dodatnog GB od korisnika i 0,1 USD za pohranjivanje 1 GB svakog dodatnog mjeseca). Rad sa telemetrijom i metrikom aplikacije takođe može zahtevati dodatna sredstva, kao i rad sa upozorenjima i obaveštenjima (besplatno je dostupno određeno ograničenje, što možda neće biti dovoljno za vaše potrebe).

Primjer: Nadgledanje sigurnosti informacija u IaaS-u zasnovano na Google Cloud Platformi

Google Cloud Platform izgleda kao mlađi u poređenju sa AWS-om i Azureom, ali ovo je djelimično dobro. Za razliku od AWS-a, koji je postepeno povećavao svoje mogućnosti, uključujući i sigurnosne, imajući probleme sa centralizacijom; GCP, kao i Azure, se mnogo bolje upravlja centralizirano, što smanjuje greške i vrijeme implementacije u cijelom preduzeću. Sa sigurnosne tačke gledišta, GCP je, začudo, između AWS-a i Azure-a. On također ima jedinstvenu registraciju događaja za cijelu organizaciju, ali je nepotpuna. Neke funkcije su još uvijek u beta modu, ali postepeno ovaj nedostatak treba eliminisati i GCP će postati zrelija platforma u smislu nadzora sigurnosti informacija.

Glavni alat za evidentiranje događaja u GCP-u je Stackdriver Logging (slično Azure Monitoru), koji vam omogućava da prikupljate događaje u cijeloj infrastrukturi oblaka (kao i sa AWS-a). Sa sigurnosne perspektive u GCP-u, svaka organizacija, projekat ili folder ima četiri dnevnika:

• Admin Activity - sadrži sve događaje vezane za administrativni pristup, na primjer, kreiranje virtuelne mašine, promjenu prava pristupa itd. Ovaj dnevnik se uvijek piše, bez obzira na vašu želju, i čuva svoje podatke 400 dana.
• Pristup podacima - sadrži sve događaje vezane za rad sa podacima od strane korisnika oblaka (kreiranje, modifikacija, čitanje, itd.). Podrazumevano, ovaj dnevnik nije zapisan, jer se njegov volumen vrlo brzo povećava. Iz tog razloga, njen rok trajanja je samo 30 dana. Osim toga, nije sve napisano u ovom časopisu. Na primjer, događaji koji se odnose na resurse koji su javno dostupni svim korisnicima ili koji su dostupni bez prijavljivanja na GCP nisu upisani u njega.
• Sistemski događaj - sadrži sistemske događaje koji se ne odnose na korisnike, ili radnje administratora koji mijenja konfiguraciju cloud resursa. Uvijek se piše i čuva 400 dana.
• Transparentnost pristupa je jedinstven primjer dnevnika koji bilježi sve radnje Googleovih zaposlenika (ali ne još za sve GCP usluge) koji pristupaju vašoj infrastrukturi kao dio svojih radnih obaveza. Ovaj dnevnik se čuva 400 dana i nije dostupan svakom GCP klijentu, ali samo ako su ispunjeni određeni uslovi (bilo podrška na Gold ili Platinum nivou, ili prisustvo 4 uloge određenog tipa kao deo korporativne podrške). Slična funkcija je također dostupna, na primjer, u Office 365 - Lockbox.

Primjer dnevnika: Transparentnost pristupa

{
 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"
}

Pristup ovim zapisnicima je moguć na nekoliko načina (približno na isti način kao što je prethodno razmatran Azure i AWS) - preko sučelja Log Viewer, preko API-ja, preko Google Cloud SDK-a ili preko stranice Aktivnosti vašeg projekta za koji ste su zainteresovani za događaje. Na isti način se mogu eksportovati u eksterna rješenja radi dodatne analize. Potonje se radi izvozom dnevnika u BigQuery ili Cloud Pub/Sub skladište.

Uz Stackdriver Logging, GCP platforma nudi i funkciju Stackdriver Monitoring, koja vam omogućava da pratite ključne metrike (performanse, MTBF, ukupno zdravlje, itd.) cloud servisa i aplikacija. Obrađeni i vizualizirani podaci mogu olakšati pronalaženje problema u vašoj infrastrukturi oblaka, uključujući i u kontekstu sigurnosti. Ali treba napomenuti da ova funkcionalnost neće biti previše bogata u kontekstu informacione sigurnosti, budući da GCP danas nema analogni isti AWS GuardDuty i ne može identifikovati loše među svim registrovanim događajima (Google je razvio Event Threat Detection, ali je još uvijek u razvoju u beta verziji i prerano je govoriti o njegovoj korisnosti). Stackdriver Monitoring bi se mogao koristiti kao sistem za otkrivanje anomalija, koje bi se potom istraživale kako bi se pronašli uzroci njihovog nastanka. Ali s obzirom na nedostatak osoblja kvalifikovanog u oblasti GCP informacione bezbednosti na tržištu, ovaj zadatak trenutno izgleda težak.

Također je vrijedno dati listu nekih modula za informacijsku sigurnost koji se mogu koristiti unutar vašeg GCP oblaka, a koji su slični onome što AWS nudi:

• Cloud Security Command Center je analogni AWS Security Hub i Azure Security Center.
• Cloud DLP – Automatsko otkrivanje i uređivanje (npr. maskiranje) podataka koji se nalaze u oblaku koristeći više od 90 unaprijed definiranih pravila klasifikacije.
• Cloud Scanner je skener za poznate ranjivosti (XSS, Flash Injection, nezakrpljene biblioteke, itd.) u App Engine-u, Compute Engine-u i Google Kubernetes-u.
• Cloud IAM - Kontrolirajte pristup svim GCP resursima.
• Cloud Identity - Upravljajte GCP korisničkim nalozima, nalozima uređaja i aplikacija sa jedne konzole.
• Cloud HSM - zaštita kriptografskih ključeva.
• Cloud Key Management Service - upravljanje kriptografskim ključevima u GCP-u.
• Kontrola VPC usluga - Kreirajte siguran perimetar oko vaših GCP resursa kako biste ih zaštitili od curenja.
• Titan sigurnosni ključ - zaštita od krađe identiteta.

Mnogi od ovih modula generiraju sigurnosne događaje koji se mogu poslati u BigQuery skladište za analizu ili izvoz u druge sisteme, uključujući SIEM. Kao što je gore spomenuto, GCP je platforma koja se aktivno razvija i Google sada razvija niz novih modula za sigurnost informacija za svoju platformu. Među njima su Event Threat Detection (sada dostupan u beta verziji), koji skenira Stackdriver dnevnike u potrazi za tragovima neovlaštene aktivnosti (analogno GuardDuty-u u AWS-u) ili Policy Intelligence (dostupan u alfa verziji), koji će vam omogućiti da razvijete inteligentne politike za pristup GCP resursima.

Napravio sam kratak pregled ugrađenih mogućnosti praćenja u popularnim cloud platformama. Ali imate li stručnjake koji su u stanju da rade sa „sirovim“ zapisima IaaS provajdera (nisu svi spremni da kupe napredne mogućnosti AWS-a ili Azurea ili Google-a)? Osim toga, mnogima je poznata izreka „vjeruj, ali provjeri“, koja je istinitija nego ikad u oblasti sigurnosti. Koliko vjerujete ugrađenim mogućnostima provajdera u oblaku koji vam šalje događaje o sigurnosti informacija? Koliko se uopće fokusiraju na sigurnost informacija?

Ponekad je vrijedno pogledati rješenja za praćenje infrastrukture u oblaku koja mogu nadopuniti ugrađenu sigurnost u oblaku, a ponekad su takva rješenja jedina opcija za stjecanje uvida u sigurnost vaših podataka i aplikacija smještenih u oblaku. Osim toga, jednostavno su praktičniji jer preuzimaju sve zadatke analize potrebnih dnevnika koje generiraju različite usluge u oblaku od različitih provajdera u oblaku. Primjer takvog rješenja preklapanja je Cisco Stealthwatch Cloud, koji je fokusiran na jedan zadatak - praćenje anomalija u informacijskoj sigurnosti u cloud okruženjima, uključujući ne samo Amazon AWS, Microsoft Azure i Google Cloud Platform, već i privatne oblake.

Primjer: Nadgledanje sigurnosti informacija pomoću Stealthwatch Clouda

AWS pruža fleksibilnu računarsku platformu, ali ova fleksibilnost olakšava kompanijama da prave greške koje dovode do sigurnosnih problema. A zajednički model sigurnosti informacija tome samo doprinosi. Pokretanje softvera u oblaku sa nepoznatim ranjivostima (sa poznatim se može boriti, na primjer, AWS Inspector ili GCP Cloud Scanner), slabim lozinkama, pogrešnim konfiguracijama, insajderima itd. A sve se to ogleda u ponašanju resursa u oblaku, koje može da prati Cisco Stealthwatch Cloud, koji je sistem za praćenje i detekciju napada na bezbednost informacija. javni i privatni oblaci.

Jedna od ključnih karakteristika Cisco Stealthwatch Cloud-a je mogućnost modeliranja entiteta. Pomoću njega možete kreirati softverski model (tj. simulaciju u skoro realnom vremenu) svakog vašeg resursa u oblaku (nije važno da li je to AWS, Azure, GCP ili nešto drugo). To može uključivati ​​servere i korisnike, kao i tipove resursa specifične za vaše okruženje u oblaku, kao što su sigurnosne grupe i grupe za automatsko skaliranje. Ovi modeli koriste strukturirane tokove podataka koje pružaju usluge u oblaku kao ulaz. Na primjer, za AWS to bi bili VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda i AWS IAM. Modeliranje entiteta automatski otkriva ulogu i ponašanje bilo kojeg vašeg resursa (možete govoriti o profiliranju svih aktivnosti u oblaku). Ove uloge uključuju Android ili Apple mobilni uređaj, Citrix PVS server, RDP server, mail gateway, VoIP klijent, terminal server, kontroler domene itd. Zatim kontinuirano prati njihovo ponašanje kako bi odredio kada se dogodi rizično ili sigurnosno ugrožavajuće ponašanje. Možete identificirati nagađanje lozinke, DDoS napade, curenje podataka, ilegalni daljinski pristup, aktivnost zlonamjernog koda, skeniranje ranjivosti i druge prijetnje. Na primjer, ovako izgleda otkrivanje pokušaja udaljenog pristupa iz zemlje netipične za vašu organizaciju (Južna Koreja) Kubernetes klasteru putem SSH-a:

A ovako izgleda navodno curenje informacija iz Postgress baze podataka u zemlju s kojom se ranije nismo susreli sa interakcijom:

Konačno, ovako izgleda previše neuspjelih pokušaja SSH iz Kine i Indonezije s vanjskog udaljenog uređaja:

Ili, pretpostavimo da instanca servera u VPC-u, prema politici, nikada neće biti odredište za udaljenu prijavu. Pretpostavimo dalje da je ovaj računar doživio udaljenu prijavu zbog pogrešne promjene u politici pravila zaštitnog zida. Funkcija Entity Modeling će otkriti i prijaviti ovu aktivnost („Neobični daljinski pristup“) u skoro realnom vremenu i ukazati na određeni AWS CloudTrail, Azure Monitor ili GCP Stackdriver Logging API poziv (uključujući korisničko ime, datum i vrijeme, između ostalih detalja ). što je dovelo do promjene ITU pravila. I tada se ove informacije mogu poslati SIEM-u na analizu.

Slične mogućnosti su implementirane za bilo koje okruženje u oblaku koje podržava Cisco Stealthwatch Cloud:

Modeliranje entiteta je jedinstveni oblik sigurnosne automatizacije koji može otkriti prethodno nepoznati problem s vašim ljudima, procesima ili tehnologijom. Na primjer, omogućava vam da otkrijete, između ostalog, sigurnosne probleme kao što su:

• Da li je neko otkrio backdoor u softveru koji koristimo?
• Postoji li softver ili uređaj treće strane u našem oblaku?
• Da li ovlašteni korisnik zloupotrebljava privilegije?
• Da li je došlo do greške u konfiguraciji koja je omogućila daljinski pristup ili drugu nenamjernu upotrebu resursa?
• Postoji li curenje podataka sa naših servera?
• Da li se neko pokušavao povezati s nama s netipične geografske lokacije?
• Je li naš oblak zaražen zlonamjernim kodom?

Detektovani događaj sigurnosti informacija može se poslati u obliku odgovarajuće ulaznice u Slack, Cisco Spark, sistem za upravljanje incidentima PagerDuty, a takođe se može poslati raznim SIEM-ovima, uključujući Splunk ili ELK. Da rezimiramo, možemo reći da ako vaša kompanija koristi multi-cloud strategiju i nije ograničena na jednog dobavljača oblaka, mogućnosti nadzora sigurnosti informacija opisane iznad, onda je korištenje Cisco Stealthwatch Clouda dobra opcija za dobivanje objedinjenog skupa nadzora mogućnosti za vodeće igrače u oblaku - Amazon, Microsoft i Google. Najzanimljivije je da ako uporedite cijene za Stealthwatch Cloud sa naprednim licencama za nadzor sigurnosti informacija u AWS, Azure ili GCP, može se pokazati da će Cisco rješenje biti čak jeftinije od ugrađenih mogućnosti Amazona, Microsofta i Google rješenja. Paradoksalno je, ali je istina. I što više oblaka i njihovih mogućnosti koristite, to će očiglednija biti prednost konsolidovanog rješenja.

Osim toga, Stealthwatch Cloud može nadzirati privatne oblake koji su raspoređeni u vašoj organizaciji, na primjer, na osnovu Kubernetes kontejnera ili praćenjem Netflow tokova ili mrežnog prometa primljenog preko preslikavanja u mrežnu opremu (čak i domaće), AD podatke ili DNS servere i tako dalje. Svi ovi podaci će biti obogaćeni informacijama Threat Intelligence koje prikuplja Cisco Talos, najveća svjetska nevladina grupa istraživača prijetnji cyber sigurnosti.

Ovo vam omogućava da implementirate objedinjeni sistem praćenja i za javne i za hibridne oblake koje vaša kompanija može koristiti. Prikupljene informacije se zatim mogu analizirati pomoću ugrađenih mogućnosti Stealthwatch Cloud-a ili poslati na vaš SIEM (Splunk, ELK, SumoLogic i nekoliko drugih su podržani prema zadanim postavkama).

Ovim ćemo zaokružiti prvi dio članka, u kojem sam pregledao ugrađene i eksterne alate za praćenje informacione sigurnosti IaaS/PaaS platformi, koji nam omogućavaju brzo otkrivanje i reagovanje na incidente koji se dešavaju u cloud okruženjima koja naše preduzeće je odabralo. U drugom dijelu ćemo nastaviti temu i razmotriti opcije za praćenje SaaS platformi na primjeru Salesforcea i Dropboxa, a pokušat ćemo sve sumirati i spojiti kreiranjem jedinstvenog sistema za praćenje sigurnosti informacija za različite cloud provajdere.

izvor: www.habr.com