Pilveturbe jälgimine

Andmete ja rakenduste pilve teisaldamine esitab ettevõtte SOC-idele uue väljakutse, kes ei ole alati valmis teiste inimeste infrastruktuuri jälgima. Netoskope'i andmetel kasutab keskmine ettevõte (ilmselt USA-s) 1246 erinevat pilveteenust, mis on 22% rohkem kui aasta tagasi. 1246 pilveteenust!!! Neist 175 on seotud personaliteenustega, 170 turundusega, 110 kommunikatsiooni valdkonnaga ning 76 finants- ja CRM-iga. Cisco kasutab "ainult" 700 välist pilveteenust. Nii et ma olen nendest numbritest veidi segaduses. Kuid igal juhul pole probleem mitte neis, vaid selles, et pilve hakkab üsna aktiivselt kasutama järjest suurem hulk ettevõtteid, kes sooviksid pilvetaristu jälgimiseks omada samasuguseid võimalusi nagu oma võrgus. Ja see trend kasvab - vastavalt Ameerika arvekoja andmetel Aastaks 2023 suletakse Ameerika Ühendriikides 1200 andmekeskust (6250 on juba suletud). Kuid pilvele üleminek ei ole lihtsalt "viigem oma serverid välise pakkuja juurde". Uus IT arhitektuur, uus tarkvara, uued protsessid, uued piirangud... Kõik see toob olulisi muudatusi mitte ainult IT, vaid ka infoturbe töösse. Ja kui pakkujad on õppinud pilve enda turvalisuse tagamisega kuidagi hakkama saama (õnneks on palju soovitusi), siis pilve infoturbe jälgimisega, eriti SaaS-i platvormidel, on olulisi raskusi, millest me räägime.

Oletame, et teie ettevõte on osa oma infrastruktuurist pilve viinud... Lõpetage. Mitte niimoodi. Kui infrastruktuur on üle viidud ja mõtlete alles nüüd, kuidas seda jälgida, siis olete juba kaotanud. Kui see pole Amazon, Google või Microsoft (ja siis reservatsioonidega), ei ole teil tõenäoliselt palju võimalusi oma andmeid ja rakendusi jälgida. Hea, kui antakse võimalus palkidega töötada. Mõnikord on turvasündmuste andmed saadaval, kuid teil pole neile juurdepääsu. Näiteks Office 365. Kui sul on odavaim E1 litsents, siis pole turvasündmused sulle üldse kättesaadavad. Kui teil on E3 litsents, siis säilitatakse teie andmeid ainult 90 päeva ja ainult E5 litsentsi olemasolul on logide kestus saadaval aasta (samas on ka omad nüansid, mis on seotud vajadusega eraldi taotleda Microsofti toelt mitmeid logidega töötamise funktsioone). Muide, E3 litsents on jälgimisfunktsioonide poolest palju nõrgem kui ettevõtte Exchange. Sama taseme saavutamiseks vajate E5 litsentsi või täiendavat Advanced Compliance litsentsi, mis võib nõuda lisaraha, mida teie finantsmudelis pilveinfrastruktuurile üleminekuks ei arvestatud. Ja see on vaid üks näide pilve infoturbe jälgimisega seotud probleemide alahindamisest. Selles artiklis tahan täielikkust pretendeerimata juhtida tähelepanu mõningatele nüanssidele, mida tuleks turvalisuse seisukohalt pilveteenuse pakkuja valikul arvesse võtta. Ja artikli lõpus antakse kontrollnimekiri, mida tasub täita enne, kui arvate, et pilve infoturbe jälgimise küsimus on lahendatud.

Pilvekeskkondades on mitmed tüüpilised intsidentideni viivad probleemid, millele infoturbeteenustel pole aega reageerida või nad ei näe neid üldse:

• Turvaloge pole olemas. See on üsna tavaline olukord, eriti pilvelahenduste turul tegutsevate algajate seas. Kuid te ei tohiks neist kohe loobuda. Väikesed tegijad, eriti kodumaised, on klientide nõudmiste suhtes tundlikumad ja suudavad kiiresti rakendada mõningaid vajalikke funktsioone, muutes oma toodete heakskiidetud tegevuskava. Jah, see ei ole Amazoni GuardDuty ega Bitrixi mooduli "Proactive Protection" analoog, vaid vähemalt midagi.
• Infoturve ei tea, kus logisid hoitakse või puudub neile juurdepääs. Siin on vaja asuda läbirääkimistesse pilveteenuse pakkujaga – ehk ta annab sellise info, kui peab klienti enda jaoks oluliseks. Kuid üldiselt pole see eriti hea, kui juurdepääs logidele antakse "eriotsusega".
• Juhtub ka seda, et pilveteenuse pakkujal on küll logid, kuid need pakuvad piiratud jälgimist ja sündmuste salvestamist, millest ei piisa kõigi intsidentide tuvastamiseks. Näiteks võite saada ainult veebisaidi muudatuste logisid või kasutajate autentimiskatsete logisid, kuid mitte muid sündmusi, näiteks võrguliiklust, mis varjab teie eest terve kihi sündmustest, mis iseloomustavad teie pilveinfrastruktuuri häkkimise katseid.
• Logid on olemas, kuid ligipääs neile on raskesti automatiseeritav, mis sunnib neid jälgima mitte pidevalt, vaid graafiku alusel. Ja kui logisid automaatselt alla laadida ei saa, võib logide allalaadimine näiteks Exceli formaadis (nagu mitmel kodumaisel pilvelahenduste pakkujal) kaasa tuua isegi ettevõtte infoturbeteenistuse vastumeelsuse nende kallal nokitseda.
• Logi jälgimine puudub. See on ehk kõige ebaselgem põhjus infoturbeintsidentide esinemisel pilvekeskkondades. Tundub, et logisid on ja neile on võimalik juurdepääsu automatiseerida, kuid keegi ei tee seda. Miks?

Jagatud pilveturbe kontseptsioon

Pilvele üleminek on alati tasakaalu otsimine soovi vahel säilitada kontroll taristu üle ja viia see üle selle hooldamisele spetsialiseerunud pilveteenuse pakkuja professionaalsematesse kätesse. Ja pilveturbe vallas tuleb seda tasakaalu ka otsida. Veelgi enam, sõltuvalt kasutatavast pilveteenuse tarnemudelist (IaaS, PaaS, SaaS) on see saldo kogu aeg erinev. Igal juhul peame meeles pidama, et kõik pilvepakkujad järgivad tänapäeval nn jagatud vastutuse ja jagatud infoturbe mudelit. Osade asjade eest vastutab pilv, teiste eest aga klient, kes paigutab pilve oma andmed, rakendused, virtuaalmasinad ja muud ressursid. Oleks hoolimatu eeldada, et pilve minnes lükkame kogu vastutuse pakkuja kaela. Kuid pole ka mõistlik pilve kolimisel kogu turvalisust ise luua. Vajalik on tasakaal, mis sõltub paljudest teguritest: - riskijuhtimise strateegia, ohumudel, pilveteenuse pakkujale kättesaadavad turvamehhanismid, seadusandlus jne.

Näiteks pilves majutatud andmete klassifitseerimise eest vastutab alati klient. Pilvepakkuja või väline teenusepakkuja saab teda aidata vaid tööriistadega, mis aitavad andmeid pilves märgistada, rikkumisi tuvastada, seadust rikkuvaid andmeid kustutada või üht või teist meetodit kasutades maskeerida. Teisest küljest vastutab füüsilise turvalisuse eest alati pilveteenuse pakkuja, mida ta ei saa klientidega jagada. Kuid kõik, mis jääb andmete ja füüsilise infrastruktuuri vahele, on just selle artikli arutelu teema. Näiteks pilve kättesaadavuse eest vastutab pakkuja ning tulemüürireeglite seadistamise või krüptimise lubamise eest vastutab klient. Selles artiklis püüame vaadata, milliseid infoturbe jälgimise mehhanisme pakuvad tänapäeval erinevad populaarsed pilveteenuse pakkujad Venemaal, millised on nende kasutamise omadused ja millal tasub vaadata väliste ülekattelahenduste poole (näiteks Cisco E- mail Security), mis laiendavad teie pilve võimalusi küberturvalisuse osas. Mõnel juhul, eriti kui järgite mitme pilve strateegiat, ei jää teil muud üle, kui kasutada väliseid infoturbe monitooringulahendusi korraga mitmes pilvekeskkonnas (näiteks Cisco CloudLock või Cisco Stealthwatch Cloud). Noh, mõnel juhul saate aru, et teie valitud (või teile peale surutud) pilveteenuse pakkuja ei paku üldse infoturbe jälgimise võimalusi. See on ebameeldiv, kuid ka mitte vähe, kuna võimaldab adekvaatselt hinnata selle pilvega töötamise riskitaset.

Pilveturbe jälgimise elutsükkel

Kasutatavate pilvede turvalisuse jälgimiseks on teil ainult kolm võimalust.

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

Vaatame, millised omadused neil kõigil valikutel on. Kuid kõigepealt peame mõistma üldist raamistikku, mida pilveplatvormide jälgimisel kasutatakse. Tooksin esile 6 pilves toimuva infoturbe jälgimise protsessi põhikomponenti:

• Infrastruktuuri ettevalmistamine. Infoturbe seisukohalt oluliste sündmuste hoidlasse kogumiseks vajalike rakenduste ja infrastruktuuri määramine.
• Kollektsioon. Selles etapis koondatakse turvasündmused erinevatest allikatest, et neid edasi töödelda, salvestada ja analüüsida.
• Ravi. Selles etapis andmeid muudetakse ja rikastatakse, et hõlbustada hilisemat analüüsi.
• Säilitamine. See komponent vastutab kogutud töödeldud ja töötlemata andmete lühi- ja pikaajalise säilitamise eest.
• Analüüs. Selles etapis on teil võimalus intsidente tuvastada ja neile automaatselt või käsitsi reageerida.
• Aruandlus. See etapp aitab sõnastada sidusrühmadele (juhtkond, audiitorid, pilvepakkuja, kliendid jne) võtmeindikaatorid, mis aitavad meil teha teatud otsuseid, näiteks pakkuja vahetamine või infoturbe tugevdamine.

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

Sisseehitatud pilveteenused

Eespool juba kirjutasin, et paljud pilveteenused ei paku tänapäeval mingit infoturbe jälgimise võimalust. Üldiselt ei pööra nad infoturbe teemale erilist tähelepanu. Näiteks üks populaarsemaid Venemaa teenuseid valitsusasutustele aruannete saatmiseks Interneti kaudu (ma ei maini selle nime konkreetselt). Kogu selle teenuse turvalisust käsitlev jaotis keerleb sertifitseeritud CIPF-i kasutamise ümber. Ei erine ka teise kodumaise pilveteenuse elektroonilise dokumendihalduse infoturbe sektsioon. Räägitakse avaliku võtme sertifikaatidest, sertifitseeritud krüptograafiast, veebihaavatavuste kõrvaldamisest, kaitsest DDoS rünnakute eest, tulemüüride kasutamisest, varukoopiatest ja isegi tavalistest infoturbeaudititest. Kuid pole sõnagi jälgimisest ega ka võimalusest pääseda ligi infoturbe sündmustele, mis võivad selle teenusepakkuja klientidele huvi pakkuda.

Kui pilveteenuse pakkuja kirjeldab oma veebisaidil ja dokumentatsioonis infoturbe probleeme, saate üldiselt aru, kui tõsiselt ta seda probleemi võtab. Näiteks kui lugeda “Minu kontor” toodete juhendeid, pole seal turvalisusest üldse sõnagi, vaid eraldi toote “Minu kontor” dokumentatsioonis. KS3”, mis on loodud kaitsma volitamata juurdepääsu eest, on tavaline FSTEC-i 17. järgu punktide loend, mida "Minu Office.KS3" rakendab, kuid pole kirjeldatud, kuidas see seda rakendab ja mis kõige tähtsam, kuidas seda rakendada. integreerida need mehhanismid ettevõtte infoturbega. Võib-olla on selline dokumentatsioon olemas, kuid ma ei leidnud seda veebisaidil „Minu kontor” avalikult. Kuigi võib-olla pole mul lihtsalt juurdepääsu sellele salateabele?

Bitrixi puhul on olukord palju parem. Dokumentatsioonis kirjeldatakse sündmuste logide vorminguid ja huvitaval kombel ka sissetungimislogi, mis sisaldab pilveplatvormi potentsiaalsete ohtudega seotud sündmusi. Sealt saate välja tõmmata IP, kasutaja või külalise nime, sündmuse allika, aja, kasutajaagendi, sündmuse tüübi jne. Tõsi, saate nende sündmustega töötada kas pilve enda juhtpaneelilt või laadida andmeid MS Exceli vormingus. Nüüd on Bitrixi logidega tööd raske automatiseerida ja peate osa tööst käsitsi tegema (aruande üleslaadimine ja SIEM-i laadimine). Aga kui meenutada, et veel suhteliselt hiljuti sellist võimalust polnud, siis on see suur edasiminek. Samas tahaksin märkida, et paljud välismaised pilveteenuse pakkujad pakuvad sarnast funktsionaalsust “algajatele” – kas vaadake logisid silmaga läbi juhtpaneeli või laadige andmed endale üles (enamik andmeid laaditakse siiski üles . csv-vormingus, mitte Excel).

Arvestamata sisselogimisvaba võimalust, pakuvad pilveteenuse pakkujad turvasündmuste jälgimiseks tavaliselt kolme võimalust – armatuurlauad, andmete üleslaadimine ja API-juurdepääs. Esimene näib lahendavat teie jaoks palju probleeme, kuid see pole täiesti tõsi – kui teil on mitu ajakirja, peate neid kuvavate ekraanide vahel lülituma, kaotades üldpildi. Lisaks ei paku pilveteenuse pakkuja teile tõenäoliselt võimalust turvasündmusi seostada ja neid üldiselt turvalisuse seisukohast analüüsida (tavaliselt on teil tegemist algandmetega, millest peate ise aru saama). On erandeid ja me räägime neist lähemalt. Lõpetuseks tasub küsida, milliseid sündmusi teie pilveteenuse pakkuja salvestab, millises vormingus ja kuidas need vastavad teie infoturbe jälgimise protsessile? Näiteks kasutajate ja külaliste tuvastamine ja autentimine. Sama Bitrix võimaldab teil nende sündmuste põhjal salvestada sündmuse kuupäeva ja kellaaja, kasutaja või külalise nime (kui teil on moodul "Web Analytics"), kasutatud objekti ja muid veebisaidile tüüpilisi elemente. . Kuid ettevõtte teabeturbeteenused võivad vajada teavet selle kohta, kas kasutaja pääses pilve juurde usaldusväärsest seadmest (näiteks ettevõtte võrgus rakendab seda ülesannet Cisco ISE). Kuidas on lood sellise lihtsa ülesandega nagu geo-IP funktsioon, mis aitab kindlaks teha, kas pilveteenuse kasutajakonto on varastatud? Ja isegi kui pilveteenuse pakkuja seda teile pakub, ei piisa sellest. Seesama Cisco CloudLock ei analüüsi ainult geolokatsiooni, vaid kasutab selleks masinõpet ja analüüsib iga kasutaja ajaloolisi andmeid ning jälgib erinevaid identifitseerimis- ja autentimiskatsete kõrvalekaldeid. Sarnased funktsioonid on ainult MS Azure'il (kui teil on vastav tellimus).

On veel üks raskus – kuna paljude pilvepakkujate jaoks on infoturbe monitooring uus teema, millega alles hakatakse tegelema, siis muudavad nad oma lahendustes pidevalt midagi. Täna on neil API-st üks versioon, homme teine, ülehomme kolmas. Ka selleks tuleb valmis olla. Sama lugu on funktsionaalsusega, mis võib muutuda, millega tuleb oma infoturbe monitooringusüsteemis arvestada. Näiteks Amazonil olid algselt eraldi pilvesündmuste jälgimisteenused – AWS CloudTrail ja AWS CloudWatch. Seejärel ilmus infoturbe sündmuste jälgimiseks eraldi teenus - AWS GuardDuty. Mõne aja pärast käivitas Amazon uue haldussüsteemi Amazon Security Hub, mis sisaldab GuardDuty, Amazon Inspector, Amazon Macie ja mitmete teistelt saadud andmete analüüsi. Teine näide on Azure'i logi integreerimise tööriist SIEM-iga – AzLog. Seda kasutasid aktiivselt paljud SIEM-i müüjad, kuni 2018. aastal teatas Microsoft oma arenduse ja toe peatamisest, mis seisis paljude seda tööriista kasutanud klientide silmitsi probleemiga (kuidas see lahendati, räägime hiljem).

Seetõttu jälgige hoolikalt kõiki jälgimisfunktsioone, mida teie pilveteenuse pakkuja teile pakub. Või usaldage väliseid lahenduste pakkujaid, kes tegutsevad vahendajatena teie SOC ja pilve vahel, mida soovite jälgida. Jah, see on kallim (kuigi mitte alati), kuid nihutate kogu vastutuse kellegi teise õlgadele. Või mitte kõik?.. Meenutagem jagatud turvalisuse kontseptsiooni ja mõistame, et me ei saa midagi nihutada – peame iseseisvalt mõistma, kuidas erinevad pilveteenuse pakkujad jälgivad teie andmete, rakenduste, virtuaalmasinate ja muude ressursside infoturvet majutatud pilves. Ja alustame sellest, mida Amazon selles osas pakub.

Näide: AWS-il põhinev infoturbe jälgimine IaaS-is

Jah, jah, ma saan aru, et Amazon ei ole parim näide, kuna see on Ameerika teenus ja seda saab blokeerida osana võitlusest äärmusluse ja Venemaal keelatud teabe levitamisega. Kuid selles väljaandes tahan lihtsalt näidata, kuidas erinevad pilveplatvormid erinevad oma infoturbe monitooringu võimaluste poolest ja millele peaksite oma võtmeprotsesse turvalisuse seisukohalt pilvedesse viimisel tähelepanu pöörama. Noh, kui mõned Venemaa pilvelahenduste arendajad õpivad enda jaoks midagi kasulikku, on see suurepärane.

Esimese asjana tuleb öelda, et Amazon ei ole läbimatu kindlus. Tema klientidega juhtub regulaarselt erinevaid intsidente. Näiteks varastati Deep Root Analyticsist 198 miljoni valija nimed, aadressid, sünniajad ja telefoninumbrid. Iisraeli ettevõte Nice Systems varastas 14 miljonit Verizoni abonendi kirjet. Kuid AWS-i sisseehitatud võimalused võimaldavad teil tuvastada mitmesuguseid juhtumeid. Näiteks:

• mõju infrastruktuurile (DDoS)
• sõlmede kompromiss (käskude süstimine)
• konto rikkumine ja volitamata juurdepääs
• vale konfiguratsioon ja haavatavused
• ebaturvalised liidesed ja API-d.

See lahknevus on tingitud asjaolust, et nagu eespool selgus, vastutab kliendi andmete turvalisuse eest klient ise. Ja kui ta ei vaevunud kaitsemehhanisme sisse lülitama ja jälgimisvahendeid sisse ei lülitanud, saab ta juhtunust teada alles meediast või klientidelt.

Juhtumite tuvastamiseks saate kasutada laias valikus erinevaid Amazoni välja töötatud jälgimisteenuseid (kuigi sageli täiendavad neid välised tööriistad, näiteks osquery). Seega jälgitakse AWS-is kõiki kasutaja toiminguid, olenemata nende tegemise viisist – halduskonsooli, käsurea, SDK või muude AWS-teenuste kaudu. Kõik kirjed iga AWS-i konto tegevuse (sh kasutajanimi, toiming, teenus, tegevuse parameetrid ja tulemus) ja API kasutuse kohta on saadaval AWS CloudTraili kaudu. Saate neid sündmusi (nt AWS IAM-konsooli sisselogimisi) vaadata CloudTraili konsoolist, analüüsida Amazon Athena abil või tellida need välistele lahendustele, nagu Splunk, AlienVault jne. AWS CloudTraili logid paigutatakse teie AWS S3 ämbrisse.

Kaks muud AWS-teenust pakuvad mitmeid muid olulisi jälgimisvõimalusi. Esiteks on Amazon CloudWatch AWS-i ressursside ja rakenduste jälgimisteenus, mis muuhulgas võimaldab tuvastada pilves erinevaid anomaaliaid. Kõik sisseehitatud AWS-teenused, nagu Amazon Elastic Compute Cloud (serverid), Amazon Relational Database Service (andmebaasid), Amazon Elastic MapReduce (andmeanalüüs) ja 30 muud Amazoni teenust, kasutavad oma logide salvestamiseks Amazon CloudWatchi. Arendajad saavad kasutada Amazon CloudWatchi avatud API-d, et lisada kohandatud rakendustele ja teenustele logide jälgimise funktsioonid, võimaldades neil turvakontekstis sündmuste analüüsi ulatust laiendada.

Teiseks võimaldab VPC Flow Logs teenus analüüsida teie AWS-serverite saadetud või vastuvõetud võrguliiklust (väliselt või sisemiselt), samuti mikroteenuste vahel. Kui mõni teie AWS VPC ressurss suhtleb võrguga, salvestavad VPC voologid võrguliikluse üksikasju, sealhulgas allika ja sihtkoha võrguliidese, samuti IP-aadresse, porte, protokolli, baitide arvu ja pakettide arvu. Saag. Kohaliku võrgu turvalisusega kogenud inimesed tunnevad selle ära kui lõimede analoogi NetFlow, mida saab luua lülitite, ruuterite ja ettevõtteklassi tulemüüridega. Need logid on infoturbe jälgimise jaoks olulised, kuna erinevalt kasutajate ja rakenduste tegevust puudutavatest sündmustest võimaldavad need teil ka AWS-i virtuaalses privaatpilvekeskkonnas võrgu interaktsioonidest ilma jääda.

Kokkuvõtteks võib öelda, et need kolm AWS-teenust – AWS CloudTrail, Amazon CloudWatch ja VPC Flow Logs – annavad koos üsna võimsa ülevaate teie kontokasutusest, kasutajate käitumisest, infrastruktuuri haldamisest, rakenduste ja teenuste tegevusest ning võrgutegevusest. Näiteks saab neid kasutada järgmiste kõrvalekallete tuvastamiseks:

• Katsed skannida saiti, otsida tagauksi, otsida haavatavusi läbi "404 vigade" purskete.
• Sisestusrünnakud (näiteks SQL-i süstimine) "500 vea" rünnakute kaudu.
• Tuntud ründetööriistad on sqlmap, nikto, w3af, nmap jne. kasutajaagendi välja analüüsi kaudu.

Amazon Web Services on küberturvalisuse eesmärgil välja töötanud ka muid teenuseid, mis võimaldavad teil lahendada palju muid probleeme. Näiteks on AWS-il sisseehitatud teenus poliitikate ja konfiguratsioonide auditeerimiseks – AWS Config. See teenus pakub teie AWS-i ressursside ja nende konfiguratsioonide pidevat auditeerimist. Võtame lihtsa näite: Oletame, et soovite veenduda, et kasutajate paroolid on kõigis teie serverites keelatud ja juurdepääs on võimalik ainult sertifikaatide alusel. AWS Config muudab selle kontrollimise kõigi teie serverite puhul lihtsaks. Pilveserveritele saab rakendada ka teisi eeskirju: "Ükski server ei saa kasutada porti 22", "Ainult administraatorid saavad tulemüürireegleid muuta" või "Uusi kasutajakontosid saab luua ainult kasutaja Ivashko ja ta saab seda teha ainult teisipäeviti. " 2016. aasta suvel laiendati AWS Configi teenust, et automatiseerida väljatöötatud poliitikate rikkumiste tuvastamist. AWS-i konfiguratsioonireeglid on sisuliselt pidevad konfiguratsioonipäringud teie kasutatavatele Amazoni teenustele, mis genereerivad sündmusi, kui vastavaid eeskirju rikutakse. Näiteks selle asemel, et perioodiliselt käitada AWS-i konfiguratsioonipäringuid, et kontrollida, kas kõik virtuaalserveris olevad kettad on krüptitud, saab AWS-i konfiguratsioonireegleid kasutada serveri ketaste pidevaks kontrollimiseks, et tagada selle tingimuse täitmine. Ja mis kõige tähtsam, selle väljaande kontekstis genereerivad kõik rikkumised sündmusi, mida teie infoturbeteenistus saab analüüsida.

AWS-il on ka samaväärne traditsiooniliste ettevõtte infoturbelahendustega, mis genereerivad ka turbesündmusi, mida saate ja peaksite analüüsima:

• Sissetungi tuvastamine – AWS GuardDuty
• Teabelekke kontroll – AWS Macie
• EDR (kuigi see räägib pilves olevatest lõpp-punktidest veidi imelikult) - AWS Cloudwatch + avatud lähtekoodiga osquery või GRR lahendused
• Netflow analüüs – AWS Cloudwatch + AWS VPC Flow
• DNS-analüüs – AWS Cloudwatch + AWS Route53
• AD – AWS-i kataloogiteenus
• Kontohaldus – AWS IAM
• SSO – AWS SSO
• turvaanalüüs – AWS inspektor
• konfiguratsioonihaldus – AWS Config
• WAF – AWS WAF.

Ma ei kirjelda üksikasjalikult kõiki Amazoni teenuseid, mis võivad infoturbe kontekstis kasulikud olla. Peaasi on mõista, et kõik need suudavad genereerida sündmusi, mida saame ja peaksime infoturbe kontekstis analüüsima, kasutades selleks nii Amazoni enda sisseehitatud võimalusi kui ka väliseid lahendusi, näiteks SIEM, mis suudab viige turvasündmused oma seirekeskusesse ja analüüsige neid seal koos teiste pilveteenuste või sisemise infrastruktuuri, perimeetri või mobiilseadmete sündmustega.

Igal juhul algab kõik andmeallikatest, mis pakuvad teile infoturbe sündmusi. Nende allikate hulka kuuluvad, kuid mitte ainult:

• CloudTrail – API kasutamine ja kasutajatoimingud
• Usaldusväärne nõustaja – turvakontroll parimate tavade suhtes
• Config – kontode ja teenuseseadete inventuur ja konfigureerimine
• VPC Flow Logs – ühendused virtuaalsete liidestega
• IAM – identifitseerimis- ja autentimisteenus
• ELB juurdepääsulogid – koormuse tasakaalustaja
• Inspektor – rakenduse haavatavused
• S3 - failide salvestamine
• CloudWatch – rakenduste tegevus
• SNS on teavitusteenus.

Amazon pakub küll sellist valikut sündmuste allikaid ja tööriistu nende genereerimiseks, kuid on väga piiratud võimega analüüsida kogutud andmeid infoturbe kontekstis. Peate iseseisvalt uurima saadaolevaid logisid, otsides neis asjakohaseid kompromissinäitajaid. AWS-i turvakeskus, mille Amazon hiljuti käivitas, püüab selle probleemi lahendada, muutudes AWS-i pilv-SIEM-iks. Kuid seni on see alles oma teekonna alguses ja seda piiravad nii allikate arv, millega see töötab, kui ka muud piirangud, mis on kehtestatud Amazoni enda arhitektuuri ja tellimuste poolt.

Näide: Azure'il põhineva IaaS-i teabeturbe jälgimine

Ma ei taha laskuda pikalt vaidlusse selle üle, kumb kolmest pilvepakkujast (Amazon, Microsoft või Google) on parem (seda enam, et igaühel neist on ikkagi oma spetsiifika ja sobib oma probleemide lahendamiseks); Keskendume infoturbe jälgimise võimalustele, mida need mängijad pakuvad. Tuleb tunnistada, et Amazon AWS oli selles segmendis üks esimesi ja seetõttu on oma infoturbe funktsioonide osas kõige kaugemale arenenud (kuigi paljud tunnistavad, et neid on raske kasutada). Kuid see ei tähenda, et me ignoreeriksime võimalusi, mida Microsoft ja Google meile pakuvad.

Microsofti tooteid on alati eristanud "avatus" ja Azure'is on olukord sarnane. Näiteks kui AWS ja GCP lähtuvad alati kontseptsioonist "mis pole lubatud, on keelatud", on Azure'il täiesti vastupidine lähenemine. Näiteks pilves virtuaalse võrgu ja selles virtuaalmasina loomisel on kõik pordid ja protokollid avatud ja vaikimisi lubatud. Seetõttu peate Microsofti pilves juurdepääsukontrollisüsteemi esialgseks seadistamiseks veidi rohkem vaeva nägema. See seab teile Azure'i pilves toimuva tegevuse jälgimise osas ka rangemad nõuded.

AWS-i eripära on seotud asjaoluga, et kui jälgite oma virtuaalseid ressursse, kui need asuvad erinevates piirkondades, on teil raskusi kõigi sündmuste ja nende ühtse analüüsi kombineerimisega, mille kõrvaldamiseks peate kasutama erinevaid nippe, näiteks Looge AWS Lambda jaoks oma kood, mis edastab sündmusi piirkondade vahel. Azure'il seda probleemi pole – selle tegevuslogi mehhanism jälgib piiranguteta kõiki tegevusi kogu organisatsioonis. Sama kehtib ka AWS Security Hubi kohta, mille Amazon töötas hiljuti välja paljude turvafunktsioonide koondamiseks ühte turvakeskusesse, kuid ainult selle regiooni piiresse, mis aga Venemaa jaoks ei ole asjakohane. Azure'il on oma turvakeskus, mis ei ole seotud piirkondlike piirangutega, pakkudes juurdepääsu kõigile pilveplatvormi turvafunktsioonidele. Lisaks võib see erinevatele kohalikele meeskondadele pakkuda oma kaitsevõimalusi, sealhulgas nende hallatavaid turvasündmusi. AWS-i turvakeskus on endiselt Azure'i turvakeskusega sarnaseks muutumise teel. Kuid tasub lisada kärbseseen – võite Azure'ist välja pigistada palju varem AWS-is kirjeldatust, kuid seda on kõige mugavam teha ainult Azure AD, Azure Monitori ja Azure'i turvakeskuse jaoks. Kõiki teisi Azure'i turbemehhanisme, sealhulgas turbesündmuste analüüsi, ei hallata veel kõige mugavamal viisil. Probleemi lahendab osaliselt API, mis läbib kõiki Microsoft Azure'i teenuseid, kuid see nõuab teilt täiendavaid jõupingutusi pilve integreerimiseks SOC-iga ja kvalifitseeritud spetsialistide olemasolu (tegelikult nagu kõigi teiste pilvega töötava SIEM-i puhul API-d). Mõned SIEM-id, millest tuleb juttu hiljem, toetavad juba Azure'i ja suudavad selle jälgimise ülesande automatiseerida, kuid sellel on ka omad raskused – mitte kõik ei suuda koguda kõiki Azure'i logisid.

Sündmuste kogumist ja jälgimist Azure'is pakutakse Azure Monitori teenuse abil, mis on peamine tööriist andmete kogumiseks, salvestamiseks ja analüüsimiseks Microsofti pilves ja selle ressurssides – Giti hoidlad, konteinerid, virtuaalmasinad, rakendused jne. Kõik Azure Monitori kogutud andmed on jagatud kahte kategooriasse – reaalajas kogutavad mõõdikud, mis kirjeldavad Azure'i pilve peamisi jõudlusnäitajaid, ja logid, mis sisaldavad kirjeteks jaotatud andmeid, mis iseloomustavad Azure'i ressursside ja teenuste tegevuse teatud aspekte. Lisaks saab Azure Monitori teenus Data Collector API abil koguda andmeid mis tahes REST-i allikast, et luua oma jälgimisstsenaariumid.

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

• Tegevuste logid – see logi vastab klassikalistele küsimustele "kes", "mis" ja "millal" seoses pilveressursside kirjutamistoimingutega (PUT, POST, DELETE). Lugemisjuurdepääsuga (GET) seotud sündmused ei sisaldu selles logis, nagu paljud teised.
• Diagnostikalogid – sisaldab andmeid teie tellimuses sisalduva konkreetse ressursiga tehtud toimingute kohta.
• Azure AD aruandlus – sisaldab nii kasutajategevust kui ka süsteemitegevust, mis on seotud rühma- ja kasutajahaldusega.
• Windows Event Log ja Linux Syslog – sisaldab pilves hostitud virtuaalmasinate sündmusi.
• Mõõdikud – sisaldab telemeetriat pilveteenuste ja -ressursside toimivuse ja tervisliku seisundi kohta. Mõõdetakse iga minut ja hoitakse. 30 päeva jooksul.
• Network Security Group Flow Logs – sisaldab andmeid võrgu turvasündmuste kohta, mis on kogutud teenuse Network Watcher ja ressursside jälgimise abil võrgu tasandil.
• Salvestuslogid – sisaldab sündmusi, mis on seotud hoiukohtadele juurdepääsuga.

Jälgimiseks saate kasutada väliseid SIEM-e või sisseehitatud Azure Monitori ja selle laiendusi. Infoturbe sündmuste haldussüsteemidest räägime hiljem, kuid praegu vaatame, mida Azure ise meile turvalisuse kontekstis andmete analüüsiks pakub. Azure Monitori kõige turvalisusega seotud põhiekraan on Log Analyticsi turbe- ja auditeerimispaneel (tasuta versioon toetab piiratud kogust sündmuste salvestusruumi vaid üheks nädalaks). See armatuurlaud on jagatud viieks põhivaldkonnaks, mis visualiseerivad kokkuvõtvat statistikat teie kasutatavas pilvekeskkonnas toimuva kohta.

• Turvadomeenid – infoturbega seotud peamised kvantitatiivsed näitajad – intsidentide arv, ohustatud sõlmede arv, paigatamata sõlmed, võrguturbe sündmused jne.
• Märkimisväärsed probleemid – kuvab aktiivsete infoturbeprobleemide arvu ja tähtsust
• Tuvastamised – kuvab teie vastu kasutatud rünnakute mustrid
• Threat Intelligence – kuvab geograafilist teavet väliste sõlmede kohta, mis teid ründavad
• Levinud turvapäringud – tüüpilised päringud, mis aitavad teil oma infoturvet paremini jälgida.

Azure Monitori laienduste hulka kuuluvad Azure Key Vault (krüptograafiliste võtmete kaitse pilves), Malware Assessment (virtuaalsete masinate pahatahtliku koodi vastase kaitse analüüs), Azure Application Gateway Analytics (muuhulgas pilve tulemüüri logide analüüs) jne. . Need tööriistad, mis on rikastatud sündmuste töötlemise teatud reeglitega, võimaldavad teil visualiseerida pilveteenuste tegevuse erinevaid aspekte, sealhulgas turvalisust, ja tuvastada teatud kõrvalekaldeid tööst. Kuid nagu sageli juhtub, nõuab igasugune lisafunktsionaalsus vastavat tasulist tellimust, mis nõuab teilt vastavaid rahalisi investeeringuid, mida peate eelnevalt planeerima.

Azure'il on mitmeid sisseehitatud ohtude jälgimise võimalusi, mis on integreeritud Azure AD-sse, Azure Monitori ja Azure'i turbekeskusesse. Nende hulgas on näiteks virtuaalmasinate interaktsiooni tuvastamine teadaolevate pahatahtlike IP-dega (Microsofti Threat Intelligence teenustega integreerimise tõttu), pahavara tuvastamine pilve infrastruktuuris pilves hostitud virtuaalmasinate häirete vastuvõtmise teel, parool. oletusrünnakud ” virtuaalmasinatele, kasutajatuvastussüsteemi konfiguratsiooni haavatavused, anonüümisaatoritest või nakatunud sõlmedest süsteemi sisselogimine, kontolekked, süsteemi sisselogimine ebatavalistest kohtadest jne. Azure on täna üks väheseid pilveteenuse pakkujaid, kes pakub kogutud teabeturbesündmuste rikastamiseks sisseehitatud Threat Intelligence'i võimalusi.

Nagu eelpool mainitud, ei ole turvafunktsionaalsus ja sellest tulenevalt ka selle genereeritud turbesündmused kõigile kasutajatele võrdselt kättesaadavad, vaid eeldavad teatud, Teile vajalikku funktsionaalsust sisaldavat liitumist, mis genereerib infoturbe monitooringuks vastavad sündmused. Näiteks mõned eelmises lõigus kirjeldatud funktsioonid kontode anomaaliate jälgimiseks on saadaval ainult Azure AD teenuse P2 premium-litsentsis. Ilma selleta peate nagu AWS-i puhul kogutud turbesündmusi "käsitsi" analüüsima. Ja olenevalt Azure AD litsentsi tüübist ei ole kõik sündmused analüüsimiseks saadaval.

Azure'i portaalis saate hallata nii teid huvitavate logide otsingupäringuid kui ka seadistada armatuurlaudu, et visualiseerida peamisi teabeturbe näitajaid. Lisaks saab seal valida Azure Monitori laiendused, mis võimaldavad laiendada Azure Monitori logide funktsionaalsust ja saada sündmustest turvalisuse seisukohast sügavamat analüüsi.

Kui teil pole vaja ainult logidega töötamise võimalust, vaid ka oma Azure'i pilveplatvormi jaoks terviklikku turbekeskust, sealhulgas teabeturbepoliitika haldust, võite rääkida vajadusest töötada Azure'i turbekeskusega, mille enamik kasulikke funktsioone on teatud raha eest saadaval, näiteks ohtude tuvastamine, jälgimine väljaspool Azure'i, vastavushindamine jne. (tasuta versioonis on teil juurdepääs ainult turvahinnangule ja soovitustele tuvastatud probleemide kõrvaldamiseks). See koondab kõik turvaprobleemid ühte kohta. Tegelikult võime rääkida kõrgemast teabeturbe tasemest, kui Azure Monitor teile pakub, kuna sel juhul rikastatakse teie pilvetehases kogutud andmeid paljudest allikatest, 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), mille peal on erinevad keerukad masinõppe ja käitumisanalüütika algoritmid, mis peaksid lõpuks parandama ohtude tuvastamise ja neile reageerimise tõhusust. .

Azure'il on ka oma SIEM – see ilmus 2019. aasta alguses. See on Azure Sentinel, mis tugineb Azure Monitori andmetele ja mida saab ka integreerida. välised turvalahendused (näiteks NGFW või WAF), mille nimekiri täieneb pidevalt. Lisaks on teil tänu Microsoft Graph Security API integreerimisele võimalus ühendada oma Threat Intelligence'i voogusid Sentineliga, mis rikastab teie Azure'i pilve vahejuhtumite analüüsimise võimalusi. Võib väita, et Azure Sentinel on esimene “native” SIEM, mis ilmus pilveteenuse pakkujatelt (sama Splunk või ELK, mida saab pilves majutada, näiteks AWS, pole ikka veel traditsiooniliste pilveteenuste pakkujate poolt välja töötatud). Azure Sentineli ja turbekeskust võiks nimetada Azure'i pilve jaoks SOC-ks ja see võiks piirduda nendega (teatud reservatsioonidega), kui teil pole enam infrastruktuuri ja viisite kõik oma arvutusressursid pilve ja see oleks Microsofti pilv Azure.

Kuid kuna Azure'i sisseehitatud võimalustest (isegi kui teil on Sentineli tellimus) ei piisa sageli teabeturbe jälgimiseks ja selle protsessi integreerimiseks muude turbesündmuste allikatega (nii pilve- kui ka sisemised), on olemas kogutud andmed eksportida välistesse süsteemidesse, mis võivad sisaldada SIEM-i. Seda tehakse nii API-d kui ka spetsiaalseid laiendusi kasutades, mis on hetkel ametlikult saadaval ainult järgmistele SIEM-idele – Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ja ELK. Kuni viimase ajani oli selliseid SIEM-e rohkem, kuid alates 1. juunist 2019 lõpetas Microsoft Azure'i logide integreerimise tööriista (AzLog) toetamise, mis Azure'i olemasolu koidikul ja logidega töötamise tavapärase standardimise puudumisel (Azure) Monitori polnud veel olemas) muutis välise SIEM-i integreerimise Microsofti pilvega lihtsaks. Nüüd on olukord muutunud ja Microsoft soovitab Azure Event Hubi platvormi teiste SIEM-ide peamise integratsioonitööriistana. Paljud on sellise integratsiooni juba rakendanud, kuid olge ettevaatlik – need ei pruugi salvestada kõiki Azure'i logisid, vaid ainult mõnda (otsige oma SIEM-i dokumentatsiooni).

Lõpetuseks tahaksin anda ühe üldise soovituse selle pilveteenuse kohta – enne, kui ütlete midagi Azure'i infoturbe jälgimise funktsioonide kohta, peaksite need väga hoolikalt konfigureerima ja testima, kas need toimivad nii nagu dokumentatsioonis ja nagu konsultandid teile Microsoftile ütlesid (ja neil võivad Azure'i funktsioonide funktsionaalsuse kohta olla erinevad vaated). Kui teil on rahalisi vahendeid, saate Azure'ist infoturbe jälgimise osas palju kasulikku teavet välja pigistada. Kui teie ressursid on piiratud, peate nagu AWS-i puhul lootma ainult oma jõududele ja Azure Monitori toorandmetele. Ja pidage meeles, et paljud jälgimisfunktsioonid maksavad raha ja parem on hinnapoliitikaga eelnevalt tutvuda. Näiteks saate tasuta salvestada 31 päeva andmeid kuni maksimaalselt 5 GB kliendi kohta – nende väärtuste ületamine nõuab lisaraha (ligikaudu 2+ dollarit kliendi iga täiendava GB talletamise eest ja 0,1 dollarit). 1 GB iga järgmise kuu salvestamine). Rakenduste telemeetria ja mõõdikutega töötamine võib samuti nõuda lisaraha, samuti hoiatuste ja märguannetega töötamine (teatud limiit on saadaval tasuta, millest ei pruugi teie vajaduste jaoks piisata).

Näide: Google Cloud Platformil põhinev infoturbe jälgimine IaaS-is

Google Cloud Platform näeb AWS-i ja Azure'iga võrreldes välja nagu noor, kuid see on osaliselt hea. Erinevalt AWS-ist, mis suurendas oma võimalusi, sealhulgas turvalisust, järk-järgult, tsentraliseerimisega probleeme; GCP-d, nagu Azure, hallatakse palju paremini tsentraalselt, mis vähendab kogu ettevõttes vigu ja juurutusaega. Turvalisuse seisukohast on GCP kummalisel kombel AWS-i ja Azure'i vahel. Tal on ka kogu organisatsiooni jaoks üks ürituse registreerimine, kuid see on puudulik. Mõned funktsioonid on veel beetarežiimis, kuid järk-järgult tuleks see puudus kõrvaldada ja GCP-st saab infoturbe monitooringu osas küpsem platvorm.

Peamine tööriist sündmuste logimiseks GCP-s on Stackdriver Logging (sarnaselt Azure Monitoriga), mis võimaldab teil koguda sündmusi kogu pilve infrastruktuurist (ja ka AWS-ist). GCP turvalisuse seisukohast on igal organisatsioonil, projektil või kaustal neli logi.

• Admin Activity – sisaldab kõiki administraatorijuurdepääsuga seotud sündmusi, näiteks virtuaalmasina loomist, juurdepääsuõiguste muutmist jne. See logi kirjutatakse alati, olenemata teie soovist, ja säilitab selle andmeid 400 päeva.
• Andmejuurdepääs – sisaldab kõiki pilve kasutajate andmetega töötamise (loomine, muutmine, lugemine jne) sündmusi. Vaikimisi seda logi ei kirjutata, kuna selle maht paisub väga kiiresti. Sel põhjusel on selle säilivusaeg vaid 30 päeva. Lisaks pole selles ajakirjas kõike kirjutatud. Näiteks ei kirjutata sellele sündmusi, mis on seotud ressurssidega, mis on kõigile kasutajatele avalikult juurdepääsetavad või millele pääseb juurde ilma GCP-sse sisse logimata.
• Süsteemisündmus – sisaldab süsteemisündmusi, mis ei ole seotud kasutajatega või pilveressursside konfiguratsiooni muutva administraatori toimingutega. Seda kirjutatakse alati ja säilitatakse 400 päeva.
• Juurdepääsu läbipaistvus on ainulaadne näide logist, mis salvestab kõik Google'i töötajate tegevused (kuid mitte veel kõigi GCP-teenuste puhul), kes pääsevad juurde teie infrastruktuurile oma tööülesannete raames. Seda logi säilitatakse 400 päeva ja see pole saadaval igale GCP-kliendile, kuid ainult siis, kui on täidetud mitu tingimust (kas kuld- või plaatinataseme tugi või 4 teatud tüüpi rolli olemasolu ettevõtte toe osana). Sarnane funktsioon on saadaval ka näiteks Office 365-s – Lockbox.

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

Juurdepääs nendele logidele on võimalik mitmel viisil (samamoodi nagu eelnevalt käsitletud Azure'i ja AWS-i puhul) – logivaaturi liidese, API, Google Cloud SDK või teie projekti tegevuse lehe kaudu, mille jaoks te on sündmustest huvitatud. Samamoodi saab neid täiendavaks analüüsiks eksportida välistesse lahendustesse. Viimane toimub logide eksportimisel BigQuery või Cloud Pub/Sub salvestusruumi.

Lisaks Stackdriver Loggingile pakub GCP platvorm ka Stackdriver Monitoring funktsionaalsust, mis võimaldab jälgida pilveteenuste ja -rakenduste põhimõõdikuid (jõudlus, MTBF, üldine tervislik seisund jne). Töödeldud ja visualiseeritud andmed võivad hõlbustada probleemide leidmist teie pilve infrastruktuuris, sealhulgas turvalisuse kontekstis. Kuid tuleb märkida, et see funktsioon ei ole infoturbe kontekstis kuigi rikas, kuna täna pole GCP-l sama AWS GuardDuty analoogi ja see ei suuda tuvastada kõigi registreeritud sündmuste hulgast halbu (Google on välja töötanud Event Threat Detection, kuid see on veel beetaversioonis väljatöötamisel ja selle kasulikkusest on veel vara rääkida). Stackdriver Monitoringut saab kasutada anomaaliate tuvastamise süsteemina, mida seejärel uuritaks nende esinemise põhjuste leidmiseks. Kuid arvestades GCP teabeturbe valdkonnas kvalifitseeritud personali puudumist turul, tundub see ülesanne praegu keeruline.

Samuti tasub anda loetelu mõnedest teabeturbemoodulitest, mida saab kasutada teie GCP-pilves ja mis on sarnased AWS-i pakutavatega:

• Cloud Security Command Center on AWS-i turbekeskuse ja Azure'i turbekeskuse analoog.
• Pilve DLP – pilves hostitud andmete automaatne avastamine ja redigeerimine (nt maskeerimine), kasutades rohkem kui 90 eelmääratletud klassifitseerimispoliitikat.
• Cloud Scanner on App Engine'i, Compute Engine'i ja Google Kubernetes'i teadaolevate turvaaukude (XSS, Flash Injection, paigamata teegid jne) skanner.
• Pilve IAM – kontrollige juurdepääsu kõigile GCP ressurssidele.
• Cloud Identity – hallake GCP kasutajate, seadmete ja rakenduste kontosid ühest konsoolist.
• Cloud HSM - krüptograafiliste võtmete kaitse.
• Cloud Key Management Service – krüptovõtmete haldamine GCP-s.
• VPC teenuse juhtimine – looge oma GCP ressursside ümber turvaline perimeeter, et kaitsta neid lekete eest.
• Titani turvavõti – kaitse andmepüügi eest.

Paljud neist moodulitest genereerivad turbesündmusi, mida saab saata BigQuery salvestusruumi analüüsimiseks või eksportimiseks teistesse süsteemidesse, sh SIEM-i. Nagu eespool mainitud, on GCP aktiivselt arenev platvorm ja Google arendab nüüd oma platvormile mitmeid uusi infoturbe mooduleid. Nende hulgas on Event Threat Detection (saadaval beetaversioonis), mis skannib Stackdriveri logisid, otsides jälgi volitamata tegevusest (analoogselt GuardDutyga AWS-is) või Policy Intelligence (saadaval alfaversioonis), mis võimaldab teil arendada intelligentseid eeskirju juurdepääs GCP ressurssidele.

Tegin lühikese ülevaate populaarsete pilveplatvormide sisseehitatud jälgimisvõimalustest. Kuid kas teil on spetsialiste, kes on võimelised töötama IaaS-i "toorete" pakkujate logidega (kõik pole valmis ostma AWS-i või Azure'i või Google'i täiustatud võimalusi)? Lisaks on paljudele tuttav kõnekäänd "usalda, kuid kontrolli", mis on turvalisuse valdkonnas tõene kui kunagi varem. Kui palju usaldate pilveteenuse pakkuja sisseehitatud võimalusi, mis saadavad teile infoturbe sündmusi? Kui palju nad infoturbele üldse keskenduvad?

Mõnikord tasub vaadata ülekattega pilvetaristu jälgimislahendusi, mis võivad täiendada sisseehitatud pilveturvet, ja mõnikord on sellised lahendused ainus võimalus oma andmete ja pilves hostitavate rakenduste turvalisusest ülevaate saamiseks. Lisaks on need lihtsalt mugavamad, kuna võtavad enda kanda kõik erinevate pilveteenuse pakkujate erinevate pilveteenuste poolt genereeritud vajalike logide analüüsimise ülesanded. Sellise ülekattelahenduse näiteks on Cisco Stealthwatch Cloud, mis on keskendunud ühele ülesandele – pilvekeskkondade infoturbeanomaaliate jälgimisele, sealhulgas mitte ainult Amazon AWS-i, Microsoft Azure’i ja Google Cloud Platformi, vaid ka privaatpilvede jaoks.

Näide: teabeturbe jälgimine Stealthwatch Cloudi abil

AWS pakub paindlikku andmetöötlusplatvormi, kuid see paindlikkus muudab ettevõtete jaoks lihtsamaks vigade tegemise, mis põhjustavad turvaprobleeme. Ja jagatud infoturbe mudel aitab sellele ainult kaasa. Pilves töötav tarkvara tundmatute haavatavustega (tuntud nendega saab võidelda näiteks AWS Inspector või GCP Cloud Scanner), nõrkade paroolide, valed seadistused, siseringid jne. Ja see kõik kajastub pilveressursside käitumises, mida saab jälgida Cisco Stealthwatch Cloudiga, mis on infoturbe jälgimise ja rünnakute tuvastamise süsteem. avalikud ja privaatsed pilved.

Üks Cisco Stealthwatch Cloudi põhifunktsioone on üksuste modelleerimise võimalus. Selle abil saate luua iga pilveressursside tarkvaramudeli (st peaaegu reaalajas simulatsiooni) (pole vahet, kas see on AWS, Azure, GCP või midagi muud). Need võivad hõlmata servereid ja kasutajaid, aga ka teie pilvekeskkonnale omaseid ressursitüüpe, nagu turvarühmad ja automaatse skaleerimise rühmad. Need mudelid kasutavad sisendina pilveteenuste pakutavaid struktureeritud andmevooge. Näiteks AWS-i jaoks oleksid need VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ja AWS IAM. Olemi modelleerimine avastab automaatselt teie mis tahes ressursi rolli ja käitumise (võite rääkida kogu pilvetegevuse profileerimisest). Nende rollide hulka kuuluvad Androidi või Apple'i mobiilseade, Citrix PVS-server, RDP-server, meililüüs, VoIP-klient, terminaliserver, domeenikontroller jne. Seejärel jälgib see pidevalt nende käitumist, et teha kindlaks, millal esineb riskantne või ohutust ohustav käitumine. Saate tuvastada parooli arvamise, DDoS-i rünnakud, andmelekked, ebaseadusliku kaugjuurdepääsu, pahatahtliku koodi tegevuse, haavatavuse skannimise ja muud ohud. Näiteks näeb selline kaugjuurdepääsu katse tuvastamine teie organisatsiooni jaoks ebatüüpilisest riigist (Lõuna-Korea) Kubernetese klastrisse SSH kaudu:

Ja selline näeb välja väidetav teabe leke Postgressi andmebaasist riiki, millega me pole varem suhtlemist kohanud:

Lõpetuseks, liiga paljud ebaõnnestunud SSH-katsed Hiinast ja Indoneesiast välisest kaugseadmest näevad välja sellised:

Või oletame, et serveri eksemplar VPC-s ei ole poliitika kohaselt kunagi kaugsisselogimise sihtkoht. Oletame veel, et see arvuti koges kaugsisselogimist tulemüürireeglite poliitika eksliku muudatuse tõttu. Olemi modelleerimise funktsioon tuvastab ja teatab selle tegevuse (“ebatavaline kaugjuurdepääs”) peaaegu reaalajas ning osutab konkreetsele AWS CloudTraili, Azure Monitori või GCP Stackdriver Logging API kõnele (sh kasutajanimi, kuupäev ja kellaaeg, muu hulgas ), mis ajendas ITU reeglit muutma. Ja siis saab selle teabe SIEM-ile analüüsimiseks saata.

Sarnased võimalused on rakendatud iga pilvekeskkonna jaoks, mida toetab Cisco Stealthwatch Cloud:

Olemi modelleerimine on ainulaadne turbeautomaatika vorm, mis võib paljastada teie inimeste, protsesside või tehnoloogiaga seotud senitundmatu probleemi. Näiteks võimaldab see tuvastada muu hulgas turvaprobleeme, nagu:

• Kas keegi on avastanud meie kasutatavas tarkvaras tagaukse?
• Kas meie pilves on kolmanda osapoole tarkvara või seade?
• Kas volitatud kasutaja kuritarvitab õigusi?
• Kas ilmnes konfiguratsiooniviga, mis võimaldas kaugjuurdepääsu või muud soovimatut ressursside kasutamist?
• Kas meie serveritest lekib andmeleke?
• Kas keegi üritas meiega ühendust luua ebatüüpilisest geograafilisest asukohast?
• Kas meie pilv on nakatunud pahatahtliku koodiga?

Tuvastatud infoturbesündmuse saab saata vastava piletina Slacki, Cisco Sparki, intsidentide haldussüsteemi PagerDuty ning saata ka erinevatesse SIEM-idesse, sh Splunk või ELK. Kokkuvõtteks võib öelda, et kui teie ettevõte kasutab mitme pilve strateegiat ega piirdu ühegi pilveteenuse pakkujaga, ülalkirjeldatud infoturbe monitooringu võimalustega, siis on Cisco Stealthwatch Cloudi kasutamine hea võimalus ühtse seirekomplekti hankimiseks. võimalused juhtivatele pilvemängijatele – Amazon, Microsoft ja Google. Kõige huvitavam on see, et kui võrrelda Stealthwatch Cloudi hindu infoturbe jälgimise täiustatud litsentsidega AWS-is, Azure'is või GCP-s, võib selguda, et Cisco lahendus tuleb isegi odavam kui Amazoni, Microsofti sisseehitatud võimalused. ja Google'i lahendusi. See on paradoksaalne, kuid see on tõsi. Ja mida rohkem pilvi ja nende võimalusi kasutate, seda ilmsem on konsolideeritud lahenduse eelis.

Lisaks saab Stealthwatch Cloud jälgida teie organisatsioonis juurutatud privaatpilvi, näiteks Kubernetese konteinerite põhjal või jälgides võrguseadmetes (isegi kodumaises toodetud), AD andmetes või DNS-serverites jms peegeldamise kaudu saadud Netflow voogusid või võrguliiklust. Kõiki neid andmeid rikastatakse ohuluure teabega, mille on kogunud Cisco Talos, maailma suurim küberjulgeolekuohtude uurijate valitsusväline rühm.

See võimaldab teil rakendada ühtset seiresüsteemi nii avalike kui ka hübriidpilvede jaoks, mida teie ettevõte võib kasutada. Seejärel saab kogutud teavet Stealthwatch Cloudi sisseehitatud võimaluste abil analüüsida või saata oma SIEM-i (Splunk, ELK, SumoLogic ja mitmed teised on vaikimisi toetatud).

Sellega lõpetame artikli esimese osa, milles vaatasin üle IaaS/PaaS platvormide infoturbe jälgimise sisseehitatud ja välised tööriistad, mis võimaldavad kiiresti tuvastada pilvekeskkondades toimuvaid intsidente ja neile reageerida. meie ettevõte on valinud. Teises osas jätkame teemat ja vaatleme Salesforce’i ja Dropboxi näitel SaaS-i platvormide jälgimise võimalusi, samuti proovime kõik kokku võtta ja kokku panna luues ühtse infoturbe monitooringusüsteemi erinevatele pilvepakkujatele.

Allikas: www.habr.com