🥇Monitorizare securitate în cloud

Mutarea datelor și aplicațiilor în cloud prezintă o nouă provocare pentru SOC-urile corporative, care nu sunt întotdeauna pregătite să monitorizeze infrastructura altor persoane. Potrivit Netoskope, întreprinderea medie (aparent în SUA) utilizează 1246 de servicii cloud diferite, ceea ce este cu 22% mai mult decât acum un an. 1246 de servicii cloud!!! 175 dintre acestea se referă la servicii HR, 170 sunt legate de marketing, 110 sunt în domeniul comunicațiilor și 76 sunt în finanțe și CRM. Cisco folosește „doar” 700 de servicii cloud externe. Deci sunt puțin confuz de aceste numere. Dar, în orice caz, problema nu este la ei, ci la faptul că cloud-ul începe să fie folosit destul de activ de un număr tot mai mare de companii care ar dori să aibă aceleași capacități de monitorizare a infrastructurii cloud ca în propria lor rețea. Și această tendință este în creștere - conform conform Camerei de Conturi Americane Până în 2023, 1200 de centre de date vor fi închise în Statele Unite (6250 s-au închis deja). Dar tranziția la cloud nu este doar „să ne mutăm serverele la un furnizor extern”. Arhitectură IT nouă, software nou, procese noi, restricții noi... Toate acestea aduc schimbări semnificative nu numai în activitatea IT, ci și în securitatea informațiilor. Și dacă furnizorii au învățat să facă față cumva cu asigurarea securității cloud-ului în sine (din fericire există o mulțime de recomandări), atunci cu monitorizarea securității informațiilor din cloud, în special pe platformele SaaS, apar dificultăți semnificative, despre care vom vorbi.

Să presupunem că compania dvs. și-a mutat o parte din infrastructura în cloud... Opriți-vă. Nu în acest fel. Dacă infrastructura a fost transferată și abia acum te gândești cum o vei monitoriza, atunci ai pierdut deja. Cu excepția cazului în care este Amazon, Google sau Microsoft (și apoi cu rezerve), probabil că nu veți avea prea multă capacitate de a vă monitoriza datele și aplicațiile. Este bine dacă vi se oferă posibilitatea de a lucra cu jurnalele. Uneori, datele despre evenimentele de securitate vor fi disponibile, dar nu veți avea acces la ele. De exemplu, Office 365. Dacă aveți cea mai ieftină licență E1, atunci evenimentele de securitate nu vă sunt disponibile deloc. Dacă aveți o licență E3, datele dumneavoastră sunt stocate doar 90 de zile și numai dacă aveți o licență E5, durata jurnalelor este disponibilă pentru un an (totuși, aceasta are și propriile nuanțe legate de necesitatea de a face separat solicitați o serie de funcții pentru lucrul cu jurnalele de la asistența Microsoft). Apropo, licența E3 este mult mai slabă în ceea ce privește funcțiile de monitorizare decât Corporate Exchange. Pentru a atinge același nivel, aveți nevoie de o licență E5 sau o licență suplimentară de conformitate avansată, care poate necesita bani suplimentari care nu au fost luați în considerare în modelul dvs. financiar pentru trecerea la infrastructura cloud. Și acesta este doar un exemplu de subestimare a problemelor legate de monitorizarea securității informațiilor în cloud. În acest articol, fără să mă prefac complet, vreau să atrag atenția asupra unor nuanțe de care ar trebui să se țină cont la alegerea unui furnizor de cloud din punct de vedere al securității. Și la sfârșitul articolului, va fi oferită o listă de verificare care merită completată înainte de a considera că problema monitorizării securității informațiilor din cloud a fost rezolvată.

Există mai multe probleme tipice care duc la incidente în mediile cloud, la care serviciile de securitate a informațiilor nu au timp să răspundă sau nu le văd deloc:

Jurnalele de securitate nu există. Aceasta este o situație destul de comună, în special în rândul jucătorilor începători pe piața soluțiilor cloud. Dar nu ar trebui să renunți la ele imediat. Jucătorii mici, în special cei autohtoni, sunt mai sensibili la cerințele clienților și pot implementa rapid unele funcții necesare schimbând foaia de parcurs aprobată pentru produsele lor. Da, acesta nu va fi un analog al GuardDuty de la Amazon sau al modulului „Proactive Protection” de la Bitrix, dar cel puțin ceva.
Securitatea informațiilor nu știe unde sunt stocate jurnalele sau nu există acces la ele. Aici este necesar să inițiezi negocieri cu furnizorul de servicii cloud - poate că va furniza astfel de informații dacă consideră clientul semnificativ pentru el. Dar, în general, nu este foarte bine când accesul la jurnal este oferit „prin decizie specială”.
De asemenea, se întâmplă ca furnizorul de cloud să aibă jurnalele, dar acestea oferă o monitorizare limitată și înregistrarea evenimentelor, care nu sunt suficiente pentru a detecta toate incidentele. De exemplu, este posibil să primiți doar jurnalele de modificări pe un site web sau jurnalele de încercări de autentificare a utilizatorilor, dar nu și alte evenimente, cum ar fi traficul de rețea, care vă vor ascunde un întreg strat de evenimente care caracterizează încercările de a vă sparge infrastructura cloud.
Există jurnalele, dar accesul la ele este greu de automatizat, ceea ce le obligă să fie monitorizate nu în mod continuu, ci în program. Și dacă nu puteți descărca automat jurnalele, atunci descărcarea de jurnale, de exemplu, în format Excel (ca și în cazul unui număr de furnizori de soluții cloud interne), poate duce chiar la o reticență din partea serviciului de securitate a informațiilor corporative de a le modifica.
Fără monitorizare jurnal. Acesta este poate cel mai neclar motiv pentru apariția incidentelor de securitate a informațiilor în mediile cloud. Se pare că există jurnale și este posibil să se automatizeze accesul la ele, dar nimeni nu face asta. De ce?

Concept de securitate în cloud partajat

Trecerea la cloud este întotdeauna o căutare a unui echilibru între dorința de a menține controlul asupra infrastructurii și transferul acestuia în mâinile mai profesioniste ale unui furnizor de cloud specializat în întreținerea acesteia. Iar în domeniul securității în cloud trebuie căutat și acest echilibru. Mai mult, în funcție de modelul de livrare a serviciilor cloud utilizat (IaaS, PaaS, SaaS), acest echilibru va fi diferit tot timpul. În orice caz, trebuie să ne amintim că toți furnizorii de cloud astăzi urmează așa-numitul model de responsabilitate comună și securitatea informațiilor partajate. Cloud-ul este responsabil pentru unele lucruri, iar pentru altele clientul este responsabil, plasându-și datele, aplicațiile, mașinile virtuale și alte resurse în cloud. Ar fi nechibzuit să ne așteptăm că, mergând la cloud, vom transfera toată responsabilitatea către furnizor. Dar, de asemenea, nu este înțelept să construiți singur toată securitatea atunci când vă mutați în cloud. Este necesar un echilibru, care va depinde de mulți factori: - strategia de management al riscului, modelul de amenințare, mecanismele de securitate disponibile furnizorului de cloud, legislație etc.

De exemplu, clasificarea datelor găzduite în cloud este întotdeauna responsabilitatea clientului. Un furnizor de cloud sau un furnizor extern de servicii îl poate ajuta doar cu instrumente care îl vor ajuta să marcheze datele în cloud, să identifice încălcările, să șteargă datele care încalcă legea sau să le mascheze folosind o metodă sau alta. Pe de altă parte, securitatea fizică este întotdeauna responsabilitatea furnizorului de cloud, pe care nu o poate împărtăși cu clienții. Dar tot ceea ce este între date și infrastructura fizică este tocmai subiectul de discuție în acest articol. De exemplu, disponibilitatea cloud-ului este responsabilitatea furnizorului, iar stabilirea regulilor de firewall sau activarea criptării este responsabilitatea clientului. În acest articol vom încerca să analizăm ce mecanisme de monitorizare a securității informațiilor sunt furnizate astăzi de diverși furnizori de cloud populari din Rusia, care sunt caracteristicile utilizării lor și când merită să ne uităm către soluții externe de suprapunere (de exemplu, Cisco E- Mail Security) care extind capacitățile cloud-ului dvs. în ceea ce privește securitatea cibernetică. În unele cazuri, mai ales dacă urmați o strategie multi-cloud, nu veți avea de ales decât să utilizați soluții externe de monitorizare a securității informațiilor în mai multe medii cloud simultan (de exemplu, Cisco CloudLock sau Cisco Stealthwatch Cloud). Ei bine, în unele cazuri vă veți da seama că furnizorul de cloud pe care l-ați ales (sau vi l-ați impus) nu oferă deloc capabilități de monitorizare a securității informațiilor. Acest lucru este neplăcut, dar și nu puțin, deoarece vă permite să evaluați în mod adecvat nivelul de risc asociat cu lucrul cu acest nor.

Ciclul de viață al monitorizării securității în cloud

Pentru a monitoriza securitatea norilor pe care le utilizați, aveți doar trei opțiuni:

bazați-vă pe instrumentele oferite de furnizorul dvs. de cloud,
utilizați soluții de la terți care vor monitoriza platformele IaaS, PaaS sau SaaS pe care le utilizați,
construiți-vă propria infrastructură de monitorizare în cloud (numai pentru platformele IaaS/PaaS).

Să vedem ce caracteristici are fiecare dintre aceste opțiuni. Dar mai întâi, trebuie să înțelegem cadrul general care va fi utilizat la monitorizarea platformelor cloud. Aș evidenția 6 componente principale ale procesului de monitorizare a securității informațiilor în cloud:

Pregatirea infrastructurii. Determinarea aplicațiilor și infrastructurii necesare pentru colectarea evenimentelor importante pentru securitatea informațiilor în stocare.
Colectie. În această etapă, evenimentele de securitate sunt agregate din diverse surse pentru transmiterea ulterioară pentru procesare, stocare și analiză.
Tratament. În această etapă, datele sunt transformate și îmbogățite pentru a facilita analiza ulterioară.
Depozitare. Această componentă este responsabilă pentru stocarea pe termen scurt și lung a datelor procesate și brute colectate.
Analiză. În această etapă, aveți capacitatea de a detecta incidente și de a răspunde la ele automat sau manual.
Raportare. Această etapă ajută la formularea unor indicatori cheie pentru părțile interesate (management, auditori, furnizor de cloud, clienți etc.) care ne ajută să luăm anumite decizii, de exemplu, schimbarea unui furnizor sau consolidarea securității informațiilor.

Înțelegerea acestor componente vă va permite să decideți rapid în viitor ce puteți lua de la furnizorul dvs. și ce va trebui să faceți singur sau cu implicarea consultanților externi.

Servicii cloud încorporate

Am scris deja mai sus că multe servicii cloud astăzi nu oferă nicio capacitate de monitorizare a securității informațiilor. În general, ei nu acordă prea multă atenție subiectului securității informațiilor. De exemplu, unul dintre serviciile populare rusești pentru trimiterea de rapoarte către agențiile guvernamentale prin internet (nu îi voi menționa în mod specific numele). Întreaga secțiune despre securitatea acestui serviciu se învârte în jurul utilizării CIPF certificate. Secțiunea de securitate a informațiilor a unui alt serviciu cloud intern pentru gestionarea documentelor electronice nu este diferită. Se vorbește despre certificate de cheie publică, criptografie certificată, eliminarea vulnerabilităților web, protecție împotriva atacurilor DDoS, utilizarea paravanelor de protecție, backup-uri și chiar audituri regulate de securitate a informațiilor. Însă nu există nici un cuvânt despre monitorizare, nici despre posibilitatea de a avea acces la evenimentele de securitate a informațiilor care ar putea fi de interes pentru clienții acestui furnizor de servicii.

În general, prin modul în care furnizorul de cloud descrie problemele de securitate a informațiilor pe site-ul său web și în documentația sa, puteți înțelege cât de serios ia această problemă. De exemplu, dacă citiți manualele pentru produsele „My Office”, nu există deloc un cuvânt despre securitate, ci în documentația pentru produsul separat „My Office. KS3”, conceput pentru a proteja împotriva accesului neautorizat, există o listă obișnuită a punctelor de ordinul 17 al FSTEC, pe care „My Office.KS3” le implementează, dar nu este descris cum îl implementează și, cel mai important, cum să îl implementeze. să integreze aceste mecanisme cu securitatea informațiilor corporative. Poate că există o astfel de documentație, dar nu am găsit-o în domeniul public, pe site-ul „My Office”. Deși poate pur și simplu nu am acces la aceste informații secrete?...

Pentru Bitrix, situația este mult mai bună. Documentația descrie formatele jurnalelor de evenimente și, interesant, jurnalul de intruziune, care conține evenimente legate de potențiale amenințări la adresa platformei cloud. De acolo puteți extrage IP-ul, numele utilizatorului sau invitatului, sursa evenimentului, ora, agentul utilizatorului, tipul evenimentului etc. Adevărat, puteți lucra cu aceste evenimente fie din panoul de control al cloud-ului propriu-zis, fie încărcați date în format MS Excel. Acum este dificil să automatizați lucrul cu jurnalele Bitrix și va trebui să faceți o parte din muncă manual (încărcarea raportului și încărcarea lui în SIEM). Dar dacă ne amintim că până relativ recent o astfel de oportunitate nu a existat, atunci acesta este un mare progres. În același timp, aș dori să remarc faptul că mulți furnizori străini de cloud oferă funcționalități similare „pentru începători” - fie uitați-vă la jurnalele cu ochii prin panoul de control, fie încărcați datele către dvs. (cu toate acestea, majoritatea încărcați date în . csv, nu Excel).

Fără a lua în considerare opțiunea fără jurnal, furnizorii de cloud vă oferă de obicei trei opțiuni pentru monitorizarea evenimentelor de securitate - tablouri de bord, încărcare de date și acces API. Prima pare să vă rezolve multe probleme, dar acest lucru nu este în întregime adevărat - dacă aveți mai multe reviste, trebuie să comutați între ecranele care le afișează, pierzând imaginea de ansamblu. În plus, este puțin probabil ca furnizorul de cloud să vă ofere capacitatea de a corela evenimentele de securitate și de a le analiza în general din punct de vedere al securității (de obicei aveți de-a face cu date brute, pe care trebuie să le înțelegeți singur). Există excepții și vom vorbi mai departe despre ele. În cele din urmă, merită să întrebați ce evenimente sunt înregistrate de furnizorul dvs. de cloud, în ce format și cum corespund procesului dvs. de monitorizare a securității informațiilor? De exemplu, identificarea și autentificarea utilizatorilor și oaspeților. Același Bitrix vă permite, pe baza acestor evenimente, să înregistrați data și ora evenimentului, numele utilizatorului sau invitatului (dacă aveți modulul „Web Analytics”), obiectul accesat și alte elemente tipice unui site web . Dar serviciile de securitate a informațiilor corporative pot avea nevoie de informații despre dacă utilizatorul a accesat cloud de pe un dispozitiv de încredere (de exemplu, într-o rețea corporativă, această sarcină este implementată de Cisco ISE). Ce zici de o sarcină atât de simplă precum funcția geo-IP, care va ajuta la stabilirea dacă un cont de utilizator al serviciului cloud a fost furat? Și chiar dacă furnizorul de cloud ți-l oferă, acest lucru nu este suficient. Același Cisco CloudLock nu analizează doar geolocalizarea, ci folosește învățarea automată pentru aceasta și analizează datele istorice pentru fiecare utilizator și monitorizează diferite anomalii în încercările de identificare și autentificare. Doar MS Azure are o funcționalitate similară (dacă aveți abonamentul corespunzător).

Există o altă dificultate - deoarece pentru mulți furnizori de cloud monitorizarea securității informațiilor este un subiect nou cu care abia încep să se ocupe, ei schimbă constant ceva în soluțiile lor. Astăzi au o versiune de API, mâine alta, poimâine o a treia. De asemenea, trebuie să fii pregătit pentru asta. Același lucru este valabil și cu funcționalitatea, care se poate modifica, care trebuie luată în considerare în sistemul dumneavoastră de monitorizare a securității informațiilor. De exemplu, Amazon a avut inițial servicii separate de monitorizare a evenimentelor în cloud — AWS CloudTrail și AWS CloudWatch. Apoi a apărut un serviciu separat pentru monitorizarea evenimentelor de securitate a informațiilor - AWS GuardDuty. După ceva timp, Amazon a lansat un nou sistem de management, Amazon Security Hub, care include analiza datelor primite de la GuardDuty, Amazon Inspector, Amazon Macie și alții. Un alt exemplu este instrumentul de integrare a jurnalelor Azure cu SIEM - AzLog. A fost folosit activ de mulți furnizori SIEM, până când în 2018 Microsoft a anunțat încetarea dezvoltării și suportului său, ceea ce i-a confruntat cu o problemă pe mulți clienți care au folosit acest instrument (vom vorbi despre cum a fost rezolvat mai târziu).

Prin urmare, monitorizați cu atenție toate funcțiile de monitorizare pe care vi le oferă furnizorul dvs. de cloud. Sau bazați-vă pe furnizori externi de soluții care vor acționa ca intermediari între SOC și cloud-ul pe care doriți să îl monitorizați. Da, va fi mai scump (deși nu întotdeauna), dar veți transfera toată responsabilitatea pe umerii altcuiva. Sau nu tot?... Să ne amintim conceptul de securitate partajată și să înțelegem că nu putem schimba nimic - va trebui să înțelegem în mod independent modul în care diferiți furnizori de cloud asigură monitorizarea securității informațiilor, a datelor, a aplicațiilor, a mașinilor virtuale și a altor resurse. găzduit în cloud. Și vom începe cu ceea ce oferă Amazon în această parte.

Exemplu: monitorizarea securității informațiilor în IaaS pe baza AWS

Da, da, înțeleg că Amazon nu este cel mai bun exemplu datorită faptului că acesta este un serviciu american și poate fi blocat ca parte a luptei împotriva extremismului și a difuzării de informații interzise în Rusia. Dar în această publicație aș dori doar să arăt cum diferă diferitele platforme cloud în ceea ce privește capacitățile lor de monitorizare a securității informațiilor și la ce ar trebui să acordați atenție atunci când vă transferați procesele cheie în cloud din punct de vedere al securității. Ei bine, dacă unii dintre dezvoltatorii ruși de soluții cloud învață ceva util pentru ei înșiși, atunci asta va fi grozav.

Primul lucru de spus este că Amazon nu este o fortăreață de nepătruns. Diverse incidente se întâmplă în mod regulat cu clienții săi. De exemplu, numele, adresele, datele de naștere și numerele de telefon a 198 de milioane de alegători au fost furate din Deep Root Analytics. Compania israeliană Nice Systems a furat 14 milioane de înregistrări ale abonaților Verizon. Cu toate acestea, capabilitățile încorporate ale AWS vă permit să detectați o gamă largă de incidente. De exemplu:

impact asupra infrastructurii (DDoS)
compromisul nodului (injectarea comenzii)
compromiterea contului și accesul neautorizat
configurație incorectă și vulnerabilități
interfețe și API-uri nesigure.

Această discrepanță se datorează faptului că, după cum am aflat mai sus, clientul însuși este responsabil pentru securitatea datelor clienților. Și dacă nu s-a obosit să activeze mecanismele de protecție și nu a activat instrumente de monitorizare, atunci va afla despre incident doar din mass-media sau de la clienții săi.

Pentru a identifica incidentele, puteți utiliza o gamă largă de servicii de monitorizare diferite dezvoltate de Amazon (deși acestea sunt adesea completate de instrumente externe, cum ar fi osquery). Deci, în AWS, toate acțiunile utilizatorului sunt monitorizate, indiferent de modul în care sunt efectuate - prin consola de management, linia de comandă, SDK sau alte servicii AWS. Toate înregistrările activității fiecărui cont AWS (inclusiv numele de utilizator, acțiunea, serviciul, parametrii activității și rezultatul) și utilizarea API-ului sunt disponibile prin AWS CloudTrail. Puteți vizualiza aceste evenimente (cum ar fi autentificarea consolei AWS IAM) din consola CloudTrail, le puteți analiza folosind Amazon Athena sau le puteți „externaliza” către soluții externe precum Splunk, AlienVault etc. Jurnalele AWS CloudTrail în sine sunt plasate în compartimentul dvs. AWS S3.

Alte două servicii AWS oferă o serie de alte capabilități importante de monitorizare. În primul rând, Amazon CloudWatch este un serviciu de monitorizare a resurselor și aplicațiilor AWS care, printre altele, vă permite să identificați diferite anomalii în cloud. Toate serviciile AWS încorporate, cum ar fi Amazon Elastic Compute Cloud (servere), Amazon Relational Database Service (baze de date), Amazon Elastic MapReduce (analiza datelor) și alte 30 de servicii Amazon, folosesc Amazon CloudWatch pentru a-și stoca jurnalele. Dezvoltatorii pot folosi API-ul deschis de la Amazon CloudWatch pentru a adăuga funcționalitate de monitorizare a jurnalelor la aplicațiile și serviciile personalizate, permițându-le să extindă sfera analizei evenimentelor într-un context de securitate.

În al doilea rând, serviciul VPC Flow Logs vă permite să analizați traficul de rețea trimis sau primit de serverele dumneavoastră AWS (extern sau intern), precum și între microservicii. Când oricare dintre resursele dvs. AWS VPC interacționează cu rețeaua, VPC Flow Logs înregistrează detalii despre traficul de rețea, inclusiv interfața de rețea sursă și destinație, precum și adresele IP, porturile, protocolul, numărul de octeți și numărul de pachete pe care le aveți. a văzut. Cei cu experiență în securitatea rețelei locale vor recunoaște acest lucru ca fiind analog cu firele NetFlow, care poate fi creat de switch-uri, routere și firewall-uri de nivel enterprise. Aceste jurnale sunt importante în scopul monitorizării securității informațiilor deoarece, spre deosebire de evenimentele despre acțiunile utilizatorilor și aplicațiilor, ele vă permit, de asemenea, să nu ratați interacțiunile de rețea din mediul cloud privat virtual AWS.

În rezumat, aceste trei servicii AWS — AWS CloudTrail, Amazon CloudWatch și VPC Flow Logs — oferă împreună o perspectivă destul de puternică asupra utilizării contului, comportamentului utilizatorilor, gestionării infrastructurii, activității aplicațiilor și serviciilor și activității în rețea. De exemplu, ele pot fi utilizate pentru a detecta următoarele anomalii:

Încercările de scanare a site-ului, căutarea ușilor din spate, căutarea vulnerabilităților prin rafale de „erori 404”.
Atacuri prin injectare (de exemplu, injectare SQL) prin rafale de „500 de erori”.
Instrumentele de atac cunoscute sunt sqlmap, nikto, w3af, nmap etc. prin analiza câmpului User Agent.

Amazon Web Services a dezvoltat și alte servicii în scopuri de securitate cibernetică care vă permit să rezolvați multe alte probleme. De exemplu, AWS are un serviciu încorporat pentru auditarea politicilor și configurațiilor - AWS Config. Acest serviciu asigură auditarea continuă a resurselor dvs. AWS și a configurațiilor acestora. Să luăm un exemplu simplu: Să presupunem că doriți să vă asigurați că parolele de utilizator sunt dezactivate pe toate serverele dvs. și că accesul este posibil numai pe baza certificatelor. AWS Config facilitează verificarea acestui lucru pentru toate serverele dvs. Există și alte politici care pot fi aplicate serverelor dvs. cloud: „Niciun server nu poate folosi portul 22”, „Numai administratorii pot schimba regulile firewall” sau „Numai utilizatorul Ivashko poate crea conturi de utilizator noi, iar el poate face doar marți. " În vara anului 2016, serviciul AWS Config a fost extins pentru a automatiza detectarea încălcărilor politicilor dezvoltate. Regulile AWS Config sunt, în esență, solicitări de configurare continue pentru serviciile Amazon pe care le utilizați, care generează evenimente dacă politicile corespunzătoare sunt încălcate. De exemplu, în loc să rulați periodic interogări AWS Config pentru a verifica dacă toate discurile de pe un server virtual sunt criptate, Regulile AWS Config pot fi folosite pentru a verifica continuu discurile serverului pentru a se asigura că această condiție este îndeplinită. Și, cel mai important, în contextul acestei publicații, orice încălcări generează evenimente care pot fi analizate de serviciul dumneavoastră de securitate a informațiilor.

AWS are, de asemenea, echivalentul soluțiilor tradiționale de securitate a informațiilor corporative, care generează și evenimente de securitate pe care le puteți și ar trebui să le analizați:

Detectarea intruziunilor - AWS GuardDuty
Controlul scurgerilor de informații - AWS Macie
EDR (deși vorbește despre punctele finale din cloud puțin ciudat) - AWS Cloudwatch + soluții open source osquery sau GRR
Analiza Netflow - AWS Cloudwatch + AWS VPC Flow
Analiză DNS - AWS Cloudwatch + AWS Route53
AD - AWS Directory Service
Managementul contului - AWS IAM
SSO - AWS SSO
analiză de securitate - AWS Inspector
gestionarea configurației - AWS Config
WAF - AWS WAF.

Nu voi descrie în detaliu toate serviciile Amazon care pot fi utile în contextul securității informațiilor. Principalul lucru este să înțelegem că toate acestea pot genera evenimente pe care le putem și ar trebui să le analizăm în contextul securității informațiilor, folosind în acest scop atât capacitățile încorporate ale Amazon în sine, cât și soluțiile externe, de exemplu, SIEM, care poate duceți evenimentele de securitate la centrul dvs. de monitorizare și analizați-le acolo împreună cu evenimentele din alte servicii cloud sau din infrastructura internă, perimetrul sau dispozitivele mobile.

În orice caz, totul începe cu sursele de date care vă oferă evenimente de securitate a informațiilor. Aceste surse includ, dar nu se limitează la:

CloudTrail - Utilizare API și acțiuni ale utilizatorului
Trusted Advisor - verificare de securitate în raport cu cele mai bune practici
Config - inventarierea și configurarea conturilor și setărilor serviciului
Jurnalele de flux VPC - conexiuni la interfețe virtuale
IAM - serviciu de identificare și autentificare
Jurnalele de acces ELB - Load Balancer
Inspector - vulnerabilități ale aplicației
S3 - stocare fișiere
CloudWatch - Activitatea aplicației
SNS este un serviciu de notificare.

Amazon, deși oferă o astfel de gamă de surse de evenimente și instrumente pentru generarea acestora, este foarte limitată în capacitatea sa de a analiza datele colectate în contextul securității informațiilor. Va trebui să studiați în mod independent jurnalele disponibile, căutând în ele indicatori relevanți de compromis. AWS Security Hub, pe care Amazon l-a lansat recent, își propune să rezolve această problemă devenind un cloud SIEM pentru AWS. Dar până acum este abia la începutul călătoriei sale și este limitat atât de numărul de surse cu care lucrează, cât și de alte restricții stabilite de arhitectura și abonamentele Amazon însuși.

Exemplu: monitorizarea securității informațiilor în IaaS bazat pe Azure

Nu vreau să intru într-o dezbatere lungă despre care dintre cei trei furnizori de cloud (Amazon, Microsoft sau Google) este mai bun (mai ales că fiecare dintre ei are încă specificul său specific și este potrivit pentru rezolvarea propriilor probleme); Să ne concentrăm pe capacitățile de monitorizare a securității informațiilor pe care le oferă acești jucători. Trebuie să recunoaștem că Amazon AWS a fost unul dintre primii pe acest segment și, prin urmare, a avansat cel mai mult în ceea ce privește funcțiile sale de securitate a informațiilor (deși mulți recunosc că sunt greu de utilizat). Dar asta nu înseamnă că vom ignora oportunitățile pe care ni le oferă Microsoft și Google.

Produsele Microsoft s-au distins întotdeauna prin „deschiderea” lor, iar în Azure situația este similară. De exemplu, dacă AWS și GCP pornesc întotdeauna de la conceptul „ceea ce nu este permis este interzis”, atunci Azure are abordarea exact opusă. De exemplu, atunci când se creează o rețea virtuală în cloud și o mașină virtuală în ea, toate porturile și protocoalele sunt deschise și permise implicit. Prin urmare, va trebui să depuneți puțin mai mult efort pentru configurarea inițială a sistemului de control al accesului în cloud de la Microsoft. Și acest lucru vă impune și cerințe mai stricte în ceea ce privește activitatea de monitorizare în cloud-ul Azure.

AWS are o particularitate asociată cu faptul că, atunci când vă monitorizați resursele virtuale, dacă acestea sunt situate în regiuni diferite, atunci aveți dificultăți în combinarea tuturor evenimentelor și analiza lor unificată, pentru a le elimina pe care trebuie să recurgeți la diverse trucuri, cum ar fi Creați-vă propriul cod pentru AWS Lambda care va transporta evenimente între regiuni. Azure nu are această problemă - mecanismul său de jurnal de activitate urmărește toată activitatea din întreaga organizație fără restricții. Același lucru este valabil și pentru AWS Security Hub, care a fost dezvoltat recent de Amazon pentru a consolida multe funcții de securitate într-un singur centru de securitate, dar numai în regiunea sa, care, totuși, nu este relevantă pentru Rusia. Azure are propriul centru de securitate, care nu este legat de restricții regionale, oferind acces la toate caracteristicile de securitate ale platformei cloud. Mai mult, pentru diferite echipe locale poate oferi propriul set de capabilități de protecție, inclusiv evenimente de securitate gestionate de acestea. AWS Security Hub este încă pe cale să devină similar cu Azure Security Center. Dar merită să adăugați o muscă în unguent - puteți scoate din Azure o mulțime din ceea ce a fost descris anterior în AWS, dar acest lucru se face cel mai convenabil numai pentru Azure AD, Azure Monitor și Azure Security Center. Toate celelalte mecanisme de securitate Azure, inclusiv analiza evenimentelor de securitate, nu sunt încă gestionate în cel mai convenabil mod. Problema este parțial rezolvată de API, care pătrunde în toate serviciile Microsoft Azure, dar acest lucru va necesita efort suplimentar din partea dvs. pentru a vă integra cloud-ul cu SOC și prezența specialiștilor calificați (de fapt, ca și în cazul oricărui alt SIEM care funcționează cu cloud). API-uri). Unele SIEM-uri, despre care se vor discuta mai târziu, acceptă deja Azure și pot automatiza sarcina de monitorizare, dar are și propriile dificultăți - nu toate pot colecta toate jurnalele pe care le are Azure.

Colectarea și monitorizarea evenimentelor în Azure este asigurată folosind serviciul Azure Monitor, care este principalul instrument de colectare, stocare și analiză a datelor în cloud-ul Microsoft și a resurselor acestuia - depozite Git, containere, mașini virtuale, aplicații etc. Toate datele colectate de Azure Monitor sunt împărțite în două categorii - metrici, colectate în timp real și care descriu indicatorii cheie de performanță ai cloud-ului Azure, și jurnalele, care conțin date organizate în înregistrări care caracterizează anumite aspecte ale activității resurselor și serviciilor Azure. În plus, folosind API-ul Data Collector, serviciul Azure Monitor poate colecta date din orice sursă REST pentru a-și construi propriile scenarii de monitorizare.

Iată câteva surse de evenimente de securitate pe care vi le oferă Azure și pe care le puteți accesa prin intermediul Azure Portal, CLI, PowerShell sau API-ul REST (și unele numai prin Azure Monitor/Insight API):

Jurnalele de activitate - acest jurnal răspunde la întrebările clasice „cine”, „ce” și „când” cu privire la orice operațiune de scriere (PUT, POST, DELETE) pe resursele cloud. Evenimentele legate de accesul la citire (GET) nu sunt incluse în acest jurnal, la fel ca multe altele.
Jurnalele de diagnosticare - conține date despre operațiunile cu o anumită resursă inclusă în abonamentul dvs.
Raportarea Azure AD - conține atât activitatea utilizatorului, cât și activitatea sistemului legată de gestionarea grupurilor și a utilizatorilor.
Windows Event Log și Linux Syslog - conține evenimente de la mașinile virtuale găzduite în cloud.
Valori - conține telemetrie despre performanța și starea de sănătate a serviciilor și resurselor dvs. cloud. Măsurat în fiecare minut și depozitat. în 30 de zile.
Jurnalele fluxului de grup de securitate de rețea - conțin date despre evenimentele de securitate a rețelei colectate folosind serviciul Network Watcher și monitorizarea resurselor la nivel de rețea.
Jurnalele de stocare - contine evenimente legate de accesul la facilitatile de stocare.

Pentru monitorizare, puteți utiliza SIEM-uri externe sau Azure Monitor încorporat și extensiile acestuia. Vom vorbi mai târziu despre sistemele de management al evenimentelor de securitate a informațiilor, dar deocamdată să vedem ce ne oferă Azure însuși pentru analiza datelor în contextul securității. Ecranul principal pentru tot ceea ce este legat de securitate în Azure Monitor este Tabloul de bord pentru securitate și audit Log Analytics (versiunea gratuită acceptă o cantitate limitată de stocare a evenimentelor pentru doar o săptămână). Acest tablou de bord este împărțit în 5 zone principale care vizualizează statistici rezumative a ceea ce se întâmplă în mediul cloud pe care îl utilizați:

Domenii de securitate - indicatori cantitativi cheie legati de securitatea informatiilor - numarul de incidente, numarul de noduri compromise, noduri nepatchate, evenimente de securitate a retelei etc.
Probleme notabile - afișează numărul și importanța problemelor active de securitate a informațiilor
Detectări - afișează modele de atacuri folosite împotriva ta
Threat Intelligence - afișează informații geografice despre nodurile externe care vă atacă
Interogări de securitate obișnuite - interogări tipice care vă vor ajuta să vă monitorizați mai bine securitatea informațiilor.

Extensiile Azure Monitor includ Azure Key Vault (protecția cheilor criptografice în cloud), Malware Assessment (analiza protecției împotriva codului rău intenționat pe mașinile virtuale), Azure Application Gateway Analytics (analiza, printre altele, a jurnalelor de firewall din cloud) etc. . Aceste instrumente, îmbogățite cu anumite reguli de procesare a evenimentelor, vă permit să vizualizați diverse aspecte ale activității serviciilor cloud, inclusiv securitatea, și să identificați anumite abateri de la funcționare. Dar, așa cum se întâmplă adesea, orice funcționalitate suplimentară necesită un abonament plătit corespunzător, care va necesita investiții financiare corespunzătoare din partea dvs., pe care trebuie să le planificați în avans.

Azure are o serie de capabilități încorporate de monitorizare a amenințărilor care sunt integrate în Azure AD, Azure Monitor și Azure Security Center. Printre acestea, de exemplu, detectarea interacțiunii mașinilor virtuale cu IP-uri malițioase cunoscute (datorită prezenței integrării cu serviciile Threat Intelligence de la Microsoft), detectarea malware-ului în infrastructura cloud prin primirea de alarme de la mașinile virtuale găzduite în cloud, parola atacuri de ghicire ” pe mașinile virtuale, vulnerabilități în configurația sistemului de identificare a utilizatorilor, autentificare în sistem de la anonimizatori sau noduri infectate, scurgeri de cont, autentificare în sistem din locații neobișnuite etc. Azure este astăzi unul dintre puținii furnizori de cloud care vă oferă capabilități încorporate de Threat Intelligence pentru a îmbogăți evenimentele de securitate a informațiilor colectate.

După cum am menționat mai sus, funcționalitatea de securitate și, ca urmare, evenimentele de securitate generate de aceasta nu sunt disponibile pentru toți utilizatorii în mod egal, dar necesită un anumit abonament care să includă funcționalitatea de care aveți nevoie, care generează evenimentele adecvate pentru monitorizarea securității informațiilor. De exemplu, unele dintre funcțiile descrise în paragraful anterior pentru monitorizarea anomaliilor în conturi sunt disponibile doar în licența premium P2 pentru serviciul Azure AD. Fără el, tu, ca și în cazul AWS, va trebui să analizezi „manual” evenimentele de securitate colectate. Și, de asemenea, în funcție de tipul de licență Azure AD, nu toate evenimentele vor fi disponibile pentru analiză.

Pe portalul Azure, puteți gestiona atât interogările de căutare pentru jurnalele de interes pentru dvs., cât și să configurați tablouri de bord pentru a vizualiza indicatorii cheie de securitate a informațiilor. În plus, acolo puteți selecta extensii Azure Monitor, care vă permit să extindeți funcționalitatea jurnalelor Azure Monitor și să obțineți o analiză mai profundă a evenimentelor din punct de vedere al securității.

Dacă aveți nevoie nu numai de capacitatea de a lucra cu jurnalele, ci și de un centru de securitate cuprinzător pentru platforma dvs. cloud Azure, inclusiv gestionarea politicii de securitate a informațiilor, atunci puteți vorbi despre necesitatea de a lucra cu Centrul de securitate Azure, dintre care majoritatea funcțiilor utile sunt disponibile pentru niște bani, de exemplu, detectarea amenințărilor, monitorizarea în afara Azure, evaluarea conformității etc. (în versiunea gratuită, aveți acces doar la o evaluare de securitate și recomandări pentru eliminarea problemelor identificate). Consolidează toate problemele de securitate într-un singur loc. De fapt, putem vorbi despre un nivel mai ridicat de securitate a informațiilor decât vi le oferă Azure Monitor, deoarece în acest caz datele colectate în întreaga fabrică de cloud sunt îmbogățite folosind multe surse, precum Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) și Microsoft Security Response Center (MSRC), pe care sunt suprapuse diverși algoritmi sofisticați de învățare automată și de analiză comportamentală, care ar trebui, în cele din urmă, să îmbunătățească eficiența detectării și a răspunsului la amenințări. .

Azure are și propriul SIEM - a apărut la începutul anului 2019. Acesta este Azure Sentinel, care se bazează pe datele de la Azure Monitor și se poate integra și cu. soluții de securitate externe (de exemplu, NGFW sau WAF), a căror listă este în continuă creștere. În plus, prin integrarea API-ului Microsoft Graph Security, aveți posibilitatea de a vă conecta propriile fluxuri Threat Intelligence la Sentinel, ceea ce îmbogățește capabilitățile de analiză a incidentelor în cloud-ul dvs. Azure. Se poate argumenta că Azure Sentinel este primul SIEM „nativ” care a apărut de la furnizorii de cloud (aceași Splunk sau ELK, care pot fi găzduite în cloud, de exemplu, AWS, încă nu sunt dezvoltate de furnizorii tradiționali de servicii cloud). Azure Sentinel and Security Center s-ar putea numi SOC pentru cloud-ul Azure și ar putea fi limitat la acestea (cu anumite rezerve) dacă nu mai aveai nicio infrastructură și ți-ai transferat toate resursele de calcul în cloud și ar fi cloud-ul Microsoft Azure.

Dar, deoarece capacitățile încorporate ale Azure (chiar dacă aveți un abonament la Sentinel) nu sunt adesea suficiente în scopul monitorizării securității informațiilor și al integrării acestui proces cu alte surse de evenimente de securitate (atât în cloud, cât și interne), există o trebuie să exportați datele colectate către sisteme externe, la care pot include SIEM. Acest lucru se face atât folosind API-ul, cât și folosind extensii speciale, care în prezent sunt disponibile oficial doar pentru următoarele SIEM - Splunk (Azure Monitor Add-On pentru Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight și ELK. Până de curând, existau mai multe astfel de SIEM-uri, dar de la 1 iunie 2019, Microsoft a încetat să mai susțină Azure Log Integration Tool (AzLog), care în zorii existenței Azure și în absența standardizării normale a lucrului cu jurnalele (Azure). Monitorul nici nu exista încă) a facilitat integrarea SIEM externă cu cloud-ul Microsoft. Acum situația s-a schimbat și Microsoft recomandă platforma Azure Event Hub ca principal instrument de integrare pentru alte SIEM-uri. Mulți au implementat deja o astfel de integrare, dar aveți grijă - s-ar putea să nu captureze toate jurnalele Azure, ci doar câteva (căutați în documentație SIEM-ul dvs.).

Încheind o scurtă excursie în Azure, aș dori să dau o recomandare generală despre acest serviciu cloud - înainte de a spune ceva despre funcțiile de monitorizare a securității informațiilor din Azure, ar trebui să le configurați foarte atent și să testați dacă funcționează așa cum este scris în documentație și după cum v-au spus consultanții Microsoft (și pot avea opinii diferite asupra funcționalității funcțiilor Azure). Dacă aveți resurse financiare, puteți extrage o mulțime de informații utile din Azure în ceea ce privește monitorizarea securității informațiilor. Dacă resursele tale sunt limitate, atunci, ca și în cazul AWS, va trebui să te bazezi doar pe propriile forțe și pe datele brute pe care Azure Monitor ți le oferă. Și amintiți-vă că multe funcții de monitorizare costă bani și este mai bine să vă familiarizați cu politica de prețuri în avans. De exemplu, gratuit puteți stoca 31 de zile de date până la un maxim de 5 GB per client - depășirea acestor valori va necesita să plătiți bani suplimentari (aproximativ 2 USD+ pentru stocarea fiecărui GB suplimentar de la client și 0,1 USD pentru stocând 1 GB în fiecare lună suplimentară). Lucrul cu telemetria și valorile aplicației poate necesita, de asemenea, fonduri suplimentare, precum și lucrul cu alerte și notificări (o anumită limită este disponibilă gratuit, care poate să nu fie suficientă pentru nevoile dvs.).

Exemplu: monitorizarea securității informațiilor în IaaS pe baza Google Cloud Platform

Google Cloud Platform arată ca un tânăr în comparație cu AWS și Azure, dar acest lucru este parțial bun. Spre deosebire de AWS, care și-a crescut capacitățile, inclusiv cele de securitate, treptat, având probleme cu centralizarea; GCP, ca și Azure, este mult mai bine gestionat la nivel central, ceea ce reduce erorile și timpul de implementare în întreaga întreprindere. Din punct de vedere al securității, GCP este, destul de ciudat, între AWS și Azure. Are și o singură înregistrare la eveniment pentru întreaga organizație, dar este incompletă. Unele funcții sunt încă în modul beta, dar treptat această deficiență ar trebui eliminată și GCP va deveni o platformă mai matură în ceea ce privește monitorizarea securității informațiilor.

Instrumentul principal pentru înregistrarea evenimentelor în GCP este Stackdriver Logging (similar cu Azure Monitor), care vă permite să colectați evenimente în întreaga infrastructură cloud (precum și de la AWS). Din punct de vedere al securității în GCP, fiecare organizație, proiect sau folder are patru jurnale:

Activitate administrativă - conține toate evenimentele legate de accesul administrativ, de exemplu, crearea unei mașini virtuale, modificarea drepturilor de acces etc. Acest jurnal este întotdeauna scris, indiferent de dorința dvs. și își stochează datele timp de 400 de zile.
Acces la date - conține toate evenimentele legate de lucrul cu datele de către utilizatorii cloud (creare, modificare, citire etc.). În mod implicit, acest jurnal nu este scris, deoarece volumul său crește foarte repede. Din acest motiv, termenul de valabilitate este de numai 30 de zile. În plus, nu totul este scris în această revistă. De exemplu, evenimentele legate de resursele care sunt accesibile public pentru toți utilizatorii sau care sunt accesibile fără a vă conecta la GCP nu sunt scrise în acesta.
Eveniment de sistem - conține evenimente de sistem care nu sunt legate de utilizatori sau acțiuni ale unui administrator care modifică configurația resurselor cloud. Este întotdeauna scris și stocat timp de 400 de zile.
Access Transparency este un exemplu unic de jurnal care surprinde toate acțiunile angajaților Google (dar nu pentru toate serviciile GCP) care accesează infrastructura dvs. ca parte a sarcinilor lor de serviciu. Acest jurnal este stocat timp de 400 de zile și nu este disponibil pentru fiecare client GCP, dar numai dacă sunt îndeplinite un număr de condiții (fie suport la nivel Gold sau Platinum, fie prezența a 4 roluri de un anumit tip ca parte a asistenței corporative). O funcție similară este disponibilă și, de exemplu, în Office 365 - Lockbox.

Exemplu de jurnal: 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"
}

Accesul la aceste jurnale este posibil în mai multe moduri (în același mod ca Azure și AWS discutat anterior) - prin interfața Log Viewer, prin API, prin Google Cloud SDK sau prin pagina Activitate a proiectului pentru care sunt interesați de evenimente. În același mod, acestea pot fi exportate în soluții externe pentru analize suplimentare. Acesta din urmă se realizează prin exportarea jurnalelor în spațiul de stocare BigQuery sau Cloud Pub/Sub.

Pe lângă Stackdriver Logging, platforma GCP oferă și funcționalitatea Stackdriver Monitoring, care vă permite să monitorizați valorile cheie (performanță, MTBF, sănătatea generală etc.) ale serviciilor și aplicațiilor cloud. Datele procesate și vizualizate pot facilita găsirea problemelor în infrastructura dvs. cloud, inclusiv în contextul securității. Dar trebuie remarcat faptul că această funcționalitate nu va fi foarte bogată în contextul securității informațiilor, deoarece astăzi GCP nu are un analog al aceluiași AWS GuardDuty și nu poate identifica pe cele proaste dintre toate evenimentele înregistrate (Google a dezvoltat Event Threat Detection, dar este încă în curs de dezvoltare în versiune beta și este prea devreme pentru a vorbi despre utilitatea sa). Stackdriver Monitoring ar putea fi folosit ca sistem de detectare a anomaliilor, care ar fi apoi investigate pentru a găsi cauzele apariției lor. Dar având în vedere lipsa de personal calificat în domeniul securității informațiilor GCP din piață, această sarcină pare în prezent dificilă.

De asemenea, merită să oferiți o listă cu câteva module de securitate a informațiilor care pot fi utilizate în cloud-ul dvs. GCP și care sunt similare cu ceea ce oferă AWS:

Cloud Security Command Center este un analog al AWS Security Hub și Azure Security Center.
Cloud DLP - Descoperirea și editarea automată (de exemplu, mascarea) datelor găzduite în cloud folosind mai mult de 90 de politici de clasificare predefinite.
Cloud Scanner este un scaner pentru vulnerabilități cunoscute (XSS, Flash Injection, biblioteci nepatchate etc.) în App Engine, Compute Engine și Google Kubernetes.
Cloud IAM - Controlați accesul la toate resursele GCP.
Cloud Identity - Gestionați conturile de utilizator, dispozitiv și aplicație GCP dintr-o singură consolă.
Cloud HSM - protecția cheilor criptografice.
Cloud Key Management Service - gestionarea cheilor criptografice în GCP.
Controlul serviciului VPC - Creați un perimetru securizat în jurul resurselor dvs. GCP pentru a le proteja de scurgeri.
Cheia de securitate Titan - protecție împotriva phishingului.

Multe dintre aceste module generează evenimente de securitate care pot fi trimise în spațiul de stocare BigQuery pentru analiză sau export în alte sisteme, inclusiv SIEM. După cum am menționat mai sus, GCP este o platformă în curs de dezvoltare, iar Google dezvoltă acum o serie de noi module de securitate a informațiilor pentru platforma sa. Printre acestea se numără Event Threat Detection (disponibilă acum în versiunea beta), care scanează jurnalele Stackdriver în căutarea unor urme de activitate neautorizată (analog cu GuardDuty în AWS) sau Policy Intelligence (disponibilă în alfa), care vă va permite să dezvoltați politici inteligente pentru acces la resursele GCP.

Am făcut o scurtă prezentare generală a capabilităților de monitorizare încorporate în platformele cloud populare. Dar aveți specialiști care sunt capabili să lucreze cu jurnalele furnizorului IaaS „brute” (nu toată lumea este pregătită să cumpere capabilitățile avansate ale AWS sau Azure sau Google)? În plus, mulți sunt familiarizați cu adagul „încredeți, dar verificați”, care este mai adevărat ca niciodată în domeniul securității. Cât de mult aveți încredere în capabilitățile încorporate ale furnizorului de cloud care vă trimit evenimente de securitate a informațiilor? Cât de mult se concentrează ei pe securitatea informațiilor?

Uneori, merită să priviți soluțiile de monitorizare suprapuse a infrastructurii cloud care pot completa securitatea încorporată în cloud și, uneori, astfel de soluții sunt singura opțiune pentru a obține o perspectivă asupra securității datelor și aplicațiilor dvs. găzduite în cloud. În plus, sunt pur și simplu mai convenabile, deoarece își asumă toate sarcinile de analiză a jurnalelor necesare generate de diferite servicii cloud de la diferiți furnizori de cloud. Un exemplu de astfel de soluție de suprapunere este Cisco Stealthwatch Cloud, care se concentrează pe o singură sarcină - monitorizarea anomaliilor de securitate a informațiilor în mediile cloud, inclusiv nu numai Amazon AWS, Microsoft Azure și Google Cloud Platform, ci și cloud-uri private.

Exemplu: Monitorizarea securității informațiilor folosind Stealthwatch Cloud

AWS oferă o platformă de calcul flexibilă, dar această flexibilitate face mai ușor pentru companii să facă greșeli care duc la probleme de securitate. Și modelul de securitate a informațiilor partajate contribuie doar la acest lucru. Rularea de software în cloud cu vulnerabilități necunoscute (cele cunoscute pot fi combatete, de exemplu, de AWS Inspector sau GCP Cloud Scanner), parole slabe, configurații incorecte, persoane din interior etc. Și toate acestea se reflectă în comportamentul resurselor cloud, care pot fi monitorizate de Cisco Stealthwatch Cloud, care este un sistem de monitorizare a securității informațiilor și de detectare a atacurilor. noruri publice și private.

Una dintre caracteristicile cheie ale Cisco Stealthwatch Cloud este capacitatea de a modela entități. Cu acesta, puteți crea un model software (adică o simulare aproape în timp real) al fiecărei resurse cloud (nu contează dacă este AWS, Azure, GCP sau altceva). Acestea pot include servere și utilizatori, precum și tipuri de resurse specifice mediului dvs. cloud, cum ar fi grupuri de securitate și grupuri de scalare automată. Aceste modele folosesc ca intrare fluxuri de date structurate furnizate de serviciile cloud. De exemplu, pentru AWS, acestea ar fi VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda și AWS IAM. Modelarea entităților descoperă automat rolul și comportamentul oricărei resurse (puteți vorbi despre profilarea întregii activități în cloud). Aceste roluri includ dispozitivul mobil Android sau Apple, serverul Citrix PVS, serverul RDP, poarta de e-mail, clientul VoIP, serverul terminal, controlerul de domeniu etc. Apoi le monitorizează continuu comportamentul pentru a determina când apare un comportament riscant sau care pune în pericol siguranța. Puteți identifica ghicirea parolelor, atacurile DDoS, scurgerile de date, accesul ilegal de la distanță, activitatea de cod rău intenționat, scanarea vulnerabilităților și alte amenințări. De exemplu, așa arată detectarea unei încercări de acces la distanță dintr-o țară atipică pentru organizația dvs. (Coreea de Sud) la un cluster Kubernetes prin SSH:

Și așa arată presupusa scurgere de informații din baza de date Postgress către o țară cu care nu am mai întâlnit interacțiuni:

În cele din urmă, așa arată prea multe încercări SSH eșuate din China și Indonezia de la un dispozitiv extern la distanță:

Sau, să presupunem că instanța de server din VPC nu va fi niciodată o destinație de conectare la distanță, prin politică. Să presupunem în continuare că acest computer a avut o conectare de la distanță din cauza unei modificări eronate a politicii regulilor firewall. Caracteristica Entity Modeling va detecta și raporta această activitate („Acces neobișnuit la distanță”) aproape în timp real și va indica apelul API specific AWS CloudTrail, Azure Monitor sau GCP Stackdriver Logging (inclusiv numele de utilizator, data și ora, printre alte detalii). ).care a determinat modificarea regulii ITU. Și apoi aceste informații pot fi trimise către SIEM pentru analiză.

Capacitățile similare sunt implementate pentru orice mediu cloud suportat de Cisco Stealthwatch Cloud:

Modelarea entităților este o formă unică de automatizare a securității care poate descoperi o problemă necunoscută anterior cu oamenii, procesele sau tehnologia dvs. De exemplu, vă permite să detectați, printre altele, probleme de securitate precum:

A descoperit cineva o ușă în spate în software-ul pe care îl folosim?
Există software sau dispozitiv terță parte în cloud-ul nostru?
Utilizatorul autorizat abuzează de privilegii?
A existat o eroare de configurare care a permis accesul de la distanță sau alte utilizări neintenționate a resurselor?
Există o scurgere de date de la serverele noastre?
A încercat cineva să se conecteze cu noi dintr-o locație geografică atipică?
Este cloud-ul nostru infectat cu cod rău intenționat?

Un eveniment de securitate a informațiilor detectat poate fi trimis sub forma unui bilet corespunzător către Slack, Cisco Spark, sistemul de gestionare a incidentelor PagerDuty și, de asemenea, trimis către diferite SIEM, inclusiv Splunk sau ELK. Pentru a rezuma, putem spune că, dacă compania dumneavoastră utilizează o strategie multi-cloud și nu se limitează la un singur furnizor de cloud, capabilitățile de monitorizare a securității informațiilor descrise mai sus, atunci utilizarea Cisco Stealthwatch Cloud este o opțiune bună pentru a obține un set unificat de monitorizare. capabilități pentru cei mai importanți jucători din cloud - Amazon, Microsoft și Google. Cel mai interesant lucru este că, dacă comparați prețurile pentru Stealthwatch Cloud cu licențe avansate pentru monitorizarea securității informațiilor în AWS, Azure sau GCP, se poate dovedi că soluția Cisco va fi chiar mai ieftină decât capabilitățile încorporate ale Amazon, Microsoft. și soluții Google. Este paradoxal, dar este adevărat. Și cu cât folosiți mai mulți nori și capacitățile acestora, cu atât avantajul unei soluții consolidate va fi mai evident.

În plus, Stealthwatch Cloud poate monitoriza cloud-urile private implementate în organizația dvs., de exemplu, pe baza containerelor Kubernetes sau prin monitorizarea fluxurilor Netflow sau a traficului de rețea primit prin oglindire în echipamente de rețea (chiar și produse interne), date AD sau servere DNS și așa mai departe. Toate aceste date vor fi îmbogățite cu informații despre Threat Intelligence colectate de Cisco Talos, cel mai mare grup neguvernamental de cercetători ai amenințărilor de securitate cibernetică din lume.

Acest lucru vă permite să implementați un sistem de monitorizare unificat atât pentru norii publici, cât și pentru cei hibridi, pe care compania dumneavoastră le poate folosi. Informațiile colectate pot fi apoi analizate folosind capabilitățile încorporate ale Stealthwatch Cloud sau trimise către SIEM (Splunk, ELK, SumoLogic și multe altele sunt acceptate implicit).

Cu aceasta, vom finaliza prima parte a articolului, în care am trecut în revistă instrumentele încorporate și externe de monitorizare a securității informaționale ale platformelor IaaS/PaaS, care ne permit să detectăm și să răspundem rapid la incidentele care apar în mediile cloud care întreprinderea noastră a ales. În a doua parte, vom continua subiectul și vom analiza opțiunile de monitorizare a platformelor SaaS folosind exemplul Salesforce și Dropbox și vom încerca, de asemenea, să rezumăm și să punem totul cap la cap prin crearea unui sistem unificat de monitorizare a securității informațiilor pentru diferiți furnizori de cloud.

Sursa: www.habr.com

Monitorizarea securității în cloud