Varnostni nadzor v oblaku

Premikanje podatkov in aplikacij v oblak predstavlja nov izziv za korporativne SOC, ki niso vedno pripravljene spremljati infrastrukture drugih ljudi. Po podatkih Netoskope povprečno podjetje (očitno v ZDA) uporablja 1246 različnih storitev v oblaku, kar je 22 % več kot pred letom dni. 1246 storitev v oblaku!!! Od tega se jih 175 nanaša na kadrovske storitve, 170 na trženje, 110 na področje komuniciranja ter 76 na področje financ in CRM. Cisco uporablja »le« 700 zunanjih storitev v oblaku. Zato sem malo zmeden zaradi teh številk. A v vsakem primeru težava ni v njih, temveč v tem, da oblak začenja precej aktivno uporabljati vse več podjetij, ki bi želela imeti enake zmogljivosti spremljanja oblačne infrastrukture kot v lastnem omrežju. In ta trend narašča – glede na po podatkih ameriške računske zbornice Do leta 2023 bodo v ZDA zaprli 1200 podatkovnih centrov (6250 jih je že zaprtih). Toda prehod v oblak ni samo "premaknimo svoje strežnike k zunanjemu ponudniku." Nova arhitektura IT, nova programska oprema, novi procesi, nove omejitve ... Vse to prinaša pomembne spremembe v delo ne le IT, ampak tudi informacijske varnosti. In če so se ponudniki naučili nekako obvladati zagotavljanje varnosti samega oblaka (na srečo je veliko priporočil), potem pri spremljanju varnosti informacij v oblaku, zlasti na platformah SaaS, obstajajo velike težave, o katerih bomo govorili.

Recimo, da je vaše podjetje del svoje infrastrukture preselilo v oblak ... Stop. Ne na ta način. Če je bila infrastruktura prenesena, vi pa šele zdaj razmišljate, kako jo boste spremljali, potem ste že izgubili. Razen če gre za Amazon, Google ali Microsoft (in potem s pridržki), verjetno ne boste imeli veliko možnosti za spremljanje svojih podatkov in aplikacij. Dobro je, če imate priložnost delati s hlodi. Včasih bodo podatki o varnostnem dogodku na voljo, vendar do njih ne boste imeli dostopa. Na primer Office 365. Če imate najcenejšo licenco E1, potem vam varnostni dogodki sploh niso na voljo. Če imate licenco E3, so vaši podatki shranjeni samo 90 dni, in le, če imate licenco E5, je trajanje dnevnikov na voljo eno leto (vendar ima to tudi svoje nianse, povezane s potrebo po ločenem od Microsoftove podpore zahtevajte številne funkcije za delo z dnevniki). Mimogrede, licenca E3 je glede nadzornih funkcij precej šibkejša od korporativne Exchange. Če želite doseči enako raven, potrebujete licenco E5 ali dodatno licenco Advanced Compliance, ki lahko zahteva dodaten denar, ki ni bil upoštevan v vašem finančnem modelu za prehod na infrastrukturo v oblaku. In to je samo en primer podcenjevanja vprašanj, povezanih z nadzorom varnosti informacij v oblaku. V tem članku želim, ne da bi se pretvarjal, da je popoln, opozoriti na nekatere nianse, ki jih je treba upoštevati pri izbiri ponudnika oblaka z varnostnega vidika. Na koncu članka bo podan kontrolni seznam, ki ga je vredno izpolniti, preden menite, da je vprašanje spremljanja varnosti informacij v oblaku rešeno.

Obstaja več tipičnih težav, ki vodijo do incidentov v oblačnih okoljih, na katere se informacijskovarnostne službe nimajo časa odzvati ali pa jih sploh ne vidijo:

• Varnostni dnevniki ne obstajajo. To je dokaj pogosta situacija, zlasti med začetniki na trgu rešitev v oblaku. Vendar se jim ne smete takoj odpovedati. Mali igralci, zlasti domači, so bolj občutljivi na zahteve kupcev in lahko hitro implementirajo nekatere zahtevane funkcije s spremembo potrjenega načrta za svoje izdelke. Da, to ne bo analog GuardDuty iz Amazona ali modula »Proaktivna zaščita« iz Bitrixa, ampak vsaj nekaj.
• Informacijska varnost ne ve, kje so dnevniki shranjeni ali pa do njih ni dostopa. Tukaj je treba začeti pogajanja s ponudnikom storitev v oblaku - morda bo posredoval takšne informacije, če se mu zdi stranka pomembna. Toda na splošno ni dobro, če je dostop do dnevnikov zagotovljen »s posebno odločbo«.
• Zgodi se tudi, da ima ponudnik oblaka dnevnike, vendar zagotavlja omejeno spremljanje in beleženje dogodkov, ki ne zadoščata za odkrivanje vseh incidentov. Na primer, lahko prejmete samo dnevnike sprememb na spletnem mestu ali dnevnike poskusov avtentikacije uporabnikov, ne pa tudi drugih dogodkov, na primer o omrežnem prometu, kar bo pred vami skrilo celo plast dogodkov, ki označujejo poskuse vdora v vašo infrastrukturo v oblaku. .
• Obstajajo dnevniki, vendar je dostop do njih težko avtomatizirati, zaradi česar jih je treba spremljati ne stalno, ampak po urniku. In če dnevnikov ne morete prenesti samodejno, potem lahko nalaganje dnevnikov, na primer v formatu Excel (kot pri številnih domačih ponudnikih rešitev v oblaku), povzroči celo nepripravljenost službe za informacijsko varnost podjetja, da bi se poigravala z njimi.
• Brez spremljanja dnevnika. To je morda najbolj nejasen razlog za pojav incidentov informacijske varnosti v oblačnih okoljih. Zdi se, da obstajajo dnevniki in je mogoče avtomatizirati dostop do njih, vendar tega nihče ne počne. Zakaj?

Koncept skupne varnosti v oblaku

Prehod v oblak je vedno iskanje ravnotežja med željo po ohranitvi nadzora nad infrastrukturo in prenosom v bolj strokovne roke ponudnika oblaka, ki je specializiran za njeno vzdrževanje. In na področju varnosti v oblaku je treba iskati tudi to ravnotežje. Poleg tega bo to ravnotežje ves čas drugačno, odvisno od uporabljenega modela dostave storitev v oblaku (IaaS, PaaS, SaaS). Vsekakor pa ne smemo pozabiti, da danes vsi ponudniki oblakov sledijo tako imenovanemu modelu deljene odgovornosti in deljene informacijske varnosti. Za nekatere stvari je odgovoren oblak, za druge pa odjemalec, ki svoje podatke, svoje aplikacije, svoje virtualne stroje in druge vire postavi v oblak. Nepremišljeno bi bilo pričakovati, da bomo z odhodom v oblak vso odgovornost prevalili na ponudnika. Vendar tudi ni pametno, da sami zgradite vso varnost pri prehodu v oblak. Zahtevano je ravnotežje, ki bo odvisno od številnih dejavnikov: - strategije obvladovanja tveganj, modela groženj, varnostnih mehanizmov, ki so na voljo ponudniku oblaka, zakonodaje itd.

Na primer, klasifikacija podatkov, ki gostujejo v oblaku, je vedno odgovornost stranke. Ponudnik oblaka ali zunanji ponudnik storitev mu lahko pomaga le z orodji, ki bodo pomagala označiti podatke v oblaku, prepoznati kršitve, izbrisati podatke, ki kršijo zakonodajo, ali jih prikriti na tak ali drugačen način. Po drugi strani pa je fizična varnost vedno odgovornost ponudnika oblaka, ki je ne more deliti z odjemalci. Toda vse, kar je med podatki in fizično infrastrukturo, je ravno predmet razprave v tem članku. Za razpoložljivost oblaka je na primer odgovoren ponudnik, za nastavitev pravil požarnega zidu ali omogočanje šifriranja pa je odgovoren odjemalec. V tem članku bomo poskušali pogledati, katere mehanizme za spremljanje varnosti informacij danes ponujajo različni priljubljeni ponudniki oblakov v Rusiji, kakšne so značilnosti njihove uporabe in kdaj se je vredno osredotočiti na zunanje prekrivne rešitve (na primer Cisco E- mail Security), ki širijo zmogljivosti vašega oblaka v smislu kibernetske varnosti. V nekaterih primerih, zlasti če sledite strategiji več oblakov, vam ne bo preostalo drugega, kot da uporabite zunanje rešitve za spremljanje varnosti informacij v več oblačnih okoljih hkrati (na primer Cisco CloudLock ali Cisco Stealthwatch Cloud). No, v nekaterih primerih boste spoznali, da ponudnik oblaka, ki ste ga izbrali (ali vam ga vsilili), sploh ne ponuja nobenih zmogljivosti za spremljanje varnosti informacij. To je neprijetno, a tudi ne malo, saj vam omogoča ustrezno oceno stopnje tveganja, povezanega z delom s tem oblakom.

Življenjski cikel spremljanja varnosti v oblaku

Za spremljanje varnosti oblakov, ki jih uporabljate, imate samo tri možnosti:

• zanašajte se na orodja, ki jih ponuja vaš ponudnik oblaka,
• uporabite rešitve tretjih oseb, ki bodo spremljale platforme IaaS, PaaS ali SaaS, ki jih uporabljate,
• zgradite lastno infrastrukturo za spremljanje oblaka (samo za platforme IaaS/PaaS).

Poglejmo, katere funkcije ima vsaka od teh možnosti. Najprej pa moramo razumeti splošni okvir, ki se bo uporabljal pri spremljanju platform v oblaku. Izpostavil bi 6 glavnih komponent procesa spremljanja informacijske varnosti v oblaku:

• Priprava infrastrukture. Določitev potrebnih aplikacij in infrastrukture za zbiranje dogodkov pomembnih za informacijsko varnost v hrambo.
• Zbirka. Na tej stopnji so varnostni dogodki združeni iz različnih virov za kasnejši prenos za obdelavo, shranjevanje in analizo.
• Zdravljenje. Na tej stopnji se podatki preoblikujejo in obogatijo za lažjo nadaljnjo analizo.
• Shranjevanje. Ta komponenta je odgovorna za kratkoročno in dolgoročno shranjevanje zbranih obdelanih in neobdelanih podatkov.
• Analiza. Na tej stopnji imate možnost zaznati incidente in se nanje odzvati samodejno ali ročno.
• Poročanje. Ta stopnja pomaga oblikovati ključne kazalnike za deležnike (vodstvo, revizorje, ponudnika oblaka, naročnike itd.), ki nam pomagajo pri sprejemanju določenih odločitev, na primer pri menjavi ponudnika ali krepitvi informacijske varnosti.

Razumevanje teh komponent vam bo omogočilo, da se boste v prihodnosti hitro odločili, kaj lahko vzamete od ponudnika in kaj boste morali storiti sami ali z vključitvijo zunanjih svetovalcev.

Vgrajene storitve v oblaku

Zgoraj sem že zapisal, da številne storitve v oblaku danes ne zagotavljajo nobenih zmožnosti spremljanja varnosti informacij. Na splošno temi informacijske varnosti ne posvečajo veliko pozornosti. Na primer, ena od priljubljenih ruskih storitev za pošiljanje poročil vladnim agencijam prek interneta (ne bom posebej omenjal njenega imena). Celotno poglavje o varnosti te storitve se vrti okoli uporabe certificiranega CIPF. Informacijsko varnostni del druge domače storitve v oblaku za upravljanje elektronskih dokumentov ni nič drugačen. Govori o potrdilih javnih ključev, certificirani kriptografiji, odpravljanju spletnih ranljivosti, zaščiti pred napadi DDoS, uporabi požarnih zidov, varnostnih kopijah in celo rednih revizijah varnosti informacij. Niti besede pa ni o spremljanju, niti o možnostih dostopa do informacijsko varnostnih dogodkov, ki bi lahko bili zanimivi za stranke tega ponudnika storitev.

Na splošno lahko iz tega, kako ponudnik oblaka na svojem spletnem mestu in v svoji dokumentaciji opisuje vprašanja informacijske varnosti, lahko razumete, kako resno jemlje to vprašanje. Na primer, če berete priročnike za izdelke »Moja pisarna«, o varnosti sploh ni besede, v dokumentaciji za ločen izdelek »Moja pisarna. KS3«, ki je namenjen zaščiti pred nepooblaščenim dostopom, obstaja običajen seznam točk 17. reda FSTEC, ki jih izvaja »Moja pisarna.KS3«, ni pa opisano, kako jih izvaja in, kar je najpomembnejše, kako integrirati te mehanizme s korporativno informacijsko varnostjo. Morda takšna dokumentacija obstaja, vendar je nisem našel v javni domeni, na spletni strani »Moja pisarna«. Čeprav morda preprosto nimam dostopa do teh tajnih podatkov?..

Za Bitrix je situacija veliko boljša. V dokumentaciji so opisani formati dnevnikov dogodkov in, zanimivo, dnevnik vdorov, ki vsebuje dogodke, povezane s potencialnimi grožnjami oblačni platformi. Od tam lahko izvlečete IP, ime uporabnika ali gosta, vir dogodka, čas, uporabniškega agenta, vrsto dogodka itd. Res je, s temi dogodki lahko delate bodisi z nadzorne plošče samega oblaka ali naložite podatke v formatu MS Excel. Zdaj je težko avtomatizirati delo z dnevniki Bitrix in boste morali nekaj dela opraviti ročno (naložiti poročilo in ga naložiti v svoj SIEM). A če se spomnimo, da do relativno nedavnega takšne priložnosti ni bilo, potem je to velik napredek. Hkrati bi rad opozoril, da številni tuji ponudniki oblakov ponujajo podobno funkcionalnost "za začetnike" - bodisi si oglejte dnevnike z očmi skozi nadzorno ploščo ali naložite podatke k sebi (vendar večina naloži podatke v . format csv, ne Excel).

Brez upoštevanja možnosti brez zapisovanja vam ponudniki oblakov običajno ponudijo tri možnosti za spremljanje varnostnih dogodkov – nadzorne plošče, nalaganje podatkov in dostop do API-ja. Zdi se, da vam prvi reši veliko težav, vendar to ni povsem res - če imate več revij, morate preklapljati med zasloni, ki jih prikazujejo, s čimer izgubite celotno sliko. Poleg tega vam ponudnik oblaka verjetno ne bo ponudil možnosti korelacije varnostnih dogodkov in njihove splošne analize z varnostnega vidika (običajno imate opravka z neobdelanimi podatki, ki jih morate razumeti sami). Obstajajo izjeme in o njih bomo še govorili. Nazadnje se je vredno vprašati, katere dogodke beleži vaš ponudnik oblaka, v kakšni obliki in kako ustrezajo vašemu procesu spremljanja varnosti informacij? Na primer identifikacija in avtentikacija uporabnikov in gostov. Isti Bitrix vam omogoča, da na podlagi teh dogodkov zabeležite datum in čas dogodka, ime uporabnika ali gosta (če imate modul »Spletna analitika«), objekt, do katerega dostopate, in druge elemente, značilne za spletno stran. . Toda službe za varnost informacij podjetja morda potrebujejo informacije o tem, ali je uporabnik dostopal do oblaka iz zaupanja vredne naprave (na primer, v omrežju podjetja to nalogo izvaja Cisco ISE). Kaj pa tako preprosto opravilo, kot je funkcija geo-IP, ki bo pomagala ugotoviti, ali je bil uporabniški račun storitve v oblaku ukraden? In tudi če vam to zagotovi ponudnik oblaka, to ni dovolj. Isti Cisco CloudLock ne analizira samo geolokacije, ampak za to uporablja strojno učenje in analizira zgodovinske podatke za vsakega uporabnika ter spremlja različne anomalije pri poskusih identifikacije in avtentikacije. Samo MS Azure ima podobno funkcionalnost (če imate ustrezno naročnino).

Obstaja še ena težava - ker je za mnoge ponudnike oblakov nadzor informacijske varnosti nova tema, s katero se šele začenjajo ukvarjati, nenehno nekaj spreminjajo v svojih rešitvah. Danes imajo eno različico API-ja, jutri drugo, pojutrišnjem tretjo. Tudi na to morate biti pripravljeni. Enako je s funkcionalnostjo, ki se lahko spremeni, kar morate upoštevati v svojem sistemu nadzora informacijske varnosti. Na primer, Amazon je imel sprva ločeni storitvi za spremljanje dogodkov v oblaku – AWS CloudTrail in AWS CloudWatch. Nato se je pojavila ločena storitev za spremljanje dogodkov informacijske varnosti - AWS GuardDuty. Čez nekaj časa je Amazon lansiral nov sistem upravljanja, Amazon Security Hub, ki vključuje analizo podatkov, prejetih od GuardDuty, Amazon Inspector, Amazon Macie in več drugih. Drug primer je orodje za integracijo dnevnika Azure s SIEM - AzLog. Aktivno so ga uporabljali številni ponudniki SIEM, dokler leta 2018 Microsoft ni napovedal prenehanja njegovega razvoja in podpore, kar je veliko strank, ki so uporabljale to orodje, soočilo s težavo (o tem, kako je bila odpravljena, bomo govorili kasneje).

Zato skrbno spremljajte vse funkcije spremljanja, ki vam jih ponuja vaš ponudnik oblaka. Ali pa se zanesite na zunanje ponudnike rešitev, ki bodo delovali kot posredniki med vašim SOC in oblakom, ki ga želite spremljati. Da, dražje bo (čeprav ne vedno), vendar boste vso odgovornost preložili na ramena nekoga drugega. Ali ne vse?.. Spomnimo se koncepta skupne varnosti in razumemo, da ne moremo ničesar premakniti - morali bomo neodvisno razumeti, kako različni ponudniki oblakov zagotavljajo spremljanje informacijske varnosti vaših podatkov, aplikacij, virtualnih strojev in drugih virov gostuje v oblaku. In začeli bomo s tem, kar ponuja Amazon v tem delu.

Primer: Nadzor informacijske varnosti v IaaS, ki temelji na AWS

Da, da, razumem, da Amazon ni najboljši primer, ker je to ameriška storitev in jo je mogoče blokirati v okviru boja proti ekstremizmu in širjenju informacij, ki so v Rusiji prepovedane. Toda v tej publikaciji bi rad samo pokazal, kako se različne oblačne platforme razlikujejo v svojih zmožnostih nadzora informacijske varnosti in na kaj morate biti pozorni pri prenosu ključnih procesov v oblake z varnostnega vidika. No, če se bodo nekateri ruski razvijalci rešitev v oblaku naučili kaj koristnega zase, potem bo to super.

Najprej je treba povedati, da Amazonka ni nepremagljiva trdnjava. Njegovim strankam se redno dogajajo različni incidenti. Iz Deep Root Analytics so na primer ukradli imena, naslove, datume rojstva in telefonske številke 198 milijonov volivcev. Izraelsko podjetje Nice Systems je ukradlo 14 milijonov zapisov o naročnikih Verizona. Vendar pa vam vgrajene zmogljivosti AWS omogočajo zaznavanje širokega nabora incidentov. Na primer:

• vpliv na infrastrukturo (DDoS)
• kompromis vozlišča (injekcija ukaza)
• ogrožanje računa in nepooblaščen dostop
• nepravilna konfiguracija in ranljivosti
• nevarni vmesniki in API-ji.

To neskladje je posledica dejstva, da je, kot smo ugotovili zgoraj, stranka sama odgovorna za varnost svojih podatkov. In če se ni potrudil vklopiti zaščitnih mehanizmov in ni vklopil nadzornih orodij, potem bo o incidentu izvedel le iz medijev ali od svojih strank.

Za prepoznavanje incidentov lahko uporabite široko paleto različnih storitev spremljanja, ki jih je razvil Amazon (čeprav jih pogosto dopolnjujejo zunanja orodja, kot je osquery). V AWS se torej spremljajo vsa uporabniška dejanja, ne glede na to, kako se izvajajo - prek upravljalne konzole, ukazne vrstice, SDK ali drugih storitev AWS. Vsi zapisi o dejavnosti vsakega računa AWS (vključno z uporabniškim imenom, dejanjem, storitvijo, parametri dejavnosti in rezultatom) in uporabi API-ja so na voljo prek AWS CloudTrail. Te dogodke (kot so prijave v konzolo AWS IAM) si lahko ogledate s konzole CloudTrail, jih analizirate z uporabo Amazon Athena ali jih »oddajate« zunanjim rešitvam, kot so Splunk, AlienVault itd. Sami dnevniki AWS CloudTrail so nameščeni v vašem vedru AWS S3.

Dve drugi storitvi AWS ponujata številne druge pomembne zmožnosti spremljanja. Prvič, Amazon CloudWatch je storitev spremljanja virov in aplikacij AWS, ki vam med drugim omogoča prepoznavanje različnih nepravilnosti v vašem oblaku. Vse vgrajene storitve AWS, kot so Amazon Elastic Compute Cloud (strežniki), Amazon Relational Database Service (baze podatkov), Amazon Elastic MapReduce (analiza podatkov) in 30 drugih storitev Amazon, uporabljajo Amazon CloudWatch za shranjevanje svojih dnevnikov. Razvijalci lahko uporabljajo odprti API iz Amazon CloudWatch, da dodajo funkcijo spremljanja dnevnika aplikacijam in storitvam po meri, kar jim omogoča razširitev obsega analize dogodkov v varnostnem kontekstu.

Drugič, storitev VPC Flow Logs vam omogoča analizo omrežnega prometa, ki ga pošljejo ali prejmejo vaši strežniki AWS (zunanji ali notranji), kot tudi med mikrostoritvami. Ko kateri koli od vaših virov AWS VPC komunicira z omrežjem, VPC Flow Logs beleži podrobnosti o omrežnem prometu, vključno z izvornim in ciljnim omrežnim vmesnikom ter naslovi IP, vrati, protokolom, številom bajtov in številom paketov, ki jih videl. Tisti, ki imajo izkušnje z varnostjo lokalnega omrežja, bodo to prepoznali kot analogno nitim NetFlow, ki ga lahko ustvarijo stikala, usmerjevalniki in požarni zidovi poslovnega razreda. Ti dnevniki so pomembni za namene nadzora informacijske varnosti, saj za razliko od dogodkov o dejanjih uporabnikov in aplikacij omogočajo tudi, da ne zamudite omrežnih interakcij v okolju virtualnega zasebnega oblaka AWS.

Če povzamemo, te tri storitve AWS – AWS CloudTrail, Amazon CloudWatch in VPC Flow Logs – skupaj zagotavljajo precej močan vpogled v uporabo vašega računa, vedenje uporabnikov, upravljanje infrastrukture, dejavnost aplikacij in storitev ter omrežno dejavnost. Uporabljajo se lahko na primer za odkrivanje naslednjih anomalij:

• Poskusi skeniranja spletnega mesta, iskanje stranskih vrat, iskanje ranljivosti prek izbruhov »404 napak«.
• Napadi z vbrizgavanjem (na primer vbrizgavanje SQL) prek izbruhov »500 napak«.
• Znana orodja za napad so sqlmap, nikto, w3af, nmap itd. z analizo polja uporabniškega agenta.

Amazon Web Services je razvil tudi druge storitve za namene kibernetske varnosti, ki vam omogočajo reševanje številnih drugih težav. AWS ima na primer vgrajeno storitev za nadzor politik in konfiguracij – AWS Config. Ta storitev zagotavlja stalno revizijo vaših virov AWS in njihovih konfiguracij. Vzemimo preprost primer: Recimo, da se želite prepričati, da so uporabniška gesla onemogočena na vseh vaših strežnikih in da je dostop možen samo na podlagi certifikatov. AWS Config olajša preverjanje tega za vse vaše strežnike. Obstajajo še drugi pravilniki, ki jih je mogoče uporabiti za vaše strežnike v oblaku: »Noben strežnik ne more uporabljati vrat 22«, »Samo skrbniki lahko spremenijo pravila požarnega zidu« ali »Samo uporabnik Ivashko lahko ustvari nove uporabniške račune in lahko to stori samo ob torkih. " Poleti 2016 je bila storitev AWS Config razširjena za avtomatizirano odkrivanje kršitev razvitih politik. Konfiguracijska pravila AWS so v bistvu neprekinjene konfiguracijske zahteve za storitve Amazon, ki jih uporabljate, ki ustvarjajo dogodke, če so kršeni ustrezni pravilniki. Na primer, namesto rednega izvajanja poizvedb AWS Config za preverjanje, ali so vsi diski na virtualnem strežniku šifrirani, lahko uporabite pravila AWS Config Rules za stalno preverjanje diskov strežnika, da zagotovite, da je ta pogoj izpolnjen. In kar je najpomembneje, v kontekstu te publikacije vse kršitve ustvarjajo dogodke, ki jih lahko analizira vaša služba za informacijsko varnost.

AWS ima tudi svoj ekvivalent tradicionalnim rešitvam za varnost informacij podjetja, ki prav tako ustvarjajo varnostne dogodke, ki jih lahko in morate analizirati:

• Zaznavanje vdorov - AWS GuardDuty
• Nadzor uhajanja informacij - AWS Macie
• EDR (čeprav malo nenavadno govori o končnih točkah v oblaku) - AWS Cloudwatch + odprtokodne rešitve osquery ali GRR
• Analiza Netflow - AWS Cloudwatch + AWS VPC Flow
• Analiza DNS - AWS Cloudwatch + AWS Route53
• AD - Imeniška storitev AWS
• Upravljanje računov - AWS IAM
• SSO – AWS SSO
• varnostna analiza - AWS Inspector
• upravljanje konfiguracije - AWS Config
• WAF - AWS WAF.

Ne bom podrobno opisoval vseh Amazonovih storitev, ki bi lahko bile uporabne v kontekstu informacijske varnosti. Glavna stvar je razumeti, da lahko vsi ustvarijo dogodke, ki jih lahko in moramo analizirati v kontekstu informacijske varnosti, pri čemer v ta namen uporabimo tako vgrajene zmogljivosti samega Amazona kot zunanje rešitve, na primer SIEM, ki lahko prenesite varnostne dogodke v svoj nadzorni center in jih tam analizirajte skupaj z dogodki iz drugih storitev v oblaku ali iz notranje infrastrukture, perimetra ali mobilnih naprav.

V vsakem primeru se vse začne pri virih podatkov, ki vam zagotavljajo dogodke informacijske varnosti. Ti viri vključujejo, vendar niso omejeni na:

• CloudTrail – uporaba API-ja in uporabniška dejanja
• Zaupanja vreden svetovalec - varnostno preverjanje glede na najboljše prakse
• Config - popis in konfiguracija računov in nastavitev storitev
• VPC Flow Logs - povezave z virtualnimi vmesniki
• IAM - storitev identifikacije in avtentikacije
• Dnevniki dostopa do ELB – Izravnalnik obremenitve
• Inspector - ranljivosti aplikacije
• S3 - shranjevanje datotek
• CloudWatch – Dejavnost aplikacije
• SNS je storitev obveščanja.

Čeprav Amazon ponuja tolikšen nabor virov dogodkov in orodij za njihovo generiranje, je zelo omejen v svojih zmožnostih analiziranja zbranih podatkov v kontekstu informacijske varnosti. Samostojno boste morali preučiti razpoložljive dnevnike in v njih poiskati ustrezne indikatorje ogroženosti. Varnostno središče AWS, ki ga je Amazon nedavno predstavil, želi rešiti to težavo tako, da postane oblak SIEM za AWS. Toda zaenkrat je šele na začetku svoje poti in je omejen tako s številom virov, s katerimi deluje, kot z drugimi omejitvami, ki jih določajo arhitektura in naročnine samega Amazona.

Primer: Nadzor informacijske varnosti v IaaS, ki temelji na Azure

Nočem se spuščati v dolgo debato o tem, kateri od treh ponudnikov oblakov (Amazon, Microsoft ali Google) je boljši (še posebej, ker ima vsak še vedno svoje specifičnosti in je primeren za reševanje svojih težav); Osredotočimo se na zmožnosti nadzora informacijske varnosti, ki jih zagotavljajo ti igralci. Priznati je treba, da je bil Amazon AWS eden prvih v tem segmentu in je zato najbolj napredoval pri funkcijah informacijske varnosti (čeprav mnogi priznavajo, da so te težke za uporabo). Vendar to ne pomeni, da bomo zanemarili priložnosti, ki nam jih ponujata Microsoft in Google.

Microsoftove izdelke že od nekdaj odlikuje »odprtost« in v Azure je situacija podobna. Na primer, če AWS in GCP vedno izhajata iz koncepta »kar ni dovoljeno, je prepovedano«, ima Azure ravno nasprotni pristop. Na primer, ko ustvarjate virtualno omrežje v oblaku in virtualni stroj v njem, so vsa vrata in protokoli odprti in privzeto dovoljeni. Zato boste morali porabiti malo več truda za začetno nastavitev sistema za nadzor dostopa v oblaku od Microsofta. To pa vam nalaga tudi strožje zahteve glede spremljanja dejavnosti v oblaku Azure.

AWS ima posebnost, povezano z dejstvom, da ko spremljate svoje virtualne vire, če se nahajajo v različnih regijah, potem imate težave pri združevanju vseh dogodkov in njihovi enotni analizi, za odpravo katere se morate zateči k raznim trikom, kot je npr. Ustvarite lastno kodo za AWS Lambda, ki bo prenašala dogodke med regijami. Azure nima te težave – njegov mehanizem dnevnika dejavnosti sledi vsem dejavnostim v celotni organizaciji brez omejitev. Enako velja za AWS Security Hub, ki ga je pred kratkim razvil Amazon za združitev številnih varnostnih funkcij v enem samem varnostnem centru, vendar le znotraj svoje regije, ki pa ni pomembna za Rusijo. Azure ima svoj varnostni center, ki ni vezan na regionalne omejitve in omogoča dostop do vseh varnostnih funkcij platforme v oblaku. Poleg tega lahko za različne lokalne ekipe zagotovi lasten niz zaščitnih zmogljivosti, vključno z varnostnimi dogodki, ki jih upravljajo. AWS Security Hub je še vedno na poti, da postane podoben Azure Security Center. Vendar je vredno dodati muho v mazilo - iz Azure lahko iztisnete veliko tega, kar je bilo prej opisano v AWS, vendar je to najbolj priročno samo za Azure AD, Azure Monitor in Azure Security Center. Vsi drugi varnostni mehanizmi Azure, vključno z analizo varnostnih dogodkov, še niso upravljani na najprimernejši način. Težavo delno reši API, ki prežema vse storitve Microsoft Azure, vendar bo to od vas zahtevalo dodatne napore pri integraciji vašega oblaka v vaš SOC in prisotnost kvalificiranih strokovnjakov (pravzaprav kot pri katerem koli drugem SIEM, ki deluje z oblakom API-ji). Nekateri SIEM-ji, o katerih bomo razpravljali kasneje, že podpirajo Azure in lahko avtomatizirajo nalogo njegovega spremljanja, vendar ima tudi svoje težave - vsi ne morejo zbrati vseh dnevnikov, ki jih ima Azure.

Zbiranje in spremljanje dogodkov v Azure je zagotovljeno s storitvijo Azure Monitor, ki je glavno orodje za zbiranje, shranjevanje in analiziranje podatkov v Microsoftovem oblaku in njegovih virih – Git repozitoriji, vsebniki, virtualni stroji, aplikacije itd. Vsi podatki, ki jih zbira Azure Monitor, so razdeljeni v dve kategoriji – meritve, zbrane v realnem času in opisujejo ključne kazalnike uspešnosti oblaka Azure, in dnevniki, ki vsebujejo podatke, organizirane v zapise, ki označujejo določene vidike dejavnosti virov in storitev Azure. Poleg tega lahko z API-jem Data Collector storitev Azure Monitor zbira podatke iz katerega koli vira REST za izdelavo lastnih scenarijev spremljanja.

Tukaj je nekaj virov varnostnih dogodkov, ki vam jih ponuja Azure in do katerih lahko dostopate prek API-ja Azure Portal, CLI, PowerShell ali REST (do nekaterih pa samo prek API-ja Azure Monitor/Insight):

• Dnevniki dejavnosti - ta dnevnik odgovarja na klasična vprašanja »kdo«, »kaj« in »kdaj« v zvezi s katero koli operacijo zapisovanja (PUT, POST, DELETE) v vire v oblaku. Dogodki, povezani z dostopom za branje (GET), niso vključeni v ta dnevnik, kot številni drugi.
• Diagnostični dnevniki - vsebujejo podatke o operacijah z določenim virom, vključenim v vašo naročnino.
• Poročanje Azure AD – vsebuje dejavnost uporabnikov in sistemsko dejavnost, povezano z upravljanjem skupin in uporabnikov.
• Dnevnik dogodkov Windows in sistemski dnevnik Linuxa - vsebuje dogodke iz virtualnih strojev, ki gostujejo v oblaku.
• Meritve – vsebuje telemetrijo o delovanju in zdravstvenem stanju vaših storitev in virov v oblaku. Merjeno vsako minuto in shranjeno. v roku 30 dni.
• Dnevniki poteka skupine za varnost omrežja - vsebuje podatke o varnostnih dogodkih v omrežju, zbrane s storitvijo Network Watcher in spremljanjem virov na ravni omrežja.
• Dnevniki shranjevanja - vsebujejo dogodke, povezane z dostopom do prostorov za shranjevanje.

Za spremljanje lahko uporabite zunanje SIEM-e ali vgrajeni monitor Azure in njegove razširitve. O sistemih za upravljanje dogodkov v zvezi z informacijsko varnostjo bomo govorili kasneje, zdaj pa poglejmo, kaj nam Azure sam ponuja za analizo podatkov v kontekstu varnosti. Glavni zaslon za vse, kar je v Azure Monitorju povezano z varnostjo, je varnostna in revizijska nadzorna plošča Log Analytics (brezplačna različica podpira omejeno količino shranjevanja dogodkov za samo en teden). Ta nadzorna plošča je razdeljena na 5 glavnih področij, ki prikazujejo povzetek statistike dogajanja v okolju oblaka, ki ga uporabljate:

• Varnostne domene - ključni kvantitativni indikatorji, povezani z informacijsko varnostjo - število incidentov, število ogroženih vozlišč, nezakrpanih vozlišč, varnostni dogodki omrežja itd.
• Pomembne težave - prikaže število in pomembnost aktivnih težav z varnostjo informacij
• Zaznavanja - prikazuje vzorce napadov, uporabljenih proti vam
• Obveščanje o grožnjah - prikazuje geografske podatke o zunanjih vozliščih, ki vas napadajo
• Pogoste varnostne poizvedbe - tipične poizvedbe, ki vam bodo pomagale bolje spremljati vašo informacijsko varnost.

Razširitve Azure Monitor vključujejo Azure Key Vault (zaščita kriptografskih ključev v oblaku), Malware Assessment (analiza zaščite pred zlonamerno kodo na virtualnih strojih), Azure Application Gateway Analytics (analiza, med drugim, dnevnikov požarnega zidu v oblaku) itd. . Ta orodja, obogatena z določenimi pravili za obdelavo dogodkov, omogočajo vizualizacijo različnih vidikov delovanja storitev v oblaku, vključno z varnostjo, in prepoznavanje določenih odstopanj od delovanja. Toda, kot se pogosto zgodi, vsaka dodatna funkcionalnost zahteva ustrezno plačano naročnino, kar bo od vas zahtevalo ustrezne finančne naložbe, ki jih morate načrtovati vnaprej.

Azure ima številne vgrajene zmožnosti za spremljanje groženj, ki so integrirane v Azure AD, Azure Monitor in Azure Security Center. Med njimi je na primer odkrivanje interakcije virtualnih strojev z znanimi zlonamernimi IP-ji (zaradi prisotnosti integracije z Microsoftovimi storitvami Threat Intelligence), odkrivanje zlonamerne programske opreme v infrastrukturi oblaka s prejemanjem alarmov od virtualnih strojev, ki gostujejo v oblaku, geslo napadi ugibanja ” na virtualne stroje, ranljivosti v konfiguraciji sistema za identifikacijo uporabnikov, prijava v sistem iz anonimizatorjev ali okuženih vozlišč, uhajanje računov, prijava v sistem z neobičajnih lokacij itd. Azure je danes eden redkih ponudnikov oblakov, ki vam ponuja vgrajene zmožnosti obveščanja o grožnjah za obogatitev zbranih informacijskih varnostnih dogodkov.

Kot že omenjeno, varnostna funkcionalnost in posledično varnostni dogodki, ki jih generira, niso na voljo vsem uporabnikom enako, ampak zahtevajo določeno naročnino, ki vključuje želeno funkcionalnost, ki generira ustrezne dogodke za nadzor informacijske varnosti. Na primer, nekatere funkcije, opisane v prejšnjem odstavku za spremljanje nepravilnosti v računih, so na voljo samo v premium licenci P2 za storitev Azure AD. Brez tega boste morali, tako kot v primeru AWS, zbrane varnostne dogodke analizirati »ročno«. Poleg tega, odvisno od vrste licence Azure AD, vsi dogodki ne bodo na voljo za analizo.

Na portalu Azure lahko upravljate iskalne poizvedbe za dnevnike, ki vas zanimajo, in nastavite nadzorne plošče za vizualizacijo ključnih indikatorjev varnosti informacij. Poleg tega lahko tam izberete razširitve Azure Monitor, ki vam omogočajo razširitev funkcionalnosti dnevnikov Azure Monitor in pridobitev globlje analize dogodkov z varnostnega vidika.

Če ne potrebujete samo zmožnosti dela z dnevniki, temveč celovito varnostno središče za svojo platformo v oblaku Azure, vključno z upravljanjem politik varnosti informacij, potem lahko govorite o potrebi po delu z varnostnim centrom Azure, katerega večina uporabnih funkcij so na voljo za nekaj denarja, na primer odkrivanje groženj, spremljanje zunaj Azure, ocena skladnosti itd. (v brezplačni različici imate dostop le do varnostne ocene in priporočil za odpravo ugotovljenih težav). Združuje vsa varnostna vprašanja na enem mestu. Pravzaprav lahko govorimo o višji ravni informacijske varnosti, kot vam jo zagotavlja Azure Monitor, saj so v tem primeru podatki, zbrani v vaši tovarni oblakov, obogateni s številnimi viri, kot so Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) in Microsoft Security Response Center (MSRC), na katerih so nadgrajeni različni sofisticirani algoritmi strojnega učenja in vedenjske analitike, ki naj bi na koncu izboljšali učinkovitost odkrivanja in odzivanja na grožnje. .

Azure ima tudi svoj SIEM - pojavil se je v začetku leta 2019. To je Azure Sentinel, ki temelji na podatkih iz Azure Monitor in se lahko tudi integrira z. zunanje varnostne rešitve (na primer NGFW ali WAF), katerih seznam se nenehno povečuje. Poleg tega imate z integracijo varnostnega API-ja Microsoft Graph možnost povezati lastne vire Threat Intelligence s Sentinelom, kar obogati zmožnosti za analizo incidentov v vašem oblaku Azure. Lahko trdimo, da je Azure Sentinel prvi "domači" SIEM, ki se je pojavil pri ponudnikih oblakov (isti Splunk ali ELK, ki jih je mogoče gostiti v oblaku, na primer AWS, še vedno niso razvili tradicionalni ponudniki storitev v oblaku). Azure Sentinel in Security Center bi lahko imenovali SOC za oblak Azure in bi bili lahko omejeni nanje (z določenimi zadržki), če ne bi imeli več nobene infrastrukture in bi vse svoje računalniške vire prenesli v oblak in bi bil to Microsoftov oblak Azure.

A ker vgrajene zmogljivosti Azure (tudi če imate naročnino na Sentinel) pogosto ne zadoščajo za namene spremljanja informacijske varnosti in integracije tega procesa z drugimi viri varnostnih dogodkov (tako v oblaku kot internih), obstaja potrebo po izvozu zbranih podatkov v zunanje sisteme, ki lahko vključujejo SIEM. To poteka tako z uporabo API-ja kot tudi s pomočjo posebnih razširitev, ki so trenutno uradno na voljo samo za naslednje SIEM-e - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight in ELK. Do nedavnega je bilo takšnih SIEM več, s 1. junijem 2019 pa je Microsoft prenehal podpirati orodje za integracijo dnevnikov Azure (AzLog), ki je ob zori obstoja Azure in v odsotnosti normalne standardizacije dela z dnevniki (Azure) Monitor sploh še ni obstajal) je olajšal integracijo zunanjega SIEM z Microsoftovim oblakom. Zdaj se je situacija spremenila in Microsoft priporoča platformo Azure Event Hub kot glavno integracijsko orodje za druge SIEM. Mnogi so že implementirali takšno integracijo, vendar bodite previdni – morda ne bodo zajeli vseh dnevnikov Azure, ampak samo nekatere (poglejte v dokumentacijo za vaš SIEM).

Ob zaključku kratkega izleta v Azure bi rad dal splošno priporočilo o tej storitvi v oblaku - preden kaj rečete o funkcijah nadzora varnosti informacij v Azure, jih morate zelo natančno konfigurirati in preizkusiti, ali delujejo, kot je zapisano v dokumentaciji in kot so vam povedali Microsoftovi svetovalci (in morda imajo različne poglede na funkcionalnost funkcij Azure). Če imate finančna sredstva, lahko iz Azure iztisnete veliko koristnih informacij v smislu nadzora informacijske varnosti. Če so vaši viri omejeni, se boste, tako kot v primeru AWS, morali zanašati le na lastno moč in neobdelane podatke, ki vam jih zagotavlja Azure Monitor. In ne pozabite, da številne funkcije spremljanja stanejo in je bolje, da se vnaprej seznanite s cenovno politiko. Na primer, brezplačno lahko shranite 31 dni podatkov do največ 5 GB na stranko - če presežete te vrednosti, boste morali odšteti dodaten denar (približno 2 $+ za shranjevanje vsakega dodatnega GB od stranke in 0,1 $ za shranjevanje 1 GB vsak dodatni mesec). Delo z aplikacijsko telemetrijo in metriko lahko zahteva tudi dodatna sredstva, kot tudi delo z opozorili in obvestili (določena omejitev je na voljo brezplačno, kar morda ne bo zadostovalo za vaše potrebe).

Primer: Nadzor informacijske varnosti v IaaS na podlagi Google Cloud Platform

Google Cloud Platform je videti kot mladinec v primerjavi z AWS in Azure, vendar je to delno dobro. Za razliko od AWS, ki je svoje zmogljivosti, vključno z varnostnimi, povečeval postopoma, s težavami s centralizacijo; GCP se, tako kot Azure, veliko bolje upravlja centralno, kar zmanjša napake in čas implementacije v podjetju. Z varnostnega vidika je GCP, nenavadno, med AWS in Azure. Ima tudi enotno prijavo na dogodek za celotno organizacijo, vendar je ta nepopolna. Nekatere funkcije so še v beta načinu, vendar naj bi postopoma to pomanjkljivost odpravili in GCP bo postal zrelejša platforma v smislu nadzora informacijske varnosti.

Glavno orodje za beleženje dogodkov v GCP je Stackdriver Logging (podobno kot Azure Monitor), ki vam omogoča zbiranje dogodkov v vaši celotni infrastrukturi v oblaku (pa tudi iz AWS). Z varnostnega vidika v GCP ima vsaka organizacija, projekt ali mapa štiri dnevnike:

• Dejavnost skrbnika - vsebuje vse dogodke, povezane s skrbniškim dostopom, na primer ustvarjanje virtualnega stroja, spreminjanje pravic dostopa itd. Ta dnevnik se vedno piše, ne glede na vašo željo, in hrani svoje podatke 400 dni.
• Dostop do podatkov - vsebuje vse dogodke, povezane z delom s podatki uporabnikov oblaka (ustvarjanje, spreminjanje, branje itd.). Privzeto se ta dnevnik ne piše, saj se njegova prostornina zelo hitro poveča. Zaradi tega je rok trajanja le 30 dni. Poleg tega v tej reviji ni vse napisano. Vanjo se na primer ne zapišejo dogodki, povezani z viri, ki so javno dostopni vsem uporabnikom ali ki so dostopni brez prijave v GCP.
• Sistemski dogodek - vsebuje sistemske dogodke, ki niso povezani z uporabniki, ali dejanja skrbnika, ki spremeni konfiguracijo virov v oblaku. Vedno je zapisan in shranjen 400 dni.
• Access Transparency je edinstven primer dnevnika, ki zajema vsa dejanja Googlovih zaposlenih (vendar še ne za vse storitve GCP), ki dostopajo do vaše infrastrukture kot del svojih delovnih nalog. Ta dnevnik se hrani 400 dni in ni na voljo vsakemu odjemalcu GCP, ampak samo, če so izpolnjeni številni pogoji (bodisi podpora na ravni Gold ali Platinum ali prisotnost 4 vlog določene vrste kot del podpore podjetja). Podobna funkcija je na voljo tudi na primer v Office 365 - Lockbox.

Primer dnevnika: Preglednost dostopa

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

Dostop do teh dnevnikov je mogoč na več načinov (približno na enak način kot prej obravnavana Azure in AWS) – prek vmesnika Log Viewer, prek API-ja, Google Cloud SDK ali prek strani Activity vašega projekta, za katerega zanimajo dogodki. Na enak način jih je mogoče izvoziti v zunanje rešitve za dodatno analizo. Slednje se izvede z izvozom dnevnikov v shrambo BigQuery ali Cloud Pub/Sub.

Platforma GCP poleg Stackdriver Logging ponuja tudi funkcionalnost Stackdriver Monitoring, ki vam omogoča spremljanje ključnih meritev (zmogljivost, MTBF, splošno zdravje itd.) storitev in aplikacij v oblaku. Obdelani in vizualizirani podatki lahko olajšajo iskanje težav v vaši infrastrukturi v oblaku, tudi v kontekstu varnosti. Vendar je treba opozoriti, da ta funkcionalnost ne bo zelo bogata v kontekstu informacijske varnosti, saj danes GCP nima analoga istega AWS GuardDuty in ne more prepoznati slabih med vsemi registriranimi dogodki (Google je razvil Event Threat Detection, vendar je še v razvoju v beta različici in je prezgodaj govoriti o njegovi uporabnosti). Stackdriver Monitoring bi lahko uporabili kot sistem za odkrivanje anomalij, ki bi jih nato raziskali in odkrili vzroke njihovega nastanka. A glede na pomanjkanje osebja, usposobljenega za področje GCP informacijske varnosti na trgu, je ta naloga trenutno videti težka.

Prav tako je vredno navesti seznam nekaterih modulov za varnost informacij, ki jih je mogoče uporabiti v vašem oblaku GCP in so podobni tistemu, kar ponuja AWS:

• Cloud Security Command Center je analog AWS Security Hub in Azure Security Center.
• Cloud DLP – Samodejno odkrivanje in urejanje (npr. maskiranje) podatkov, ki gostujejo v oblaku, z uporabo več kot 90 vnaprej določenih klasifikacijskih pravilnikov.
• Cloud Scanner je pregledovalnik znanih ranljivosti (XSS, Flash Injection, nepopravljene knjižnice itd.) v App Engine, Compute Engine in Google Kubernetes.
• Cloud IAM – nadzor dostopa do vseh virov GCP.
• Identiteta v oblaku – upravljajte račune uporabnikov, naprav in aplikacij GCP z ene same konzole.
• Cloud HSM - zaščita kriptografskih ključev.
• Cloud Key Management Service - upravljanje kriptografskih ključev v GCP.
• Nadzor storitev VPC – ustvarite varno območje okoli svojih virov GCP, da jih zaščitite pred uhajanjem.
• Varnostni ključ Titan - zaščita pred lažnim predstavljanjem.

Mnogi od teh modulov ustvarjajo varnostne dogodke, ki jih je mogoče poslati v shrambo BigQuery za analizo ali izvoz v druge sisteme, vključno s SIEM. Kot je navedeno zgoraj, je GCP platforma, ki se aktivno razvija in Google zdaj razvija številne nove module za varnost informacij za svojo platformo. Med njimi sta Event Threat Detection (zdaj na voljo v različici beta), ki skenira dnevnike Stackdriver in išče sledi nepooblaščene dejavnosti (analogno GuardDuty v AWS), ali Policy Intelligence (na voljo v različici alfa), ki vam bo omogočila razvoj inteligentnih politik za dostop do virov GCP.

Naredil sem kratek pregled vgrajenih zmožnosti spremljanja v priljubljenih platformah v oblaku. Toda ali imate strokovnjake, ki znajo delati s "surovimi" dnevniki ponudnika IaaS (niso vsi pripravljeni kupiti naprednih zmogljivosti AWS ali Azure ali Google)? Poleg tega mnogi poznajo pregovor »zaupaj, vendar preveri«, ki na področju varnosti velja bolj kot kdaj koli prej. Koliko zaupate vgrajenim zmogljivostim ponudnika oblaka, ki vam pošilja informacijsko varnostne dogodke? Koliko se sploh posvečajo informacijski varnosti?

Včasih se splača pogledati rešitve za nadzor prekrivne infrastrukture v oblaku, ki lahko dopolnijo vgrajeno varnost v oblaku, včasih pa so takšne rešitve edina možnost za vpogled v varnost vaših podatkov in aplikacij, ki gostujejo v oblaku. Poleg tega so preprosto bolj priročni, saj prevzamejo vse naloge analize potrebnih dnevnikov, ki jih ustvarijo različne storitve v oblaku različnih ponudnikov v oblaku. Primer takšne prekrivne rešitve je Cisco Stealthwatch Cloud, ki je osredotočen na eno samo nalogo – spremljanje anomalij informacijske varnosti v oblačnih okoljih, ki vključujejo ne samo Amazon AWS, Microsoft Azure in Google Cloud Platform, temveč tudi zasebne oblake.

Primer: Nadzor informacijske varnosti z uporabo Stealthwatch Cloud

AWS zagotavlja prilagodljivo računalniško platformo, vendar ta prilagodljivost podjetjem olajša napake, ki povzročajo varnostne težave. In model skupne informacijske varnosti k temu samo prispeva. Izvajanje programske opreme v oblaku z neznanimi ranljivostmi (proti znanim se je mogoče boriti na primer z AWS Inspector ali GCP Cloud Scanner), šibkimi gesli, nepravilnimi konfiguracijami, insajderji itd. In vse to se odraža v obnašanju virov v oblaku, ki jih lahko spremlja Cisco Stealthwatch Cloud, ki je sistem za nadzor informacijske varnosti in zaznavanje napadov. javnih in zasebnih oblakov.

Ena od ključnih lastnosti Cisco Stealthwatch Cloud je zmožnost modeliranja entitet. Z njim lahko ustvarite programski model (to je simulacijo v skoraj realnem času) vsakega od vaših virov v oblaku (ni pomembno, ali gre za AWS, Azure, GCP ali kaj drugega). Ti lahko vključujejo strežnike in uporabnike ter vrste virov, specifične za vaše okolje v oblaku, kot so varnostne skupine in skupine za samodejno prilagajanje velikosti. Ti modeli kot vhod uporabljajo tokove strukturiranih podatkov, ki jih zagotavljajo storitve v oblaku. Na primer, za AWS bi to bili VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda in AWS IAM. Modeliranje entitet samodejno odkrije vlogo in vedenje katerega koli od vaših virov (lahko govorimo o profiliranju vseh dejavnosti v oblaku). Te vloge vključujejo mobilno napravo Android ali Apple, strežnik Citrix PVS, strežnik RDP, poštni prehod, odjemalca VoIP, terminalski strežnik, krmilnik domene itd. Nato nenehno spremlja njihovo vedenje, da ugotovi, kdaj pride do tveganega ali varnostno ogrožajočega vedenja. Prepoznate lahko ugibanje gesel, napade DDoS, uhajanje podatkov, nezakonit dostop na daljavo, dejavnost zlonamerne kode, skeniranje ranljivosti in druge grožnje. Takole je na primer videti zaznavanje poskusa oddaljenega dostopa iz netipične države za vašo organizacijo (Južna Koreja) do gruče Kubernetes prek SSH:

In tako izgleda domnevno uhajanje informacij iz baze podatkov Postgress v državo, s katero doslej še nismo naleteli na interakcijo:

Končno, takole izgleda preveč neuspelih poskusov SSH iz Kitajske in Indonezije z zunanje oddaljene naprave:

Ali pa predpostavimo, da primerek strežnika v VPC po pravilniku nikoli ne sme biti cilj oddaljene prijave. Predpostavimo še, da je ta računalnik doživel oddaljeno prijavo zaradi napačne spremembe pravilnika o pravilih požarnega zidu. Funkcija Entity Modeling bo zaznala in poročala o tej dejavnosti (»nenavaden oddaljeni dostop«) v skoraj realnem času in pokazala na določen klic AWS CloudTrail, Azure Monitor ali GCP Stackdriver Logging API (med drugimi podrobnostmi vključno z uporabniškim imenom, datumom in uro). ). kar je spodbudilo spremembo pravila ITU. Nato se te informacije lahko pošljejo SIEM v analizo.

Podobne zmogljivosti so implementirane za katero koli okolje v oblaku, ki ga podpira Cisco Stealthwatch Cloud:

Modeliranje entitet je edinstvena oblika varnostne avtomatizacije, ki lahko odkrije prej neznano težavo z vašimi ljudmi, procesi ali tehnologijo. Omogoča vam na primer odkrivanje med drugim varnostnih težav, kot so:

• Je kdo odkril stranska vrata v programski opremi, ki jo uporabljamo?
• Ali je v našem oblaku programska oprema ali naprava tretjih oseb?
• Ali pooblaščeni uporabnik zlorablja privilegije?
• Ali je prišlo do konfiguracijske napake, ki je omogočila oddaljeni dostop ali drugo nenamerno uporabo virov?
• Ali prihaja do uhajanja podatkov iz naših strežnikov?
• Se je nekdo poskušal povezati z nami z netipične geografske lokacije?
• Ali je naš oblak okužen z zlonamerno kodo?

Zaznan informacijsko-varnostni dogodek je mogoče poslati v obliki ustrezne vstopnice Slacku, Cisco Sparku, sistemu za upravljanje incidentov PagerDuty in tudi različnim SIEM-om, vključno s Splunk ali ELK. Če povzamemo, lahko rečemo, da če vaše podjetje uporablja strategijo več oblakov in ni omejeno na enega samega ponudnika oblaka, zmožnosti nadzora informacijske varnosti, ki so opisane zgoraj, je uporaba Cisco Stealthwatch Cloud dobra možnost za pridobitev enotnega niza nadzora zmogljivosti za vodilne igralce v oblaku – Amazon, Microsoft in Google. Najbolj zanimivo pa je, da če primerjate cene za Stealthwatch Cloud z naprednimi licencami za nadzor informacijske varnosti v AWS, Azure ali GCP, se lahko izkaže, da bo rešitev Cisco celo cenejša od vgrajenih zmogljivosti Amazona, Microsofta. in Googlove rešitve. To je paradoksalno, vendar je res. In več oblakov in njihovih zmogljivosti boste uporabili, bolj očitna bo prednost konsolidirane rešitve.

Poleg tega lahko Stealthwatch Cloud spremlja zasebne oblake, nameščene v vaši organizaciji, na primer na podlagi vsebnikov Kubernetes ali s spremljanjem tokov Netflow ali omrežnega prometa, prejetega prek zrcaljenja v omrežni opremi (tudi domače proizvodnje), podatkov AD ali strežnikov DNS itd. Vsi ti podatki bodo obogateni z informacijami o obveščanju o grožnjah, ki jih zbira Cisco Talos, največja svetovna nevladna skupina raziskovalcev groženj kibernetski varnosti.

To vam omogoča implementacijo enotnega sistema spremljanja za javne in hibridne oblake, ki jih lahko uporablja vaše podjetje. Zbrane informacije je nato mogoče analizirati z vgrajenimi zmožnostmi Stealthwatch Cloud ali poslati v vaš SIEM (Splunk, ELK, SumoLogic in številni drugi so privzeto podprti).

S tem bomo zaključili prvi del članka, v katerem sem pregledal vgrajena in zunanja orodja za spremljanje informacijske varnosti platform IaaS/PaaS, ki nam omogočajo hitro odkrivanje in odzivanje na incidente, ki se pojavljajo v oblačnih okoljih, ki naše podjetje izbralo. V drugem delu bomo nadaljevali temo in pogledali možnosti spremljanja platform SaaS na primeru Salesforce in Dropbox, prav tako pa bomo poskušali vse skupaj povzeti in povezati z izdelavo enotnega sistema nadzora informacijske varnosti za različne ponudnike oblakov.

Vir: www.habr.com