Cloud Security Monitoring

Presun údajov a aplikácií do cloudu predstavuje novú výzvu pre podnikové SOC, ktoré nie sú vždy pripravené monitorovať infraštruktúru niekoho iného. Podľa Netoskope priemerný podnik (zrejme v USA) využíva 1246 22 rôznych cloudových služieb, čo je o 1246 % viac ako pred rokom. 175 cloudových služieb!!! 170 z nich sa týka HR služieb, 110 marketingu, 76 oblasti komunikácie a 700 financií a CRM. Cisco využíva „len“ XNUMX externých cloudových služieb. Tak som z týchto čísel trochu zmätený. Ale v každom prípade problém nie je v nich, ale v tom, že cloud začína pomerne aktívne využívať čoraz viac firiem, ktoré by chceli mať rovnaké možnosti na monitorovanie cloudovej infraštruktúry ako vo vlastnej sieti. A tento trend rastie – podľa podľa Americkej účtovnej komory Do roku 2023 sa v Spojených štátoch zatvorí 1200 6250 dátových centier (XNUMX XNUMX už bolo zatvorených). Prechod na cloud však nie je len „presuňme naše servery k externému poskytovateľovi“. Nová IT architektúra, nový softvér, nové procesy, nové obmedzenia... To všetko prináša výrazné zmeny do práce nielen IT, ale aj informačnej bezpečnosti. A ak sa poskytovatelia naučili nejako zvládnuť zabezpečenie bezpečnosti samotného cloudu (našťastie existuje veľa odporúčaní), potom s monitorovaním bezpečnosti informácií v cloude, najmä na platformách SaaS, existujú značné ťažkosti, o ktorých budeme hovoriť.

Povedzme, že vaša spoločnosť presunula časť svojej infraštruktúry do cloudu... Stop. Nie takto. Ak bola infraštruktúra prevedená a vy len teraz uvažujete o tom, ako ju budete monitorovať, tak ste už prehrali. Pokiaľ to nie je Amazon, Google alebo Microsoft (a potom s výhradami), pravdepodobne nebudete mať veľkú možnosť monitorovať svoje dáta a aplikácie. Je dobré, ak máte možnosť pracovať s protokolmi. Niekedy budú k dispozícii údaje o udalostiach zabezpečenia, ale nebudete k nim mať prístup. Napríklad Office 365. Ak máte najlacnejšiu licenciu E1, tak bezpečnostné udalosti pre vás nie sú vôbec dostupné. Ak máte licenciu E3, vaše údaje sú uložené iba 90 dní a iba ak máte licenciu E5, trvanie protokolov je k dispozícii na rok (má to však aj svoje nuansy súvisiace s potrebou oddelene vyžiadajte si od podpory spoločnosti Microsoft množstvo funkcií na prácu s protokolmi). Mimochodom, licencia E3 je z hľadiska monitorovacích funkcií oveľa slabšia ako firemná Exchange. Na dosiahnutie rovnakej úrovne potrebujete licenciu E5 alebo dodatočnú licenciu Advanced Compliance, ktorá si môže vyžadovať ďalšie peniaze, ktoré neboli zohľadnené vo vašom finančnom modeli prechodu na cloudovú infraštruktúru. A to je len jeden príklad podceňovania problémov súvisiacich s monitorovaním bezpečnosti informácií v cloude. V tomto článku, bez toho, aby som predstieral, že je úplný, chcem upozorniť na niektoré nuansy, ktoré je potrebné vziať do úvahy pri výbere poskytovateľa cloudu z hľadiska bezpečnosti. A na konci článku bude uvedený kontrolný zoznam, ktorý stojí za to dokončiť predtým, ako zvážime, že problém monitorovania bezpečnosti informácií v cloude bol vyriešený.

Existuje niekoľko typických problémov, ktoré vedú k incidentom v cloudových prostrediach, na ktoré služby informačnej bezpečnosti nemajú čas reagovať alebo ich vôbec nevidia:

• Protokoly zabezpečenia neexistujú. Ide o pomerne bežnú situáciu najmä medzi začínajúcimi hráčmi na trhu cloudových riešení. Nemali by ste sa ich však hneď vzdávať. Malí hráči, najmä domáci, sú citlivejší na požiadavky zákazníkov a môžu rýchlo implementovať niektoré požadované funkcie zmenou schválenej cestovnej mapy svojich produktov. Áno, nebude to analóg GuardDuty od Amazonu alebo modul „Proaktívna ochrana“ od Bitrix, ale aspoň niečo.
• Informačná bezpečnosť nevie, kde sú protokoly uložené, alebo k nim nie je prístup. Tu je potrebné vstúpiť do jednania s poskytovateľom cloudových služieb – možno takéto informácie poskytne, ak považuje klienta za dôležitého. Vo všeobecnosti však nie je veľmi dobré, keď sa prístup k protokolom poskytuje „na základe osobitného rozhodnutia“.
• Stáva sa tiež, že poskytovateľ cloudu má protokoly, ktoré však poskytujú obmedzené monitorovanie a zaznamenávanie udalostí, ktoré nestačia na odhalenie všetkých incidentov. Môžete napríklad dostávať iba protokoly zmien na webovej stránke alebo protokoly pokusov o overenie používateľa, ale nie iné udalosti, ako je sieťová prevádzka, ktorá pred vami skryje celú vrstvu udalostí, ktoré charakterizujú pokusy o hacknutie vašej cloudovej infraštruktúry.
• Existujú protokoly, ale prístup k nim je ťažké automatizovať, čo núti ich sledovať nie nepretržite, ale podľa plánu. A ak nemôžete sťahovať protokoly automaticky, sťahovanie protokolov napríklad vo formáte Excel (ako u mnohých domácich poskytovateľov cloudových riešení) môže dokonca viesť k neochote zo strany podnikovej informačnej bezpečnostnej služby pohrať sa s nimi.
• Žiadne sledovanie denníka. Toto je možno najnejasnejší dôvod výskytu incidentov informačnej bezpečnosti v cloudových prostrediach. Zdá sa, že existujú protokoly a je možné k nim automatizovať prístup, ale nikto to nerobí. prečo?

Zdieľaný cloudový bezpečnostný koncept

Prechod na cloud je vždy hľadaním rovnováhy medzi túžbou udržať kontrolu nad infraštruktúrou a jej odovzdaním do profesionálnejších rúk cloudového poskytovateľa, ktorý sa na jej údržbu špecializuje. A túto rovnováhu treba hľadať aj v oblasti cloudovej bezpečnosti. Navyše, v závislosti od použitého modelu poskytovania cloudových služieb (IaaS, PaaS, SaaS) bude tento zostatok neustále odlišný. V každom prípade musíme pamätať na to, že všetci poskytovatelia cloudu sa dnes riadia takzvaným modelom zdieľanej zodpovednosti a zdieľanej informačnej bezpečnosti. Za niektoré veci je zodpovedný cloud a za iné je zodpovedný klient, ktorý do cloudu umiestňuje svoje dáta, svoje aplikácie, svoje virtuálne stroje a ďalšie zdroje. Bolo by bezohľadné očakávať, že prechodom do cloudu presunieme všetku zodpovednosť na poskytovateľa. Pri prechode do cloudu je však tiež nerozumné budovať všetko zabezpečenie sami. Vyžaduje sa rovnováha, ktorá bude závisieť od mnohých faktorov: - stratégia riadenia rizík, model hrozby, bezpečnostné mechanizmy dostupné poskytovateľovi cloudu, legislatíva atď.

Napríklad za klasifikáciu dát hostených v cloude je vždy zodpovedný zákazník. Poskytovateľ cloudu alebo externý poskytovateľ služieb mu môže pomôcť len nástrojmi, ktoré pomôžu označovať údaje v cloude, identifikovať porušenia, mazať údaje porušujúce zákon alebo ich maskovať tak či onak. Na druhej strane, fyzická bezpečnosť je vždy zodpovednosťou poskytovateľa cloudu, ktorú nemôže zdieľať s klientmi. Ale všetko, čo je medzi dátami a fyzickou infraštruktúrou, je presne predmetom diskusie v tomto článku. Napríklad dostupnosť cloudu je v kompetencii poskytovateľa a nastavenie pravidiel firewallu alebo povolenie šifrovania je v kompetencii klienta. V tomto článku sa pokúsime pozrieť na to, aké mechanizmy monitorovania informačnej bezpečnosti dnes poskytujú rôzni populárni poskytovatelia cloudu v Rusku, aké sú vlastnosti ich použitia a kedy sa oplatí hľadať externé prekrývacie riešenia (napríklad Cisco E- mail Security), ktoré rozširujú možnosti vášho cloudu z hľadiska kybernetickej bezpečnosti. V niektorých prípadoch, najmä ak sa riadite multicloudovou stratégiou, vám nezostane nič iné, ako použiť externé riešenia monitorovania informačnej bezpečnosti vo viacerých cloudových prostrediach naraz (napríklad Cisco CloudLock alebo Cisco Stealthwatch Cloud). V niektorých prípadoch si uvedomíte, že poskytovateľ cloudu, ktorého ste si vybrali (alebo ktorý vám bol uložený), neponúka vôbec žiadne možnosti monitorovania bezpečnosti informácií. Je to nepríjemné, ale tiež nie málo, pretože vám to umožňuje primerane posúdiť úroveň rizika spojeného s prácou s týmto cloudom.

Životný cyklus monitorovania bezpečnosti cloudu

Na monitorovanie bezpečnosti cloudov, ktoré používate, máte len tri možnosti:

• spoliehať sa na nástroje, ktoré poskytuje váš poskytovateľ cloudu,
• používať riešenia od tretích strán, ktoré budú monitorovať platformy IaaS, PaaS alebo SaaS, ktoré používate,
• vybudovať si vlastnú cloudovú monitorovaciu infraštruktúru (iba pre platformy IaaS/PaaS).

Pozrime sa, aké funkcie má každá z týchto možností. Najprv však musíme pochopiť všeobecný rámec, ktorý sa bude používať pri monitorovaní cloudových platforiem. Vyzdvihol by som 6 hlavných komponentov procesu monitorovania informačnej bezpečnosti v cloude:

• Príprava infraštruktúry. Určenie potrebných aplikácií a infraštruktúry na zber udalostí dôležitých pre bezpečnosť informácií do úložiska.
• Zbierka. V tejto fáze sú bezpečnostné udalosti agregované z rôznych zdrojov na následný prenos na spracovanie, uloženie a analýzu.
• Liečba. V tejto fáze sa údaje transformujú a obohatia, aby sa uľahčila následná analýza.
• Skladovanie. Tento komponent je zodpovedný za krátkodobé a dlhodobé ukladanie zozbieraných spracovaných a nespracovaných údajov.
• Analýza. V tejto fáze máte možnosť detekovať incidenty a reagovať na ne automaticky alebo manuálne.
• Nahlasovanie. Táto fáza pomáha formulovať kľúčové ukazovatele pre zainteresované strany (manažment, audítorov, poskytovateľa cloudu, klientov atď.), ktoré nám pomáhajú pri určitých rozhodnutiach, napríklad pri zmene poskytovateľa alebo posilnení informačnej bezpečnosti.

Pochopenie týchto komponentov vám umožní v budúcnosti rýchlo sa rozhodnúť, čo si môžete vziať od svojho poskytovateľa a čo budete musieť urobiť sami alebo so zapojením externých konzultantov.

Vstavané cloudové služby

Už som písal vyššie, že mnohé cloudové služby dnes neposkytujú žiadne možnosti monitorovania informačnej bezpečnosti. Vo všeobecnosti sa téme informačnej bezpečnosti príliš nevenujú. Napríklad jedna z populárnych ruských služieb na posielanie správ vládnym agentúram cez internet (jej názov konkrétne neuvediem). Celá časť o bezpečnosti tejto služby sa točí okolo používania certifikovaného CIPF. Nie je tomu inak ani v sekcii informačnej bezpečnosti ďalšej domácej cloudovej služby pre správu elektronických dokumentov. Hovorí o certifikátoch verejného kľúča, certifikovanej kryptografii, odstraňovaní slabín webu, ochrane pred DDoS útokmi, používaní firewallov, zálohovaní a dokonca aj pravidelných auditoch informačnej bezpečnosti. Ale nie je tam ani slovo o monitorovaní, ani o možnosti získať prístup k udalostiam informačnej bezpečnosti, ktoré môžu byť zaujímavé pre klientov tohto poskytovateľa služieb.

Vo všeobecnosti, podľa toho, ako poskytovateľ cloudu popisuje problémy s bezpečnosťou informácií na svojej webovej stránke a vo svojej dokumentácii, môžete pochopiť, ako vážne berie tento problém. Ak si napríklad prečítate príručky k produktom „My Office“, o bezpečnosti nie je ani slovo, ale v dokumentácii k samostatnému produktu „My Office. KS3“, určený na ochranu pred neoprávneným prístupom, je zaužívaný zoznam bodov 17. rádu FSTEC, ktorý „Moja kancelária.KS3“ implementuje, ale nie je popísané, ako to implementuje a hlavne ako integrovať tieto mechanizmy s podnikovou informačnou bezpečnosťou. Možno takáto dokumentácia existuje, ale nenašiel som ju vo verejnej doméne na webovej stránke „My Office“. Aj keď možno len nemám prístup k týmto tajným informáciám?...

Pre Bitrix je situácia oveľa lepšia. Dokumentácia popisuje formáty protokolov udalostí a, čo je zaujímavé, protokol narušenia, ktorý obsahuje udalosti súvisiace s potenciálnymi hrozbami pre cloudovú platformu. Odtiaľ môžete vytiahnuť IP, meno používateľa alebo hosťa, zdroj udalosti, čas, používateľského agenta, typ udalosti atď. Pravda, s týmito udalosťami môžete pracovať buď z ovládacieho panela samotného cloudu, alebo nahrávať dáta vo formáte MS Excel. Teraz je ťažké automatizovať prácu s protokolmi Bitrix a časť práce budete musieť vykonať manuálne (nahrať správu a načítať ju do vášho SIEM). Ale ak si spomenieme, že ešte relatívne nedávno takáto možnosť neexistovala, tak je to veľký pokrok. Zároveň by som rád poznamenal, že mnohí zahraniční poskytovatelia cloudu ponúkajú podobnú funkcionalitu „pre začiatočníkov“ - buď sa na protokoly pozerajte očami cez ovládací panel, alebo si údaje nahrajte do seba (väčšina však nahráva údaje vo formáte . csv, nie Excel).

Bez toho, aby ste zvážili možnosť bez protokolovania, poskytovatelia cloudu vám zvyčajne ponúkajú tri možnosti monitorovania bezpečnostných udalostí – dashboardy, nahrávanie údajov a prístup k API. Zdá sa, že prvý za vás vyrieši veľa problémov, ale nie je to celkom pravda – ak máte niekoľko časopisov, musíte prepínať medzi obrazovkami, ktoré ich zobrazujú, a strácať tak celkový obraz. Okrem toho je nepravdepodobné, že vám poskytovateľ cloudu poskytne možnosť korelovať bezpečnostné udalosti a vo všeobecnosti ich analyzovať z hľadiska bezpečnosti (zvyčajne máte do činenia s nespracovanými údajmi, ktorým musíte porozumieť sami). Existujú výnimky a o nich si povieme ďalej. Nakoniec stojí za to sa opýtať, aké udalosti zaznamenáva váš poskytovateľ cloudu, v akom formáte a ako zodpovedajú vášmu procesu monitorovania bezpečnosti informácií? Ide napríklad o identifikáciu a autentifikáciu používateľov a hostí. Ten istý Bitrix vám umožňuje na základe týchto udalostí zaznamenať dátum a čas udalosti, meno používateľa alebo hosťa (ak máte modul „Web Analytics“), ku ktorému sa pristupuje a ďalšie prvky typické pre webovú stránku. . Služby podnikovej informačnej bezpečnosti však môžu potrebovať informácie o tom, či používateľ pristupoval ku cloudu z dôveryhodného zariadenia (napríklad v podnikovej sieti túto úlohu implementuje Cisco ISE). A čo taká jednoduchá úloha, akou je funkcia geo-IP, ktorá pomôže určiť, či bol používateľský účet cloudovej služby odcudzený? A aj keď vám to poskytovateľ cloudu poskytne, nestačí to. Ten istý Cisco CloudLock neanalyzuje iba geolokáciu, ale využíva na to strojové učenie a analyzuje historické údaje pre každého používateľa a monitoruje rôzne anomálie v pokusoch o identifikáciu a autentifikáciu. Podobnú funkcionalitu má iba MS Azure (ak máte príslušné predplatné).

Je tu ešte jedna ťažkosť – keďže pre mnohých cloudových poskytovateľov je monitoring informačnej bezpečnosti novou témou, ktorou sa len začínajú zaoberať, neustále niečo vo svojich riešeniach menia. Dnes majú jednu verziu API, zajtra druhú, pozajtra tretiu. Aj na to treba byť pripravený. Rovnako je to aj s funkcionalitou, ktorá sa môže meniť, čo je potrebné zohľadniť vo vašom systéme monitorovania informačnej bezpečnosti. Napríklad Amazon mal pôvodne samostatné služby monitorovania cloudových udalostí – AWS CloudTrail a AWS CloudWatch. Potom sa objavila samostatná služba na monitorovanie udalostí informačnej bezpečnosti - AWS GuardDuty. Po určitom čase Amazon spustil nový systém správy, Amazon Security Hub, ktorý zahŕňa analýzu údajov získaných od GuardDuty, Amazon Inspector, Amazon Macie a niekoľkých ďalších. Ďalším príkladom je integračný nástroj Azure log so SIEM – AzLog. Aktívne ho používali mnohí predajcovia SIEM, až kým v roku 2018 Microsoft neoznámil zastavenie jeho vývoja a podpory, čo mnohých klientov, ktorí tento nástroj používali, konfrontovalo s problémom (o tom, ako sa to vyriešilo, si povieme neskôr).

Preto pozorne sledujte všetky funkcie monitorovania, ktoré vám váš poskytovateľ cloudu ponúka. Alebo sa spoľahnite na externých poskytovateľov riešení, ktorí budú pôsobiť ako sprostredkovatelia medzi vaším SOC a cloudom, ktorý chcete monitorovať. Áno, bude to drahšie (aj keď nie vždy), ale všetku zodpovednosť presuniete na plecia niekoho iného. Alebo nie všetko?... Pripomeňme si koncept zdieľanej bezpečnosti a pochopme, že nemôžeme nič posunúť – budeme musieť nezávisle pochopiť, ako rôzni poskytovatelia cloudu zabezpečujú monitorovanie informačnej bezpečnosti vašich dát, aplikácií, virtuálnych strojov a iných zdrojov hosťované v cloude. A začneme tým, čo ponúka Amazon v tejto časti.

Príklad: Monitorovanie informačnej bezpečnosti v IaaS založené na AWS

Áno, áno, chápem, že Amazon nie je najlepším príkladom, pretože ide o americkú službu a môže byť zablokovaná v rámci boja proti extrémizmu a šíreniu informácií zakázaných v Rusku. Ale v tejto publikácii by som chcel len ukázať, ako sa rôzne cloudové platformy líšia v možnostiach monitorovania informačnej bezpečnosti a na čo by ste si mali dať pozor pri prenose vašich kľúčových procesov do cloudu z bezpečnostného hľadiska. No, ak sa niektorí z ruských vývojárov cloudových riešení naučia niečo užitočné pre seba, bude to skvelé.

Prvá vec, ktorú treba povedať, je, že Amazon nie je nepreniknuteľná pevnosť. Jeho klientom sa pravidelne stávajú rôzne incidenty. Napríklad mená, adresy, dátumy narodenia a telefónne čísla 198 miliónov voličov boli ukradnuté z Deep Root Analytics. Izraelská spoločnosť Nice Systems ukradla 14 miliónov záznamov predplatiteľov Verizonu. Vstavané možnosti AWS vám však umožňujú odhaliť širokú škálu incidentov. Napríklad:

• vplyv na infraštruktúru (DDoS)
• kompromis uzla (injekcia príkazu)
• kompromitácia účtu a neoprávnený prístup
• nesprávna konfigurácia a slabé miesta
• nezabezpečené rozhrania a API.

Tento nesúlad je spôsobený tým, že ako sme zistili vyššie, za bezpečnosť zákazníckych údajov je zodpovedný sám zákazník. A ak sa neunúval zapnúť ochranné mechanizmy a nezapol monitorovacie nástroje, tak sa o incidente dozvie až z médií alebo od svojich klientov.

Na identifikáciu incidentov môžete použiť širokú škálu rôznych monitorovacích služieb vyvinutých spoločnosťou Amazon (aj keď sú často doplnené externými nástrojmi, ako je osquery). Takže v AWS sú všetky akcie používateľov monitorované bez ohľadu na to, ako sa vykonávajú - prostredníctvom riadiacej konzoly, príkazového riadku, SDK alebo iných služieb AWS. Všetky záznamy o aktivite každého účtu AWS (vrátane používateľského mena, akcie, služby, parametrov aktivity a výsledku) a používaní API sú dostupné prostredníctvom AWS CloudTrail. Tieto udalosti (napríklad prihlásenia do konzoly AWS IAM) môžete zobraziť z konzoly CloudTrail, analyzovať ich pomocou Amazon Athena alebo ich „outsourcovať“ externým riešeniam, ako sú Splunk, AlienVault atď. Samotné protokoly AWS CloudTrail sú umiestnené vo vašom vedre AWS S3.

Dve ďalšie služby AWS poskytujú množstvo ďalších dôležitých možností monitorovania. Po prvé, Amazon CloudWatch je služba monitorovania zdrojov a aplikácií AWS, ktorá vám okrem iného umožňuje identifikovať rôzne anomálie vo vašom cloude. Všetky vstavané služby AWS, ako je Amazon Elastic Compute Cloud (servery), Amazon Relational Database Service (databázy), Amazon Elastic MapReduce (analýza údajov) a 30 ďalších služieb Amazonu, používa Amazon CloudWatch na ukladanie svojich protokolov. Vývojári môžu použiť otvorené API od Amazon CloudWatch na pridanie funkcie monitorovania protokolov do vlastných aplikácií a služieb, čo im umožní rozšíriť rozsah analýzy udalostí v rámci bezpečnostného kontextu.

Po druhé, služba VPC Flow Logs vám umožňuje analyzovať sieťovú prevádzku odosielanú alebo prijímanú vašimi servermi AWS (externe alebo interne), ako aj medzi mikroslužbami. Keď ktorýkoľvek z vašich zdrojov AWS VPC interaguje so sieťou, protokoly toku VPC zaznamenávajú podrobnosti o sieťovej prevádzke vrátane rozhrania zdroja a cieľovej siete, ako aj adresy IP, porty, protokol, počet bajtov a počet paketov, ktoré videl. Tí, ktorí majú skúsenosti s lokálnou sieťovou bezpečnosťou, to uznajú za analogické s vláknami NetFlow, ktoré môžu byť vytvorené prepínačmi, smerovačmi a podnikovými firewallmi. Tieto protokoly sú dôležité pre účely monitorovania bezpečnosti informácií, pretože na rozdiel od udalostí o akciách používateľov a aplikácií vám tiež umožňujú nepremeškať sieťové interakcie v prostredí virtuálneho privátneho cloudu AWS.

Stručne povedané, tieto tri služby AWS – AWS CloudTrail, Amazon CloudWatch a VPC Flow Logs – spolu poskytujú pomerne silný prehľad o používaní vášho účtu, správaní používateľov, správe infraštruktúry, aktivite aplikácií a služieb a sieťovej aktivite. Môžu sa napríklad použiť na detekciu nasledujúcich anomálií:

• Pokusy o skenovanie stránky, hľadanie zadných vrátok, hľadanie zraniteľností prostredníctvom návalov „chyb 404“.
• Injekčné útoky (napríklad SQL injection) prostredníctvom návalov „500 chýb“.
• Známe nástroje útoku sú sqlmap, nikto, w3af, nmap atď. prostredníctvom analýzy poľa User Agent.

Amazon Web Services vyvinula aj ďalšie služby na účely kybernetickej bezpečnosti, ktoré vám umožňujú vyriešiť mnoho ďalších problémov. Napríklad AWS má vstavanú službu na auditovanie politík a konfigurácií - AWS Config. Táto služba poskytuje nepretržitý audit vašich prostriedkov AWS a ich konfigurácií. Vezmime si jednoduchý príklad: Povedzme, že sa chcete uistiť, že používateľské heslá sú zakázané na všetkých vašich serveroch a že prístup je možný len na základe certifikátov. AWS Config uľahčuje kontrolu tohto pre všetky vaše servery. Existujú aj ďalšie zásady, ktoré možno použiť na vaše cloudové servery: „Žiadny server nemôže používať port 22“, „Pravidlá brány firewall môžu meniť iba správcovia“ alebo „Nové používateľské účty môže vytvárať iba používateľ Ivashko a môže to robiť iba v utorok. " V lete 2016 bola služba AWS Config rozšírená o automatizáciu detekcie porušení vyvinutých politík. Pravidlá AWS Config sú v podstate nepretržité konfiguračné požiadavky pre služby Amazonu, ktoré používate, ktoré generujú udalosti, ak sú porušené príslušné pravidlá. Napríklad namiesto pravidelného spúšťania dotazov AWS Config na overenie, či sú všetky disky na virtuálnom serveri šifrované, je možné použiť pravidlá AWS Config na nepretržitú kontrolu diskov servera, aby sa zabezpečilo, že je splnená táto podmienka. A čo je najdôležitejšie, v kontexte tejto publikácie akékoľvek porušenia generujú udalosti, ktoré môže analyzovať vaša služba informačnej bezpečnosti.

AWS má tiež svoj ekvivalent k tradičným podnikovým informačným bezpečnostným riešeniam, ktoré tiež generujú bezpečnostné udalosti, ktoré môžete a mali by ste analyzovať:

• Detekcia narušenia - AWS GuardDuty
• Kontrola úniku informácií - AWS Macie
• EDR (aj keď trochu zvláštne hovorí o koncových bodoch v cloude) - AWS Cloudwatch + open source osquery alebo riešenia GRR
• Analýza Netflow - AWS Cloudwatch + AWS VPC Flow
• Analýza DNS - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Správa účtov - AWS IAM
• SSO - AWS SSO
• bezpečnostná analýza - AWS Inspector
• správa konfigurácie - AWS Config
• WAF - AWS WAF.

Nebudem podrobne popisovať všetky služby Amazonu, ktoré môžu byť užitočné v kontexte informačnej bezpečnosti. Hlavnou vecou je pochopiť, že všetky môžu generovať udalosti, ktoré môžeme a mali by sme analyzovať v kontexte informačnej bezpečnosti, pričom na tento účel využívajú vstavané schopnosti samotného Amazonu a externé riešenia, napríklad SIEM, ktoré môžu preneste bezpečnostné udalosti do svojho monitorovacieho centra a analyzujte ich tam spolu s udalosťami z iných cloudových služieb alebo z internej infraštruktúry, perimetra alebo mobilných zariadení.

V každom prípade to všetko začína zdrojmi údajov, ktoré vám poskytujú udalosti týkajúce sa bezpečnosti informácií. Tieto zdroje zahŕňajú, ale nie sú obmedzené na:

• CloudTrail - Použitie API a akcie používateľa
• Dôveryhodný poradca – bezpečnostná kontrola podľa osvedčených postupov
• Config - inventarizácia a konfigurácia účtov a nastavení služieb
• VPC Flow Logs - pripojenia k virtuálnym rozhraniam
• IAM - služba identifikácie a autentifikácie
• ELB Access Logs - Load Balancer
• Inšpektor – zraniteľnosti aplikácie
• S3 - úložisko súborov
• CloudWatch – Aplikačná aktivita
• SNS je oznamovacia služba.

Amazon, hoci ponúka takú škálu zdrojov udalostí a nástrojov na ich generovanie, má veľmi obmedzenú schopnosť analyzovať zozbierané údaje v kontexte informačnej bezpečnosti. Budete musieť nezávisle študovať dostupné protokoly a hľadať v nich relevantné ukazovatele kompromisu. AWS Security Hub, ktorý Amazon nedávno spustil, má za cieľ vyriešiť tento problém tým, že sa stane cloudovým SIEM pre AWS. Zatiaľ je však iba na začiatku svojej cesty a je limitovaný počtom zdrojov, s ktorými pracuje, ako aj ďalšími obmedzeniami, ktoré stanovuje architektúra a predplatné samotného Amazonu.

Príklad: Monitorovanie informačnej bezpečnosti v IaaS na báze Azure

Nechcem sa púšťať do dlhej debaty o tom, ktorý z troch cloudových poskytovateľov (Amazon, Microsoft alebo Google) je lepší (najmä preto, že každý z nich má stále svoje špecifické špecifiká a je vhodný na riešenie vlastných problémov); Zamerajme sa na možnosti monitorovania informačnej bezpečnosti, ktoré títo hráči poskytujú. Treba priznať, že Amazon AWS bol jedným z prvých v tomto segmente, a preto vo svojich funkciách informačnej bezpečnosti pokročil najďalej (hoci mnohí priznávajú, že ich používanie je náročné). To však neznamená, že budeme ignorovať príležitosti, ktoré nám Microsoft a Google poskytujú.

Produkty Microsoftu sa vždy vyznačovali svojou „otvorenosťou“ a v Azure je situácia podobná. Napríklad, ak AWS a GCP vždy vychádzajú z konceptu „čo nie je povolené, je zakázané“, Azure má presne opačný prístup. Napríklad pri vytváraní virtuálnej siete v cloude a virtuálneho stroja v nej sú všetky porty a protokoly štandardne otvorené a povolené. Preto budete musieť vynaložiť trochu viac úsilia na prvotné nastavenie systému kontroly prístupu v cloude od Microsoftu. A to na vás kladie aj prísnejšie požiadavky z hľadiska monitorovania aktivity v cloude Azure.

AWS má zvláštnosť spojenú so skutočnosťou, že keď monitorujete svoje virtuálne zdroje, ak sa nachádzajú v rôznych regiónoch, máte ťažkosti s kombinovaním všetkých udalostí a ich jednotnou analýzou, na odstránenie ktorej je potrebné uchýliť sa k rôznym trikom, ako napr. Vytvorte si vlastný kód pre AWS Lambda, ktorý bude prenášať udalosti medzi regiónmi. Azure tento problém nemá – jeho mechanizmus Activity Log sleduje všetky aktivity v celej organizácii bez obmedzení. To isté platí pre AWS Security Hub, ktorý bol nedávno vyvinutý spoločnosťou Amazon na konsolidáciu mnohých bezpečnostných funkcií v rámci jedného bezpečnostného centra, ale iba v rámci svojho regiónu, čo však pre Rusko nie je relevantné. Azure má svoje vlastné Centrum zabezpečenia, ktoré nie je viazané regionálnymi obmedzeniami a poskytuje prístup ku všetkým bezpečnostným funkciám cloudovej platformy. Navyše pre rôzne miestne tímy môže poskytnúť vlastnú sadu ochranných schopností, vrátane nimi riadených bezpečnostných udalostí. AWS Security Hub je stále na ceste stať sa podobným Azure Security Center. Ale stojí za to pridať muchu - z Azure môžete vytlačiť veľa z toho, čo bolo predtým opísané v AWS, ale najpohodlnejšie sa to robí iba pre Azure AD, Azure Monitor a Azure Security Center. Všetky ostatné bezpečnostné mechanizmy Azure, vrátane analýzy bezpečnostných udalostí, zatiaľ nie sú spravované tým najpohodlnejším spôsobom. Problém čiastočne rieši API, ktoré preniká do všetkých služieb Microsoft Azure, ale to si od vás bude vyžadovať ďalšie úsilie na integráciu vášho cloudu s vaším SOC a prítomnosť kvalifikovaných špecialistov (v skutočnosti, rovnako ako pri akomkoľvek inom SIEM, ktorý spolupracuje s cloudové API). Niektoré SIEM, o ktorých sa bude diskutovať neskôr, už podporujú Azure a dokážu automatizovať úlohu jeho monitorovania, no má to aj svoje ťažkosti – nie všetky dokážu zbierať všetky protokoly, ktoré má Azure.

Zhromažďovanie a monitorovanie udalostí v Azure je zabezpečené pomocou služby Azure Monitor, ktorá je hlavným nástrojom na zhromažďovanie, ukladanie a analýzu dát v cloude Microsoftu a jeho zdrojoch – Git repozitároch, kontajneroch, virtuálnych strojoch, aplikáciách atď. Všetky údaje, ktoré zbiera Azure Monitor, sú rozdelené do dvoch kategórií – metriky, zbierané v reálnom čase a popisujúce kľúčové ukazovatele výkonu cloudu Azure, a protokoly, obsahujúce údaje usporiadané do záznamov charakterizujúcich určité aspekty činnosti zdrojov a služieb Azure. Okrem toho môže služba Azure Monitor pomocou rozhrania Data Collector API zhromažďovať údaje z ľubovoľného zdroja REST na vytváranie vlastných scenárov monitorovania.

Tu je niekoľko zdrojov udalostí zabezpečenia, ktoré vám Azure ponúka a ku ktorým máte prístup cez Azure Portal, CLI, PowerShell alebo REST API (a niektoré iba cez Azure Monitor/Insight API):

• Protokoly aktivít – tento protokol odpovedá na klasické otázky „kto“, „čo“ a „kedy“ v súvislosti s akoukoľvek operáciou zápisu (PUT, POST, DELETE) do cloudových zdrojov. Udalosti súvisiace s prístupom na čítanie (GET) nie sú zahrnuté v tomto denníku, podobne ako mnohé iné.
• Diagnostické protokoly – obsahuje údaje o operáciách s konkrétnym zdrojom zahrnutým vo vašom predplatnom.
• Reporting Azure AD – obsahuje aktivitu používateľov aj aktivitu systému súvisiacu so správou skupín a používateľov.
• Windows Záznam udalostí a Linux Syslog – obsahuje udalosti z virtuálnych počítačov hostovaných v cloude.
• Metriky – obsahuje telemetriu o výkone a zdravotnom stave vašich cloudových služieb a zdrojov. Merané každú minútu a uložené. do 30 dní.
• Network Security Group Flow Logs – obsahuje údaje o udalostiach zabezpečenia siete zhromaždené pomocou služby Network Watcher a monitorovania zdrojov na úrovni siete.
• Záznamy úložiska – obsahuje udalosti súvisiace s prístupom k úložiskám.

Na monitorovanie môžete použiť externé SIEM alebo vstavaný Azure Monitor a jeho rozšírenia. O systémoch správy udalostí informačnej bezpečnosti si povieme neskôr, ale teraz sa pozrime, čo nám samotný Azure ponúka na analýzu údajov v kontexte bezpečnosti. Hlavnou obrazovkou pre všetko, čo súvisí so zabezpečením v Azure Monitor, je tabuľka Log Analytics Security and Audit Dashboard (bezplatná verzia podporuje obmedzené množstvo úložiska udalostí iba na jeden týždeň). Tento informačný panel je rozdelený do 5 hlavných oblastí, ktoré vizualizujú súhrnné štatistiky toho, čo sa deje v cloudovom prostredí, ktoré používate:

• Bezpečnostné domény – kľúčové kvantitatívne ukazovatele súvisiace s informačnou bezpečnosťou – počet incidentov, počet napadnutých uzlov, neoplatených uzlov, udalosti zabezpečenia siete atď.
• Pozoruhodné problémy – zobrazuje počet a dôležitosť aktívnych problémov s bezpečnosťou informácií
• Detekcie – zobrazuje vzory útokov použitých proti vám
• Threat Intelligence – zobrazuje geografické informácie o externých uzloch, ktoré na vás útočia
• Bežné bezpečnostné otázky – typické otázky, ktoré vám pomôžu lepšie monitorovať bezpečnosť vašich informácií.

Medzi rozšírenia Azure Monitor patrí Azure Key Vault (ochrana kryptografických kľúčov v cloude), Malware Assessment (analýza ochrany pred škodlivým kódom na virtuálnych počítačoch), Azure Application Gateway Analytics (analýza okrem iného protokolov cloudového firewallu) atď. . Tieto nástroje obohatené o určité pravidlá spracovania udalostí umožňujú vizualizovať rôzne aspekty činnosti cloudových služieb vrátane bezpečnosti a identifikovať určité odchýlky od prevádzky. Ako sa však často stáva, akékoľvek ďalšie funkcie si vyžadujú zodpovedajúce platené predplatné, ktoré si od vás bude vyžadovať zodpovedajúce finančné investície, ktoré si musíte naplánovať vopred.

Azure má množstvo vstavaných funkcií monitorovania hrozieb, ktoré sú integrované do Azure AD, Azure Monitor a Azure Security Center. Medzi nimi napríklad detekcia interakcie virtuálnych strojov so známymi škodlivými IP adresami (kvôli prítomnosti integrácie so službami Threat Intelligence od spoločnosti Microsoft), detekcia malvéru v cloudovej infraštruktúre prijímaním alarmov z virtuálnych strojov hostených v cloude, heslo hádanie útokov “ na virtuálne stroje, zraniteľnosti v konfigurácii systému identifikácie používateľov, prihlasovanie sa do systému z anonymizátorov alebo infikovaných uzlov, úniky účtov, prihlasovanie sa do systému z neobvyklých miest atď. Azure je dnes jedným z mála poskytovateľov cloudu, ktorý vám ponúka vstavané funkcie Threat Intelligence na obohatenie zhromaždených udalostí zabezpečenia informácií.

Ako už bolo spomenuté vyššie, bezpečnostná funkcionalita a v dôsledku toho ňou generované bezpečnostné udalosti nie sú dostupné pre všetkých používateľov rovnako, ale vyžadujú si určité predplatné, ktoré zahŕňa vami potrebnú funkcionalitu, ktorá generuje príslušné udalosti na monitorovanie informačnej bezpečnosti. Napríklad niektoré funkcie popísané v predchádzajúcom odseku na monitorovanie anomálií v účtoch sú dostupné iba v prémiovej licencii P2 pre službu Azure AD. Bez neho budete musieť, ako v prípade AWS, analyzovať zhromaždené bezpečnostné udalosti „ručne“. A tiež, v závislosti od typu licencie Azure AD, nie všetky udalosti budú dostupné na analýzu.

Na portáli Azure môžete spravovať vyhľadávacie dopyty pre denníky, ktoré vás zaujímajú, a nastaviť dashboardy na vizualizáciu kľúčových indikátorov zabezpečenia informácií. Okrem toho si tu môžete vybrať rozšírenia Azure Monitor, ktoré vám umožnia rozšíriť funkčnosť protokolov Azure Monitor a získať hlbšiu analýzu udalostí z hľadiska bezpečnosti.

Ak potrebujete nielen schopnosť pracovať s protokolmi, ale komplexné bezpečnostné centrum pre vašu cloudovú platformu Azure, vrátane správy politiky informačnej bezpečnosti, potom môžete hovoriť o potrebe práce s Azure Security Center, ktorého väčšina užitočných funkcií sú dostupné za nejaké peniaze, napríklad detekcia hrozieb, monitorovanie mimo Azure, hodnotenie súladu atď. (v bezplatnej verzii máte prístup len k hodnoteniu bezpečnosti a odporúčaniam na odstránenie zistených problémov). Konsoliduje všetky bezpečnostné problémy na jednom mieste. V skutočnosti môžeme hovoriť o vyššej úrovni zabezpečenia informácií, ako vám poskytuje Azure Monitor, pretože v tomto prípade sú údaje zhromaždené v celej vašej cloudovej továrni obohatené o mnoho zdrojov, ako sú Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) a Microsoft Security Response Center (MSRC), na ktorých sú umiestnené rôzne sofistikované algoritmy strojového učenia a behaviorálnej analýzy, čo by malo v konečnom dôsledku zlepšiť efektivitu zisťovania a reagovania na hrozby. .

Azure má tiež svoj vlastný SIEM - objavil sa začiatkom roka 2019. Ide o Azure Sentinel, ktorý sa spolieha na dáta z Azure Monitor a dokáže sa s ním aj integrovať. externé bezpečnostné riešenia (napríklad NGFW alebo WAF), ktorých zoznam sa neustále rozrastá. Navyše vďaka integrácii rozhrania Microsoft Graph Security API máte možnosť pripojiť svoje vlastné informačné kanály Threat Intelligence k Sentinelu, čo obohacuje možnosti analýzy incidentov vo vašom cloude Azure. Dá sa tvrdiť, že Azure Sentinel je prvým „natívnym“ SIEM, ktorý sa objavil od poskytovateľov cloudu (rovnaký Splunk alebo ELK, ktoré môžu byť hosťované v cloude, napríklad AWS, stále nie sú vyvinuté tradičnými poskytovateľmi cloudových služieb). Azure Sentinel a Security Center by sa dali nazvať SOC pre cloud Azure a mohli by sa na ne obmedziť (s určitými výhradami), ak by ste už nemali žiadnu infraštruktúru a presunuli ste všetky svoje výpočtové zdroje do cloudu a bol by to cloud Azure od spoločnosti Microsoft.

Keďže však vstavané možnosti Azure (aj keď máte predplatné Sentinelu) často nestačia na účely monitorovania informačnej bezpečnosti a integrácie tohto procesu s inými zdrojmi bezpečnostných udalostí (cloudové aj interné), existuje je potrebné exportovať zozbierané údaje do externých systémov, do ktorých môže patriť SIEM. A to ako pomocou API, tak aj pomocou špeciálnych rozšírení, ktoré sú zatiaľ oficiálne dostupné len pre nasledujúce SIEM – Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight a ELK. Donedávna bolo takýchto SIEM viac, no od 1. júna 2019 Microsoft prestal podporovať Azure Log Integration Tool (AzLog), ktorý na úsvite existencie Azure a pri absencii bežnej štandardizácie práce s protokolmi (Azure Monitor ešte ani neexistoval) uľahčil integráciu externého SIEM s cloudom Microsoftu. Teraz sa situácia zmenila a Microsoft odporúča platformu Azure Event Hub ako hlavný integračný nástroj pre ostatné SIEM. Mnohí už takúto integráciu implementovali, ale buďte opatrní – nemusia zachytávať všetky protokoly Azure, ale iba niektoré (pozrite si dokumentáciu k vášmu SIEM).

Na záver krátkej exkurzie do Azure by som rád dal všeobecné odporúčanie o tejto cloudovej službe – predtým, ako niečo poviete o funkciách monitorovania bezpečnosti informácií v Azure, mali by ste ich veľmi starostlivo nakonfigurovať a otestovať, či fungujú tak, ako je napísané v dokumentácii a ako vám povedali konzultanti Microsoft (a môžu mať rôzne názory na funkčnosť funkcií Azure). Ak máte finančné prostriedky, môžete z Azure vyžmýkať veľa užitočných informácií z hľadiska monitorovania informačnej bezpečnosti. Ak sú vaše zdroje obmedzené, tak ako v prípade AWS sa budete musieť spoľahnúť iba na svoje sily a nespracované dáta, ktoré vám Azure Monitor poskytuje. A nezabudnite, že mnohé monitorovacie funkcie stoja peniaze a je lepšie sa vopred oboznámiť s cenovou politikou. Bezplatne môžete napríklad uložiť 31 dní dát až do maximálnej kapacity 5 GB na zákazníka – prekročenie týchto hodnôt si bude vyžadovať vyplatenie ďalších peňazí (približne 2+ USD za uloženie každého ďalšieho GB od zákazníka a 0,1 USD za uloženie 1 GB každý ďalší mesiac). Práca s telemetriou a metrikami aplikácie si tiež môže vyžadovať dodatočné finančné prostriedky, ako aj práca s upozorneniami a upozorneniami (určitý limit je k dispozícii zadarmo, čo nemusí vašim potrebám stačiť).

Príklad: Monitorovanie informačnej bezpečnosti v IaaS založené na Google Cloud Platform

Google Cloud Platform vyzerá ako mladík v porovnaní s AWS a Azure, ale je to čiastočne dobré. Na rozdiel od AWS, ktoré postupne zvyšovalo svoje schopnosti, vrátane bezpečnostných, s problémami s centralizáciou; GCP, podobne ako Azure, je oveľa lepšie spravované centrálne, čo znižuje chyby a čas implementácie v rámci celého podniku. Z bezpečnostného hľadiska je GCP, napodiv, medzi AWS a Azure. Má tiež jednu registráciu na podujatie pre celú organizáciu, no tá je neúplná. Niektoré funkcie sú zatiaľ v beta režime, no postupne by sa tento nedostatok mal odstrániť a GCP sa stane vyspelejšou platformou z hľadiska monitorovania informačnej bezpečnosti.

Hlavným nástrojom na protokolovanie udalostí v GCP je Stackdriver Logging (obdoba Azure Monitor), ktorý vám umožňuje zbierať udalosti naprieč celou vašou cloudovou infraštruktúrou (aj z AWS). Z hľadiska zabezpečenia v GCP má každá organizácia, projekt alebo priečinok štyri denníky:

• Admin Activity – obsahuje všetky udalosti súvisiace s administratívnym prístupom, napríklad vytvorenie virtuálneho počítača, zmena prístupových práv atď. Tento denník je vždy zapísaný bez ohľadu na vaše želanie a uchováva svoje údaje po dobu 400 dní.
• Data Access – obsahuje všetky udalosti súvisiace s prácou s dátami zo strany užívateľov cloudu (vytváranie, úprava, čítanie a pod.). Štandardne sa tento protokol nezapisuje, pretože jeho objem sa veľmi rýchlo nafúkne. Z tohto dôvodu je jeho trvanlivosť iba 30 dní. Navyše v tomto časopise nie je napísané všetko. Napríklad udalosti súvisiace so zdrojmi, ktoré sú verejne prístupné všetkým používateľom alebo ktoré sú prístupné bez prihlásenia do GCP, sa do neho nezapisujú.
• Systémová udalosť – obsahuje systémové udalosti, ktoré nesúvisia s používateľmi, alebo akcie správcu, ktorý mení konfiguráciu cloudových prostriedkov. Vždy sa zapisuje a uchováva 400 dní.
• Transparentnosť prístupu je jedinečným príkladom denníka, ktorý zachytáva všetky akcie zamestnancov spoločnosti Google (zatiaľ však nie pre všetky služby GCP), ktorí pristupujú k vašej infraštruktúre v rámci svojich pracovných povinností. Tento protokol je uložený po dobu 400 dní a nie je dostupný pre každého klienta GCP, ale len pri splnení viacerých podmienok (buď podpora na úrovni Gold alebo Platinum, alebo prítomnosť 4 rolí určitého typu v rámci firemnej podpory). Podobná funkcia je dostupná napríklad aj v Office 365 – Lockbox.

Príklad denníka: Transparentnosť prístupu

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

Prístup k týmto protokolom je možný niekoľkými spôsobmi (v podstate rovnakým spôsobom, ako už bolo diskutované o Azure a AWS) – cez rozhranie Log Viewer, cez API, cez Google Cloud SDK alebo cez stránku Aktivita vášho projektu, pre ktorý zaujímajú sa o udalosti. Rovnakým spôsobom ich možno exportovať do externých riešení na dodatočnú analýzu. To sa vykonáva exportovaním denníkov do úložiska BigQuery alebo Cloud Pub/Sub.

Platforma GCP ponúka okrem Stackdriver Logging aj funkcionalitu Stackdriver Monitoring, ktorá umožňuje sledovať kľúčové metriky (výkon, MTBF, celkový stav atď.) cloudových služieb a aplikácií. Spracované a vizualizované dáta môžu uľahčiť hľadanie problémov vo vašej cloudovej infraštruktúre, a to aj v kontexte bezpečnosti. Treba však poznamenať, že táto funkcionalita nebude v kontexte informačnej bezpečnosti príliš bohatá, pretože GCP dnes nemá analóg rovnakého AWS GuardDuty a nedokáže identifikovať zlé medzi všetkými zaregistrovanými udalosťami (Google vyvinul Event Threat Detection, ale stále je vo vývoji v beta verzii a je príliš skoro hovoriť o jej užitočnosti). Stackdriver Monitoring by sa dal využiť ako systém na zisťovanie anomálií, ktoré by sa následne skúmali s cieľom nájsť príčiny ich vzniku. Ale vzhľadom na nedostatok kvalifikovaného personálu v oblasti informačnej bezpečnosti GCP na trhu sa táto úloha v súčasnosti javí ako náročná.

Tiež stojí za to uviesť zoznam niektorých modulov zabezpečenia informácií, ktoré možno použiť v rámci cloudu GCP a ktoré sú podobné tým, ktoré ponúka AWS:

• Cloud Security Command Center je analógom AWS Security Hub a Azure Security Center.
• Cloud DLP – Automatické zisťovanie a úprava (napr. maskovanie) údajov hosťovaných v cloude pomocou viac ako 90 preddefinovaných klasifikačných politík.
• Cloud Scanner je skener známych zraniteľností (XSS, Flash Injection, neopravené knižnice atď.) v App Engine, Compute Engine a Google Kubernetes.
• Cloud IAM – Riadenie prístupu ku všetkým zdrojom GCP.
• Cloud Identity – Spravujte účty používateľov, zariadení a aplikácií GCP z jedinej konzoly.
• Cloud HSM - ochrana kryptografických kľúčov.
• Cloud Key Management Service – správa kryptografických kľúčov v GCP.
• Kontrola služieb VPC – Vytvorte bezpečný obvod okolo svojich zdrojov GCP, aby ste ich chránili pred únikmi.
• Titan Security Key - ochrana pred phishingom.

Mnohé z týchto modulov generujú bezpečnostné udalosti, ktoré možno odoslať do úložiska BigQuery na analýzu alebo exportovať do iných systémov vrátane SIEM. Ako už bolo spomenuté vyššie, GCP je aktívne sa rozvíjajúca platforma a Google teraz pre svoju platformu vyvíja množstvo nových modulov informačnej bezpečnosti. Medzi nimi je Event Threat Detection (teraz k dispozícii v beta verzii), ktorá skenuje protokoly Stackdriver pri hľadaní stôp neoprávnenej aktivity (podobne ako GuardDuty v AWS), alebo Policy Intelligence (dostupná v alpha), ktorá vám umožní vyvinúť inteligentné politiky pre prístup k zdrojom GCP.

Urobil som krátky prehľad vstavaných možností monitorovania v populárnych cloudových platformách. Máte však špecialistov, ktorí sú schopní pracovať s „surovými“ protokolmi poskytovateľa IaaS (nie každý je pripravený kúpiť si pokročilé možnosti AWS alebo Azure alebo Google)? Okrem toho mnohí poznajú príslovie „dôveruj, ale preveruj“, ktoré je v oblasti bezpečnosti pravdivejšie ako kedykoľvek predtým. Do akej miery dôverujete vstavaným schopnostiam poskytovateľa cloudu, ktorý vám posiela udalosti týkajúce sa bezpečnosti informácií? Ako veľmi sa vôbec zameriavajú na informačnú bezpečnosť?

Niekedy stojí za to pozrieť sa na prekryvné riešenia monitorovania cloudovej infraštruktúry, ktoré môžu dopĺňať vstavané cloudové zabezpečenie, a niekedy sú takéto riešenia jedinou možnosťou, ako získať prehľad o bezpečnosti vašich údajov a aplikácií hostovaných v cloude. Okrem toho sú jednoducho pohodlnejšie, pretože preberajú všetky úlohy analýzy potrebných protokolov generovaných rôznymi cloudovými službami od rôznych poskytovateľov cloudu. Príkladom takéhoto overlay riešenia je Cisco Stealthwatch Cloud, ktorý je zameraný na jedinú úlohu – monitorovanie anomálií informačnej bezpečnosti v cloudových prostrediach, ktoré zahŕňajú nielen Amazon AWS, Microsoft Azure a Google Cloud Platform, ale aj privátne cloudy.

Príklad: Monitorovanie bezpečnosti informácií pomocou cloudu Stealthwatch

AWS poskytuje flexibilnú výpočtovú platformu, ale táto flexibilita uľahčuje spoločnostiam robiť chyby, ktoré vedú k problémom so zabezpečením. A model zdieľanej informačnej bezpečnosti k tomu len prispieva. Spustený softvér v cloude s neznámymi zraniteľnosťami (so známymi sa dá bojovať napr. AWS Inspector alebo GCP Cloud Scanner), slabými heslami, nesprávnymi konfiguráciami, insidermi atď. A to všetko sa odráža v správaní cloudových zdrojov, ktoré môže monitorovať Cisco Stealthwatch Cloud, čo je systém monitorovania bezpečnosti informácií a detekcie útokov. verejné a súkromné ​​cloudy.

Jednou z kľúčových funkcií služby Cisco Stealthwatch Cloud je jej schopnosť modelovania entít. Umožňuje vám vytvoriť programový model (t. j. simuláciu takmer v reálnom čase) každého z vašich cloudových zdrojov (či už ide o AWS, Azure, GCP alebo niečo iné). Tieto môžu zahŕňať servery a používateľov, ako aj typy zdrojov špecifické pre vaše cloudové prostredie, ako sú bezpečnostné skupiny a skupiny s automatickým škálovaním. Tieto modely používajú ako vstup štruktúrované dátové toky poskytované cloudovými službami. Napríklad pre AWS by to boli VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda a AWS IAM. Modelovanie entít automaticky zisťuje úlohu a správanie všetkých vašich zdrojov (efektívne profiluje všetku cloudovú aktivitu). Medzi tieto úlohy patria aj mobilné zariadenia. Android alebo Apple, server Citrix PVS, RDP server, poštová brána, VoIP klient, terminálový server, radič domény atď. Následne nepretržite monitoruje ich správanie, aby zistil, kedy dochádza k rizikovému alebo bezpečnostne ohrozujúcemu správaniu. Môžete identifikovať hádanie hesla, útoky DDoS, úniky údajov, nelegálny vzdialený prístup, malvér, skenovanie zraniteľností a ďalšie hrozby. Napríklad takto vyzerá detekcia pokusu o vzdialený prístup z nezvyčajného miesta (Južná Kórea) do klastra Kubernetes cez SSH:

A takto vyzerá údajný únik informácií z databázy Postgress do krajiny, s ktorou sme sa doteraz nestretli s interakciou:

Nakoniec takto vyzerá príliš veľa neúspešných pokusov o SSH z Číny a Indonézie z externého vzdialeného zariadenia:

Alebo predpokladajme, že inštancia servera vo VPC podľa politiky nikdy nebude cieľom vzdialeného prihlásenia. Ďalej predpokladajme, že tento počítač zaznamenal vzdialené prihlásenie v dôsledku chybnej zmeny v pravidlách brány firewall. Funkcia Entity Modeling zistí a nahlási túto aktivitu („Nezvyčajný vzdialený prístup“) takmer v reálnom čase a ukáže na konkrétne volanie AWS CloudTrail, Azure Monitor alebo GCP Stackdriver Logging API (vrátane používateľského mena, dátumu a času, medzi inými podrobnosťami). ), čo vyvolalo zmenu pravidla ITU. A potom môžu byť tieto informácie odoslané do SIEM na analýzu.

Podobné funkcie sú implementované pre akékoľvek cloudové prostredie podporované Cisco Stealthwatch Cloud:

Modelovanie entít je jedinečná forma automatizácie bezpečnosti, ktorá dokáže odhaliť predtým neznámy problém s vašimi ľuďmi, procesmi alebo technológiou. Umožňuje vám napríklad odhaliť okrem iného bezpečnostné problémy, ako sú:

• Objavil niekto zadné vrátka v softvéri, ktorý používame?
• Je v našom cloude nejaký softvér alebo zariadenie tretej strany?
• Zneužíva oprávnený používateľ privilégiá?
• Vyskytla sa chyba konfigurácie, ktorá umožňovala vzdialený prístup alebo iné neúmyselné použitie zdrojov?
• Dochádza k úniku údajov z našich serverov?
• Pokúšal sa k nám niekto pripojiť z atypického geografického miesta?
• Je náš cloud infikovaný škodlivým kódom?

Zistená udalosť informačnej bezpečnosti môže byť odoslaná vo forme zodpovedajúceho lístka do Slack, Cisco Spark, systému správy incidentov PagerDuty a tiež do rôznych SIEM, vrátane Splunk alebo ELK. Aby sme to zhrnuli, môžeme povedať, že ak vaša spoločnosť používa multi-cloudovú stratégiu a nie je obmedzená na žiadneho poskytovateľa cloudu, možnosti monitorovania bezpečnosti informácií popísané vyššie, potom je použitie Cisco Stealthwatch Cloud dobrou možnosťou na získanie jednotného monitorovania. schopnosti pre popredných cloudových hráčov – Amazon , Microsoft a Google. Najzaujímavejšie je, že ak porovnáte ceny za Stealthwatch Cloud s pokročilými licenciami na monitorovanie informačnej bezpečnosti v AWS, Azure alebo GCP, môže sa ukázať, že riešenie Cisco bude ešte lacnejšie ako vstavané možnosti Amazonu, Microsoftu a riešenia Google. Je to paradoxné, ale je to tak. A čím viac cloudov a ich možností využívate, tým jasnejšia bude výhoda konsolidovaného riešenia.

Okrem toho môže Stealthwatch Cloud monitorovať privátne cloudy nasadené vo vašej organizácii, napríklad na základe kontajnerov Kubernetes alebo monitorovaním tokov Netflow alebo sieťovej prevádzky prijatej prostredníctvom zrkadlenia v sieťových zariadeniach (aj v domácej produkcii), v údajoch AD alebo serveroch DNS atď. Všetky tieto údaje budú obohatené o informácie Threat Intelligence zozbierané spoločnosťou Cisco Talos, najväčšou svetovou mimovládnou skupinou výskumníkov kybernetických hrozieb.

To vám umožňuje implementovať jednotný monitorovací systém pre verejné aj hybridné cloudy, ktoré môže vaša spoločnosť využívať. Zhromaždené informácie potom možno analyzovať pomocou vstavaných funkcií Stealthwatch Cloud alebo ich odoslať do vášho SIEM (štandardne sú podporované Splunk, ELK, SumoLogic a niekoľko ďalších).

Týmto dokončíme prvú časť článku, v ktorej som zhodnotil vstavané a externé nástroje na monitorovanie informačnej bezpečnosti platforiem IaaS/PaaS, ktoré nám umožňujú rýchlo odhaliť a reagovať na incidenty vyskytujúce sa v cloudových prostrediach, ktoré si náš podnik vybral. V druhej časti budeme v téme pokračovať a pozrieme sa na možnosti monitorovania SaaS platforiem na príklade Salesforce a Dropbox a všetko sa pokúsime zhrnúť a dať dokopy vytvorením jednotného systému monitorovania informačnej bezpečnosti pre rôznych poskytovateľov cloudu.

Zdroj: hab.com