Pilvede turvalisuse jälgimine

Andmete ja rakenduste üleviimine pilvetehnoloogiasse on uus väljakutse ettevõtte SOC-idele, mis ei ole alati valmis jälgima teiste infrastruktuuri. Netoskopsi andmetel kasutab keskmine ettevõte (ilmselt siiski USA-s) 1246 erinevat pilveteenust, mis on 22% rohkem kui eelmisel aastal. 1246 pilveteenust!!! 175 neist on seotud HR-teenustega, 170 turundusega, 110 kommunikatsiooniga ja 76 rahanduse ja CRM-iga. Cisco kasutab "ainult" 700 välist pilveteenust. Seetõttu tunnen ma natuke segadust nende numbrite üle. Kuid igal juhul ei ole probleem neis numbrites, vaid selles, et pilveteenuseid hakkab aktiivselt kasutama üha rohkem ettevõtteid, kes soovivad omada samu võimalusi pilveinfrastruktuuri jälgimiseks nagu oma võrgu sees. Ja see trend kasvab — ameriklaste arvestus- ja auditibüroo andmetel kuni 2023. aastani plaanitakse USA-s sulgeda 1200 andmekeskust (6250 on juba suletud). Kuid üleminek pilve ei ole lihtsalt "ah, las viime meie serverid välisele teenusepakkujale". Uus IT-arhitektuur, uus tarkvara, uued protsessid, uued piirangud... Kõik see toob kaasa olulisi muutusi mitte ainult IT, vaid ka küberturbe töös. Ja kui pilve enda turvalisuse tagamisega on teenusepakkujatel kuidagi hakkama saadud (õnneks on soovitusi piisavalt palju), siis pilvede küberturbe jälgimisega, eriti SaaS-platvormidel, on märkimisväärseid raskusi, millest me ka räägime.

Kujutage ette, et teie ettevõte on viinud osa oma infrastruktuurist pilve... Peatage. Vale. Kui infrastruktuur on juba viidud ja te alles mõtlema hakkate, kuidas seda jälgida, siis olete juba kaotanud. Kui see ei ole Amazon, Google või Microsoft (ning isegi siis eranditega), siis tõenäoliselt ei ole teil palju võimalusi oma andmete ja rakenduste jälgimiseks. Hea on, kui teile antakse võimalus logidega töötada. Mõnikord on turvaintsidentide andmed saadaval, kuid teil pole neile juurdepääsu. Näiteks Office 365. Kui teil on kõige odavam litsents E1, siis ei ole teil turvaintsidentide andmeid üldse saadaval. E3 litsentsiga on teie andmed saadaval ainult 90 päeva ja ainult E5 litsentsiga on logide säilivus ühe aasta (tõsi, ka siin on omad nüansid, mis on seotud vajadusega eraldi küsida mitmeid logifunktsioone Microsofti toelt). Muide, E3 litsents on oma jälgimisfunktsioonide osas palju nõrgem kui ettevõtte Exchange. Sama taseme saavutamiseks on teil vaja E5 litsentsi või lisalitsentsi Advanced Compliance, mis võib nõuda täiendavaid kulutusi, mis ei olnud arvesse võetud teie rahandusmudelis pilve infrastruktuurile üleminekul. Ja see on vaid üks näide alahinnatud probleemidest, mis on seotud pilveisikute jälgimisega. Selles artiklis, mitte pretendeerides täielikkusele, tahan juhtida tähelepanu teatud nüanssidele, mida tasub arvestada pilveteenuse pakkuja valimisel turvalisuse vaatenurgast. Artikli lõpus on esitatud kontrollnimekiri, mille tuleks täita enne, kui arvate, et pilveandmete jälgimise küsimus on teie jaoks lahendatud.

On mitu tüüpilist probleemide rida, mis võivad põhjustada intsidente pilvesümpaatikates, millele turvafunktsioonid ei suuda reageerida või ei näe neid üldse:

• Turvalogid ei eksisteeri. See on üsna levinud olukord, eriti uutele mängijatele pilveteenuste turul. Kuid ka nendele ei tohiks kohe kriipsu peale tõmmata. Väikesed mängijad, eriti kodumaised, on klientide nõudmiste osas tundlikumad ja võivad kiiresti rakendada mõnda nõutavat funktsiooni, muutes oma toote kinnitatud teekaarti. Jah, see ei ole Amazon GuardDuty või Bitrixi „Proaktiivse kaitse“ moodul, kuid ikka midagi.
• IT-turvalisus ei tea, kus logid asuvad või ei pääse neile ligi. Siin tuleb alustada läbirääkimisi pilveteenuse paketiga - võib-olla nad jagavad seda teavet, kui nad peavad klienti enda jaoks oluliseks. Kuid tervikuna pole see hea, kui juurdepääs logidele antakse 'erakordse otsuse' alusel.
• On ka nii, et pilveteenuse pakkujal on logid olemas, kuid need pakuvad piiratud jälgimist ja sündmuste registreerimist, mis pole piisavad, et kõiki intsidente avastada. Näiteks võivad nad anda vaid veebisaidi muudatuste logid või kasutajate autentimise katsed, kuid muid sündmusi, näiteks võrguliiklus, ei jagata, mis varjab teilt olulist teavet, mis iseloomustab katseid häkkida teie pilveinfrastruktuuri.
• Logid on olemas, kuid nende juurde juurdepääsu automatiseerimine on keeruline, mis sunnib neid jälgima mitte pidevalt, vaid graafiku järgi. Kui logisid ei saa ka automaatselt eksportida, siis näiteks logide eksportimine Exceli formaadis (nagu mõned kodumaised pilveteenuste pakkujad) võib viia nii kaugele, et ettevõtte IT-turvalisuse teenistuse huvi nende vastu väheneb.
• Logide jälgimist ei toimu. See on ilmselt kõige arusaamatum IT-turvalisuse intsidentide tekkimise põhjus pilvetes. Tundub, et logid on olemas ja nende juurde pääsemise automatiseerimine on võimalik, kuid keegi seda ei tee. Miks?

Pilve jagatud turbe kontseptsioon

Pilvikasutusse üleminek on alati tasakaalu otsimine sooviga säilitada kontroll infrastruktuuri üle ja usaldada see professionaalsetele kätele pilveteenuse taastäitja, kes on spetsialiseerunud selle hooldamisele. Ja pilvesüsteemide turvalisuse valdkonnas on see tasakaal samuti vajalik. Eriti, et sõltuvalt kasutatavast pilveteenuste pakkumise mudelist (IaaS, PaaS, SaaS) on see tasakaal pidevalt erinev. Igasugustes olukordades tuleb meeles pidada, et kõik pilveteenuse pakkujad järgivad tänapäeval nn jagatud vastutuse ja jagatud teabe kaitse mudelit. Pilv vastutab millegi eest, klient, kes on pilves oma andmed, rakendused, virtuaalmasinad ja muud ressursid paigutanud, vastutab millegi eest. Üldiselt oleks lootus, et pilve minekuga saame kogu vastutuse teenuse pakkuja õlgadele, ettevaatlikult. Samuti ei ole mõistlik kogu turvalisust iseseisvalt korraldada pilve üleminekul. Vajalik on tasakaal, mis sõltub paljusid tegureid: riskide haldamise strateegiast, ohumudelist, pilveteenuse pakkujal olemasolevatest kaitsemehhanismidest, seadusandlusest jne.

Näiteks on andmete klassifitseerimine, mis asub pilves, alati kliendi vastutus. Pilveteenuse pakkuja või väline teenusepakkuja saab vaid aidata tööriistadega, mis aitavad andmeid pilves tähistada, rikkumisi tuvastada, seadusevastased andmed eemaldada või neid maskeerida mingi meetodi kaudu. Teisest küljest on füüsiline turvalisus alati pilveteenuse pakkuja vastutus, mida ta ei saa klientidega jagada. Kõik, mis jääb andmete ja füüsilise infrastruktuuri vahele, ongi selle artikli teema. Näiteks on pilve kättesaadavus pakkuja vastutus, samas kui MSE seadete määramine või krüpteerimise sisse lülitamine on juba kliendi vastutus. Selles artiklis püüame vaadata, milliseid küberturbe jälgimise mehhanisme pakuvad täna erinevad populaarsed pilveteenuse pakkujad Venemaal, millised on nende rakendamise eripärad ja millal tasub vaatama hakata välistesse lahendustesse (näiteks Cisco E-mail Security), mis laiendavad teie pilve omadusi küberturbe osas. Mitmetel juhtudel, eriti mitme pilve strateegia järgimisel, ei jää teil muud valikut kui kasutada küberturbe jälgimise välist lahendust mitmes pilves (näiteks Cisco CloudLock või Cisco Stealthwatch Cloud). Kuid mõnel juhul saate aru, et teie valitud (või teie jaoks kohustuslik) pilveteenuse pakkuja ei paku üldse küberturbe jälgimise võimalusi. See on ebamugav, kuid siiski väärtuslik, sest võimaldab adekvaatselt hinnata riski taset, mis on seotud selle pilvega töötamisega.

Pilve turvamonitorimise eluring

Teie kasutuses olevate pilvede turvalisuse jälgimiseks on teil vaid kolm võimalust:

• tugineda oma pilveteenuse pakkuja pakutavatele tööriistadele,
• kasutada kolmandate osapoolte lahendusi, mis jälgivad teie kasutatavaid IaaS, PaaS või SaaS platvorme,
• ehitada oma pilveteenuste jälgimise infrastruktuur (ainult IaaS/PaaS platvormide jaoks).

Vaadake, millised omadused on igal neist variantidest. Kuid enne seda peame mõistma üldist skeemi, mida kasutatakse pilveplatvormide jälgimisel. Toetuksin kuuele peamisele komponendile pilve turvalisuse jälgimise protsessis:

• Infrastruktuuri ettevalmistamine. Määrake vajalikud rakendused ja infrastruktuur, et koguda turvalisuse jaoks olulisi sündmusi andmehoidlas.
• Kogumine. Selles etapis kogutakse turvalisuse sündmusi erinevatest allikatest, et neid edaspidi töödelda, hoida ja analüüsida.
• Töötlemine. Selles etapis muudetakse ja rikastatakse andmeid, et hõlbustada nende edasist analüüsi.
• Hoidmine. See komponent vastutab kogutud töödeldud ja „toorsete” andmete lühiajalise ja pikaajalise säilitamise eest.
• Analüüs. Selles etapis on võimalus avastada intsidente ja reageerida neile automaatsetes või käsitsi režiimides.
• Aruandlus. See etapp aitab luua huvigruppidele (juhtkond, audiitorid, pilveteenuse pakkuja, kliendid jne) võtmeindikaatoreid, mis aitavad teha otsuseid, näiteks teenusepakkuja väljavahetamine või turvalisuse täiendamine.

Nende komponentide mõistmine võimaldab teil hiljem kiiresti otsustada, mida saate oma teenusepakkujalt küsida ja mida peate ise või väliste konsultantide kaasamisega tegema.

Pilveteenuste sisseehitatud võimalused

Olen juba varem maininud, et paljud pilveteenused ei paku tänapäeval mingit võimalust teabe turvalisuse jälgimiseks. Üldiselt ei pühendata teabele turvalisuse küsimustele suurt tähelepanu. Näiteks üks tuntud Vene teenus, mille abil saadetakse riigiasutustele aruandlust Interneti kaudu (ei maini selle nime). Kogu selle teenuse turvalisuse jaotumine radikaalselt keskendub sertifitseeritud krüptoressursside rakendamisele. Teise kohaliku pilveteenuse, mis pakub elektroonilisi dokumente, teabe turvalisuse jaotus on tunduvalt mahukam. Seal räägitakse avalike võtmete sertifikaatidest, sertifitseeritud krüptograafiast, veebiennustuste kõrvaldamisest, DDoS-rünnakute kaitsmisest, teabe turvalisuse hindamisest, varundamisest ja isegi regulaarsetest teabe turvalisuse audititest. Kuid jälgimise kohta ei öelda sõnagi, samuti nagu ka sellele, kuidas pääseda juurde teabe turvalisuse sündmustele, mis võivad olla huvitavad selle teenuse pakkuja klientidele.

Üldiselt võib pilveteenuse pakkuja kodulehe ja dokumentatsiooni kaudu teabe turvalisuse küsimuste kohta aru saada, kui tõsiselt ta sellele küsimusele läheneb. Näiteks, kui lugeda "Minu kontori" tooteid käsitlevaid juhendeid, siis seal ei ole sõnagi turvalisusest, kuid eraldi toote, "Minu kontor. K3", mis on ette nähtud volitamata juurdepääsu kaitseks, dokumentatsioonis on lihtsalt loetletud FSTEK-i 17. määruse punktid, mida "Minu kontor. K3" täidab, kuid ei ole põhjalikult kirjeldatud, kuidas neid jaotisi rakendatakse ja, mis on kõige olulisem, kuidas integreerida neid mehhanisme ettevõtte teabe turvalisusse. Võib-olla selline dokumentatsioon olemas on, kuid avalikus juurdepääsus, kodulehe "Minu kontor" kohaselt, ei leidnud ma seda. Kuigi võib-olla on mul lihtsalt sellele salajasele teabele juurdepääs puudulik?

Sama Bitrixi puhul on olukord kordades parem. Dokumentatsioonis on kirjeldatud sündmuste logide formaate ja, mis huvitav, ka sissetungi logi, mis sisaldab sündmusi, mis on seotud potentsiaalsete ohtudega pilvplatvormile. Sealt saad välja võtta IP-aadressi, kasutajanime või külastaja nime, sündmuse allika, aja, kasutajaagendi, sündmuse tüübi jne. Tõsi, nende sündmuste töötlemine on keeruline ja saad seda teha kas pilve halduspaneelist või laadida andmed välja MS Exceli formaadis. Bitrixi logide automatiseerimine on praegu keeruline ning osa tööst tuleb teha käsitsi (raporti eksportimine ja selle üleslaadimine oma SIEMi). Kuid kui meenutada, et veel suhteliselt hiljuti ei olnud isegi sellist võimalust, on see suur edasiminek. Samuti tahan märkida, et paljud välismaised pilveteenuse pakkujad pakuvad sarnast funktsionaalsust "algajatele" — kas vaata logisid silma kaudu halduspaneelis või laadige andmed endale (kuigi enamik eksportib andmeid .csv formaadis, mitte Excelis).

Kui mitte arvestada varianti logide puudumisega, siis pilvepakkujad pakuvad tavaliselt kolme varianti turvasündmuste jälgimiseks — juhtpaneelid, andmete eksport ja API kaudu juurdepääs. Esimene näib lahvatavat palju probleeme teie eest, kuid see ei ole päris nii — mitme logi olemasolu korral tuleb teil vahetada ekraanide vahel, mis neid kuvavad, kaotades üldpildi. Lisaks on ebatõenäoline, et pilvepakkuja annab teile võimaluse turvasündmuste korreleerimiseks ja nende analüüsimiseks turvalisuse seisukohalt (tavaliselt tegelete toorete andmetega, mille mõistmine on teie enda ülesanne). Erandeid on ja neist räägime hiljem. Lõpuks on mõistlik uurida, milliseid sündmusi fikseerib teie pilvepakkuja, millises formaadis ning kuidas need vastavad teie teabe turbe jälgimise protsessile. Näiteks kasutajate ja külaliste tuvastamine ja autentimine. Sama Bitrix võimaldab teil nende sündmuste põhjal fikseerida sündmuse kuupäeva ja kellaaja, kasutajanime või külalise nime (kui on olemas "Veebianalüüsi" moodul), objekti, millele on juurdepääs saavutatud, ja teised tüüpilised veebilehe elemendid. Kuid ettevõtte IT-teenustele võib vajada infot selle kohta, kas kasutaja pääses pilvele usaldusväärsest seadmest (nt ettevõtte võrgu puhul lahendab selle ülesande Cisco ISE). Ja sellise lihtsa ülesande, nagu geolocation IP funktsioon, mis aitab kindlaks teha, kas pilve teenuse kasutaja konto on varastatud? Ja isegi kui pilvepakkuja selle teile annab, on seda siiski vähe. Samuti Cisco CloudLock mitte ainult ei analüüsi geolokaati, vaid kasutab selleks masinõpet ja analüüsib ajaloolisi andmeid iga kasutaja kohta ning jälgib erinevaid anomaaliaid identifitseerimise ja autentimise katsetes. Sarnast funktsionaalsust pakub ainult MS Azure (vastava tellimuse olemasolul).

On veel üks keerukus — kuna paljude pilveteenuse pakkujate jaoks on IT-juhtimise jälgimine uus teema, millega nad alles hakkavad tegelema, muudavad nad pidevalt oma lahendusi. Täna on neil üks API versioon, homme teine, ülehomme kolmas. Selleks peab ka valmis olema. Sama kehtib ka funktsionaalsuse kohta, mis võib muutuda ja mida tuleb oma IT-juhtimise jälgimissüsteemis arvestada. Näiteks, Amazonil olid algselt eraldi teenused pilveürituste jälgimiseks — AWS CloudTrail ja AWS CloudWatch. Seejärel ilmus eraldi IT-juhtimise ürituste jälgimise teenus — AWS GuardDuty. Mõne aja pärast käivitas Amazon uue haldussüsteemi Amazon Security Hub, mis sisaldab andmeanalüüsi, mis saadakse GuardDuty, Amazon Inspector, Amazon Macie ja mitme muu teenuse abil. Teine näide on Azure logide integreerimise tööriist SIEM-iga — AzLog. Seda kasutasid aktiivselt paljud SIEM-i tarnijad, kuni Microsoft kuulutas 2018. aastal välja selle arendamise ja toe lõpetamise, mis tähendas paljudele kliendidele, kes seda tööriista kasutasid, probleemi (kuidas see lahendati, räägime hiljem).

Seetõttu jälgige hoolikalt kõiki jälgimisfunktsioone, mida teie pilveteenuse pakkuja pakub. Või usaldage välist lahenduspakkujat, kes toimib teie SOC-i ja pilve vahel, mida soovite jälgida. Jah, see on kallim (kuigi mitte alati), kuid nii suunate kogu vastutuse teistele. Või kas mitte kõik? Tuletagem meelde jagatud vastutuse kontseptsioon ja mõistame, et me ei saa mitte midagi teistele üle kanda — peame ise välja selgitama, kuidas erinevad pilveteenuse pakkujad tagavad teie andmete, rakenduste, virtuaalmasinate ja muude pilves olevate ressursside IT-juhtimise jälgimise. Ja alustatud saame sellest, mida Amazon selles osas pakub.

Näide: IT-juhtimise jälgimine IaaS põhjal AWS-is

Jah, ma mõistan, et Amazon ei ole parim näide, kuna see on Ameerika teenus ja seda võivad blokkeerida äärmuslust ja Venemaal keelatud teabe levikut tõkestava seadusandluse raames. Kuid selles publikatsioonis soovin näidata, kui erinevad on erinevad pilveplatvormid teabe turbe jälgimise võimaluste poolest ning millele tuleks tähelepanu pöörata oma kriitiliste protsesside pilve viimise juures turvalisuse seisukohalt. Ja kui mõni Venemaa pilvelahenduste arendaja leiab 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 varastati Deep Root Analyticsilt 198 miljoni valija nimed, aadressid, sünnipäevad ja telefoninumbrid. Iisraeli ettevõttelt Nice Systems varastati 14 miljonit Verizoniga seotud abonentide andmekogumit. Samas võimaldavad AWSi sisseehitatud funktsioonid avastada laia valikut intsidente. Näiteks:

• infrastruktuuri rünnak (DDoS)
• sõlme kompromiteerimine (käskude süstimine)
• kasutajakonto kompromiteerimine ja volitamata juurdepääs
• vale konfigureerimine ja haavatavused
• kaitsmata liidesed ja API-d.

Selline vastuolu tuleneb sellest, et andmete kaitse eest vastutab, nagu me eespool märkisime, klient ise. Ja kui ta ei ole mures kaitsemehhanismide aktiveerimise ja jälgimisvahendite sisselülitamise pärast, siis saab ta intsidentist teada ainult ajakirjandusest või oma klientidelt.

Incidentide tuvastamiseks saab kasutada laia valikut erinevaid monitooringuteenuseid, mis on välja töötatud Amazonis (kuigi neid täiendavad sageli välistööriistad, näiteks osquery). AWS-is jälgitakse kõiki kasutajate tegevusi, sõltumata sellest, kuidas need toimuvad — läbi juhtpaneeli, käsurida, SDK või muude AWS teenuste. Kõik AWS konto tegevuste logid (sealhulgas kasutajanimi, tegevus, teenus, tegevuse parameetrid ja tulemused) ning API kasutamine on kergesti kättesaadavad AWS CloudTraili teenuse kaudu. Saate neid sündmusi (näiteks AWS IAM-i konsooli sisselogimine) vaadata CloudTraili konsoolist, analüüsida neid Amazon Athenas või edastada neid välistesse lahendustesse, näiteks Splunk, AlienVault jne. AWS CloudTraili logid salvestatakse teie AWS S3 ämbritesse.

Kaks muud AWS teenust pakuvad veel mitmeid olulisi monitooringuvõimalusi. Esiteks on Amazon CloudWatch AWS ressursside ja rakenduste monitooringuteenuste seas, mis võimaldab näiteks tuvastada ja erinevaid anomaaliaid teie pilves. Kõik AWS integreeritud teenused, nagu Amazon Elastic Compute Cloud (serverid), Amazon Relational Database Service (andmebaasid), Amazon Elastic MapReduce (andmete analüüs) ja veel 30 muud Amazon teenust, kasutavad oma logide salvestamiseks Amazon CloudWatchi. Arendajad saavad kasutada Amazon CloudWatchi avatud API-d, et lisada logide monitooringu funktsioon kasutajarakendustes ja teenustes, mis võimaldab laiendada analüüsitavate sündmuste ulatust IT-turbe kontekstis.

Teiseks, VPC Flow Logs teenus võimaldab analüüsida võrgu liiklust, mis suunatakse või saadakse teie AWS serveritest (väljast või seest), samuti mikroteenuste vahel. Kui mõni teie AWS VPC ressursidest suhtleb võrguga, salvestab VPC Flow Logs teenus võrgu liikluse andmed, sealhulgas lähte ja sihtkoha võrguinterfaci, samuti IP-aadressid, pordid, protokollid, nähtud baitide ja pakettide arv. Need, kes on omakorda töötanud kohaliku võrgu turvalisuse valdkonnas, tunnevad seda analoogina voogudest. NetFlow, mida saavad luua ettevõtte taseme lülitid, marsruuterid ja tulemüürid. Need logid on olulised küberturbe jälgimise eesmärkidel, kuna need, erinevalt kasutajate ja rakenduste tegevustest, võimaldavad jälgida ka võrguühendusi virtuaalses eraldi pilves keskkonnas AWS.

Seega tagavad need kolm AWS teenust — AWS CloudTrail, Amazon CloudWatch ja VPC Flow Logs — piisavalt tõhusa ülevaate teie konto kasutamisest, kasutajate käitumisest, infrastruktuuri haldamisest, rakenduste ja teenuste aktiivsusest ning võrgu aktiivsusest. Näiteks nende abil saab tuvastada järgmisi anomaaliaid:

• Aadresside skaneerimise katsed, tagauksete otsimine, haavatavuste otsimine läbi '404 veateate' puhangute.
• Sisestamise rünnakud (nt SQL injection) '500 veateate' puhangute kaudu.
• Tuntud tööriistad SQL-rünnakuteks nagu sqlmap, nikto, w3af, nmap jne, kasutades User Agent välja analüüsi.

Amazon Web Services on välja töötanud ka teisi teenuseid küberjulgeoleku eesmärkidel, mis aitavad lahendada mitmeid teisi ülesandeid. Näiteks on AWS-s sisseehitatud teenus poliitikate ja konfiguratsioonide auditiks — AWS Config. See teenus tagab teie AWS-i ressursside ja nende konfiguratsioonide pideva auditi. Vaatame lihtsat näidet: oletame, et soovite veenduda, et kasutajate paroolid on kõigil teie serveritel keelatud ja juurdepääs on võimalik ainult sertifikaatide alusel. AWS Config võimaldab seda kõigi teie serverite jaoks lihtsalt kontrollida. On ka teisi poliitikate, mida saab rakendada teie pilveserveritele: „Ükski server ei tohi kasutada porti 22”, „Ainult administraatorid saavad muuta tulemüürireegleid” või „Ainult kasutaja Ivashko võib luua uusi kasutajakontosid ja ta saab seda teha ainult teisipäeviti.” 2016. aasta suvel laiendati AWS Config teenust, et automatiseerida välja töötatud poliitikate rikkumiste avastamist. AWS Config Rules on põhimõtteliselt pidevad konfiguratsiooniküsimused teie kasutatavate Amazoni teenuste kohta, mis genereerivad sündmusi poliitikate rikkumise korral. Näiteks, selle asemel et perioodiliselt teha AWS Config-i päringuid selle kontrollimiseks, et kõik virtuaalserveri kettad on krüpteeritud, saab AWS Config Rules-i kasutada serverikettade pidevaks kontrollimiseks selle tingimuse täitmise osas. Ja mis kõige olulisem, antud publikatsiooni kontekstis genereerivad kõik rikkumised sündmusi, mida teie küberturbe teenus saab analüüsida.

AWS-s on ka oma ekvivalendid traditsioonilistele ettevõtte küberjulgeoleku lahendustele, mis samuti genereerivad turvasündmusi, mida saate ja peaksite analüüsima:

• sissetungide avastamine — AWS GuardDuty
• teabe leketega toimetulek — AWS Macie
• EDR (kuigi rääkida pilve lõpp-seadmetest on veidi kummaline) — 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
• kontode haldamine — AWS IAM
• SSO — AWS SSO
• turvalisuse analüüs — AWS Inspector
• konfiguratsioonide haldamine — AWS Config
• WAF — AWS WAF.

Ma ei hakka üksikasjalikult järgima kõiki Amazon'i teenuseid, mis võivad olla kasulikud teabejulgestuse kontekstis. Peamine, mida tuleb mõista, on see, et kõik need võivad genereerida sündmusi, mida me saame ja peame analüüsima teabejulgestuse kontekstis, kasutades selleks nii Amazon'i enda sisseehitatud võimalusi kui ka väliseid lahendusi, nagu näiteks SIEM, mis saavad tuua turvasündmusi teie jälgimiskeskusesse ja analüüsida neid seal koos sündmustega teistelt pilveteenustelt või sisemistelt infrastruktuuridelt, perimeetritelt või mobiilsetelt seadmetelt.

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

• CloudTrail — API kasutamine ja kasutajate tegevused.
• Trusted Advisor — turvalisuse kontroll vastavuses parimate praktikatega.
• Config — kontode ja teenuste seadete inventeerimine ja konfiguratsioon.
• VPC Flow Logs — ühendused virtuaalsete liidesega.
• IAM — identifitseerimise ja autentimise teenus.
• ELB Access Logs — koormuse tasakaalustaja logid.
• Inspector — rakenduste haavatavused.
• S3 — failide salvestuskoht.
• CloudWatch — rakenduste aktiivsus.
• SNS — teavitusteenus.

Amazon, pakkudes sellist sündmusallikate spektrit ja nende genereerimise tööriistu, on siiski väga piiratud analüüsivõimalustes kogutud andmete osas teabejulgestuse kontekstis. Teil tuleb iseseisvalt uurida olemasolevaid logisid, otsides neist vastavaid kompromiteerimise näitajaid. AWS Security Hub, mille Amazon hiljuti käivitas, peab seda probleemi lahendama, saades omamoodi pilve SIEM-i AWS-i jaoks. Kuid hetkel on see alles oma tee alguses ja piiratud nii allikate arvuga, millega ta töötab, kui ka muude piirangutega, mis on kehtestatud Amazon'i arhitektuuri ja tellimuste poolt.

Näide: Teabejulgestuse jälgimine IaaS-i baasil Azure'is.

Ma ei taha alustada pikka arutelu selle üle, milline kolmest pilveteenuse pakkujast (Amazon, Microsoft või Google) on parem (kuna igal neist on oma kindel eripära ja nad sobivad erinevate ülesannete lahendamiseks); keskendume nende võimalustele, mida nad pakuvad andmete turvamonitorimise valdkonnas. Tuleb tunnistada, et Amazon AWS oli selles segmendis üks esimesi ja seega on nad oma andmeturbe funktsioonides kõige kaugemale arenenud (kuigi paljud tunnistavad, et nende kasutamine on keeruline). Kuid see ei tähenda, et me peaksime ignoreerima võimalusi, mida Microsoft ja Google meile pakuvad.

Microsofti tooted on alati silma paistnud oma "avanesuses" ning Azure'i olukord on sarnane. Näiteks kui AWS ja GCP lähtuvad alati printsiibist "kõik, mis ei ole lubatud, on keelatud", siis Azure'i lähenemine on täiesti vastupidine. Näiteks, luues pilves virtuaalvõrgu ja selles virtuaalmasina, on kõik pordid ja protokollid vaikimisi avatud ja lubatud. Seetõttu peate Microsofti pilves pääsupiirangute süsteemi esialgse seadistamise jaoks veidi rohkem vaeva nägema. See seab teile ka karmimad nõuded Azure'i pilves tegevuse jälgimise osas.

AWS-il on omadus, et kui jälgite oma virtuaalseid ressursse, siis kui need asuvad erinevates piirkondades, tekivad teil raskused kõigi sündmuste koondamises ja nende ühtses analüüsis, mille lahendamiseks peate kasutama erinevaid nippe, näiteks looma oma koodi AWS Lambda jaoks, mis kannab sündmusi piirkondade vahel. Azure'il ei ole sellist probleemi — selle Activity Log mehhanism jälgib kogu tegevust organisatsiooni tasandil ilma piiranguteta. Sama kehtib ka AWS Security Hub'i kohta, mis on hiljuti välja töötatud Amazoni poolt, et koondada mitmeid turbefunktsioone ühtsesse turbe keskusesse, kuid ainult oma piirkonna piires, mis ei ole Venemaa jaoks asjakohane. Azure'il on oma Security Center, mis ei ole seotud piirkondlike piirangutega, pakkudes juurdepääsu kõigile pilveplatvormi turbefunktsioonidele. Veelgi enam, erinevatele kohalikele meeskondadele võib see pakkuda oma kaitsefunktsioonide komplekti, sealhulgas hallatavaid turbeüritusi. AWS Security Hub püüab veel saada sarnaseks Azure Security Center'iga. Kuid tuleb lisada ka negatiivne külg — saate Azure'ist välja pigistada palju sellist, mis on eelnevalt kirjeldatud AWS-is, kuid kõige mugavam on seda teha ainult Azure AD, Azure Monitori ja Azure Security Center'i jaoks. Kõik teised Azure'i kaitsemehhanismid, sealhulgas turbeürituste analüüs, ei ole hetkel kõige mugavamad. Osaliselt lahendab probleemi API, mis läbib kõiki Microsoft Azure'i teenuseid, kuid see nõuab teilt täiendavaid jõupingutusi, et integreerida teie pilv oma SOC-iga ja omada kvalifitseeritud spetsialiste (nagu kõikide teiste pilve API-dega töötavate SIEM-i puhul). Mõned SIEM-id, millest räägitakse hiljem, toetavad juba Azure't ja saavad automatiseerida selle jälgimise ülesande, kuid ka sellega on oma raskused — mitte kõik neist ei suuda kõiki logisid, mis Azure'il olemas on, kätte saada.

Sündmuste kogumine ja nende jälgimine Azure'is toimub Azure Monitor teenuse abil, mis on peamine tööriist andmete kogumiseks, salvestamiseks ja analüüsimiseks Microsofti pilves ning selle ressurssides – Git repositooriates, konteinerites, virtuaalmasinates, rakendustes jne. Kõik andmed, mida Azure Monitor kogub, jagunevad kaheks kategooriaks – reaalajas kogutavad mõõdikud, mis kirjeldavad Azure'i pilve võtmeindikaatoreid, ja logifailid, mis sisaldavad andmeid, korraldatud kirjetesse, iseloomustades teatud aspekte ressursside ja teenuste tegevusest Azure'is. Lisaks, Data Collector API abil suudab Azure Monitor koguda andmeid mistahes REST allikast, et luua oma jälgimisskeeme.

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

• Activity Logs – see logi vastab klassikalistele küsimustele "kes", "mida" ja "millal" seoses mistahes kirjeoperatsiooniga (PUT, POST, DELETE) pilveressursi üle. Lugemisele suunatud sündmused (GET) sellesse logisse ei pääse, samuti mitmed teised.
• Diagnostic Logs – sisaldab andmeid operatsioonide kohta, mis puudutavad teatud ressurssi, mis kuulub teie tellimusse.
• Azure AD aruandlus – sisaldab nii kasutajate aktiivsust kui ka süsteemi aktiivsust, mis on seotud gruppide ja kasutajate haldamisega.
• Windows Event Log ja Linux Syslog – sisaldab sündmusi virtuaalmasinatest, mis on majutatud pilves.
• Metrics – sisaldab telemeetriat teie pilveteenuste ja ressursside jõudluse ja „tervise“ seisundist. Mõõdetakse iga minuti järel ja hoitakse 30 päeva jooksul.
• Network Security Group Flow Logs – sisaldab andmeid võrgu turvasündmuste kohta, mis on kogutud Network Watcher teenuse ja võrgu taseme ressursside jälgimise kaudu.
• Storage Logs – sisaldab sündmusi, mis on seotud juurdepääsuga salvestusele.

Jälgimiseks saate kasutada väliseid SIEM-e või sisseehitatud Azure Monitorit ja selle laiendusi. Infoturbe sündmuste haldamise süsteemide kohta räägime hiljem, aga vaata, mida Azure pakub andmete analüüsimiseks turvalisuse kontekstis. Kõige olulisem ekraan, mis on seotud Azure Monitori turvalisuse ja auditi, on Log Analytics Security and Audit Dashboard (tasuta versioon toetab piiratud hulga sündmuste salvestamist vaid ühe nädala jooksul). See paneel on jagatud viieks peamiseks valdkonnaks, mis visualiseerivad kokkuvõtlikku statistikat selle kohta, mis toimub teie kasutatavas pilvekeskkonnas:

• Turvalisuse valdkonnad — peamised kvantitatiivsed näitajad, mis on seotud infotehnoloogia turvalisusega — intsidentide arv, kompromiteeritud sõlmede arv, parandamata sõlmede arv, võrgu turvasündmused jne.
• Olulised probleemid — näitab aktiivsete infotehnoloogia turvalisuse probleemide arvu ja tähtsust
• Tuvastused — näitab mustreid pidevatest rünnakutest teie vastu
• Ohutuse intelligentsus — näitab geograafilist teavet välistest sõlmedest, mis teie vastu ründavad
• Tüüpilised turvaküsimused — tüüpilised päringud, mis aitavad teil paremini jälgida oma infotehnoloogia turvalisust.

Azure Monitori laiendusteks on näiteks Azure Key Vault (kriptograafiliste võtmete kaitse pilves), Malware Assessment (kahjuritarkvara kaitse analüüs virtuaalmasinates), Azure Application Gateway Analytics (analüüs, sealhulgas pilve tulemüüride logide analüüs) jne. Need tööriistad, mis on rikastatud teatavate sündmuste töötlemise reeglitega, võimaldavad visualiseerida erinevaid pilveteenuste tegevuse aspekte, sealhulgas turvalisust, ning tuvastada erinevaid kõrvalekaldeid nende töös. Kuid nagu ikka, vajab iga täiendav funktsioon vastavat tasulist tellimust, mis nõuab enneaegset rahalist planeerimist.

Azure'il on mitmeid sisseehitatud funktsioone, mis on seotud ohtude jälgimisega ning need on integreeritud Azure AD, Azure Monitor ja Azure Security Center. Näiteks on nende seas virtuaalmasinate interaktsioonide avastamine tuntud pahatahtlike IP-dega (tänu Microsofti Threat Intelligence teenuste integreerimisele), pahavara avastamine pilvinees, mis saadab hoiatuse signaale pilve paigaldatud virtuaalmasinatelt, virtuaalmasinate paroolide purustamise rünnakud, kasutajate tuvastamise süsteemide konfiguratsiooni haavatavused, sisenemine anonüümsete teenuste või nakatunud sõlmede kaudu, kontoandmete lekkeid, sisenemine harjumatutes kohtades jne. Täna on Azure üks väheseid pilveteenuse pakkujaid, kes pakub teile sisseehitatud Threat Intelligence võimalusi kogutud infojulgeoleku sündmuste rikastamiseks.

N nagu eelnevalt mainitud, ei ole kaitsefunktsioon ja selle tagajärjel genereeritud turvasündmused kõigile kasutajatele ühesugused, vaid nõuavad kindla tellimuse olemasolu, mis sisaldab vajalikku funktsionaalsust, mis nende turvasündmuste jälgimiseks genereerib. Näiteks on osa eelnevas lõigus kirjeldatud ebatavaliste konto jälgimise funktsioonidest saadaval ainult Azure AD teenuse P2 premium litsentsiga. Ilma selleta tuleb teil, nagu ka AWS-i puhul, kogutud turvasündmusi „käsitsi” analüüsida. Samuti, sõltuvalt Azure AD litsentsi tüübist, ei ole teile kõik sündmused analüüsiks saadaval.

Azure'i portaalis saate hallata nii otsingupäringuid teid huvitavates logides kui ka seadistada juhtpaneele infojulgeoleku peamiste näitajate visualiseerimiseks. Lisaks saate valida ka Azure Monitori laiendusi, mis võimaldavad teil laiendada Azure Monitori logide funktsionaalsust ja saada põhjalikumat analüüsi sündmustest julgeoleku aspektist.

Kui teil on vaja mitte ainult logide haldamise võimalust, vaid ka kõikehõlmavat turbe keskpunkti oma Azure pilveplatvormi jaoks, sealhulgas IT-turbe poliitikate haldamist, siis tuleks rääkida Azure Security Center kasutamise vajadusest, mille enamik kasulikke funktsioone on saadaval eraldi tasu eest. Näiteks ohtude avastamine, Azure'ist väljaspool monitoorimine, vastavuse hindamine jne (tasuta versioonis on teil saadaval ainult turvaolukorra hindamine ja soovitused tuvastatud probleemide kõrvaldamiseks). See koondab kõik turbeaspektid ühte kohta. Sisuliselt räägime kõrgemast IT-turbe tasemest, kui seda pakub Azure Monitor, kuna selles olukorras kogutud andmed kogu teie pilvesüsteemist rikastatakse paljude allikate, 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), abil, millele rakendatakse erinevaid keerukaid masinõppe ja käitumisanalüüsi algoritme, mis peaks lõpuks parandama ohtude avastamise ja neile reageerimise tõhusust.

Azure'l on ka oma SIEM — see ilmus 2019. aasta alguses. See on Azure Sentinel, mis tugineb Azure Monitori andmetele ning võib integreeruda ka väliste turvalahendustega (näiteks NGFW või WAF), mille nimekiri täieneb pidevalt. Lisaks sellele, tänu Microsoft Graph Security API integreerimisele, on teil võimalus lisada Sentinelisse oma Threat Intelligence vooge, mis rikastavad teie Azure'i pilves sündmuste analüüsi võimalusi. Võib väita, et Azure Sentinel on esimene 'natiivne' SIEM, mis on tekkinud pilveteenuse pakkujate seas (sarnased Splunk või ELK, mida saab pilves paigaldada, näiteks AWS, on ikkagi välja töötatud traditsiooniliste pilveteenuste pakkujate poolt). Azure Sentinel ja Security Center võiksid olla nagu SOC Azure pilve jaoks ning neid võiks seadistada ka piiratud kasutamiseks (teatud märkustega), kui teil ei oleks muud infrastruktuuri ja kõik teie arvutusressursid oleksid pilve üle viidud ning see oleks Microsoft Azure'i pilv.

Kuna Azure'i sisseehitatud võimalused (isegi kui teil on Sentinel'i tellimus) ei täida sageli infotehnoloogia jälgimise ja selle protsessi integreerimise vajadusi teiste turvaeesmärkide allikatega (nii pilve- kui ka sisemised), on vajalik kogutud andmete eksportimine välistesse süsteemidesse, mille hulka võib kuuluda ka SIEM. Seda tehakse nii API-de abil kui ka spetsiaalsete laiendite kaudu, mis on praegu ametlikult saadaval ainult järgmistele SIEM-idele — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ja ELK. Veel hiljuti oli selliseid SIEM-e rohkem, kuid alates 1. juunist 2019 lõpetas Microsoft Azure Log Integration Tool'i (AzLog) toe, mis varajases Azure'i ajaloos ning ilma korraliku logide standardiseerimiseta (Azure Monitor polnud isegi 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 integreerimise teinud, kuid olge ettevaatlikud — nad ei pruugi haarata kõiki Azure'i logisid, vaid ainult teatud (vaadake oma SIEM-i dokumentatsioonist).

Lõpetades lühikese ülevaate Azure'ist, tahaksin anda üldise soovituse selle pilveteenuse kohta — enne kui kinnitate midagi Azure'i küberturbe jälgimisfunktsioonide kohta, peaksite need väga hoolikalt seadistama ja testima, et need töötavad nii, nagu on kirjutatud dokumentatsioonis ja kuidas Microsofti konsultandid teile rääkisid (ning nende arvamused Azure'i funktsioonide tõhususe kohta võivad erineda). Kui finantsvõimalused seda võimaldavad, saate Azure'ist välja pigistada palju kasulikku küberturbe jälgimise osas. Kui aga teie ressursid on piiratud, siis nagu ka AWS-i puhul, peate toetuma ainult oma jõududele ja tooredatele andmetele, mida Azure Monitor teile annab. Ja pidage meeles, et paljude jälgimisfunktsioonide eest tuleb maksta ning hindade poliitikaga on parem tutvuda eelnevalt. Näiteks võite tasuta hoida andmeid 31 päeva jooksul mahus kuni 5 GB kliendi kohta — nende väärtuste ületamine nõuab teilt täiendavaid kulutusi (umbes 2+ dollarit iga täiendava GB hoidmise eest kliendi kohta ja 0,1 dollarit iga täiendava GB hoidmise eest iga kuu). Rakenduste telemeetriaga ja mõõdikute haldamisega tegelemine võib samuti nõuda täiendavaid rahalisi vahendeid, samuti häalertide ja teavitustega tegelemine (teatud tasuta limiit on saadaval, kuid see ei pruugi teie vajadustele piisav olla).

Näide: Küberturbe jälgimine IaaS-i põhjal Google Cloud Platformis

Google Cloud Platform AWS ja Azure'i taustal paistab täiesti noorukina, kuid see on osaliselt hea. Erinevalt AWS-ist, mis on järk-järgult oma võimalusi, sealhulgas kaitsemeetmeid, suurendanud, ent kesksete haldamise probleemide tõttu; GCP, nagu ka Azure, haldab paremini keskelt, mis vähendab vigade arvu ja rakendamise aega organisatsioonis. Turvalisuse seisukohalt on GCP, üllatus-üllatus, AWS ja Azure'i vahel. Sellel on samuti kogu organisatsiooni hõlmav sündmuste registreerimine, kuid see ei ole täielik. Mõned funktsioonid on endiselt beetastaatuse, kuid järk-järgult tuleks see puudus kõrvaldata ja GCP-st peaks saama küberturbe jälgimise osas küpsem platvorm.

GCP peamine tööriist sündmuste registreerimiseks on Stackdriver Logging (sarnane Azure Monitorile), mis võimaldab teil koguda sündmusi kogu teie pilvine infrastruktuur (sealhulgas AWS). Turvalisuse seisukohalt on GCP-s igal organisatsioonil, projektil või kaustal neli registreerimisprotokolli:

• Admin Activity — sisaldab kõiki sündmusi, mis on seotud haldusõigustega, näiteks virtuaalmasina loomine, juurdepääsuõiguste muutmine jne. See protokoll kirjutatakse alati, sõltumata teie soovist, ja säilitab oma andmeid 400 päeva.
• Data Access — sisaldab kõiki sündmusi, mis on seotud andmetega töötamisega pilvekasutajate poolt (loomine, muutmine, lugemine jne). Vaikimisi ei kirjutata seda protokolli, kuna selle maht suureneb väga kiiresti. Seetõttu on selle säilitamise aeg vaid 30 päeva. Lisaks ei kirjutata sellesse protokolli sugugi mitte kõiki sündmusi. Näiteks ei registreerita sellesse sündmusi, mis on seotud inimesi jaoks avalikult kergesti kättesaadavate ressurssidega või mis on saadaval ilma GCP-sse sisenemiseta.
• System Event — sisaldab süsteemisündmusi, mis ei ole seotud kasutajatega, või administraatori toiminguid, kes muudab pilveressursside konfiguratsiooni. See kirjutatakse alati ja säilitakse 400 päeva.
• Access Transparency — on ainulaadne näide registreerimisprotokollist, mis registreerib kõik Google'i töötajate toimingud (kuid mitte veel kõikide GCP teenuste jaoks), kes pääsevad teie infrastruktuurile ligi oma ametialaste kohustuste täitmise käigus. See protokoll säilitakse 400 päeva ja ei ole kergesti kättesaadav kõigile GCP klientidele, vaid ainult teatud tingimuste täitmisel (kas Gold või Platinum taseme tugi või 4 konkreetse tüübi rolli olemasolu ettevõtte toetas). Sarnane funktsioon on olemas näiteks ka Office 365-s — Lockbox.

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

Logidesse logidele on ligipääs mitme teega (umbes nagu varem käsitletud Azure ja AWS) — Log Vieweri liidese, API, Google Cloud SDK või teie projekti tegevuslehe kaudu, mis teid huvitab. Samuti on võimalik neid eksportida välistesse lahendustesse täiendavaks analüüsiks. Viimane toimub logide eksportimise kaudu BigQuery või Cloud Pub/Subi salvestisse.

Lisaks Stackdriver Loggingule pakub GCP platvorm veel Stackdriver Monitoringut, mis võimaldab jälgida võtme mõõdikuid (sooritusvõime, rikkealtius, üldine seisund jne) pilveteenuste ja rakenduste puhul. Erilised visuaaliseeritud andmed võivad lihtsustada probleemide leidmist teie pilveinfrastruktuuris, sealhulgas turbe kontekstis. Tuleb siiski märkida, et see funktsionaalsus ei ole turvalisuse osas väga rikkalik, kuna GCP-l puudub praegu analoog AWS GuardDuty’le ja ei suuda eristada halbu sündmusi kõikidest registreeritud sündmustest (Google on välja töötanud Event Threat Detection, kuid see on praegu beetaversioonis ja sellest rääkida on liiga vara). Stackdriver Monitoringut võiks kasutada anomaaliate tuvastamise süsteemina, mida seejärel uuritakse nende tekkepõhjuste leidmiseks. Kuid turvalise IT-ala kvalifitseeritud spetsialistide puudumise tõttu GCP turul tundub see ülesanne praeguses olukorras keeruline.

Samuti tasub tuua välja mõned IB moodulid, mida võib rakendada teie GCP pilves ja mis sarnanevad AWS pakutavaga:

• Cloud Security Command Center — analog AWS Security Hubile ja Azure Security Centerile.
• Cloud DLP — automaatne avastamine ja redigeerimine (nt varjamine) andmete kohta, mis on talletatud pilves, enam kui 90 eelmääratud klassifitseerimispoliitika alusel.
• Cloud Scanner — tuntud haavatavuste skanner (XSS, Flash Injection, patšeerimata raamatukogud jne) App Engine'is, Compute Engine'is ja Google Kubernetes'is.
• Cloud IAM — ligipääsu haldamine kõigile GCP ressurssidele.
• Cloud Identity — GCP kasutajakontode, seadmete ja rakenduste haldamine ühest juhtpaneelist.
• Cloud HSM — krüptograafiliste võtmete kaitsmine.
• Cloud Key Management Service — krüptograafiliste võtmete haldamine GCP-s.
• VPC Service Control — turvalise piiri loomine teie GCP ressursside ümber, et kaitsta neid lekkimise eest.
• Titan Security Key — kaitse phishingu eest.

Paljud neist moodulitest genereerivad turbehüsteeme, mida saab saata BigQuery andmehoidlasse analüüsimiseks või eksportimiseks teistesse süsteemidesse, sealhulgas SIEM-i. Nagu juba mainitud, on GCP aktiivselt arenev platvorm ja praegu arendab Google mitmeid uusi küberturbe mooduleid oma platvormile. Nende seas on Event Threat Detection (hetkel beetas), mis skaneerib Stackdriveri logisid, et leida jälgi volitamata tegevusest (sarnane GuardDuty'le AWS-is), või Policy Intelligence (saadaval alfa versioonis), mis võimaldab välja töötada intelligentseid ligipääsupoliitikaid GCP ressurssidele.

Olen teinud väikese ülevaate populaarsete pilveteenuste sisseehitatud jälgimisvõimalustest. Kuid kas teil on spetsialiste, kes suudavad töötada IaaS-teenusepakkuja „tooredate” logidega (kõik ei ole valmis ostma AWS-i, Azure'i või Google'i laiendatud võimalusi)? Lisaks on paljudele teada ütlus „usu, aga kontrolli”, mis on turvalisuse valdkonnas tõepoolest viimase peal. Kui palju te usaldate pilveteenusepakkuja sisseehitatud võimalusi, mis edastavad teile küberturbe sündmusi? Kui palju nad üldse keskenduvad küberturbe peale?

Mõnikord tasub vaadata pilveinfrastruktuuri järelevalve lahendusi, mis võivad täiendada pilveteenuste sisseehitatud turvalisust, ja mõnikord on need lahendused ainus variant saada teavet teie pilves hostitud andmete ja rakenduste turvalisuse kohta. Lisaks on need lihtsalt mugavamad, kuna nad võtavad enda kanda kõik vajalikud logide analüüsi ülesanded, mida genereerivad erinevad pilveteenused erinevatelt teenusepakkujatelt. Näiteks sellise järelevalve lahendusena võib tuua Cisco Stealthwatch Cloud, mis keskendub ainule ülesandele — küberohtude jälgimisele pilvekeskkondades, sealhulgas mitte ainult Amazon AWS, Microsoft Azure ja Google Cloud Platform, vaid ka privaatpilved.

Näide: Küberohtude jälgimine Stealthwatch Cloud abil

AWS pakub paindlikku arvutusplatvormi, kuid see paindlikkus toob endaga kaasa, et ettevõtted teevad kergemini vigu, mis võivad põhjustada turvaprobleeme. Ja jagatud küberturbe mudel ainult soodustab seda. Pilves tundmatute haavatavustega tarkvara käivitamine (tuntud haavatavustega saab näiteks tegeleda AWS Inspector või GCP Cloud Scanner), nõrgad paroolid, vale konfiguratsioon ja siseringi töötajad jne. Kõik see kajastub pilveressursside käitumises, mida saab jälgida Cisco Stealthwatch Cloud, mis on küberturbe järelevalve ja rünnakute avastamise süsteem avalikes ja privaatsetes pilvkeskkondades.

Üks Cisco Stealthwatch Cloud'i peamistest omadustest on võimalus mudelda entiteete. Selle abil saab luua programmimudeli (st peaaegu reaalajas simulatsiooni) iga teie pilveressursi kohta (olgu need AWS, Azure, GCP või midagi muud). Nende hulka kuuluvad serverid ja kasutajad, samuti teie pilves keskkonna eripärased ressursitüübid, nagu turvagruppid ja teenuste automaatse skaleerimise grupid. Need mudelid kasutavad sisendina struktureeritud andmevooge, mida pakuvad pilveteenused. Näiteks AWS-i puhul on need VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ja AWS IAM. Entiteetide mudeldamine tuvastab automaatselt iga teie ressursi rolli ja käitumise (võib rääkida kogu pilveaktiivsuse profiliseerimisest). Selliste rollide hulka kuuluvad Android või Apple mobiilseade, Citrix PVS server, RDP-server, meiliserver, VoIP klient, terminaliserver, domeinide kontrollija jne. Seejärel jälgib see pidevalt nende käitumist, et tuvastada riske või ohte turvalisusele. Saate tuvastada paroolide proovimise, DDoS-rünnakud, andmelekked, ebaseadusliku kaugjuurdepääsu, pahavara tegevuse, haavatavuste skannimise ja muid ohte. Näiteks, nii näeb välja kaugjuurdepääsu katse tuvastamine teie organisatsioonile ebatüüpilisest riigist (Lõuna-Korea) Kubernetes klastrisse SSH kaudu:

Nii näeb välja eeldatav andmelekke juhtum Postgress andmebaasist riiki, millega varasemalt ei ole suheldud:

Lõpuks, nii näeb välja liiga suur hulk ebaõnnestunud SSH juurdepääsukatseid Hiinast ja Indoneesiast välisest kaugseadmest:

Või oletame, et serveri eksemplar VPC-s ei tohiks poliitika kohaselt kunagi olla kaugjuurdepääsu sihtpunkt. Oletame veel, et sellel arvutil toimus kaugjuurdepääs vale tulemüürireegli muutmise tõttu. Entiteetide modelleerimise funktsioon tuvastab ja teatab sellest aktiivsusest („Ebatavaline kaugjuurdepääs”) peaaegu reaalajas ning osutab konkreetsele AWS CloudTrail, Azure Monitor või GCP Stackdriver Logging API kutsele (kasutajanime, kuupäeva ja kellaaja ja muude detailide hulgas), mis tekitas muudatuse tulemüürireeglis. See teave võib seejärel minna SIEM-i analüüsimiseks.

Sarnaseid võimalusi rakendatakse igasuguste pilvekeskkondade jaoks, mida toetab Cisco Stealthwatch Cloud:

Entiteetide modelleerimine on ainulaadne turvakasutuse automatiseerimise vorm, mis suudab tuvastada seni tundmatuid probleeme, mis on seotud teie töötajate, protsesside või tehnoloogiatega. Näiteks võimaldab see tuvastada muu hulgas järgmisi turvaprobleeme:

• Kas keegi avastas meie kasutatavas tarkvaras tagaukse?
• Kas meie pilves on mingit kolmanda osapoole tarkvara või seadet?
• Kas autoriseeritud kasutaja väärkasutab õigusi?
• Kas meie konfiguratsioonis on olnud viga, mis võimaldab kaugjuurdepääsu või muud tahtmatut ressursside kasutamist?
• Kas meie serveritest toimub andmelekked?
• Kas keegi on proovinud meiega ühendust võtta ebatavalisest geograafilisest asukohast?
• Kas meie pilv on nakatunud pahavara?

Tuvastatud infoturbe sündmus võib edastada vastava piletina Slacki, Cisco Sparks, PagerDuty intsidentide juhtimisse ja samuti erinevatesse SIEM süsteemidesse, sealhulgas Splunk või ELK. Kokkuvõttes võib öelda, et kui teie ettevõte kasutab mitme pilve strateegiat ega piirdu ühe konkreetse pilveteenuse pakkujaga, siis varem mainitud infoturbe jälgimisvõimalused, siis Cisco Stealthwatch Cloud rakendamine on hea valik, et saada ühtne jälgimisvõimaluste komplekt peamiste pilveteenuste osutajate — Amazon, Microsoft ja Google — jaoks. Mis on kõige huvitavam, on see, et kui võrrelda Stealthwatch Cloudi hindu arenenud infotehnoloogia jälgimise litsentside hindadega AWS-is, Azure-is või GCP-s, siis võib juhtuda, et Cisco lahendus osutub isegi odavamaks kui Amazoni, Microsofti ja Google'i sisseehitatud võimalused. Paratamatult on see nii. Ja mida rohkem pilvi ja nende võimalusi te kasutate, seda ilmsem on koondlahenduse eelis.

Lisaks saab Stealthwatch Cloud jälgida ka teie organisatsioonis loodud era- ja hübriidpilvi, näiteks Kubernetes konteinerite põhjal või jälgides Netflow vooge või võrgu liiklust, mis saadakse võrgu seadmete peegeldamise teel (isegi kodumaise tootmisega), AD või DNS-serveritest saadud andmeid jne. Kõik need andmed rikastatakse Cisco Talose poolt kogutud Threat Intelligence teabega, mis on maailma suurim valitsusväline infoturbe uurijate rühm.

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

Selles lõpetame artikli esimese osa, kus ma käsitlesin IaaS/PaaS platvormide sisseehitatud ja väliseid turvamonitooringu tööriistu, mis võimaldavad meil kiiresti tuvastada ja reageerida meie ettevõtte valitud pilvikeskkondades toimuvale juhtumitele. Teises osas jätkame teemat ja vaatame SaaS platvormide monitooringu võimalusi Salesforce'i ja Dropboxi näitel ning proovime kokku võtta ja luua ühtse turvamonitooringu süsteemi erinevate pilveteenuse pakkujate jaoks.

Allikas: habr.com