Praćenje sigurnosti oblaka

Premik podatkov in aplikacij v oblak predstavlja nov izziv za korporativne SOC-e, ki niso vedno pripravljeni na nadzor tuje infrastrukture. Po podatkih podjetja Netskope povprečno podjetje (verjetno v ZDA) uporablja 1246 različnih oblačnih storitev, kar je 22 % več kot pred letom dni. 1246 oblačnih storitev!!! 175 od njih se nanaša na HR storitve, 170 na marketing, 110 na komunikacije in 76 na finance ter CRM. V podjetju Cisco uporabljajo "samo" 700 zunanjih oblačnih storitev. Zato me te številke nekoliko zmedo. Toda v vsakem primeru težava ni v njih, temveč v tem, da oblak vse bolj aktivno uporabljajo številne podjetja, ki bi želela imeti enake možnosti za nadzor oblačne infrastrukture kot v lastnem omrežju. In ta trend se povečuje — po podatkih Ameriškega urada za računovodstvo naj bi do leta 2023 v ZDA zaprli 1200 podatkovnih centrov (6250 jih je že zaprlo). Vendar prehod na oblak ni preprosto "pa dajmo preseliti naše strežnike k zunanjemu ponudniku". Nova IT arhitektura, nov programski oprem, novi procesi, nove omejitve… Vse to prinaša pomembne spremembe v delovanju ne samo IT-jev, ampak tudi varnosti informacij. In če so se ponudniki kakor tako naučili zagotavljati varnost samega oblaka (na srečo je dovolj priporočil), pa obstajajo pomembne težave z oblačnim nadzorom varnosti informacij, zlasti na platformah SaaS, o katerih se bomo pogovorili.

Recimo, da je vaša družba del svoje infrastrukture preselila v oblak... Ne tako. Če je infrastruktura preseljena in se šele zdaj sprašujete, kako jo boste spremljali, ste že izgubili. Če to ni Amazon, Google ali Microsoft (in tudi to z rezervacijo), verjetno ne boste imeli veliko možnosti za spremljanje vaših podatkov in aplikacij. Dobro je, če vam dajo možnost dela z dnevniki. Včasih bodo podatki o varnostnih dogodkih na voljo, a do njih ne boste imeli dostopa. Na primer, Office 365. Če imate najcenejšo licenco E1, so vam varnostni dogodki sploh nedostopni. Z licenco E3 so vaši podatki shranjeni le 90 dni, le pri E5 pa je dolžina dnevnikov na voljo eno leto (v resnici pa so tu tudi posebnosti, povezane z nujnostjo dodatnega zaprosila za nekatere funkcije dela z dnevniki pri podpori Microsoft). Mimogrede, licenca E3 je pri funkcijah spremljanja precej šibkejša kot korporativni Exchange. Da bi dosegli enako raven, potrebujete licenco E5 ali dodatno licenco Advanced Compliance, kar lahko zahteva dodatna sredstva, ki niso bila upoštevana v vašem finančnem modelu prehoda na oblačno infrastrukturo. In to je le en primer podcenjevanja vprašanj, povezanih s spremljanjem informacijske varnosti v oblaku. V tem članku, ne da bi trdil, da zajemam vse, želim opozoriti na nekatere nianse, ki jih je treba upoštevati pri izbiri oblačnega ponudnika z vidika varnosti. Na koncu članka bo priložen kontrolni seznam, ki ga je treba izpolniti, preden ugotovite, da je vprašanje spremljanja oblačne informacijske varnosti rešeno.

Lahko izpostavimo več tipičnih težav, ki vodijo do incidentov v oblačnih okoljih, na katere se varnostne službe ne morejo pravočasno odzvati ali jih sploh ne opazijo:

• Varnostni dnevniki ne obstajajo. To je precej pogosta situacija, zlasti pri začetnikih na trgu oblačnih rešitev. A takoj jih tudi ni treba obsojati. Majhni ponudniki, zlasti domači, so bolj pozorni na potrebe naročnikov in lahko hitro uvedejo zahtevane funkcije, tako da spremenijo odobren načrt razvoja svojih produktov. Da, to ne bo ekvivalent GuardDuty od Amazona ali modula 'Proaktivna zaščita' od Bitrixa, a vseeno nekaj.
• IB ne ve, kje se hranijo dnevniki ali pa dostop do njih ni mogoč. V tem primeru je treba začeti pogajanja s ponudnikom oblačnih storitev — morda vam bo ta informacije posredoval, če teče oseba zanj pomembna. Toda na splošno ni dobro, da je dostop do dnevnikov na voljo le "na posebno odločitev".
• Včasih se zgodi, da ponudnik oblačnih storitev ima dnevnike, vendar zagotavlja omejeno spremljanje in beleženje dogodkov, ki niso dovolj za odkrivanje vseh incidentov. Na primer, morda vam bodo dali le dnevnike sprememb na spletni strani ali dnevnike poskusov avtentikacije uporabnikov, vendar drugih dogodkov, kot je omrežni promet, ne bodo posredovali, kar vam bo prikrilo velik del dogodkov, ki ponazarjajo poskuse vdora v vašo oblačno infrastrukturo.
• Dnevniki so na voljo, a dostop do njih je težko avtomatizirati, kar pomeni, da jih je treba spremljati neprekosno, ampak po urniku. In če tudi izvoz dnevnikov ni mogoč v avtomatiziranem načinu, lahko prenos dnevnikov, na primer v formatu Excel (kot pri številnih domačih ponudnikih oblačnih rešitev), vodi v to, da se korporativne službe IB ne želijo ukvarjati z njimi.
• Nobenega spremljanja dnevnikov. To je verjetno najtežji razlog za nastanek incidentov IB v oblačnih okoljih. Dnevniki so, dostop do njih je mogoče avtomatizirati, a nihče tega ne počne. Zakaj?

Koncept deljene varnosti oblakov

Prehod v oblak je vedno iskanje ravnotežja med željo po ohranjanju nadzora nad infrastrukturo in prenosom le-te v bolj strokovne roke ponudnika oblačnih storitev, ki se specializira za njeno vzdrževanje. To ravnotežje je nujno iskati tudi na področju varnosti oblačnih okolij. Še posebno zato, ker se bo to ravnotežje vedno razlikovalo glede na uporabljeni model zagotavljanja oblačnih storitev (IaaS, PaaS, SaaS). Ne smemo pozabiti, da vsi oblačni ponudniki danes sledijo tako imenovanemu modelu deljene odgovornosti in deljene informacijske varnosti. Za nekaj odgovarja oblak, za nekaj pa stranka, ki je v oblak namestila svoje podatke, svoje aplikacije, svoje virtualne naprave in druge vire. Nepremišljeno bi bilo računati, da bomo z odhodom v oblak prenesli vso odgovornost na ponudnika. Toda prav tako ni razumno, da bi celotno varnost postavili na svoje rame ob prehodu v oblak. Potrebno je ravnotežje, ki bo odvisno od številnih dejavnikov: — strategije upravljanja tveganj, modela groženj, zaščitnih mehanizmov, ki jih ima oblačni ponudnik, zakonodaje itd.

Na primer, razvrstavanje podatkov, shranjenih v oblaku, je vedno odgovornost naročnika. Oblačni ponudnik ali zunanji ponudnik storitev mu lahko le pomaga z orodji, ki bodo omogočila označevanje podatkov v oblaku, odkrivanje kršitev, odstranjevanje podatkov, ki kršijo zakonodajo, ali njihovo zakrivanje z različnimi metodami. Fizična varnost pa je vedno odgovornost oblačnega ponudnika, katere ne more deliti s strankami. Vse, kar je med podatki in fizično infrastrukturo, pa je predmet obravnave tega članka. Na primer, razpoložljivost oblaka je odgovornost ponudnika, medtem ko so nastavitve pravil za MSE ali vključitev šifriranja že odgovornost naročnika. V tem članku bomo poskušali raziskati, katere mehanizme spremljanja IKT danes ponujajo različni priljubljeni oblačni ponudniki v Sloveniji, kakšne so značilnosti njihove uporabe in kdaj je smiselno pogledati proti zunanjim rešitvam (na primer, Cisco E-mail Security), ki razširjajo možnosti vašega oblaka na področju kibernetske varnosti. V nekaterih primerih, še posebej v okviru večoblačne strategije, ne boste imeli izbire, razen da boste uporabili zunanje rešitve za spremljanje IKT takoj v več oblačnih okoljih (na primer, Cisco CloudLock ali Cisco Stealthwatch Cloud). V nekaterih primerih pa boste ugotovili, da izbrani (ali vsiljeni) oblačni ponudnik ne ponuja nobenih možnosti za spremljanje IKT. To je neprijetno, a tudi nujno, saj omogoča ustrezno oceno stopnje tveganja, povezanega z delom s tem oblakom.

Življenjski cikel spremljanja varnosti oblaka

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

• zanasati se na orodja, ki jih zagotavlja vaš oblačni ponudnik,
• izkoristiti rešitve tretjih oseb, ki bodo spremljale uporabljene IaaS, PaaS ali SaaS-platforme,
• zgraditi lastno infrastrukturo za spremljanje oblačnih okolij (samo za IaaS/PaaS-platforme).

Poglejmo, kakšne značilnosti ima vsaka od teh možnosti. Preden pa to storimo, moramo razumeti splošno shemo, ki se bo uporabljala pri spremljanju oblačnih platform. Izpostavil bi 6 osnovnih komponent procesa spremljanja IB v oblaku:

• Priprava infrastrukture. Določitev potrebnih aplikacij in infrastrukture za zbiranje dogodkov, pomembnih za IB, v skladišču.
• Zbiranje. V tej fazi se varnostni dogodki agregirajo iz različnih virov za nadaljnji prenos za obdelavo, shranjevanje in analizo.
• Obdelava. V tej fazi se podatki obdelajo in obogatijo, da olajšajo njihovo nadaljnjo analizo.
• Shranjevanje. Ta komponenta je odgovorna za kratkoročno in dolgoročno shranjevanje zbranih obdelanih in „surovih“ podatkov.
• Analiza. V tej fazi imate možnost odkrivati incidente in nanje reagirati v avtomatskem ali ročnem režimu.
• Poročanje. Ta faza pomaga oblikovati ključne kazalnike za zainteresirane strani (vodi, revizorje, oblačne ponudnike, stranke itd.), ki nam pomagajo sprejemati odločitve, kot so zamenjava ponudnika ali okrepitev IB.

Razumevanje teh komponent vam bo omogočilo, da se v prihodnje hitro odločite, kaj lahko prevzamete od svojega ponudnika, in kaj boste morali narediti sami ali s pomočjo zunanjih svetovalcev.

Vgrajene možnosti oblačnih storitev

Že sem že povedal, da mnogi danes oblačni servisi ne nudijo nobene možnosti za spremljanje informacijske varnosti. Na to temo res ne posvečajo veliko pozornosti. Na primer, eden izmed priljubljenih ruskih servisov za pošiljanje poročil državi preko interneta (njegovega imena ne bom omenjal). Celotna sekcija o varnosti tega servisa se vrti okoli uporabe certificiranih SKZI. Sekcija o informacijski varnosti drugega domačega oblačnega servisa za elektronsko poslovanje je neprimerno obsežnejša. V njej govorijo o certifikatih odprtih ključev, certificirani kriptografiji, odpravi spletnih ranljivosti, zaščiti pred DDoS napadi, uporabi MSE, varnostnem kopiranju in celo rednem izvajanju revizij informacijske varnosti. O spremljanju pa ni besede, prav tako tudi ne o možnosti dostopa do dogodkov informacijske varnosti, ki bi lahko zanimali stranke tega ponudnika storitev.

Na splošno, kako oblačni ponudnik opisuje vprašanja informacijske varnosti na svoji spletni strani in v dokumentaciji, lahko razumete, kako resno se sploh loteva tega vprašanja. Na primer, če preberete navodila za produkta 'Moj urad', tam ni niti besede o varnosti, medtem ko dokumentacija za posamezen produkt 'Moj urad. KS3', ki je namenjen zaščiti pred nepooblaščenim dostopom, vsebuje navaden seznam točk 17. naloga FSTEK, ki ga izpolnjuje 'Moj urad.KS3', toda ni opisano kako ga izpolnjuje in, kar je najpomembneje, kako integrirati te mehanizme s korporativno informacijsko varnostjo. Morda ta dokumentacija res obstaja, ampak v javnem dostopu na spletni strani 'Moj urad' je nisem našel. Morda nimam dostopa do teh skrivnih informacij...

Situacija z Bitrixom je precej boljša. V dokumentaciji so opisani formati dnevnikov dogodkov in, kar je zanimivo, dnevnik vdorov, ki vsebuje dogodke, povezane s potencialnimi grožnjami za oblačno platformo. Odtod lahko izvlečete IP, ime uporabnika ali gosta, vir dogodka, čas, User Agent, tip dogodka itd. Res je, da zthese dogodki lahko delate bodisi iz upravljalske plošče samega oblaka bodisi izvozite podatke v formatu MS Excel. Avtomatizacija dela z logi Bitrix je trenutno otežena in del dela boste morali opraviti ročno (izvoz poročila in nalaganje le-tega v vaš SIEM). Toda če pomislimo, da takšne možnosti niti nedavno še nismo imeli, potem je to velik napredek. Ob tem želim poudariti, da številni tuji oblačni ponudniki ponujajo podoben funkcionalnost „za začetnike“ — bodisi gledate dnevnike s pomočjo uporabniške plošče bodisi izvažate podatke k sebi (res je, da večina izvozi podatke v formatu .csv, ne pa Excel).

Če ne upoštevamo možnosti brez dnevnikov, običajno oblačni ponudniki ponujajo tri možnosti za spremljanje varnostnih dogodkov — nadzorne plošče, izvoz podatkov in dostop do njih prek API. Prva možnost se zdi, da reši številne težave namesto vas, a to ni povsem res — pri več dnevnikih je potrebno preklapljati med zasloni, ki jih prikazujejo, kar preprečuje dober pregled. Poleg tega oblačni ponudnik verjetno ne bo ponudil možnosti korelacije varnostnih dogodkov in njihove analize z vidika varnosti (običajno imate opravka z neobdelanimi podatki, v katerih se morate sami znajti). Obstajajo izjeme, o katerih bomo govorili kasneje. Na koncu se vprašajte, katere dogodke beleži vaš oblačni ponudnik, v kakšni obliki in kako se ti usklajujejo z vašim postopkom spremljanja informacijskih varnosti? Na primer, identifikacija in avtentikacija uporabnikov in gostov. Tudi Bitrix vam omogoča, da na podlagi teh podatkov zabeležite datum in čas dogodka, ime uporabnika ali gosta (če je modul "Spletna analitika" vključen), objekt, do katerega je bil dostop in druge tipične elemente spletne strani. Vendar korporativnim službam informacijskih varnosti morda potrebujejo informacije, ali se je uporabnik v oblak prijavil z zaupanja vrednega naprava (na primer, v korporacijski mreži to nalogo izvaja Cisco ISE). In tako preprosta naloga, kot je funkcija geo-IP, ki pomaga ugotoviti, ali je bila uporabniška račun oblačne storitve ukradena? In tudi če vam oblačni ponudnik to ponudi, bo to premalo. Cisco CloudLock ne le analizira geolokacijo, temveč uporablja tudi strojno učenje ter analizira zgodovinske podatke za vsakogar uporabnika in spremlja različne nepravilnosti v poskusih identifikacije in avtentikacije. Podoben funkcionalnost ima le MS Azure (ob prisotnosti ustrezne naročnine).

Obstaja še ena težava - saj je spremljanje kibernetske varnosti še vedno nova tema za mnoge oblačne ponudnike, ki se šele začenjajo ukvarjati s tem, zato nenehno spreminjajo svoje rešitve. Danes imajo eno različico API, jutri drugo, pojutrišnem tretjo. Tudi na to se je treba pripraviti. Enako velja za funkcionalnosti, ki se lahko spreminjajo, kar je treba upoštevati v vašem sistemu za spremljanje kibernetske varnosti. Na primer, Amazon je sprva imel ločene storitve za spremljanje dogodkov v oblaku - AWS CloudTrail in AWS CloudWatch. Nato se je pojavila ločena storitev za spremljanje dogodkov kibernetske varnosti - AWS GuardDuty. Po določenem času je Amazon lansiral nov sistem upravljanja Amazon Security Hub, ki vključuje analizo podatkov, pridobljenih iz GuardDuty, Amazon Inspector, Amazon Macie in drugih. Drug primer je orodje za integracijo dnevnikov Azure s SIEM - AzLog. Aktivno so ga uporabljali številni ponudniki SIEM, dokler Microsoft leta 2018 ni napovedal prenehanja njegovega razvoja in podpore, kar je mnogim strankam, ki so uporabljale to orodje, povzročilo težave (kako se je to rešilo, bomo govorili kasneje).

Zato natančno spremljajte vse funkcije spremljanja, ki vam jih ponuja vaš oblačni ponudnik. 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, to bo dražje (čeprav ne vedno), a tako boste prenesli vso odgovornost na tuje ramena. Ali pa ne? Spomnimo se na koncept deljene varnosti in spoznamo, da ne moremo prenesti vsega - sami se bomo morali spoprijeti s tem, kako različni oblačni ponudniki zagotavljajo spremljanje kibernetske varnosti vaših podatkov, aplikacij, virtualnih naprav in drugih virov, ki so shranjeni v oblaku. In začeli bomo s tem, kar ponuja Amazon na tem področju.

Primer: Spremljanje kibernetske varnosti v IaaS, temelječem na AWS

Da, razumem, da Amazon ni najboljši primer, saj gre za ameriški servis in ga lahko blokirajo v okviru boja proti ekstremizmu ter širjenju nezakonitih informacij na območju Rusije. V tej objavi pa bi rad preprosto pokazal, kako se različne oblačne platforme razlikujejo po možnostih nadzora informacijske varnosti in na kaj je treba biti pozoren pri prenosu svojih ključnih procesov v oblake z vidika varnosti. In če bodo nekateri od ruskih razvijalcev oblačnih rešitev pridobili kaj koristnega, bo to res odlična stvar.

Najprej je treba povedati, da Amazon ni nedostopna trdnjava. Različni incidenti se pogosto dogajajo njegovim strankam. Na primer, podjetju Deep Root Analytics so ukradli imena, naslove, datume rojstva in telefone 198 milijonov volivcev. Pri izraelskem podjetju Nice Systems so ukradli 14 milijonov zapisov o strankah Verizon. Kljub temu pa vgrajene možnosti AWS omogočajo odkrivanje širokega spektra incidentov. Na primer:

• vpliv na infrastrukturo (DDoS)
• kompromitacija vozlišča (injektiranje ukazov)
• kompromitacija računa in nepooblaščen dostop
• napačna konfiguracija in ranljivosti
• nezavarovani vmesniki in API.

Takšna neusklajenost je povezana s tem, da za varnost podatkov naročnika, kot smo ugotovili zgoraj, odgovarja sam naročnik. In če ne poskrbi za vključitev zaščitnih mehanizmov ter ne aktivira orodij za nadzor, bo o incidentu izvedel le iz medijev ali od svojih strank.

Za odkrivanje incidentov lahko uporabite širok spekter različnih storitev za spremljanje, ki jih je razvijal Amazon (čeprav jih pogosto dopolnjujejo zunanja orodja, na primer osquery). V AWS se spremljajo vsi ukrepi uporabnikov, ne glede na to, kako se izvajajo — skozi nadzorno konzolo, ukazno vrstico, SDK ali druge storitve AWS. Vsa poročila o ukrepih vsakega računa AWS (vključno z imenom uporabnika, ukrepom, storitvijo, parametri aktivnosti in njenim rezultatom) ter uporaba API-jev so na voljo preko storitve AWS CloudTrail. Te dogodke (na primer, prijava v konzolo AWS IAM) lahko pregledujete iz konzole CloudTrail, jih analizirate z Amazon Atheno ali jih »posredujete« zunanjim rešitvam, kot sta Splunk, AlienVault itd. Logi AWS CloudTrail so shranjeni v vaši vedru AWS S3.

Two druga storitvi AWS zagotavljata še vrsto pomembnih zmogljivosti za spremljanje. Prvič, Amazon CloudWatch — to je storitev spremljanja virov in aplikacij AWS, ki omogoča med drugim prepoznavanje različnih anomalij 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) ter še 30 drugih storitev Amazon, uporabljajo Amazon CloudWatch za shranjevanje svojih logov. Razvijalci lahko uporabijo odprt API Amazon CloudWatch za dodajanje funkcije spremljanja logov v uporabniške aplikacije in storitve, kar omogoča širši spekter analiziranih dogodkov v kontekstu varnosti informacij.

Drugič, storitev VPC Flow Logs omogoča analizo omrežnega prometa, ki ga pošiljajo ali prejemajo vaši strežniki AWS (zunaj ali od znotraj), prav tako pa tudi med mikroservisi. Ko katerikoli od vaših virov AWS VPC komunicira z omrežjem, storitev VPC Flow Logs zabeleži informacije o omrežnem prometu, vključno z omrežnim vmesnikom izvora in cilja ter IP naslovi, vrati, protokolom, številom bajtov in številom paketov, ki ste jih videli. Tisti, ki imajo izkušnje z lokalno omrežno varnostjo, to prepoznajo kot analogne tokov. NetFlow, ki jih lahko ustvarjajo preklopniki, usmerjevalniki in požarni zidovi na ravni podjetja. Ti dnevniki so pomembni za spremljanje varnosti, ker omogočajo preverjanje omrežnih interakcij v virtualnem zasebnem oblačnem okolju AWS, poleg dogodkov o dejanjih uporabnikov in aplikacij.

Tako te tri storitve AWS - AWS CloudTrail, Amazon CloudWatch in VPC Flow Logs - skupaj zagotavljajo zelo učinkovito predstavitev o uporabi vašega računa, vedenju uporabnikov, upravljanju infrastrukture, aktivnosti aplikacij in storitev ter omrežni aktivnosti. Na primer, z njimi lahko zaznate naslednje anomalias:

• Poskusi skeniranja spletnih strani, iskanja povratnih povezav, iskanja ranljivosti preko porasta "napak 404".
• Vbrizgane napade (na primer, SQL injection) skozi porast "napak 500".
• Znana orodja za napade sqlmap, nikto, w3af, nmap itd. preko analize polja User Agent.

Amazon Web Services je razvil tudi druge storitve za namen kibernetske varnosti, ki omogočajo reševanje številnih drugih nalog. Na primer, v AWS je vgrajena storitev za preučevanje politik in konfiguracij — AWS Config. Ta storitev zagotavlja neprekinjeno preverjanje vaših AWS virov in njihovih konfiguracij. Poglejmo enostaven primer: domnevajte, da želite preveriti, ali so gesla uporabnikov onemogočena na vseh vaših strežnikih in da je dostop mogoč samo na podlagi certifikatov. AWS Config to omogoča enostavno preverjanje za vse vaše strežnike. Obstoječe so tudi druge politike, ki jih je mogoče uporabiti za vaše oblačne strežnike: "Noben strežnik ne sme uporabljati vrat 22", "Samo skrbniki lahko spreminjajo pravila požarnih zidov" ali "Samo uporabnik Ivaško lahko ustvarja nove uporabniške račune in to lahko počne samo ob torkih". Poleti 2016 je bila storitev AWS Config razširjena za avtomatizacijo odkrivanja kršitev vzpostavljenih politik. AWS Config Rules so v bistvu neprekinjena preverjanja konfiguracij storitev Amazon, ki jih uporabljate, ter generirajo dogodke v primeru kršečih politik. Na primer, namesto da bi občasno izvajali poizvedbe AWS Config za preverjanje, ali so vsi diski na virtualnem strežniku šifrirani, se lahko AWS Config Rules uporabijo za stalno preverjanje strežniških diskov, da se to pogoje izpolni. In, kar je najpomembneje v kontekstu te objave, vse kršitve generirajo dogodke, ki jih lahko analizira vaša služba za informacijsko varnost.

V AWS obstajajo tudi njihovi ekvivalenti tradicionalnim podjetniškim rešitvam za informacijsko varnost, ki prav tako generirajo varnostne dogodke, ki jih lahko in morate analizirati:

• odkrivanje vdorov — AWS GuardDuty
• nadzor uhajanja informacij — AWS Macie
• EDR (čeprav se o končnih napravah v oblaku sliši nekoliko nenavadno) — AWS Cloudwatch + rešitve open source osquery ali GRR
• analiza Netflow — AWS Cloudwatch + AWS VPC Flow
• analiza DNS — AWS Cloudwatch + AWS Route53
• AD — AWS Directory Service
• upravljanje računov — AWS IAM
• SSO — AWS SSO
• analiza varnosti — AWS Inspector
• upravljanje konfiguracij — AWS Config
• WAF — AWS WAF.

Ne bom podrobno opisoval vseh storitev Amazon, ki so lahko koristne v kontekstu informacijske varnosti. Ključno je razumeti, da lahko vse te storitve generirajo dogodke, ki jih lahko in moramo analizirati v okviru IV, pri čemer lahko izkoriščamo tako vgrajene možnosti samega Amazona kot tudi zunanje rešitve, kot je SIEM, ki lahko črpajo varnostne dogodke v vaš center za spremljanje ter jih analizirajo skupaj z dogodki iz drugih oblačnih storitev ali iz notranje infrastrukture, perimetra ali mobilnih naprav.

V vsakem primeru se vse začne s podatkovnimi viri, ki vam zagotavljajo dogodke IV. Med te vire lahko med drugim štejemo:

• CloudTrail — uporaba API-jev in dejanj uporabnikov
• Trusted Advisor — preverjanje varnosti glede na najboljše prakse
• Config — inventarizacija in konfiguracija računov ter nastavitev storitev
• VPC Flow Logs — povezave z virtualnimi vmesniki
• IAM — storitev identifikacije in avtentikacije
• ELB Access Logs — dnevniki uravnoteževalnika obremenitev
• Inspector — ranljivosti v aplikacijah
• S3 — shramba datotek
• CloudWatch — aktivnost aplikacij
• SNS — storitev obveščanja.

Amazon, ki ponuja tovrsten spekter virov dogodkov in orodij za njihovo generiranje, je hkrati močno omejen v možnostih analize zbranih podatkov v kontekstu IV. Morali boste sami raziskovati obstoječe dnevnike in iskati v njih ustrezne indikatorje kompromitacije. AWS Security Hub, ki ga je Amazon nedavno zagnal, naj bi reševal ta problem in postal nekakšen oblačen SIEM za AWS. Vendar je še vedno le na začetku svoje poti in je omejen tako zaradi števila virov, s katerimi deluje, kot tudi drugih omejitev, ki jih postavlja arhitektura in naročnine samega Amazona.

Primer: Spremljanje IV v IaaS na osnovi Azure

Ne želim se upuštati u dugu raspravu o tome koji od tri cloud pružatelja (Amazon, Microsoft ili Google) je najbolji (tim više što svaki od njih ima svoju specifičnost i pogodniji je za određene zadatke); usredotočimo se na mogućnosti praćenja sigurnosti informacija (IB), koje ovi igrači nude. Treba priznati da je Amazon AWS bio jedan od prvih u ovom segmentu i stoga je napredovao dalje od svih u pogledu svojih funkcija praćenja sigurnosti (iako mnogi priznaju da je teško koristiti ih). No, to ne znači da ćemo ignorirati mogućnosti koje nam pružaju Microsoft i Google.

Proizvodi Microsofta oduvek su se odlikovali svojom „otvorenošću“ i situacija s Azureom je slična. Na primer, dok AWS i GCP uvek polaze od koncepta „sve što nije dopušteno, zabranjeno je“, Azure ima suprotan pristup. Na primer, kada kreirate virtuelnu mrežu u oblaku i virtuelnu mašinu unutar nje, svi portovi i protokoli su po difoltu otvoreni i dozvoljeni. Zbog toga, moraćete uložiti malo više truda u prvotnu postavku sistema kontrole pristupa u oblaku od Microsofta. Ovo takođe postavlja strože zahteve u pogledu praćenja aktivnosti u Azure oblaku.

AWS ima posebnost vezanu uz to da, kada pratite svoje virtualne resurse, ako se nalaze u različitim regijama, pojavljuju se poteškoće u kombiniranju svih događaja i njihovoj jedinstvenoj analizi, za čije ćete rješavanje morati pribjeći različitim trikovima, poput stvaranja vlastitog koda za AWS Lambda koji će prenositi događaje između regija. U Azure nema ovog problema — njegov mehanizam Activity Log prati sve aktivnosti unutar cijele organizacije bez ograničenja. Isto vrijedi i za AWS Security Hub, koji je nedavno razvijen od strane Amazona za konsolidaciju mnogih funkcija sigurnosti unutar jednog sigurnosnog centra, ali samo unutar svoje regije, što, istini za volju, za Rusiju nije aktualno. U Azure postoji vlastiti Security Center koji nije ograničen regijama, pružajući pristup svim funkcijama sigurnosti oblaka. Štoviše, za različite lokalne timove može pružiti svoj set zaštitnih mogućnosti, uključujući i upravljane događaje sigurnosti. AWS Security Hub još uvijek teži tome da postane sličan Azure Security Centeru. No valja dodati i mrvicu gorčine — možete izvući jako puno iz Azure-a onoga što je prethodno opisano za AWS, ali najprikladnije se to radi samo za Azure AD, Azure Monitor i Azure Security Center. Sve ostale zaštitne mjere u Azure-u, uključujući analizu događaja sigurnosti, za sada se ne upravljaju najprikladnije. Djelomično, problem rješava API koji prožima sve usluge Microsoft Azure-a, ali to će od vas zahtijevati dodatne napore za integraciju vaše infrastrukture s vašim SOC-om i prisustvo kvalificiranih stručnjaka (baš kao i s bilo kojim drugim SIEM-om koji radi s API-jem oblaka). Neki SIEM-ovi, o kojima će se kasnije raspravljati, već podržavaju Azure i mogu automatizirati zadatak njegovog praćenja, ali i tu postoje određene poteškoće — ne mogu svi oni preuzeti sve logove koje Azure ima.

Zbirka događaja i njihovo praćenje u Azure-u vrši se putem usluge Azure Monitor, koja je ključni alat za prikupljanje, skladištenje i analizu podataka u oblaku Microsoft-a i njegovim resursima — repozitorijima Git, kontejnerima, virtuelnim mašinama, aplikacijama itd. Svi podaci prikupljeni od strane Azure Monitor podeljeni su u dve kategorije — metrike koje se prikupljaju u realnom vremenu i opisuju ključne pokazatelje performansi Azure oblaka, i logovi, koji sadrže podatke organizovane u zapise koji opisuju određene aspekte rada resursa i usluga Azure-a. Pored toga, uz pomoć Data Collector API-a, usluga Azure Monitor može prikupljati podatke sa bilo kojeg REST izvora za izgradnju vlastitih scenarija praćenja.

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 (neki samo putem Azure Monitor / Insight API-ja):

• Logovi aktivnosti — ovaj log odgovara na klasična pitanja “ko”, “šta” i “kada” u vezi sa svakom operacijom zapisa (PUT, POST, DELETE) nad resursima u oblaku. Događaji vezani za pristup u čitanju (GET) ne ulaze u ovaj log, kao ni mnogi drugi.
• Logovi dijagnostike — sadrže podatke o operacijama sa određenim resursima koji su deo vaše pretplate.
• Izveštavanje Azure AD-a — sadrži kako aktivnost korisnika, tako i sistemsku aktivnost vezanu za upravljanje grupama i korisnicima.
• Windows Event Log i Linux Syslog — sadrže događaje sa virtuelnih mašina smeštenih u oblaku.
• Metrike — sadrže telemetriju o stanju performansi i „zdravlju“ vaših oblaka usluga i resursa. Mere se svake minute i čuvaju se 30 dana.
• Logovi tokova Network Security Group-a — sadrže podatke o mrežnim sigurnosnim događajima prikupljenim putem usluge Network Watcher i praćenja resursa na mrežnom nivou.
• Logovi skladišta — sadrže događaje vezane za pristup skladištima.

Za spremljanje lahko uporabite zunanje SIEM ali vgrajen Azure Monitor in njegovo razširitev. O sistemih za upravljanje z varnostnimi dogodki bomo še govorili, zdaj pa poglejmo, kaj nam ponuja Azure za analizo podatkov v okviru varnosti. Glavna pogled za vse, kar je povezano z varnostjo v Azure Monitor, je Log Analytics Security and Audit Dashboard (brezplačna različica podpira shranjevanje omejenega števila dogodkov le en teden). Ta plošča je razdeljena na 5 glavnih območij, ki vizualizirajo povzetek statistike o tem, kaj se dogaja v vaši uporabljeni oblačni okolici:

• Varnostna področja – ključni kvantitativni kazalniki, povezani z varnostjo – število incidentov, število kompromitiranih vozlišč, nepravilno popravljenih vozlišč, dogodki omrežne varnosti itd.
• Opazne težave – prikazuje število in pomembnost aktivnih težav z varnostjo
• Odkritja – prikazuje vzorce, uporabljene proti vam v napadih
• Obveščevalske informacije o grožnjah – prikazuje geografske informacije o zunanjih vozliščih, ki napadajo vas
• Pogosta varnostna poizvedovanja – tipične poizvedbe, ki vam bodo pomagale bolje spremljati vašo varnost.

Med razširitvami Azure Monitor lahko omenimo Azure Key Vault (zaščita kriptografskih ključev v oblaku), Malware Assessment (analiza zaščite pred zlonamerno programsko opremo na virtualnih strojih), Azure Application Gateway Analytics (analiza, med drugim, dnevnikov oblačnega požarnega zidu) itd. Ta orodja, obogatena z določenimi pravili obdelave dogodkov, omogočajo vizualizacijo različnih vidikov delovanja oblačnih storitev, vključno z varnostjo, in odkrivanje določenih odstopanj v delovanju. A kot to pogosto velja, vsak dodatni funkcionalnost zahteva ustrezno plačljivo naročnino, kar pomeni, da boste morali načrtovati ustrezne finančne vložke vnaprej.

Azure ima niz ugrađenih mogućnosti za nadzor pretnji, koje su integrisane u Azure AD, Azure Monitor i Azure Security Center. Među njima su, na primer, otkrivanje interakcija virtuelnih mašina sa poznatim zlonamernim IP adresama (zahvaljujući integraciji sa Microsoftovim uslugama Threat Intelligence), otkrivanje zlonamernog softvera u cloud infrastrukturi putem signala alarma sa virtuelnih mašina smeštenih u oblaku, napadi tipa „bruteforce” na virtuelne mašine, ranjivosti u konfiguraciji sistema identifikacije korisnika, prijavljivanje preko anominazera ili zaraženih čvorova, curenje naloga, prijavljivanje iz neobičnih lokacija itd. Danas je Azure jedan od retkih cloud provajdera koji vam nudi ugrađene mogućnosti Threat Intelligence za obogaćivanje prikupljenih informacija o bezbednosti.

Kao što je već rečeno, zaštitne funkcije i, samim tim, događaji bezbednosti koje generišu, nisu dostupni svim korisnicima jednako i zahtevaju određenu pretplatu koja uključuje potrebne funkcije, koje generišu odgovarajuće događaje za nadzor bezbednosti. Na primer, deo funkcija opisanih u prethodnom paragrafu za nadzor anomalija u nalozima dostupan je samo u premijum licenci P2 za uslugu Azure AD. Bez nje, kao i u slučaju AWS-a, moraćete da analizirate prikupljene događaje bezbednosti „ručno“. Takođe, u zavisnosti od tipa licence za Azure AD, neće vam biti dostupni svi događaji za analizu.

Na Azure portalu možete upravljati kako pretraživačkim zahtevima za interesantnim logovima, tako i konfigurirati kontrolne table za vizualizaciju ključnih pokazatelja bezbednosti. Pored toga, tamo možete birati Azure Monitor ekstenzije, koje vam omogućavaju da proširite funkcionalnost logova Azure Monitor i dobijete dublju analizu događaja sa aspekta bezbednosti.

Če potrebujete ne samo možnosti dela z dnevniki, ampak celovit center za varnost vaše oblačne platforme Azure, vključno z upravljanjem varnostnih politik, potem se lahko pogovarjamo o nujnosti dela z Azure Security Center, katerega večina koristnih funkcij je na voljo za dodatno plačilo, kot so odkrivanje groženj, spremljanje zunaj Azure, ocena skladnosti itd. (v brezplačni različici imate dostop samo do ocene varnosti in priporočil za odpravo ugotovljenih težav). Združuje vse varnostne zadeve na enem mestu. V bistvu lahko govorimo o višjem nivoju varnosti, kot ga ponuja Azure Monitor, saj se v tem primeru podatki, zbrani po celotni ohišnici, obogatijo z mnogimi 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), nanje pa se uporabljajo različni napredni algoritmi strojnega učenja in vedenjske analitike, kar bi v končni fazi moralo povečati učinkovitost odkrivanja groženj in odzivanja nanje.

Azure ima tudi svoj SIEM, ki se je pojavil sredi leta 2019. To je Azure Sentinel, ki se zanaša na podatke iz Azure Monitorja in se lahko integrira z zunanjimi varnostnimi rešitvami (na primer, NGFW ali WAF), katerih seznam se stalno dopolnjuje. Poleg tega, zaradi integracije z Microsoft Graph Security API, imate možnost povezovanja lastnih virov Threat Intelligence s Sentinelom, kar obogati možnosti analize incidentov v vaši oblačni storitvi Azure. Lahko trdimo, da je Azure Sentinel prvi 'nativni' SIEM, ki se je pojavil pri oblačnih ponudnikih (tisti Splunk ali ELK, ki jih je mogoče namestiti v oblaku, na primer AWS, so vendarle razviti ne od ponudnikov tradicionalnih oblačnih storitev). Azure Sentinel in Security Center bi lahko poimenovali SOC za oblak Azure, in bi ju lahko omejili na to (s posebnimi opombami), če ne bi imeli nobene druge infrastrukture in bi vse svoje računske vire prenesli v oblak, pa še to bi bil oblak Microsoft Azure.

Ker pa so vgrajene možnosti Azure (tudi ob naročnini na Sentinel) pogosto nezadostne za potrebe spremljanja informacijske varnosti (IV) in integracijo tega procesa z drugimi viri varnostnih dogodkov (tako oblačnimi kot notranjimi), se pojavi potreba po izvozu zbranih podatkov v zunanje sisteme, kamor lahko spada tudi SIEM. To se izvaja tako preko API-ja kot tudi s posebnimi razširitvami, ki so trenutno uradno na voljo samo za naslednje SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight in ELK. Še nedavno je bilo več takšnih SIEM, toda od 1. junija 2019 je Microsoft prenehal s podporo za Azure Log Integration Tool (AzLog), ki je ob začetku obstoja Azure in ob odsotnosti ustrezne standardizacije dela z logi (Azure Monitor še ni obstajal) omogočal enostavno integracijo zunanjih SIEM z oblakom Microsoft. Danes se je situacija spremenila in Microsoft priporoča platformo Azure Event Hub kot glavno orodje za integracijo z ostalimi SIEM. Mnogi so že izvedli to integracijo, vendar bodite previdni — ti lahko zajemajo le nekatere Azure loge, zato preverite dokumentacijo za vaš SIEM.

Zaključujući kratak pregled Azure-a, želim dati opću preporuku o ovoj usluzi u oblaku — prije nego što nešto tvrdite o funkcijama praćenja bezbednosti u Azure-u, potrebno ih je pažljivo postaviti i testirati da bi se uverili da rade onako kako je objašnjeno u dokumentaciji i kako su vam rekli konsultanti Microsoft-a (a oni mogu imati različite poglede na funkcionalnost Azure funkcija). Ako imate finansijske mogućnosti, iz Azure-a se može izvući mnogo korisnog u pogledu praćenja bezbednosti. Ako su vaši resursi ograničeni, kao i u slučaju AWS-a, moraćete se osloniti samo na sopstvene snage i sirove podatke koje vam pruža Azure Monitor. Takođe zapamtite da mnoge funkcije praćenja koštaju novac i bolje je unapred se upoznati sa cenovnom politikom. Na primer, besplatno možete čuvati podatke do 31 dan u obimu ne većem od 5 GB po klijentu — prekoračenje ovih vrednosti zahtevaće dodatne troškove (otprilike 2+ dolara za čuvanje svakog dodatnog GB po klijentu i 0,1 dolara za svaki dodatni GB mesečno). Rad sa telemetrijom aplikacija i metrike takođe može zahtevati dodatne troškove, kao i rad sa alarmima i obaveštenjima (na raspolaganju je određeni besplatni limit koji možda neće biti dovoljan za vaše potrebe).

Primer: Praćenje bezbednosti u IaaS-u na bazi Google Cloud Platforme

Google Cloud Platforma u poređenju sa AWS-om i Azure-om izgleda kao potpuni novajlija, ali to je delimično dobro. Za razliku od AWS-a, koji je postepeno povećavao svoje mogućnosti, uključujući i zaštitu, suočen sa problemima centralizacije; GCP, kao i Azure, mnogo bolje se upravlja centralizovano, što smanjuje broj grešaka i vreme implementacije u preduzeću. Sa stanovišta bezbednosti, GCP se iznenađujuće nalazi između AWS-a i Azure-a. Ima jedinstveno registrovanje događaja za celu organizaciju, ali ono nije potpuno. Neke funkcije su još uvek u beta režimu, ali se postepeno očekuje da će se ovaj nedostatak otkloniti i GCP će postati zrelija platforma sa stanovišta praćenja bezbednosti.

Glavni alat za registraciju događaja u GCP-u je Stackdriver Logging (ekvivalent Azure Monitor-a), koji vam omogućava da prikupljate događaje širom vaše Cloud infrastrukture (kao i s AWS-a). Sa tačke gledišta sigurnosti, u GCP-u svaka organizacija, projekat ili folder ima četiri registra:

• Admin Activity — sadrži sve događaje povezane s administrativnim pristupom, poput kreiranja virtuelne mašine, promene prava pristupa itd. Ovaj registar se uvek vodi, nezavisno od vaših želja, i čuva podatke tokom 400 dana.
• Data Access — sadrži sve događaje vezane za rad sa podacima cloud korisnika (kreiranje, izmena, čitanje itd.). Po defaultu, ovaj registar se ne vodi, jer se njegov obim vrlo brzo povećava. Iz tog razloga, njegov rok čuvanja iznosi samo 30 dana. Pored toga, u ovaj registar ne ulaze svi događaji. Na primer, događaji povezani sa resursima koji su javno dostupni svim korisnicima ili koji su dostupni bez prijave u GCP se ne beleže.
• System Event — sadrži sistemske događaje koji nisu povezani s korisnicima ili radnje administratora koji menja konfiguraciju cloud resursa. Uvek se beleži i čuva tokom 400 dana.
• Access Transparency — jedinstven je primer registra koji beleži sve radnje zaposlenih u Google-u (ali za sada ne za sve GCP usluge) koji pristupaju vašoj infrastrukturi u okviru izvršavanja svojih radnih zadataka. Ovaj registar se čuva 400 dana i nije dostupan svim GCP klijentima, već samo uz određene uslove (ili podrška na Gold ili Platinum nivou, ili postojanje četiri određene uloge u okviru korporativne podrške). Slična funkcija postoji, na primer, u Office 365 — Lockbox.

Primer registra: Access Transparency

{
 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.comaccess_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 navedenih dnevnikov je mogoč na več načinov (podobno kot prej obravnavana Azure in AWS) — prek vmesnika Log Viewer, prek API-ja, prek Google Cloud SDK ali prek strani Activity vašega projekta, za katerega vas zanimajo dogodki. Na enak način jih je mogoče izvoziti v zunanje rešitve za nadaljnjo analizo. To se izvede s izvozi dnevnikov v skladišče BigQuery ali Cloud Pub/Sub.

Poleg Stackdriver Logging platforma GCP ponuja tudi funkcionalnost Stackdriver Monitoring, ki omogoča spremljanje ključnih metrik (učinkovitost, odpornost, splošno stanje itd.) oblačnih storitev in aplikacij. Obdelani in vizualizirani podatki lahko olajšajo iskanje težav v vaši oblačni infrastrukturi, vključno s kontekstom varnosti. Vendar je treba opozoriti, da ta funkcionalnost ni posebej bogata v kontekstu varnosti informacij, saj GCP trenutno nima analoga AWS GuardDuty in ne more izpostaviti slabe dogodke med vsemi zabeleženimi. (Google je razvil Event Threat Detection, vendar je ta še vedno v beta različici in o njegovi uporabnosti je prezgodaj govoriti). Stackdriver Monitoring bi lahko uporabili kot sistem za odkrivanje anomalij, ki bi jih nato preiskali za iskanje vzrokov. Vendar pa se ob pomanjkanju kvalificiranega osebja na področju varnosti informacij na trgu to nalogo trenutno zdi zahtevno.

Prav tako je smiselno navesti seznam nekaterih modulov za varnost informacij, ki jih je mogoče uporabiti v okviru vašega oblačnega GCP in se podobajo tistim, kar ponuja AWS:

• Cloud Security Command Center je analog AWS Security Hub in Azure Security Center.
• Cloud DLP — avtomatsko zaznavanje in urejanje (na primer, maskiranje) podatkov, ki so shranjeni v oblaku, na podlagi več kot 90 prednastavljenih politik klasifikacije.
• Cloud Scanner — skener znanih ranljivosti (XSS, Flash Injection, nepodprte knjižnice itd.) v App Engine, Compute Engine in Google Kubernetes.
• Cloud IAM — upravljanje dostopa do vseh virov GCP.
• Cloud Identity — upravljanje uporabniških računov, naprav in aplikacij GCP iz enotne konzole.
• Cloud HSM — zaščita kriptografskih ključev.
• Cloud Key Management Service — upravljanje kriptografskih ključev v GCP.
• VPC Service Control — ustvarjanje zaščitenega perimetra okoli vaših virov GCP za zaščito pred uhajanjem.
• Titan Security Key — zaščita pred phishingom.

Številni od teh modulov ustvarjajo varnostne dogodke, ki jih je mogoče poslati v skladišče BigQuery za analizo ali izvoz v druge sisteme, vključno s SIEM. Kot je bilo že omenjeno, je GCP aktivno razvijajoča platforma, trenutno pa Google razvija vrsto novih modulov za informacijsko varnost za svojo platformo. Med njimi je Event Threat Detection (trenutno dostopen v beta verziji), ki skenira dnevnike Stackdriver za iskanje sledi nepooblaščene aktivnosti (podobno GuardDuty v AWS) ali Policy Intelligence (dostopen v alfa verziji), ki bo omogočil razvoj inteligentnih politik dostopa do virov GCP.

Naredil sem kratek pregled vgrajenih možnosti za spremljanje v priljubljenih oblačnih platformah. Ampak ali imate strokovnjake, ki znajo delati s 'surovimi' dnevniki IaaS ponudnika (ne vsi so pripravljeni kupiti napredne možnosti AWS ali Azure ali Google)? Poleg tega je mnogim znana izjava 'zaupaj, ampak preveri', ki je na področju varnosti kot nikoli pomembna. Koliko zaupate vgrajenim možnostim oblačnega ponudnika, ki vam predaja dogodke informacijske varnosti? Kako zelo se sploh osredotočajo na informacijsko varnost?

Včasih je smiselno razmisliti o nameščenih rešitvah za spremljanje oblačnih infrastrukture, ki lahko dopolnijo vgrajeno varnost oblačnih storitev, včasih pa so takšne rešitve edina možnost za pridobitev podatkov o varnosti vaših podatkov in aplikacij, ki so nameščeni v oblaku. Poleg tega so preprostejše, saj prevzamejo vse naloge analize potrebnih dnevnikov, ki jih generirajo različne oblačne storitve različnih oblačnih ponudnikov. Kot primer takšne nameščene rešitve lahko navedemo Cisco Stealthwatch Cloud, ki je osredotočen na edino nalogo – spremljanje nepravilnosti v oblačnih okoljih, med katerimi so ne le Amazon AWS, Microsoft Azure in Google Cloud Platform, temveč tudi zasebni oblaki.

Primer: Spremljanje varnosti z uporabo Stealthwatch Cloud

AWS nudi prilagodljivo platformo za izračune, vendar ta prilagodljivost podjetjem olajša napake, ki lahko vodijo do težav z varnostjo. In deljen model varnosti le to spodbuja. Zaženite v oblaku programsko opremo z neznanimi ranljivostmi (z znanimi se lahko bori, na primer, AWS Inspector ali GCP Cloud Scanner), šibke gesla, nepravilne konfiguracije, notranji uporabniki itd. In vse to vpliva na obnašanje oblačnih virov, ki jih lahko spremlja Cisco Stealthwatch Cloud, ki je sistem za spremljanje varnosti in odkrivanje napadov v javnih in zasebnih oblakih.

Ena iz ključnih značilnosti Cisco Stealthwatch Cloud je možnost modeliranja entitet. S tem lahko ustvarite programski model (to je simulacijo skoraj v realnem času) vsakega od vaših oblačnih virov (ne glede na to, ali gre za AWS, Azure, GCP ali kaj drugega). Ti lahko vključujejo strežnike in uporabnike, pa tudi vrste virov, specifične za vaše oblačno okolje, kot so varnostne skupine in skupine avtomatskega skaliranja storitev. Ti modeli uporabljajo kot vhodne podatke strukturirane tokove podatkov, ki jih zagotavljajo oblačne storitve. Na primer, za AWS bodo to VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda in AWS IAM. Modeliranje entitet samodejno odkrije vlogo in obnašanje katerega koli od vaših virov (lahko govorimo o profiliranju celotne oblačne aktivnosti). Med takimi vlogami so mobilne naprave Android ali Apple, strežnik Citrix PVS, RDP-strežnik, poštni prehod, VoIP odjemalec, terminalski strežnik, kontroler domene itd. Potem nenehno sledi njihovemu obnašanju, da ugotovi, kdaj pride do tveganega ali varnostno ogrožajočega obnašanja. Lahko identificirate poskuse uganiti gesla, DDoS napade, uhajanja podatkov, nezakonit oddaljen dostop, delovanje zlonamerne programske opreme, skeniranje ranljivosti in druge grožnje. Na primer, tako izgleda odkrivanje poskusa oddaljenega dostopa iz nenavadne države za vašo organizacijo (Južna Koreja) do Kubernetes klasterja preko SSH:

Tako pa izgleda domnevno uhajanje informacij iz baze podatkov Postgress v državo, s katero prej ni bilo stika:

Na koncu, tako izgleda pretirano število neuspešnih poskusov dostopa preko SSH iz Kitajske in Indonezije z zunanjega oddaljenega naprave:

Ali, predpostavimo, da je primer strežnika v VPC, ki po pravilniku nikoli ne sme biti cilj za oddaljen dostop do sistema. Predpostavimo še, da je na tem računalniku prišlo do oddaljenega dostopa do sistema zaradi napačne spremembe pravilnika požarnega zidu. Funkcija modeliranja entitet bo zaznala in poročala o tej aktivnosti ("Nenavaden oddaljen dostop") skoraj v realnem času ter označila specifičen klic API AWS CloudTrail, Azure Monitor ali GCP Stackdriver Logging (vključno z imenom uporabnika, datumom in časom ter drugimi podrobnostmi), ki so povzročile spremembo v pravilniku požarnega zidu. Te informacije se nato lahko posredujejo v SIEM za analizo.

Podobne zmogljivosti so na voljo za katero koli oblačno okolje, ki ga podpira Cisco Stealthwatch Cloud:

Modeliranje entitet je edinstvena oblika avtomatizacije varnosti, ki lahko zazna prej neznano težavo z vašimi ljudmi, procesi ali tehnologijami. Na primer, omogoča zaznavanje med drugim takih težav varnosti, kot so:

• Je kdo odkril zadnja vrata v programski opremi, ki jo uporabljamo?
• Ali obstaja kakšna tretja programska oprema ali naprava v našem oblaku?
• Ali pooblaščen uporabnik zlorablja svoje privilegije?
• Ali je prišlo do napake v konfiguraciji, ki omogoča oddaljen dostop ali drugo nenamerno uporabo virov?
• Ali ni prišlo do uhajanja podatkov s naših strežnikov?
• Ali je kdo poskušal dostopati do nas iz nenavadnega geografske lokacije?
• Ali je naš oblak okužen z zlonamerno programsko opremo?

Obnovljeni dogodki IKT lahko pošljejo v obliki ustrezne karte v Slack, Cisco Spark, sistem za upravljanje incidentov PagerDuty ter prenesejo v različne SIEM, med katerimi so Splunk ali ELK. Na kratko, lahko rečemo, da če vaša družba uporablja večkratno oblačno strategijo in ni omejena le na enega oblačnega ponudnika, so možnosti za nadzor IKT, ki so bile opisane zgoraj, uporaba Cisco Stealthwatch Cloud dober način za pridobitev enotnega sklopa funkcij za spremljanje glavnih oblačnih ponudnikov - Amazon, Microsoft in Google. Najbolj zanimivo je, da v primerjavi s cenami Stealthwatch Cloud z naprednimi licencami za nadzor IKT v AWS, Azure ali GCP lahko ugotovite, da je rešitev Cisco celo cenejša od vgrajenih možnosti rešitev Amazon, Microsoft in Google. Paradoksalno, a resnično. In bolj ko uporabljate različna oblačna okolja in njihove možnosti, bolj očitna bo prednost konsolidirane rešitve.

Poleg tega lahko Stealthwatch Cloud spremlja tudi zasebna oblačila, razporejena v vaši organizaciji, na primer na osnovi kontejnerjev Kubernetes ali z nadzorom Netflow tokov ali omrežnega prometa, pridobljenega z mirroringom v omrežni opremi (tudi domače proizvodnje), podatkov AD ali DNS strežnikov itd. Vsi ti podatki bodo obogateni z informacijami Threat Intelligence, ki jih zbira oddelek Cisco Talos, največja nevladna skupina raziskovalcev groženj IKT na svetu.

To vam omogoča, da izvedete enoten sistem nadzora tako javnih kot hibridnih oblakov, ki jih lahko uporablja vaša podjetje. Zbrane informacije je nato mogoče analizirati z vgrajenimi funkcijami Stealthwatch Cloud ali poslati v vaš SIEM (privzeto podpirajo Splunk, ELK, SumoLogic in nekaj drugih).

Na tem bomo zaključili prvi del članka, v katerem sem obravnaval vgrajena in zunanja orodja za spremljanje IT varnosti IaaS/PaaS platform, ki nam omogočajo hitro odkrivanje in odzivanje na incidente, ki se dogajajo v oblačnih okoljih, ki jih izbere naše podjetje. V drugem delu bomo nadaljevali temo in obravnavali možnosti spremljanja SaaS platform na primeru Salesforce in Dropbox, ter poskušali povzemati in združiti vse skupaj, ustvarjajoč enoten sistem spremljanja IT varnosti različnih oblačnih ponudnikov.

Izvor: habr.com