Pilveteenuste turvamonitooring

Andmete ja rakenduste üleviimine pilvedesse esitab uue väljakutse ettevõtete SOC-idele, kes ei ole alati valmis jälgima teiste infrastruktuuri. Netoskope andmetel kasutab keskmine ettevõte (tõenäoliselt siiski Ameerika Ühendriikides) 1246 erinevat pilveteenust, mis on 22% rohkem kui aasta tagasi. 1246 pilveteenust!!! 175 neist puudutab HR-teenuseid, 170 on seotud turundusega, 110 - kommunikatsiooni valdkonnas ja 76 rahanduses ja CRM-is. Cisco kasutab 'ainult' 700 välist pilveteenust. Seetõttu mind need numbrid natuke segadusse ajavad. Kuid igal juhul ei seisne probleem neis, vaid selles, et pilved hakkavad üha rohkemate ettevõtete seas aktiivselt kasutusele võtma, kes soovivad omada samu jälgimisvõimalusi pilveinfrastruktuuris nagu oma võrgus. Ja see suundumus tugevneb - vastavalt Ameerika Ühendriikide auditi büroo andmetele Aastal 2023 USA-s on plaanis sulgeda 1200 andmekeskust (6250 on juba suletud). Kuid üleminek pilve ei ole lihtsalt "ülevaatame oma serverid välise teenusepakkuja juurde". Uus IT-arkeitektuur, uus tarkvara, uued protsessid, uued piirangud... Kõik need muudatused toovad olulisi muudatusi mitte ainult IT-sse, vaid ka teabe turbe. Ja kuigi teenusepakkujad on õppinud kuidagi hoolitsema pilve enda turvamise eest (õnneks on soovitusi piisavalt), on pilve teabe turbe jälgimisega, eriti SaaS-platvormidel, tõsiseid raskusi, millest me ka räägime.

Oletame, et teie ettevõte on viinud osa oma infrastruktuurist pilve... Oota. Mitte nii. Kui infrastruktuur on viidud, aga te alles nüüd mõtlete sellele, kuidas seda jälgida, olete juba kaotanud. Kui see ei ole Amazon, Google või Microsoft (ja isegi siis tuleb ettevaatus), siis tõenäoliselt ei ole teil paljusid võimalusi oma andmete ja rakenduste jälgimiseks. Hea on, kui teil lubatakse logidega töötada. Mõnikord võivad turvalisuse sündmuste andmed olla saadaval, kuid teil pole neile ligipääsu. Näiteks Office 365. Kui teil on odavaim E1 litsents, siis turvalisuse sündmused on teile üldse ligipääsmatud. E3 litsentsi olemasolu korral on andmed saadaval ainult 90 päeva, ja ainult E5 litsentsiga on logide kestus saadaval aasta jooksul (tõsi, ka siin on omad nüansid, mis on seotud vajadusega eraldi küsida mõningaid logide funktsioone Microsofti toe kaudu). Üks detail, mis tasub mainimist, on see, et E3 litsentsi funktsioonid jälgimise osas on palju nõrgemad kui ettevõtte Exchange'il. Sama taseme saavutamiseks on teil vaja E5 litsentsi või täiendavat Advanced Compliance litsentsi, mis võib nõuda lisakulusid, mis ei ole teie pilvinfrastruktuuri ülemineku rahastamismudelis arvesse võetud. Ja see on ainult üks näide alahinnatud küsimustest, mis on seotud pilveküberturbe jälgimisega. Selles artiklis, ilma et ma pretendeeriksin käesoleva teema täielikkusele, tahan juhtida tähelepanu mõningatele nüanssidele, mida tasub arvestada pilveteenuse pakkuja valiku osas turvalisuse perspektiivist. Artikli lõpus on esitatud kontrollnimekiri, mida tuleks täita, enne kui leiate, et pilveküberturbe jälgimise küsimus on lahendatud.

Võib tuvastada mitu tüüpilist probleemi, mis toovad kaasa juhtumeid pilvkeskkondades, millele küberturbe teenused ei jõua reageerida või ei märka neid üldse:

• Turvalogid puuduvad. See on üsna levinud olukord, eriti esialgsetel pilveteenuste turu mängijatel. Kuid ei tohiks neid kohe tõsiselt maha kanda. Väikesed tegijad, eriti kodumaised, on rohkem tundlikud klientide nõudmiste suhtes ja võivad kiiresti rakendada mõningaid nõutud funktsioone, muutes oma toodete kinnitatud teekaarti. Jah, see ei ole Amazonist pärit GuardDuty või Bitrixi „Proaktiivse kaitse” mooduli analoog, aga vähemalt midagi.
• Küberturbe teenustel ei ole teadmiseks, kus logid asuvad või neile ei pääse ligi. Siin on tarvis alustada läbirääkimisi pilveteenuse pakkujaga — võib-olla annab ta sellist teavet, kui peab klienti enda jaoks oluliseks. Kuid üldiselt ei ole see väga hea, kui ligipääs logidele antakse „erilise otsuse” alusel.
• On olukordi, kus pilveteenuse pakkujal on logid olemas, kuid need pakuvad piiratud jälgimist ja sündmuste registreerimist, mis ei piisa kõikide intsidentide tuvastamiseks. Näiteks võidakse anda ainult veebilehe muudatuste logid või kasutajate autentimise katsed, kuid muid sündmusi, näiteks võrguliikluse kohta, ei väljastata, mis varjab teilt olulisi andmeid, mis iseloomustavad katseid teie pilvi infrastruktuuri sisenemiseks.
• Logid on olemas, kuid nendele ligipääsu automatiseerimine on keeruline, mistõttu tuleb neid jälgida mitte pidevalt, vaid ajakava alusel. Ja kui logisid ei saa automaatsetes režiimides laadida, siis logide eksportimine, näiteks Exceli formaadis (nagu paljudel kodumaistel pilvelahenduste pakkujatel), võib viia korporatiivsete infotehnoloogia teenistuste soovimatuse nende kallal vaeva näha.
• Logide jälgimist ei ole. See on ilmselt kõige arusaamatum põhjus, miks pilves pärast intsidente tekivad. Näiliselt on logid olemas ja nendele ligipääsu saab automatiseerida, kuid keegi seda ei tee. Miks?

Jagatud pilve turvakontseptsioon

Üleminek pilve tähendab alati tasakaalu otsimist soovide vahel, et säilitada kontroll infrastruktuuri üle ja usaldada see professionaalse pilveteenuse osutaja kätte, kes on spetsialiseerunud selle hooldamisele. Samuti tuleb seda tasakaalu otsida ka pilvekeskkondade turvalisuse valdkonnas. Eelkõige seetõttu, et sõltuvalt kasutatavast pilveteenuse mudelist (IaaS, PaaS, SaaS) on see tasakaal pidevalt erinev. Ükskõik, kuidas see välja kukub, tuleb meeles pidada, et kõik pilveteenuse pakkujad järgivad täna nn jagatud vastutuse ja jagatud küberturbe mudelit. Pilv vastutab millegi eest, klient, kes on pilve oma andmed, rakendused, virtuaalmasinad ja muud ressursid paigutanud, vastutab millegi eest. Naivseks oleks eeldada, et pilve minnes saame kogu vastutuse teenuse osutaja kaela laadida. Kuid ka kogu turvalisuse iseseisev ülesehitamine pilve minekul ei ole mõistlik. On vajalik tasakaal, mis sõltub paljusid teguritest: - riskijuhtimisstrateegiast, ähvardusmudelist, olemasolevatest kaitsemehhanismidest, mis on pilveteenuse pakkujal, seadusandlusest jne.

Andmete klassifitseerimine, mis on salvestatud pilve, on alati tellija vastutus. Pilveteenuse pakkuja või väline teenuseosutaja võib aidata ainult vahenditega, mis aitavad andmeid pilves märgistada, tuvastada rikkumisi, kustutada seadusega vastuolus olevaid andmeid või varjata neid teatud viisil. Teisalt on füüsiline turvalisus alati pilveteenuse pakkuja vastutus, mida ta ei saa klientidega jagada. Kogu, mis jääb andmete ja füüsilise infrastruktuuri vahele, ongi selle artikli arutelu teema. Näiteks on pilve kättesaadavus teenusepakkuja vastutus, kuid MSO reeglite seadistamine või krüpteerimise lubamine on juba kliendi kohustus. Selles artiklis vaatame, millised turvalisuse jälgimise mehhanismid on täna erinevatel Venemaa pilveteenuse pakkujatel, millised on nende rakendamise eripärad ning millal tasub mõelda välistatud lahendustele (näiteks Cisco E-mail Security), mis laiendavad teie pilve küberjulgeoleku võimalusi. Teatud juhtudel, eriti mitmepilvestrateegiaid järgides, ei jää teil muud valikut, kui kasutada turvalisuse jälgimise välislahendusi mitmes pilves (näiteks Cisco CloudLock või Cisco Stealthwatch Cloud). Ja teatud juhtudel mõistate, et teie valitud (või teile peale surutud) pilveteenus ei paku absoluutselt mingeid võimalusi turvalisuse jälgimiseks. See on ebameeldiv, kuid samas oluline, sest see võimaldab adekvaatselt hinnata riski taset, mis on seotud antud pilve kasutamisega.

Pilve turvamonitori elutsükkel

Pilvede turvalisuse jälgimiseks on teil kolm võimalust:

• toetuda oma pilveteenuse pakkuja pakutavatele tööriistadele,
• kasutada kolmandate osapoolte lahendusi, mis jälgivad teie kasutatavaid IaaS, PaaS või SaaS platvorme,
• luua omaenda pilve keskkonna jälgimis infrastruktuur (ainult IaaS/PaaS platvormide jaoks).

Vaatame, millised omadused on igal neist valikutest. Kuid esmalt peame mõistma üldist skeemi, mida kasutatakse pilveplatvormide jälgimisel. Toome välja kuus peamist komponenti pilveturbe jälgimise protsessis:

• Infrastruktuuri ettevalmistamine. Vajalikud rakendused ja infrastruktuur, et koguda turbe jaoks olulisi sündmusi andmekogusse.
• Kogumine. Selles etapis koondatakse turvasündmused erinevatest allikatest edasiseks töötlemiseks, salvestamiseks ja analüüsimiseks.
• Töötlemine. Selles etapis muudetakse ja rikastatakse andmeid, et hõlbustada nende edasist analüüsi.
• Salvestamine. See komponent vastutab kogutud töötlemise ja "toore" andmete lühiajalise ja pikaajalise säilitamise eest.
• Analüüs. Sellel etapil on teil võimalus tuvastada intsidente ja sellele reageerida automaatse või käsitsi režiimis.
• Aruandlus. See etapp aitab koostada huvirühmadele (juhtkond, audiitorid, pilveteenuse pakkuja, kliendid jne) põhinäitajaid, mis aitavad meil teha teatud otsuseid, näiteks teenusepakkuja vahetamine või küberturbetegevuse tugevdamine.

Nende komponentide mõistmine võimaldab teil edaspidi kiirelt otsustada, mida oma teenusepakkujalt saate ja mida peate tegema ise või kaasates välishaldureid.

Pilveteenuste sisseehitatud võimalused

Olen juba varem maininud, et paljud pilveteenused ei paku täna mingit võimalust teabe turbe (IB) jälgimiseks. Üldiselt ei pöörata sellele teemale suurt tähelepanu. Näiteks üks populaarne Venemaa teenus, mis võimaldab riigiasutustele aruandeid Interneti kaudu edastada (ei maini selle nime). Kogu selle teenuse turvalisuse jaotises räägitakse ainult sertifitseeritud krüptograafilisest kaitsevahendist. Teise kodumaise pilveteenuse jaotises elektrooniliseks dokumendihaldamiseks on turbeosas palju rohkem teavet. Seal räägitakse avatud võtme sertifikaatidest, sertifitseeritud krüptograafiast, veebivulnerabiliteetide kõrvaldamisest, DDoS-rünnakute kaitsmisest, kasutussertifikaadi rakendamisest, andmete varundamisest ja isegi regulaarsetest turbeaudititest. Kuid jälgimise osas ei ole sõnagi, samuti ei räägita juurdepääsu saamisest IB sündmustele, mis võiksid selle teenuse pakkuja klientidele huvi pakkuda.

Üldiselt saab pilveteenuse pakkuja veebisaidil ja dokumentatsioonis infoseisundi küsimuste kirjeldusest aru, kui tõsiselt nad sellele teemale suhtuvad. Näiteks, kui lugeda juhiseid tootele "Minu kontor", siis seal ei ole sõnagi turvalisusest, kuid eraldi tootest "Minu kontor. KS3", mis on mõeldud volitamata juurdepääsu kaitsmiseks, on tavaline loetelu FSTEKi 17. korralduse punktidest, mida täidab "Minu kontor. KS3", kuid ei ole selgitatud, kuidas seda tehakse ja mis kõige tähtsam, kuidas integreerida neid mehhanisme ettevõtte infoseisundisse. Võib-olla selline dokumentatsioon eksisteerib, kuid ma ei leidnud seda "Minu kontori" veebisaidilt. Kuigi võib-olla on mul lihtsalt sellele salajasele teabele juurdepääs keelatud...?

Sama Bitrixi puhul on olukord selgelt parem. Dokumentatsioonis on kirjeldatud sündmuste logifailide vormate ja huvitaval kombel ka sissetungi logi, mis sisaldab sündmusi, mis on seotud potentsiaalsete ohtudega pilveplatvormile. Sealt saate välja võtta IP-aadressi, kasutajanime või külalise nime, sündmuse allika, aja, User Agenti, sündmuse tüübi jne. Tõsi, nende sündmustega töötamine on võimalik kas pilve juhtpaneelilt või andmete eksportimise kaudu MS Exceli formaati. Bittirxi logide automatiseerimine on praegu keeruline ning peate osa tööst tegema käsitsi (aruande eksportimine ja selle üleslaadimine teie SIEM-i). Kuid kui meenutada, et veel suhteliselt hiljuti ei olnud sellist võimalust, on see suur edasiminek. Samas tahan märkida, et ka paljud välismaised pilveteenuse pakkujad pakuvad sarnast funktsionaalsust 'algajatele' — kas vaata logisid käsitsi juhtpaneeli kaudu või eksporti andmed enda juurde (tõsi, enamus ekspordivad andmed .csv formaadis, mitte Excelis).

Kui mitte arvestada logide puudumist, pakuvad pilveteenuse pakkujad tavaliselt kolme varianti turvasündmuste jälgimiseks — juhtpaneelid, andmete eksport ja nendele API kaudu ligipääs. Esimene variant näib küll paljusid probleeme teie eest lahendavat, kuid see pole päris nii — mitme logi olemasolul tuleb vahetada nende kuvamise ekraanide vahel, kaotades ülevaate olukorrast. Lisaks on ebatõenäoline, et pilveteenuse pakkuja annaks teile võimaluse turvasündmuste korreleerimiseks ja nende analüüsimiseks (tavaliselt tegelete toorete andmetega, millega peate iseseisvalt tutvuma). Erandid on olemas ja neist räägime hiljem. Viimaks tasub uurida, milliseid sündmusi fikseerib teie pilveteenuse pakkuja, mismoodi ja kuivõrd need vastavad teie infotehnoloogia jälgimise protsessile. Näiteks kasutajate ja külaliste tuvastamine ja autentimine. Sama Bitrix võimaldab teil nende sündmuste alusel fikseerida sündmuse kuupäeva ja kellaaja, kasutaja või külalise nime (kui on olemas “Veebianalüüsi” moodul), objekti, millele ligipääseti, ja muid tüüpilisi veebisaidi elemente. Kuid ettevõtte infotehnoloogia teenustele võib olla vajalik teave selle kohta, kas kasutaja pääses pilve juurde usaldusväärsest seadmest (näiteks ettevõtte võrgus viibimise puhul lahendab selle ülesande Cisco ISE). Ja nii lihtne funktsioon nagu geolokatsiooni IP, mis aitaks määrata, kas pilveteenuse kasutaja konto on varastatud? Ja isegi kui pilveteenuse pakkuja seda teile pakub, jääb sellest väheseks. Sama Cisco CloudLock mitte ainult ei analüüsi geolokatsiooni, vaid kasutab selleks masinõpet ja analüüsib ajaloolisi andmeid iga kasutaja kohta ning jälgib erinevaid anomaaliaid tuvastamise ja autentimise katsetes. Sarnane funktsionaalsus on saadaval ka MS Azure puhul (vastava tellimuse olemasolul).

On veel üks keerukus — kuna paljude pilveteenuste pakkujate jaoks on turvaalasüsteemide jälgimine uus teema, millega nad alles alustavad, muudetakse pidevalt nende lahendusi. Täna on neil üks API versioon, homme teine ja ülehomme kolmas. Sellega tuleb samuti arvestada. Sama kehtib ka funktsionaalsuse kohta, mis võib muutuda ja mida tuleb oma turvaalasüsteemi jälgimises arvesse võtta. Näiteks, Amazonil olid alguses eraldi pilveürituste jälgimise teenused — AWS CloudTrail ja AWS CloudWatch. Siis tuli välja eraldi teenus turvaalasüsteemide jälgimiseks — AWS GuardDuty. Mõne aja pärast käivitas Amazon uue haldussüsteemi Amazon Security Hub, mis hõlmab andmete analüüsi, mida saadakse GuardDuty, Amazon Inspectori, Amazon Macie ja teiste teenuste kaudu. Teine näide on Azure logide integreerimistööriist SIEM-ile — AzLog. Seda kasutati aktiivselt paljude SIEM-i müüjate poolt, kuni Microsoft kuulutas 2018. aastal välja selle arendamise ja toe lõpetamise, mis tõi paljudele selle tööriista kasutajatele kaasa probleeme (kuidas see lahendati, arutame hiljem).

Seetõttu jälgige hoolikalt kõiki jälgimisfunktsioone, mida pakub teie pilveteenuse pakkuja. Või usaldage väliseid lahenduspakkujaid, kes toimivad vahendajatena teie SOC-i ja pilve vahel, mida soovite jälgida. Jah, see on kallim (kuigi mitte alati), kuid seetõttu kandite kogu vastutuse teiste õlgadele. Või mitte kogu?.. Tuletame meelde jagatud turvalisuse kontseptsiooni ja mõistame, et me ei saa vastutust täielikult üle kanda — peame ise läbi uurima, kuidas erinevad pilveteenuse pakkujad tagavad teie andmete, rakenduste, virtuaalmasinate ja muude pilves paiknevate ressursside jälgimise. Alustame Amazonist ja sellest, mida see pakub selles osas.

Näide: IaaS-i andme- ja rakenduste turvamonitooring AWS-is

Jah, ma mõistan, et Amazon ei ole kõige parem näide, kuna see on Ameerika teenus ja seda võidakse blokeerida seoses ekstremismi ja Venemaal keelatud teabe levitamise vastu võitlemisega. Kuid selles publikatsioonis soovin ma lihtsalt näidata, kui erinevad on erinevad pilveplatvormid IT-jälgimise võimaluste osas ja millele tuleks tähelepanu pöörata oma kriitiliste protsesside pilve viimise juures turvalisuse aspektist. Kui mõned Venemaa pilvesaadete arendajad saavad sealt midagi kasulikku, siis oleks see suurepärane.

Esiteks tuleb öelda, et Amazon ei ole ületamatu kindlus. Selle klientidega juhtub regulaarselt erinevaid intsidente. Näiteks Deep Root Analytics'ilt varastati 198 miljoni valija nimed, aadressid, sünnikuupäevad ja telefoninumbrid. Iisraeli ettevõttelt Nice Systems varastati 14 miljonit Verizon'i abonentide salvestust. Samas võimaldavad AWSi sisseehitatud funktsioonid teil avastada laia valiku intsidente. Näiteks:

• infrastruktuuri rünnak (DDoS)
• sõlme kompromiteerimine (käskude süstimine)
• konto kompromiteerimine ja volitamata ligipääs
• vale konfiguratsioon ja haavatavused
• kaitsmata liideseid ja API-sid.

See vastukäive tuleneb sellest, et kliendi andmete turvalisuse eest, nagu eelnevalt selgitasime, vastutab klient ise. Kui ta ei ole mures kaitsemehhanismide sisselülitamise ega jälgimistööriistade seadistamise pärast, siis saab ta juhtumist teada ainult meedia kaudu või oma klientidelt.

Incidentide tuvastamiseks saab kasutada erinevaid jälgimisteenuseid, mida on arendanud Amazon (kuigi neid täiendavad sageli välisharjutused, näiteks osquery). AWS-is jälgitakse kõiki kasutajate tegevusi, sõltumata sellest, kuidas need on tehtud — läbi halduskonsooli, käsurealiideses, SDK või muude AWS teenuste kaudu. Kõik iga AWS konto tegevuse logid (sealhulgas kasutajanimi, tegevus, teenus, tegevuse parameetrid ja tulemused) ning API kasutamine on saadaval AWS CloudTraili teenuse kaudu. Saate kuvada neid sündmusi (näiteks sisselogimist AWS IAM konsooli) CloudTraili konsoolist, analüüsida neid Amazon Athenaga või edastada neid välisharjutustele nagu Splunk, AlienVault jne. AWS CloudTraili logid salvestatakse teie AWS S3 ämbritesse.

Kaks muud AWS teenust pakuvad veel mitmeid olulisi jälgimisvõimalusi. Esiteks on Amazon CloudWatch AWS-i ressursside ja rakenduste jälgimise teenus, mis võimaldab muu hulgas tuvastada erinevaid anomaaliaid teie pilves. Kõik AWS-i sisseehitatud teenused, nagu Amazon Elastic Compute Cloud (serverid), Amazon Relational Database Service (andmebaasid), Amazon Elastic MapReduce (andmeanalüüs) ja veel 30 muud Amazoni teenust, kasutavad logide salvestamiseks Amazon CloudWatch'i. Arendajad saavad kasutada Amazon CloudWatch'i avatud API-t, et lisada logide jälgimise funktsionaalsust oma kohandatud rakendustesse ja teenustesse, laiendades seeläbi analüüsitavate sündmuste ulatust küberturbe kontekstis.

Teiseks, VPC Flow Logs teenus võimaldab analüüsida võrgu liiklust, mille teie AWS serverid saadavad või saavad (väljast või seest), samuti mikroteenuste vahel. Kui mõni teie AWS VPC ressurs ostab või suhelda võrguga, salvestab VPC Flow Logs teenus teavet võrgu liikluse kohta, sealhulgas allika ja sihtkoha võrgu liidese, samuti IP-aadressid, pordid, protokoll, baitide arv ja pakettide arv, mida olete näinud. Need, kes on töötanud kohaliku võrgu kaitsega, tunnevad seda analoogina voogudest NetFlow, mis võivad olla genereeritud ettevõtte tasandi lülitite, ruuterite ja tulemürete poolt. Need logid on olulised infoturbe jälgimise eesmärkidel, sest erinevalt kasutajate ja rakenduste tegevuste sündmustest võimaldavad nad ka mitte tähelepanuta jätta võrgu suhtlemist virtuaalses erasektori AWS keskkonnas.

Seega pakuvad need kolm AWS-teenust — AWS CloudTrail, Amazon CloudWatch ja VPC Flow Logs — koos piisavalt tõhusat ülevaadet teie konto kasutamisest, kasutajate käitumisest, infrastruktuuri haldamisest, rakenduste ja teenuste aktiivsusest ning võrguaktiivsusest. Näiteks nende abil on võimalik tuvastada järgmised kõrvalekalded:

• Saidi skaneerimise katsed, tagasiulatuvate uksete otsimine, haavatavuste otsimine läbi „404 viga” puhangute.
• Sisestusrünnakud (nt SQL injection) läbi „500 viga” puhangute.
• Tuntud tööriistad sqlmap, nikto, w3af, nmap jne rünnakute tuvastamiseks kasutajaagendi välja analüüsi kaudu.

Amazon Web Services on küberturvalisuse eesmärkidel välja töötanud ka teisi teenuseid, mis aitavad lahendada mitmeid teisi probleeme. Näiteks AWS-is on sisseehitatud teenus poliitikate ja konfiguratsioonide auditeerimiseks — AWS Config. See teenus tagab teie AWS-i ressursside ja nende konfiguratsioonide pideva auditeerimise. Vaatame lihtsat näidet: oletame, et soovite veenduda, et kasutajate paroolid on kõigis teie serverites keelatud ja ligipääs on võimalik ainult sertifikaatide alusel. AWS Config võimaldab seda hõlpsasti kontrollida kõigi teie serverite jaoks. On ka teisi poliitikaid, mida saab rakendada teie pilveserveritele: „Ükski server ei tohi kasutada porti 22“, „Ainult administraatorid saavad muuta tulemüüri reegleid“ või „Ainult kasutaja Ivashko võib luua uusi kasutajakontosid, ja ta võib seda teha ainult teisipäeviti“. 2016. aasta suvel laiendati teenust AWS Config, et automatiseerida välja töötatud poliitikate rikkumiste tuvastamist. AWS Config Rules on sisuliselt pidevad konfiguratsiooni päringud, mida kasutate Amazon teenustes, mis genereerivad sündmusi, kui vastavaid poliitikaid rikutakse. Näiteks selle asemel, et perioodiliselt teha AWS Config päringuid, et kontrollida, kas kõik virtuaalserveri kettad on krüpteeritud, saab AWS Config Rules kasutada, et pidevalt kontrollida serverikettaste vastavust sellele tingimusele. Ja mis kõige tähtsam, käesoleva väljaande kontekstis genereerivad mis tahes rikkumised sündmusi, mida teie küberturbe teenus saab analüüsida.

AWS-l on ka oma vasted traditsioonilistele ettevõtte andmekaitse lahendustele, mis genereerivad turvasekke, mida peaksite analüüsima:

• sissetungide avastamine — AWS GuardDuty
• info lekete kontroll — AWS Macie
• EDR (kuigi on veidi kummaline rääkida pilvandmetöötlusesse kuuluvatest lõpp-punktidest) — AWS Cloudwatch + avatud lähtekoodiga lahendused osquery või GRR
• Netflow analüüs — AWS Cloudwatch + AWS VPC Flow
• DNS analüüs — AWS Cloudwatch + AWS Route53
• AD — AWS Directory Service
• kasutajate haldus — AWS IAM
• SSO — AWS SSO
• turvalisuse analüüs — AWS Inspector
• konfiguratsioonide haldus — AWS Config
• WAF — AWS WAF.

Ma ei hakka üksikasjalikult loetlema kõiki Amazoni teenuseid, mis võivad olla kasulikud andmekaitse kontekstis. Oluline on mõista, et kõik need teenused saavad genereerida sündmusi, mida peame analüüsima andmekaitse kontekstis, kasutades selleks nii Amazoni enda sisseehitatud võimalusi kui ka välist lahendust, näiteks SIEMi, mis saavad edastada turvasüsteemide sündmusi teie jälgimiskeskusesse ja analüüsida neid koos teiste pilveteenustelt või sisemisest infrastruktuurist, perimeetrist või mobiilseadmetest saadud sündmustega.

Igal juhul algab kõik andmeallikatest, mis pakuvad teile IKT sündmusi. Selliste allikate hulka kuuluvad muu hulgas:

• CloudTrail — API kasutamine ja kasutajate tegevused
• Trusted Advisor — turvaskaanimine parimate praktikate järgi
• Config — kontode ja teenuste seadete inventuur ja konfigureerimine
• VPC Flow Logs — ühendused virtuaalsete liidestega
• IAM — identifitseerimise ja autentimise teenus
• ELB Access Logs — koormusebalanseerija logid
• Inspector — rakenduste haavatavused
• S3 — failide salvestamine
• CloudWatch — rakenduste aktiivsus
• SNS — teatiste teenus.

Amazon, pakkudes sellist sündmuste allikate ja nende genereerimise tööriistade spektrit, on samas tugevalt piiratud kogutud andmete analüüsi võimalustes IT-öises kontekstis. Te peate ise uurima olemasolevaid logisid, otsides neist vastavaid kompromiteerimise indikaatoreid. AWS Security Hub, mille Amazon just lansseeris, on mõeldud selle probleemi lahendamiseks, olles nagu pilve SIEM AWS-i jaoks. Kuid praegu on see alles oma teekonna alguses ja piiratud nii allikate arvuga, millega ta töötab, kui ka teiste piirangutega, mis on kehtestatud Amazoni arhitektuuri ja tellimuste poolt.

Näide: IT-ohutuse monitooring IaaS Azure'i baasil

Ma ei soovi pikaaegset arutelu, kumb kolme pilveteenuse pakkujast (Amazon, Microsoft või Google) on parem (veelgi enam, et igal neist on oma kindel eripära ja need sobivad erinevate ülesannete lahendamiseks); keskendume nende pakkujate poolt pakutavatele võimalustele seire jaoks. Tuleb tunnistada, et Amazon AWS oli selles valdkonnas üks esimesi ja seetõttu on nad oma infotehnoloogia funktsioonide osas kõige kaugemale jõudnud (kuigi paljud tunnustavad, et nende kasutamine võib olla keeruline). Kuid see ei tähenda, et me ei võtaks arvesse Microsofti ja Google’i pakutavaid võimalusi.

Microsofti tooted on alati silma paistnud oma "avatuse" poolest, ja sama kehtib ka Azure'i puhul. Näiteks, kui AWS ja GCP lähtuvad alati printsiibist "kõik, mis ei ole lubatud, on keelatud", siis Azure'i lähenemine on otseselt vastupidine. Näiteks, luues virtuaalset võrku pilves ja seal virtuaalmasina, on kõik pordid ja protokollid vaikimisi avatud ja lubatud. Seetõttu tuleb teil teha veidi rohkem pingutusi Microsofti pilvekasutuse juurdepääsu haldamise algse seadistamise osas. Samuti seab see teile rangemad nõuded Azure'i pilve tegevuse jälgimise osas.

AWS-l on omadus, et kui jälgite oma virtuaalseid ressursse erinevates regioonides, siis esinevad raskused, kui soovite kõikide sündmuste kokkuvõtteid ja nende analüüsi. Selle lahendamiseks tuleb kasutusele võtta erinevaid trikke, näiteks luua oma kood AWS Lambda jaoks, mis kannab sündmused erinevate regioonide vahel. Azure's sellist probleemi ei esine – selle Activity Log mehhanism jälgib kogu organisatsiooni tegevust ilma piiranguteta. Sama kehtib ka AWS Security Hub'i kohta, mille Amazon hiljuti arendas turvafunktsioonide konsolideerimiseks ühe ohutuse keskuses, kuid ainult oma regiooni piires, mis Venemaa jaoks ei ole aktuaalne. Azure'il on oma Security Center, mis ei ole seotud regionaalsete piirangutega, pakkudes juurdepääsu kõikidele pilveteenuse turvafunktsioonidele. Veelgi enam, erinevatele kohalikele meeskondadele võib see pakkuda enda kaitsevõimaluste komplekti, sealhulgas nende hallatavaid turvaseisundeid. AWS Security Hub alles püüab muutuda sarnaseks Azure Security Center'iga. Kuid siia tuleb lisada ka varjatud probleem – Azure's saate kasutada palju sellest, mis on varem AWS-is kirjeldatud, kuid kõige mugavamalt toimub see ainult Azure AD, Azure Monitor ja Azure Security Center'i puhul. Kõik muud Azure'i kaitsemehhanismid, sealhulgas turvasündmuste analüüs, ei ole praegu kõige mugavama haldamise all. Osaliselt lahendab probleemi API, mis läbib kõiki Microsoft Azure teenuseid, kuid see nõuab teie pilve integreerimist teie SOC-iga ja kvalifitseeritud spetsialistide olemasolu (nagu ka igasuguste teiste SIEMidega, mis töötavad pilve API-dega). Mõned SIEMid, millest räägitakse hiljem, toetavad juba Azure'i ja võivad automatiseerida selle jälgimist, kuid sellega on ka enda keerukused – mitte kõik neist ei suuda koguda kõiki logisid, mis Azure'il on.

Azure'is sündmuste kogumine ja nende jälgimine toimub Azure Monitor teenuse kaudu, mis on Microsofti pilve ja selle ressursside — näiteks Git repositooriumite, konteinerite, virtuaalmasinate ja rakenduste — peamine andmete kogumise, salvestamise ja analüüsi tööriist. Kõik Azure Monitor'i kogutavad andmed jagunevad kaheks kategooriaks: reaalajas kogutud mõõdikud, mis kirjeldavad Azure'i pilve võtme tulemusi, ja logifailid, mis sisaldavad ressursi ja teenuste tegevuse konkreetseid aspekte iseloomustavaid andmeid. Lisaks võib Azure Monitor teenus Data Collector API kaudu koguda andmeid igast REST-allikast, et luua oma jälgimisstsenaariume.

Siin on mõned turvasündmuste allikad, mida Azure teile pakub ja millele saate juurde pääseda Azure'i portaali, CLI, PowerShelli või REST API kaudu (ja mõned ainult Azure Monitor'i / Insight API kaudu):

• Tegevuslogid — see ajakiri vastab klassikalistele küsimustele “kes”, “mida” ja “millal” seoses mis tahes kirjeoperatsiooniga (PUT, POST, DELETE) pilvressursside üle. Lugemisõiguste (GET) sündmused selle ajakirja ei jõua, samuti mõned teised.
• Diagnostikalogid — sisaldab andmeid operatsioonide kohta, mis on seotud teie tellimuses olevate ressurssidega.
• Azure AD raportimine — sisaldab nii kasutajate tegevust kui ka süsteemi tegevust, mis on seotud rühmade ja kasutajate haldamisega.
• Windowsi sündmuste logi ja Linuxi Syslog — sisaldab sündmusi virtuaalmasinatelt, mis asuvad pilves.
• Mõõdikud — sisaldab telemeetriat teie pilveteenuste ja ressursside jõudluse ja “tervise” seisundi kohta. Need mõõdetakse igal minutil ja hoitakse 30 päeva jooksul.
• Võrgu turberühma voogude logid — sisaldab andmeid võrgu turbe sündmuste kohta, mida kogutakse Network Watcher teenuse ja võrgu taseme ressursside jälgimise abil.
• Säilitamislogid — sisaldab sündmusi, mis on seotud juurdepääsuga ladustamisresurssidele.

Jälgimiseks võite kasutada väliseid SIEM-süsteeme või sisseehitatud Azure Monitorit ja selle pistikprogramme. Räägime veel teabehalduse süsteemidest, aga vaatame, mida Azure iseenesest pakub andmete analüüsimiseks turvalisuse kontekstis. Peamine ekraan, mis on seotud Azure Monitori turvalisuse ja auditi jälgimisega, on Log Analytics Security and Audit Dashboard (tasuta versioon toetab piiratud arvu sündmuste säilitamist vaid ühe nädala). See paneel on jagatud viieks peamiseks valdkonnaks, mis visualiseerivad kokkuvõtlikku statistikat selle kohta, mis toimub teie kasutatavas pilvemajas:

• Turvadomeenid — peamised kvantitatiivsed näitajad, mis on seotud informaatikaga — juhtumite arv, kompromiteeritud sõlmede arv, patcheeritud sõlmed, võrgu turbe sündmused jne.
• Olulised probleemid — kuvab aktiivsete turbeprobleemide arvu ja tähtsuse
• Avastused — kuvab mustreid, mis on kasutatud teie vastu suunatud rünnakute korral
• Ohtude teabe kogumine — kuvab geograafilist teavet välistest sõlmedest, mis teid ründavad
• Üldised turbe päringud — tüüpilised päringud, mis aitavad teil paremini jälgida teie informaatikat.

Azure Monitori laiendustena võib nimetada Azure Key Vault'i (kryptograafiliste võtmete kaitse pilves), Malware Assessment'i (kahjuritarkvara kaitse analüüs virtuaalmasinates), Azure Application Gateway Analytics'i (sealhulgas pilveteenuste tulemüüri logide analüüs) jne. Need tööriistad, mis on rikastatud konkreetsete sündmuste töötlemise reeglitega, võimaldavad visualiseerida erinevaid pilveteenuste tegevuse aspekte, sealhulgas turvalisust, ja tuvastada tööde kõrvalekaldeid. Kuid, nagu sageli juhtub, vajab iga täiendav funktsioon vastavat tasulist tellimust, mis nõuab teilt vastavaid rahalisi investeeringuid, mida peaksite eelnevalt planeerima.

Azure’il on mitmeid sisseehitatud ohutusmonitorimise võimalusi, mis on integreeritud Azure AD, Azure Monitori ja Azure Security Centeriga. Nende hulka kuuluvad näiteks virtuaalmasinate suhtlemise tuvastamine tuntud pahavara IP-dega (tänu Microsofti Threat Intelligence teenuste integreerimisele), pahavara tuvastamine pilvinfrastruktuuris häiresignaalide kaudu virtuaalmasinatelt, mis asuvad pilves, virtuaalmasinatele suunatud sõnumite “paroolide proovimise” rünnakud, kasutajate tuvastamise süsteemi konfiguratsiooni haavatavused, sisenemine anonüümselt või nakatunud sõlmede kaudu, konto lekkeid, sisenemine ebatavalistest asukohtadest jne. Tänaseks on Azure üks haruldasi pilveteenuse pakkujaid, kes pakub sisseehitatud Threat Intelligence võimalusi kogutud infoturbe sündmuste rikastamiseks.

Nagu juba varem mainitud, ei ole kaitsefunktsioonid ja seega genereeritud turbeefektid kõikidele kasutajatele võrdselt kättesaadavad, vaid nõuavad teatud tellimuse olemasolu, mis sisaldab vajalikku funktsionaalsust, mis genereerib vastavad sündmused infoturbetegevuse jälgimiseks. Näiteks on osa eelpool kirjeldatud kontode ebanormaalsuste monitoorimise funktsioonidest saadaval ainult Azure AD teenuse premium P2 litsentsiga. Ilma selleta, nagu ka AWS-i puhul, peate turbeefektide kogumise analüüsima „käeliselt“. Samuti sõltub Azure AD litsentsi tüübist, millised sündmused on analüüsimiseks saadaval.

Azure'i portaalis saate hallata nii otsingupäringuid teile huvipakkuvatesse logidesse kui ka konfigureerida armatuurlaudu infotehnoloogia peamiste näitajate visualiseerimiseks. Lisaks saate seal valida Azure Monitori laiendusi, mis võimaldavad teil laiendada Azure Monitori logide funktsionaalsust ja saada süvitsi minevat analüüsi sündmustest turbe vaatenurgast.

Kui vajate mitte ainult logide haldamise võimalust, vaid ka laiaulatuslikku turvakeskust oma Azure'i pilveplatvormi jaoks, sealhulgas küberturbe poliitikate haldamist, siis tuleks rääkida Azure Security Centeri kasutamisest. Selle enamus kasulikke funktsioone on saadaval lisatasu eest, näiteks ohtude tuvastamine, Azure'ist väljaspool jälgimine, vastavuse hindamine jne. (tasuta versioonis on teil juurdepääs ainult turvahindamisele ja soovitustele tuvastatud probleemide lahendamiseks). See koondab kõik turvaküsimused ühte kohta. Tegelikult võib öelda, et see pakub kõrgemat küberturbe taset kui Azure Monitor, kuna antud juhul rikastatakse kogu teie pilveettevõttest kogutud andmeid mitmete allikatega, nagu Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) ja Microsoft Security Response Center (MSRC), millele lisanduvad erinevad keerukad masinõppe ja käitumusliku analüüsi algoritmid, mis lõpuks peaksid suurendama ohtude tuvastamise ja neile reageerimise tõhusust.

Azure'l on ka oma SIEM — see ilmnes 2019. aasta alguses. See on Azure Sentinel, mis toetub Azure Monitor'i andmetele ja suudab integreeruda ka väliste turvalahendustega (näiteks NGFW või WAF), mille nimekiri pidevalt täieneb. Lisaks võimaldab Microsoft Graph Security API integreerimine teil lisada Sentineli oma Threat Intelligence andmevooge, mis rikastab juhtumite analüüsi võimalusi teie Azure'i pilves. Võib öelda, et Azure Sentinel on esimene "kohalik" SIEM, mis on välja töötatud pilveteenuse pakkujate poolt (näiteks Splunk või ELK, mida saab majutada pilves nagu AWS, on ikkagi loodud traditsiooniliste pilveteenuste pakkujate poolt). Azure Sentinel ja Security Center võiksid olla Azure'i pilve SOC ja nendega võiks piirduda (teatud ettevaatustega), kui teil ei oleks enam mingit infrastruktuuri ja kõik teie arvutusressursid oleksid üle viidud pilve ning see oleks Microsoft Azure'i pilv.

Kuna Azure'i sisseehitatud funktsioonid (isegi kui Sentinel'i tellimus on olemas) ei pruugi sageli piisata teabe turvalisuse jälgimise eesmärkideks ja selle protsessi integreerimiseks teiste turvasündmuste allikatega (nii pilves kui kohapeal), tekib vajadus kogutud andmete eksportimiseks välistesse süsteemidesse, mille hulka võib kuuluda ka SIEM. Seda teostatakse nii API kaudu kui ka spetsiaalsete laienduste abil, mida praegu ametlikult pakuvad järgmised SIEM-id — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ja ELK. Veel hiljuti oli selliseid SIEM-e rohkem, kuid 1. juuni 2019. aastast lõpetas Microsoft Azure Log Integration Tool'i (AzLog) toe, mis varajases Azure'i eksisteerimise perioodis ja korrapärase logitöötluse standardiseerimise puudumisel (Azure Monitor polnud veel olemas) võimaldas hõlpsalt integreerida väliseid SIEM-e Microsofti pilve. Praegu on olukord muutunud ja Microsoft soovitab Azure Event Hub'i platvormi peamise integreerimistööriistana teistele SIEM-idele. Paljud on juba sellise integratsiooni teinud, kuid olge ettevaatlikud — nad ei pruugi hõlmata kõiki Azure'i logisid, vaid vaid teatud (vt oma SIEM-i dokumentatsiooni).

Kokkuvõttes Azure'ist soovin anda üldise soovituse selle pilveteenuse kohta: enne kui kinnitate midagi Azure'i turbe- ja häiremonitooringu funktsioonide osas, seadistage need hoolikalt ja testige, et need töötavad nii, nagu on kirjas dokumentatsioonis, ja nagu Microsofti konsultandid teile rääkisid (neil võivad olla erinevad arvamused Azure'i funktsioonide toimivuse kohta). Finantsteenuste olemasolul saate Azure'ist välja pigistada palju kasulikku turbe monitooringu osas. Kuid kui teie ressursid on piiratud, peate nagu AWS-i puhul lootma ainult oma jõududele ja tooretele andmetele, mida Azure Monitor teile annab. Ja pidage meeles, et paljude monitooringufunktsioonide eest tuleb maksta ning hinnapoliitikaga on parem eelnevalt tutvuda. Näiteks saate tasuta hoida andmeid 31 päeva kuni 5 GB suuruses tellimuses — nende väärtuste ületamine nõuab teilt lisakulutusi (umbes 2+ dollarit iga täiendava GB hoidmise eest tellija puhul ja 0,1 dollarit iga täiendava GB hoidmise eest iga kuu). Rakenduste telemeetria ja mõõdikute kasutamine võib samuti nõuda täiendavaid rahalisi vahendeid, nagu ka häirede ja teatistega tegelemine (teatud piirmäär on tasuta, kuid see ei pruugi teie vajadusi rahuldada).

Näide: IaaS-i turvalisuse jälgimine Google Cloud Platformil

Google Cloud Platform paistab AWS-i ja Azure'i taustal noorelt välja, kuid see on osaliselt hea. Erinevalt AWS-ist, mis on oma funktsioone, sealhulgas turvalisust, järk-järgult täiustanud ja kesksuse probleemide tõttu vaeva näinud, on GCP, nagu ka Azure, palju paremini keskset haldamist võimaldav, vähendades vigu ja juurutamise aega ettevõttes. Turvalisuse seisukohalt asub GCP kummalisel kombel AWS-i ja Azure'i vahel. Tal on ka kõikjal organisatsioonis sündmustekirje registreerimine, kuid see ei ole täielik. Mõned funktsioonid on veel beetarežiimis, kuid see puudus peaks järk-järgult olema kõrvaldatud ning GCP-ist saab küberturvalisuse jälgimise seisukohalt küpsem platvorm.

GCP põhivahend sündmustekirjete registreerimiseks on Stackdriver Logging (sarnane Azure Monitorile), mis võimaldab teil koguda sündmusi kogu oma pilveinfrastruktuuris (aga ka AWS-is). Turvalisuse aspektist on GCP-l igal organisatsioonil, projektil või kaustal neli registreerimislogi:

• Admin Activity — sisaldab kõiki haldustoimingutega seotud sündmusi, nagu virtuaalmasina loomine, juurdepääsuõiguste muutmine jne. See logi kirjutatakse alati, sõltumata teie soovidest, ning salvestatakse andmed 400 päevaks.
• Data Access — sisaldab kõiki andmete haldamisega seotud sündmusi pilvekasutajate poolt (loomine, muutmine, lugemine jne). Vaikimisi seda logi ei kirjuta, kuna selle maht paisub väga kiiresti. Seetõttu on selle säilivusaeg vaid 30 päeva. Lisaks ei kirjutata sellesse logi kaugeltki mitte kõik. Näiteks ei kajastata seal sündmusi, mis on seotud avalikult kõigile kasutajatele juurdepääsetavate ressurssidega või mis on ligipääsetavad ilma GCP-sse sisselogimata.
• System Event — sisaldab süsteemisündmusi, mis ei ole seotud kasutajatega, või administraatori toimingut, kes muudab pilveressursside konfiguratsiooni. See kirjutatakse alati ja salvestatakse 400 päevaks.
• Access Transparency on ainulaadne registreerimisvahend, mis fikseerib kõik Google'i töötajate tegevused (kuid mitte kõigi GCP teenuste jaoks), kes pääsevad juurde teie infrastruktuurile oma ametialaste kohustuste täitmise käigus. See register säilib 400 päeva ja pole iga GCP kliendi jaoks saadaval, vaid ainult teatud tingimuste täitmise korral (kas Gold või Platinum taseme tugi, või neli teatud tüüpi rolli ettevõtte toe raames). Sarnane funktsioon on näiteks ka Office 365-s — Lockbox.

Registri näide: 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.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"
}

Logidele on võimalik juurde pääseda mitmel viisil (peaaegu nagu varem käsitletud Azure ja AWS) — Log Viewer'i liidese, API, Google Cloud SDK või teie projekti Activity lehe kaudu, kus teid huvitavad sündmused. Neid on võimalik ka eksportida välistesse lahendustesse täiendavaks analüüsiks. Viimane toimub logide eksportimise kaudu BigQuery või Cloud Pub/Sub salvestusse.

Lisaks Stackdriver Logging'ule pakub GCP platvorm ka Stackdriver Monitoring funktsiooni, mis võimaldab jälgida pilveteenuste ja rakenduste võtmemétrikaid (täitmine, rikke aeg, üldine seisund jne). Spetsiaalselt töötlemine ja visualiseeritud andmed võivad lihtsustada probleemide leidmist teie pilvi infrastruktuuris, sealhulgas ka turvakontekstis. Tuleb siiski märkida, et selle funktsiooni rikkus ei ole just suur turvalisuse kontekstis, kuna GCP-l ei ole tänapäeval analooge AWS GuardDutyle ning ta ei suuda eristada halbu sündmusi kõigi registreeritud sündmuste hulgast (Google on välja töötanud Event Threat Detectioni, kuid see on veel beetaversioonis ja on vara rääkida selle kasulikkusest). Stackdriver Monitoringut võiks kasutada anomaaliate avastamise süsteemina, mille põhjuseid seejärel uuritakse. Kuid turvalisuse alal kvalifitseeritud personali puudumise tõttu GCP-s on see ülesanne praegu keeruline.

Samuti tasub tuua välja nimekiri mõnest IB moodulist, mida saab kasutada teie GCP pilves ja mis on sarnased AWSi pakkumistega:

• Cloud Security Command Center — sarnane AWS Security Hub'ile ja Azure Security Center'ile.
• Cloud DLP — automaatne tundlike andmete tuvastamine ja redigeerimine (nt varjamine), mis on salvestatud pilves, rohkem kui 90 eelseadistatud klassifitseerimispoliitika alusel.
• Cloud Scanner — tuntud haavatavuste skanner (XSS, Flash'i sisestamine, patšimata teegid jne) App Engine'is, Compute Engine'is ja Google Kubernetes'is.
• Cloud IAM — juurdepääsu haldamine kõigile GCP ressurssidele.
• Cloud Identity — GCP kasutajakontode, seadmete ja rakenduste haldamine ühelt platvormilt.
• Cloud HSM — krüptograafiliste võtmete kaitse.
• Cloud Key Management Service — krüptograafiliste võtmete haldamine GCP-s.
• VPC Service Control — turvalise piiri loomine teie GCP ressursside ümber nende lekete kaitsmiseks.
• Titan Security Key — kaitse fidži vastu.

Paljuski neist moodulitest genereerivad turbehäireid, mida saab saata BigQuery ladustamisele analüüsimiseks või eksportimiseks teistesse süsteemidesse, sealhulgas SIEM-idesse. Nagu juba eelnevalt mainitud, on GCP aktiivselt arenev platvorm ja praegu arendab Google mitmeid uusi teabe- ja küberjulgeoleku mooduleid oma platvormile. Nende hulgas on Event Threat Detection (hetkel beetaversioonis), mis skaneerib Stackdriveri logisid, et leida märkide järelevalve tegevust (sarnane GuardDuty'le AWS-is), või Policy Intelligence (hetkel alfa versioonis), mis võimaldab arendada intelligentseid juurdepääsupoliitikaid GCP ressurssidele.

Tegin väikese ülevaate populaarsete pilveteenuste sisseehitatud jälgimisvõimalustest. Kuid kas teil on spetsialiste, kes suudavad töötada IaaS-teenuse pakkuja 'toore' logidega (kõik ei ole valmis ostma AWS-i või Azure'i või Google'i täiustatud võimalusi)? Lisaks on paljudele teada ütlus 'uskuda, kuid kontrollida', mis küberjulgeoleku valdkonnas on tõeliselt aktuaalne. Kui palju usaldusväärsed on teie jaoks pilveteenuse pakkuja sisseehitatud võimalused, mis edastavad teile küberohte? Kuidas nad üldse keskenduvad küberjulgeolekule?

Mõnikord tasub vaadata pilveteenuste turvamonitorimise lahendusi, mis võivad täiendada pilveteenuste sisseehitatud turvameetmeid; mõnikord on need lahendused ainus võimalus saada teavet teie andmete ja rakenduste turvalisuse kohta, mis asuvad pilves. Lisaks on need lahendused lihtsalt mugavamad, kuna nad hoolitsevad kõigi vajalike logide analüüsi eest, mida genereerivad erinevad pilveteenused erinevatelt teenusepakkujatelt. Näiteks selliseks lahenduseks on Cisco Stealthwatch Cloud, mis keskendub ainult ühele ülesandele — eriolukordade jälgimisele pilvekeskkondades, sealhulgas mitte ainult Amazon AWS, Microsoft Azure ja Google Cloud Platform, vaid ka eraklitused.

Näide: Stealthwatch Cloud abil turvamonitorimine

AWS pakub paindlikku arvutusplatvormi, kuid see paindlikkus muudab ettevõtetele lihtsamaks vigu tegemise, mis toob kaasa turvaprobleeme. Jagatud teabe turbe mudel suurendab seda veelgi. Tarkvara käitamine pilves, millel on tundmatud haavatavused (tuntud haavatavuste vastu saab näiteks võidelda AWS Inspectori või GCP Cloud Scanneriga), nõrgad paroolid, valed konfiguratsioonid, siseküljed jne. Kõik see mõjutab pilveressursside käitumist, mida saab jälgida Cisco Stealthwatch Cloud, mis on turva- ja rünnakute avastamise jälgimissüsteem avalikes ja privaatsetes pilvedes.

Üks Cisco Stealthwatch Cloud'i põhifunktsioone on võimalus luua olevike mudeleid. Selle abil saab luua tarkvaramudeli (st peaaegu reaalajas simuleerimise) iga teie pilveressursi kohta (olgu need AWS, Azure, GCP või mõni muu). Need võivad hõlmata servereid ja kasutajaid, samuti teie pilvestrateegiale spetsiifilisi ressursitüüpe, nagu turvagruppide ja teenuste automaatse määramise rühmad (auto-scale). Need mudelid kasutavad sisendi jaoks struktureeritud andmevooge, mida pakuvad pilveteenused. Näiteks AWS-i jaoks on need VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ja AWS IAM. Olevike modelleerimine tuvastab automaatselt kõigi teie ressursside rolli ja käitumise (võib rääkida kogu pilveaktiivsuse jälgimisest). Selliste rollide hulka kuuluvad Androidi või Apple'i mobiilseade, Citrix PVS server, RDP-server, postiserver, VoIP klient, terminaliserver, domeeni kontroller jne. Seejärel jälgib see nende käitumist pidevalt, et tuvastada, millal toimub riskantne või turvarikkumise käitumine. Saate tuvastada paroolide arvu katseid, DDoS rünnakuid, andmelekeid, ebaseaduslikku kaugjuurdepääsu, kahjulike koodide tegevust, haavatavuste skaneerimist ja teisi ohte. Näiteks näeb kaugjuurdepääsu katse iseloomulikust riigist (Lõuna-Korea) Kubernetes klastrisse SSH kaudu välja selline:

Nii näeb välja oletatav teave lekke Postgressi andmebaasist riiki, millega varasemalt ei olnud kokkupuudet:

Lõpuks, nii näeb välja liiga palju ebaõnnestunud SSH-pääsupüüde Hiinast ja Indoneesiast välisest kaugseadmest:

Võtame näiteks, et VPC serveri eksemplar ei tohiks poliitika kohaselt kunagi olla kaugpääsu sihtkoht. Eeldame edasi, et selles arvutis toimus kaugpääs, kuna tulemüürireeglite poliitika muudeti ekslikult. Olendite modelleerimise funktsioon tuvastab ja teatab sellest tegevusest ("Ebatavaline kaugpääs") peaaegu reaalajas ning näitab konkreetset AWS CloudTraili, Azure Monitori või GCP Stackdriver Logimise API-kutsumist (sealhulgas kasutajanimi, kuupäev ja kellaaeg, lisaks muudele detailidele), mis põhjustas Muudatuse MSE reeglisse. Seejärel võib see teave edastada SIEMi analüüsimiseks.

Sarnased võimalused on rakendatud igasugustes pilvkeskkondades, mida toetab Cisco Stealthwatch Cloud:

Olenemiste modelleerimine on ainulaadne automaatika vorm, mis suudab tuvastada varem teadmata probleemid teie inimeste, protsesside või tehnoloogiatega. Näiteks võimaldab see tuvastada muu hulgas järgmisi turvaprobleeme:

• Kas keegi leidis meie kasutatavas tarkvaras tagauks?
• Kas meie pilves on mõni kolmanda osapoole tarkvara või seade?
• Kas autoriseeritud kasutaja kuritarvitab õigusi?
• Kas on tehtud konfiguratsiooniviga, mis võimaldab kaugjuurdepääsu või muud tahtmatut ressursside kasutust?
• Kas meie serveritest ei leki andmeid?
• Kas keegi on üritanud meiega ühendust võtta ebatavalistest geograafilistest kohtadest?
• Kas meie pilv on nakatunud pahavaraga?

IB avastamine võib olla edastatud vastava piletina Slacki, Cisco Spark'i, PagerDuty juhtimissüsteemi või erinevatesse SIEM-idessse, sealhulgas Splunk või ELK. Kokkuvõttes võib öelda, et kui teie ettevõte kasutab mitme pilve strateegiat ega piirdu ühe pilveteenuse pakkujaga, siis antud IB seirevõimaluste rakendamine, mida eelnevalt kirjeldati, teeb Cisco Stealthwatch Cloud'i hea valiku, et saada ühtne seirevõimaluste komplekt juhtivate pilveteenuste nagu Amazon, Microsoft ja Google jaoks. Huvi pakub, et võrreldes Stealthwatch Cloud'i hindadega AWS, Azure või GCP arenenud IB seire litsentside jaoks, võib selguda, et Cisco lahendus osutub isegi odavamaks kui Amazon, Microsoft ja Google'i sisseehitatud võimalused. Paratamatult, kuid see on tõsi. Mida rohkem pilvi ja nende võimalusi te kasutate, seda selgemini ilmneb koondatud lahenduse eelised.

Lisaks saab Stealthwatch Cloud jälgida ka teie organisatsioonis paiknevaid privaatsüsteeme, näiteks Kubernetes konteinerite baasil või jälgides Netflow vooge või võrguliiklust, mis saadakse võrgu seadmete peegeldamise teel (isegi kodumaistelt tootjatelt), AD andmeid või DNS-servereid jne. Kõik need andmed rikastatakse Cisco Talose Threat Intelligence'i teabega, mis on maailma suurim mittetulunduslik küberohtude uurijate grupp.

See võimaldab teil luua ühtse jälgimissüsteemi nii avalike kui ka hübriidpilvede jaoks, mida teie ettevõte kasutada saab. Kogutud teavet saab seejärel analüüsida Stealthwatch Cloud sisseehitatud võimaluste abil või saata teie SIEM-i (vaikimisi toetatakse Splunk, ELK, SumoLogic ja mitmeid teisi).

Selle saavutame artikli esimese osa lõpule, kus käsitlesin IaaS/PaaS platvormide sisemisi ja välist jälgimistööriistu, mis võimaldavad meil kiiresti tuvastada ja reageerida meie ettevõtte valitud pilvemajandustees toimuvatele intsidentidele. Teises osas jätkame teemat ja vaatleme SaaS platvormide jälgimise võimalusi, kasutades näitena Salesforce'i ja Dropboxi, ning üritame kokku võtta ja luua ühtse monitorimisse süsteemi erinevate pilveteenuse pakkujate vahel.

Allikas: habr.com