🥇Monitorizarea securității cloud

Transferul de date și aplicații în cloud reprezintă o nouă problemă pentru SOC-urile de întreprindere, care nu sunt întotdeauna pregătite pentru monitorizarea infrastructurii externe. Potrivit Netoskope, o medie de întreprindere (probabil din SUA) utilizează 1246 de servicii cloud diferite, cu 22% mai mult decât în anul precedent. 1246 de servicii cloud!!! 175 dintre ele se referă la servicii de resurse umane, 170 sunt legate de marketing, 110 — în domeniul comunicațiilor și 76 în finanțe și CRM. Cisco utilizează „doar” 700 de servicii cloud externe. Prin urmare, aceste cifre mă cam derutează. Dar, în orice caz, problema nu este în ele, ci în faptul că cloud-urile sunt din ce în ce mai activ folosite de un număr tot mai mare de companii, care ar dori să aibă aceleași capabilități de monitorizare a infrastructurii cloud ca și în propria rețea. Și această tendință crește — conform datelor oficiului de contabilitate al Statelor Unite până în 2023, se estimează că în SUA se vor închide 1200 de centre de date (aproximativ 6250 au fost deja închise). Dar trecerea la cloud nu este doar „hai să ne mutăm serverele la un furnizor extern”. O nouă arhitectură IT, un nou software, noi procese, noi constrângeri… Toate acestea aduc modificări semnificative în funcționarea nu doar a IT-ului, ci și a securității informațiilor. Și, deși furnizorii au reușit cumva să facă față asigurării securității propriului cloud (din fericire, recomandările sunt destul de numeroase), monitorizarea securității cloud, în special pe platformele SaaS, prezintă dificultăți semnificative, despre care vom discuta.

Să presupunem că compania dumneavoastră a mutat o parte din infrastructură în cloud... Stop. Nu așa. Dacă infrastructura a fost mutată și acum vă gândiți cum o veți monitoriza, atunci ați pierdut deja. Dacă nu este vorba despre Amazon, Google sau Microsoft (chiar și cu câteva precizări), probabil că nu veți avea multe opțiuni pentru a monitoriza datele și aplicațiile dumneavoastră. Este bine dacă vi se va oferi 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 sunt disponibile deloc. Cu o licență E3, datele sunt păstrate doar timp de 90 de zile, iar doar cu licența E5 durata jurnalelelor este disponibilă timp de un an (totuși, aici sunt și unele nuanțe legate de necesitatea de a solicita separat o serie de funcții pentru gestionarea jurnalelelor de la suportul Microsoft). Apropo, licența E3 este mult mai slabă în termeni de funcționalitate de monitorizare comparativ cu Exchange-ul corporativ. Pentru a obține același nivel, aveți nevoie de o licență E5 sau de o licență suplimentară Advanced Compliance, care ar putea necesita fonduri suplimentare care nu au fost luate în calcul în modelul dumneavoastră financiar de tranziție către infrastructura cloud. Și acesta este doar un exemplu de subestimare a problemelor legate de monitorizarea security cloud. În acest articol, fără a pretinde că este complet, vreau să atrag atenția asupra unor nuanțe pe care ar trebui să le considerați atunci când alegeți un furnizor de cloud din perspectiva securității. La sfârșitul articolului va fi oferit un checklist pe care trebuie să-l bifați înainte de a considera că problema monitorizării securității cloud a fost rezolvată.

Se pot evidenția câteva probleme tipice care duc la incidente în medii cloud, la care serviciile de securitate nu reușesc să reacționeze sau pe care nu le văd deloc:

Jurnalele de securitate nu există. Aceasta este o situație destul de comună, mai ales la jucătorii începători pe piața soluțiilor cloud. Dar nici nu ar trebui să renunțați la ei imediat. Jucătorii mici, în special cei locali, sunt mai sensibili la cerințele clienților și pot implementa rapid anumite funcții solicitate, modificând foaia de parcurs stabilită pentru produsele lor. Da, nu va fi un echivalent al GuardDuty de la Amazon sau al modulului „Protecție proactivă” de la Bitrix, dar va fi totuși ceva.
Securitatea informațiilor nu știe unde sunt stocate jurnalele sau nu are acces la ele. Aici este necesar să se înceapă negocierea cu furnizorul de servicii cloud - poate că acesta va oferi astfel de informații dacă consideră clientul semnificativ pentru el. În general, nu este bine când accesul la jurnale se oferă "pe o decizie specială".
Există situații în care furnizorul cloud are jurnale, dar acestea oferă o monitorizare și o înregistrare a evenimentelor limitate, insuficiente pentru detectarea tuturor incidentelor. De exemplu, s-ar putea să primiți doar jurnalele modificărilor de pe site sau jurnalele încercărilor de autentificare a utilizatorilor, dar alte evenimente, cum ar fi traficul de rețea, nu sunt furnizate, ceea ce va ascunde un întreg strat de evenimente ce caracterizează încercările de atac asupra infrastructurii dumneavoastră cloud.
Jurnalele există, dar accesul la ele este greu de automatizat, ceea ce le obligă să fie monitorizate nu continuu, ci conform unui program. Și dacă, în plus, jurnalele nu pot fi încărcate în mod automat, atunci exportul jurnalele, de exemplu, în format Excel (așa cum fac unii furnizori locali de soluții cloud), poate duce la o dorință de a evita utilizarea acestora din partea serviciului de securitate corporativ.
Nu există monitorizare a jurnale. Aceasta este, probabil, cea mai neclară cauză a apariției incidentelor de securitate în mediile cloud. Se pare că jurnalele există, iar accesul la ele poate fi automatizat, dar nimeni nu face acest lucru. De ce?

Conceptul de securitate comună în cloud

Trecerea la cloud este întotdeauna o căutare a echilibrului între dorința de a menține controlul asupra infrastructurii și predarea acesteia în mâinile mai profesioniste ale unui furnizor de cloud, care se specializează în întreținerea acesteia. Și în domeniul securității mediilor cloud, acest echilibru trebuie căutat și el. Cu atât mai mult cu cât, în funcție de modelul de furnizare a serviciilor cloud utilizat (IaaS, PaaS, SaaS), acest echilibru va fi diferit în permanență. În orice situație, trebuie să ne amintim că toți furnizorii de cloud de astăzi urmează așa-numitul model de responsabilitate shared și securitate shared. Cloudul este responsabil pentru ceva, iar clientul care își plasează datele, aplicațiile, mașinile virtuale și alte resurse în cloud este responsabil pentru altceva. Ar fi imprudent să credem că, odată ce am trecut la cloud, vom transfera toată responsabilitatea asupra furnizorului. Dar, de asemenea, nu ar fi rațional să construim întreaga securitate singuri în timpul tranziției la cloud. Este necesar un echilibru, care va depinde de o mulțime de factori: strategia de gestionare a riscurilor, modelul de amenințări, mecanismele de protecție pe care le are furnizorul de cloud, legislația etc.

De exemplu, clasificarea datelor stocate în cloud este întotdeauna responsabilitatea clientului. Furnizorul de cloud sau un furnizor extern de servicii poate doar să ofere instrumentele necesare, care ajută la marcarea datelor în cloud, identificarea încălcărilor, eliminarea datelor ilegale sau mascarea acestora printr-o metodă sau alta. Pe de altă parte, securitatea fizică este întotdeauna responsabilitatea furnizorului de cloud, pe care acesta nu o poate împărtăși cu clienții. Tot ce se află între date și infrastructura fizică este exact subiectul acestei articole. De exemplu, disponibilitatea cloud-ului este responsabilitatea furnizorului, iar setările regulilor MSE sau activarea criptării devin deja responsabilitatea clientului. În acest articol, vom încerca să analizăm ce mecanisme de monitorizare a securității informațiilor oferă astăzi diferiți furnizori de cloud populari în Rusia, care sunt caracteristicile aplicării acestora și când este necesar să ne uităm spre soluții externe (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 atunci când urmați o strategie multi-cloud, nu veți avea altă opțiune decât să utilizați soluții externe de monitorizare a securității informațiilor în mai multe medii cloud (de exemplu, Cisco CloudLock sau Cisco Stealthwatch Cloud). În alte cazuri, veți înțelege că furnizorul de cloud ales (sau impus) nu oferă deloc posibilități de monitorizare a securității informațiilor. Este dezamăgitor, dar este, de asemenea, important, deoarece permite evaluarea corectă a nivelului de risc asociat cu utilizarea acestui cloud.

Ciclul de viață al monitorizării securității cloud-ului

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

să vă bazați pe instrumentele furnizate de furnizorul dvs. de cloud,
să utilizați soluțiile unor terți care vor monitoriza platformele dvs. IaaS, PaaS sau SaaS,
să construiți propria infrastructură de monitorizare a mediilor cloud (doar pentru platforme IaaS/PaaS).

Să examinăm care sunt caracteristicile fiecărei opțiuni. Dar înainte de toate, trebuie să înțelegem schema generală care va fi utilizată pentru monitorizarea platformelor cloud. Aș evidenția 6 componente principale ale procesului de monitorizare a securității informațiilor în cloud:

Pregătirea infrastructurii. Determinarea aplicațiilor și infrastructurii necesare pentru colectarea evenimentelor importante pentru securitatea informațiilor în stocare.
Colectarea. În această etapă, evenimentele de securitate sunt agregate din diverse surse pentru a fi ulterior transmise pentru procesare, stocare și analiză.
Procesarea. În această etapă, datele sunt transformate și îmbogățite pentru a facilita analiza ulterioară.
Stocarea. Această componentă se ocupă de stocarea pe termen scurt și lung a datelor procesate și „neprelucrate” colectate.
Analiza. În această etapă, aveți posibilitatea să identificați incidentele și să reacționați la ele în mod automat sau manual.
Raportarea. Această etapă ajută la formarea pentru părțile interesate (management, auditori, furnizor de cloud, clienți etc.) a indicatorilor cheie care ne ajută să luăm anumite decizii, de exemplu, schimbarea furnizorului sau întărirea securității informațiilor.

Înțelegerea acestor componente vă va permite în continuare să identificați rapid ce puteți obține de la furnizorul dumneavoastră și ce va trebui să faceți singur sau cu implicarea consultantilor externi.

Funcționalitățile integrate ale serviciilor cloud

Am menționat deja mai sus că foarte multe servicii cloud de astăzi nu oferă nicio posibilitate de monitorizare a securității informațiilor. De obicei, acestui subiect nu îi acordă o atenție prea mare. De exemplu, unul dintre serviciile populare din Rusia pentru transmiterea raportărilor în instituțiile guvernamentale prin Internet (nu voi menționa numele său) are întreaga secțiune despre securitate concentrată pe utilizarea sistemelor de criptare certificate. Secțiunea referitoare la securitatea informațiilor a unui alt serviciu cloud intern de schimb de documente electronice este incomparabil mai cuprinzătoare. Aceasta discută despre certificatele de chei publice, criptografia certificată, eliminarea vulnerabilităților web, protecția împotriva atacurilor DDoS, aplicarea măsurilor de securitate, backupul și chiar desfășurarea regulată a auditului în domeniul securității informațiilor. Dar nu se spune nimic despre monitorizare, la fel cum nu există mențiuni despre accesul la evenimentele de securitate care ar putea interesa clienții acestui furnizor de servicii.

În general, modul în care un furnizor de cloud descrie pe site-ul său și în documentație aspectele legate de securitatea informațiilor poate oferi indicii despre cât de serios abordează această problemă. De exemplu, dacă citim ghidurile pentru produsele „Biroul Meu”, nu se menționează deloc securitatea, iar în documentația pentru un produs specific „Biroul Meu. KS3”, destinat protecției împotriva accesului neautorizat, este prezentată doar o enumerare a punctelor din ordinul 17 al FSTEC, pe care „Biroul Meu. KS3” le respectă, dar nu se explică cum se respectă și, cel mai important, cum se integrează aceste mecanisme în securitatea informațională corporativă. Poate că o astfel de documentație există, dar nu am găsit-o în accesul public pe site-ul „Biroul Meu”. Totuși, poate că pur și simplu nu am acces la această informație secretă?

La același Bitrix, situația este cu mult mai bună. Documentația descrie formatele jurnalelor de evenimente și, interesant, jurnalul de intruziuni, care conține evenimente legate de potențiale amenințări pentru platforma de cloud. De acolo poți extrage IP-ul, numele utilizatorului sau al oaspetelui, sursa evenimentului, timpul, User Agent-ul, tipul evenimentului etc. Adevărul este că, pentru a lucra cu aceste evenimente, trebuie fie să folosești panoul de control al cloud-ului, fie să exporți datele în format MS Excel. Automatizarea lucrului cu jurnalele Bitrix este acum dificilă și va trebui să efectuezi parte din muncă manual (exportarea raportului și încărcarea acestuia în SIEM-ul tău). Dar dacă ne gândim că nu cu mult timp în urmă nu exista chiar și această posibilitate, atunci este un mare progres. De asemenea, vreau să subliniez că mulți furnizori străini de cloud oferă funcționalități similare „pentru începători” - fie să privești jurnalele cu ochii prin panoul de control, fie să îți exporți datele (deși, majoritatea exportă datele în format .csv, nu Excel).

Dacă nu luăm în considerare varianta absenței jurnalelor, furnizorii de cloud oferă de obicei trei opțiuni pentru monitorizarea evenimentelor de securitate - panouri de control, export de date și acces la acestea prin API. Prima opțiune pare să rezolve multe probleme pentru tine, dar nu este chiar așa - atunci când ai mai multe jurnale, trebuie să te schimbi între ecranele care le afișează, pierzând astfel imaginea de ansamblu. În plus, furnizorul de cloud probabil nu îți va oferi posibilitatea de corelare a evenimentelor de securitate și, în general, de analizare a acestora din perspectiva securității (de obicei, ai de-a face cu date brute, pe care trebuie să le procesezi tu însuți). Există și excepții, despre care vom vorbi mai departe. În cele din urmă, merită să te întrebi ce evenimente înregistrează furnizorul tău de cloud, în ce format, și cât de bine se aliniază acestea cu procesul tău de monitorizare a securității informațiilor? De exemplu, identificarea și autentificarea utilizatorilor și oaspeților. Același Bitrix îți permite, pe baza acestor date, să înregistrezi data și ora evenimentului, numele utilizatorului sau oaspeților (dacă modulul de „Analiză web” este activat), obiectul căruia i s-a acordat acces și alte elemente tipice unui site web. Dar serviciile corporative de securitate a informațiilor pot avea nevoie de informații despre dacă utilizatorul a accesat cloud-ul de pe un dispozitiv de încredere (de exemplu, în rețeaua corporativă, o astfel de sarcină este realizată de Cisco ISE). Și o sarcină atât de simplă, precum funcția geo-IP, care ajută să se determine dacă contul utilizatorului serviciului de cloud a fost furat? Chiar dacă furnizorul de cloud îți oferă această posibilitate, este insuficient. Cisco CloudLock nu doar analizează geolocația, ci folosește pentru asta învățarea automată și analizează datele istorice pentru fiecare utilizator, monitorizând diverse anomalii în încercările de identificare și autentificare. Funcționalități similare sunt disponibile doar în MS Azure (dacă există subscripția corespunzătoare).

Există o altă dificultate – pentru că pentru mulți furnizori de servicii cloud monitorizarea securității informațiilor este un subiect nou, la care abia încep să lucreze, aceștia modifică constant soluțiile lor. Astăzi au o versiune de API, mâine alta, poimâine a treia. Trebuie să fiți pregătiți și pentru asta. Același lucru se aplică funcționalității care poate varia, ceea ce trebuie să se reflecte în sistemul vostru de monitorizare a securității informațiilor. De exemplu, Amazon a avut inițial servicii separate pentru monitorizarea evenimentelor din cloud – AWS CloudTrail și AWS CloudWatch. Apoi a apărut un serviciu special pentru monitorizarea evenimentelor de securitate – AWS GuardDuty. După o vreme, Amazon a lansat un nou sistem de management, Amazon Security Hub, care include analiza datelor primite de la GuardDuty, Amazon Inspector, Amazon Macie și alte servicii. Un alt exemplu este instrumentul de integrare a jurnalelor Azure cu SIEM – AzLog. Acesta a fost utilizat pe scară largă de mulți furnizori de SIEM, până în 2018, când Microsoft a anunțat oprirea dezvoltării și suportului, lăsând mulți clienți, care foloseau acest instrument, în fața unei probleme (cum s-a rezolvat aceasta, vom discuta mai departe).

Așadar, urmăriți cu atenție toate funcțiile de monitorizare oferite de furnizorul vostru de servicii cloud. Sau încredințați acest lucru unor furnizori externi de soluții care vor acționa ca intermediari între SOC-ul vostru și cloud-ul pe care doriți să-l monitorizați. Da, aceasta va fi mai costisitoare (deși nu întotdeauna), dar astfel veți transfera toată responsabilitatea pe alte umeri. Sau nu întreaga? Să ne amintim de conceptul de responsabilitate comună și să înțelegem că nu putem transfera totul – va trebui să ne descurcăm singuri pentru a înțelege cum diferiți furnizori cloud asigură monitorizarea securității informațiilor pentru datele, aplicațiile, mașinile virtuale și alte resurse găzduite în cloud. Și vom începe cu ceea ce oferă Amazon în acest domeniu.

Exemplu: Monitorizarea securității informațiilor în IaaS bazat pe AWS

Da, da, înțeleg că Amazon nu este cel mai bun exemplu, având în vedere că este un serviciu american și poate fi blocat în contextul combaterii extremismului și răspândirii informațiilor interzise pe teritoriul Rusiei. Cu toate acestea, în această publicație aș dori să arăt cât de diferite sunt platformele cloud în ceea ce privește capacitățile de monitorizare a securității informațiilor și la ce ar trebui să fim atenți când transferăm procesele noastre esențiale în cloud din perspectiva securității. Și dacă unele dintre companiile rusești dezvoltatoare de soluții cloud mai găsesc ceva util pentru ele, ar fi excelent.

În primul rând, trebuie spus că Amazon nu este o fortăreață de neclintit. Clienții săi întâmpină frecvent diverse incidente. De exemplu, la Deep Root Analytics au fost furate numele, adresele, datele de naștere și numerele de telefon a 198 de milioane de alegători. La compania israeliană Nice Systems au fost furate 14 milioane de înregistrări despre abonații Verizon. Totuși, funcționalitățile încorporate ale AWS vă permit să detectați un spectru larg de incidente. De exemplu:

atacuri asupra infrastructurii (DDoS)
compromiterea nodului (injectarea de comenzi)
compromiterea contului și acces neautorizat
configurare incorectă și vulnerabilități
interfețe și API-uri nesecurizate.

Această discrepanță se datorează faptului că clientul este responsabil pentru securitatea datelor sale, așa cum am stabilit mai sus. Și dacă acesta nu s-a asigurat că au fost activate mecanismele de protecție și nu a inclus instrumentele de monitorizare, atunci va afla despre incident doar din mass-media sau de la clienții săi.

Pentru a identifica incidentele, se poate utiliza o gamă largă de servicii de monitorizare dezvoltate de Amazon (deși acestea sunt adesea completate de instrumente externe, cum ar fi osquery). Astfel, în AWS sunt urmărite toate acțiunile utilizatorilor, indiferent de modul în care sunt realizate — prin consola de management, linia de comandă, SDK sau alte servicii AWS. Toate înregistrările despre activitățile fiecărei cont AWS (inclusiv numele utilizatorului, acțiunea, serviciul, parametrii de activitate și rezultatul acesteia) și utilizarea API-ului sunt disponibile prin serviciul AWS CloudTrail. Puteți vizualiza aceste evenimente (de exemplu, autentificarea în consola AWS IAM) din consola CloudTrail, le puteți analiza cu Amazon Athena sau le puteți „trimite” către soluții externe, cum ar fi Splunk, AlienVault etc. Jurnalele AWS CloudTrail sunt stocate în coșul dumneavoastră AWS S3.

Două alte servicii AWS oferă o serie de capacități importante de monitorizare. În primul rând, Amazon CloudWatch este un serviciu de monitorizare a resurselor și aplicațiilor AWS, care permite printre altele identificarea diverselor anomalii din cloud-ul dumneavoastră. Toate serviciile integrate AWS, cum ar fi Amazon Elastic Compute Cloud (servere), Amazon Relational Database Service (baze de date), Amazon Elastic MapReduce (analiză de date) și alte 30 de servicii Amazon, folosesc Amazon CloudWatch pentru a-și stoca jurnalele. Dezvoltatorii pot utiliza API-ul public de la Amazon CloudWatch pentru a adăuga funcția de monitorizare a jurnalelor în aplicațiile și serviciile personalizate, permițând astfel extinderea spectrului de evenimente analizate în contextul securității informațiilor.

În al doilea rând, serviciul VPC Flow Logs permite analizarea traficului de rețea trimis sau primit de serverele dumneavoastră AWS (din afară sau din interior), precum și între microservicii. Atunci când oricare dintre resursele dumneavoastră AWS VPC interacționează cu rețeaua, serviciul VPC Flow Logs înregistrează informații 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-ați observat. Cei care au experiență în securitatea rețelelor locale recunosc aceasta ca fiind un echivalent al fluxurilor NetFlow, care pot fi generate de switch-uri, routere și firewall-uri de nivel enterprise. Aceste jurnale sunt importante pentru scopurile de monitorizare a securității informațiilor, deoarece, spre deosebire de evenimentele legate de acțiunile utilizatorilor și aplicațiilor, permite și captarea interacțiunilor de rețea într-un mediu cloud privat virtual AWS.

Astfel, aceste trei servicii AWS — AWS CloudTrail, Amazon CloudWatch și VPC Flow Logs — împreună oferă o imagine suficient de eficientă despre utilizarea contului dvs., comportamentul utilizatorilor, gestionarea infrastructurii, activitatea aplicațiilor și serviciilor, precum și activitatea rețelei. De exemplu, cu ajutorul lor, se pot detecta următoarele anomalii:

Încercări de scanare a site-ului, căutarea backdoor-urilor, căutarea vulnerabilităților prin vârfuri de „erori 404”.
Atacuri prin injecție (de exemplu, SQL injection) prin vârfuri de „erori 500”.
Instrumente cunoscute pentru atacuri precum sqlmap, nikto, w3af, nmap etc. prin analiza câmpului User Agent.

Amazon Web Services a dezvoltat și alte servicii pentru scopurile de securitate cibernetică, care permit rezolvarea multor alte sarcini. De exemplu, în AWS există un serviciu integrat pentru auditarea politicilor și configurărilor — AWS Config. Acest serviciu asigură un audit continuu al resurselor și configurațiilor dumneavoastră AWS. Să luăm un exemplu simplu: să presupunem că doriți să vă asigurați că parolele utilizatorilor sunt dezactivate pe toate serverele dumneavoastră și accesul este posibil doar pe baza certificatelor. AWS Config vă permite să verificați cu ușurință acest lucru pentru toate serverele dumneavoastră. Există și alte politici care pot fi aplicate serverelor dumneavoastră în cloud: „Niciun server nu poate folosi portul 22”, „Numai administratorii pot modifica regulile de firewall” sau „Numai utilizatorul Ivanov poate crea noi conturi de utilizator, și poate face acest lucru doar marțea”. Vara anului 2016, serviciul AWS Config a fost extins pentru a automatiza descoperirea încălcărilor politicilor dezvoltate. AWS Config Rules sunt, în esență, interogări continue de configurare a serviciilor Amazon pe care le utilizați, care generează evenimente în cazul încălcării politicilor corespunzătoare. De exemplu, în loc să efectueze periodic interogări AWS Config pentru a verifica dacă toate discurile serverului virtual sunt criptate, AWS Config Rules poate fi folosit pentru a verifica constant discurile serverului în legătură cu acest criteriu. Și, ceea ce este cel mai important, în contextul acestei publicații, orice încălcare generează evenimente care pot fi analizate de serviciul dumneavoastră de securitate informațională.

AWS are și echivalente pentru soluțiile tradiționale de securitate cibernetică, care de asemenea generează evenimente de securitate pe care le puteți și trebuie să le analizați:

detectarea intruziunilor — AWS GuardDuty
controlul scurgerilor de informații — AWS Macie
EDR (deși este puțin ciudat să vorbim despre dispozitivele finale în cloud) — AWS Cloudwatch + soluții open source osquery sau GRR
analiza Netflow — AWS Cloudwatch + AWS VPC Flow
analiza DNS — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
gestionarea conturilor — AWS IAM
SSO — AWS SSO
analiza securității — AWS Inspector
gestionarea configurațiilor — AWS Config
WAF — AWS WAF.

Nu voi detalia toate serviciile Amazon care ar putea fi utile în contextul securității informației. Cel mai important este să înțelegem că toate acestea pot genera evenimente, pe care noi le putem și trebuie să le analizăm în contextul securității informației, folosind atât capacitățile încorporate ale Amazon, cât și soluții externe, cum ar fi SIEM, care pot prelua evenimentele de securitate în centrul dumneavoastră de monitorizare și le pot analiza 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ă evenimentele de securitate a informației. Printre aceste surse se numără, printre altele:

CloudTrail — utilizarea API-urilor și acțiunile utilizatorilor
Trusted Advisor — verificarea securității conform celor mai bune practici
Config — inventarierea și configurarea conturilor și a setărilor serviciilor
VPC Flow Logs — conexiuni cu interfețele virtuale
IAM — serviciul de identificare și autentificare
ELB Access Logs — jurnalul de acces al echilibratoarelor de sarcină
Inspector — vulnerabilitățile aplicațiilor
S3 — stocarea de fișiere
CloudWatch — activitatea aplicațiilor
SNS — serviciul de notificări.

Amazon, oferind un astfel de spectru de surse de evenimente și instrumente pentru generarea lor, este în același timp foarte limitat în capacitățile de analiză a datelor colectate în contextul securității informației. Va trebui să studiați singuri jurnalele disponibile, căutând în ele indicii relevante de compromitere. AWS Security Hub, pe care Amazon l-a lansat recent, își propune să rezolve această problemă, devenind un fel de SIEM cloud pentru AWS. Însă, deocamdată, se află doar la începutul călătoriei sale și este limitat atât în numărul surselor cu care interacționează, cât și de alte restricții impuse de arhitectură și subscripțiile Amazon.

Exemplu: Monitorizarea securității informației în IaaS bazată pe Azure

Nu vreau să intru într-o polemică lungă despre care dintre cei trei furnizori de cloud (Amazon, Microsoft sau Google) este mai bun (mai ales că fiecare are specificitățile sale și se potrivește pentru rezolvarea propriilor sarcini); să ne concentrăm pe opțiunile de monitorizare a securității informației oferite de acești jucători. Trebuie să recunoaștem că Amazon AWS a fost unul dintre primii în acest segment și de aceea a avansat cel mai mult în ceea ce privește funcțiile sale de securitate (deși mulți recunosc că utilizarea lor este complicată). Dar asta nu înseamnă că vom ignora opțiunile pe care ni le oferă Microsoft și Google.

Produsele Microsoft au fost întotdeauna caracterizate prin „deschiderea” lor, iar în Azure situația este similară. De exemplu, în timp ce AWS și GCP pleacă întotdeauna de la conceptul că „tot ce nu este permis este interzis”, Azure are o abordare complet opusă. De exemplu, atunci când creezi o rețea virtuală în cloud și o mașină virtuală în interiorul acesteia, toate porturile și protocoalele sunt, în mod implicit, deschise și permise. Prin urmare, va trebui să depui un efort suplimentar în configurarea inițială a sistemului de delimitare a accesului în cloud-ul Microsoft. Aceasta impune, de asemenea, cerințe mai stricte în ceea ce privește monitorizarea activității în cloud-ul Azure.

AWS are o caracteristică, legată de faptul că atunci când monitorizați resursele dvs. virtuale, dacă acestea se află în regiuni diferite, apar dificultăți în agregarea tuturor evenimentelor și în analiza acestora, pentru a elimina aceste probleme va trebui să apelați la diverse subterfugii, cum ar fi crearea propriului cod pentru AWS Lambda, care va transfera evenimente între regiuni. În Azure nu există această problemă — mecanismul său Activity Log urmărește toată activitatea din cadrul organizației fără restricții. Aceasta se aplică și AWS Security Hub, care a fost recent dezvoltat de Amazon pentru a consolida multe funcții de securitate într-un singur centru de securitate, dar doar în cadrul propriei regiuni, ceea ce, de altfel, nu este relevant pentru Rusia. Azure are propriul său Security Center, care nu este legat de restricții regionale, oferind acces la toate funcțiile de securitate ale platformei cloud. Mai mult, pentru diverse echipe locale poate oferi propriul set de capacități de securitate, inclusiv evenimentele de securitate gestionate de acestea. AWS Security Hub aspiră încă să devină similar cu Azure Security Center. Dar trebuie adăugat și un strop de amărăciune — puteți extrage din Azure foarte multe dintre cele descrise anterior în AWS, dar cel mai convenabil se face doar pentru Azure AD, Azure Monitor și Azure Security Center. Toate celelalte mecanisme de securitate Azure, inclusiv analiza evenimentelor de securitate, sunt gestionate încă într-un mod nu foarte confortabil. Parțial, problema este rezolvată prin API-ul care străbate toate serviciile Microsoft Azure, dar acest lucru va necesita eforturi suplimentare din partea dvs. pentru integrarea cloud-ului cu SOC-ul dvs. și disponibilitatea de specialiști calificați (în mod normal, ca și în cazul oricărui alt SIEM, care lucrează cu API-urile cloud). Unele SIEM, despre care se va discuta mai departe, deja suportă Azure și pot automatiza sarcina monitorizării acestuia, dar și cu acestea există dificultăți — nu toate pot prelua toate logurile pe care le are Azure.

Colectarea și monitorizarea evenimentelor în Azure se efectuează prin intermediul serviciului Azure Monitor, care este instrumentul principal pentru colectarea, stocarea și analizarea datelor în cloudul Microsoft și în resursele sale — repo-uri 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 jurnale de înregistrare, care conțin date organizate în înregistrări ce caracterizează diferite aspecte ale activității resurselor și serviciilor Azure. În plus, prin intermediul Data Collector API, serviciul Azure Monitor poate colecta date din orice sursă REST pentru a crea propriile scenarii de monitorizare.

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

Jurnale de activitate — acest jurnal răspunde la întrebările clasice „cine”, „ce” și „când” în legătură cu orice operațiune de scriere (PUT, POST, DELETE) asupra resurselor cloud. Evenimentele legate de accesul în citire (GET) nu sunt incluse în acest jurnal, la fel și unele altele.
Jurnale de diagnosticare — conține date despre operațiunile legate de o anumită resursă inclusă în abonamentul dvs.
Raportarea Azure AD — conține atât activitatea utilizatorilor, cât și activitatea sistemului, legată de gestionarea grupurilor și utilizatorilor.
Jurnalul de evenimente Windows și Syslog Linux — conține evenimente din mașinile virtuale găzduite în cloud.
Metrici — conține telemetrie despre starea performanței și „sănătății” serviciilor și resurselor dvs. din cloud. Acestea sunt măsurate la fiecare minut și păstrate timp de 30 de zile.
Jurnalele de flux pentru grupul de securitate al rețelei — conține date despre evenimentele de securitate a rețelei, colectate prin serviciul Network Watcher și monitorizarea resurselor la nivel de rețea.
Jurnale de stocare — conține evenimente legate de accesul la stocare.

Pentru monitorizare, puteți folosi SIEM externe sau Azure Monitor încorporat și extensiile sale. Despre sistemele de gestionare a incidentelor de securitate informațională vom discuta mai târziu, dar să ne uităm la ce ne oferă Azure pentru analiza datelor în contextul securității. Ecranul principal pentru tot ceea ce ține de securitate în Azure Monitor este Log Analytics Security and Audit Dashboard (versiunea gratuită suportă stocarea unui volum limitat de evenimente timp de o săptămână). Această panou este împărțit în 5 domenii principale, care vizualizează statistici rezumative privind ceea ce se întâmplă în mediul dvs. cloud folosit:

Domenii de securitate — indicatori cheie cantitativi legați de securitatea informațională — numărul incidentelor, numărul nodurilor compromise, noduri nepatch-uite, evenimente de securitate în rețea etc.
Probleme notabile — afișează numărul și importanța problemelor active de securitate informațională
Detectări — afișează tiparele atacurilor folosite împotriva dvs.
Intelligence privind amenințările — afișează informații geografice despre nodurile externe care vă atacă
Interogări de securitate comune — interogări tipice care vă pot ajuta să monitorizați mai bine securitatea informațională.

Printre extensiile Azure Monitor se numără Azure Key Vault (protecția cheilor criptografice în cloud), Malware Assessment (analiza protecției împotriva malware-ului pe mașinile virtuale), Azure Application Gateway Analytics (analiza, printre altele, a jurnalelor firewall-ului cloud) etc. Aceste instrumente, îmbogățite cu anumite reguli de procesare a evenimentelor, permit vizualizarea diferitelor aspecte ale activității serviciilor cloud, inclusiv securitatea, și identificarea abaterilor de la funcționarea normală. Dar, așa cum se întâmplă adesea, orice funcționalitate suplimentară necesită un abonament plătit corespunzător, ceea ce va necesita investiții financiare pe care trebuie să le planificați din timp.

Azure dispune de o serie de capacități integrate de monitorizare a amenințărilor, care sunt integrate în Azure AD, Azure Monitor și Azure Security Center. Acestea includ, de exemplu, detectarea interacțiunilor mașinilor virtuale cu IP-uri cunoscute ca fiind malițioase (datorită integrării cu serviciile Threat Intelligence de la Microsoft), detectarea malware-ului în infrastructura cloud prin primirea alertelor de la mașinile virtuale găzduite în cloud, atacurile de tip „brute force” asupra mașinilor virtuale, vulnerabilitățile în configurația sistemului de identificare a utilizatorilor, autentificarea prin intermediul anonimizatoarelor sau nodurilor infectate, scurgerile de conturi, autentificarea din locații neobișnuite etc. Azure este astăzi unul dintre puținii furnizori de cloud care vă oferă capacități integrate de Threat Intelligence pentru a îmbogăți evenimentele de securitate colectate.

După cum s-a menționat mai sus, funcționalitatea de protecție și, ca urmare, evenimentele de securitate generate, nu sunt disponibile pentru toți utilizatorii în mod egal, ci necesită un anumit tip de abonament care să includă funcționalitatea de care aveți nevoie, care generează evenimente corespunzătoare pentru monitorizarea securității informației. De exemplu, o parte din 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ă aceasta, la fel ca și în cazul AWS, va trebui să analizați evenimentele de securitate colectate „manual”. De asemenea, în funcție de tipul de licență pentru Azure AD, nu toate evenimentele vor fi disponibile pentru analiză.

Pe portalul Azure, puteți gestiona atât interogările pentru jurnalele de înregistrare care vă interesează, cât și să configurați tablouri de bord pentru vizualizarea indicatorilor cheie de securitate. În plus, acolo puteți alege extensiile 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 perspectiva securității.

Dacă aveți nevoie nu doar de funcționalitatea de gestionare a jurnalele, ci și de un centru cuprinzător de securitate pentru platforma dvs. cloud Azure, inclusiv administrarea politicilor de Securitate Informatica, atunci se poate discuta despre necesitatea utilizării Azure Security Center, majoritatea funcțiilor utile fiind disponibile contra cost, de exemplu, detectarea amenințărilor, monitorizarea în afara Azure, evaluarea conformității etc. (în versiunea gratuită aveți acces doar la evaluarea securității și recomandări pentru remedierea problemelor identificate). Acesta consolidează toate aspectele securității într-un singur loc. Practic, se poate spune că oferă un nivel mai înalt de Securitate Informatica decât Azure Monitor, deoarece, în acest caz, datele colectate din întreaga fabrică cloud sunt îmbogățite cu ajutorul multor surse, cum ar fi Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) și Microsoft Security Response Center (MSRC), asupra cărora se aplică diferite algoritmi avansați de învățare automată și analiză comportamentală, ceea ce, în cele din urmă, ar trebui să îmbunătățească eficiența detectării amenințărilor și reacția la acestea.

Azure dispune și de propriul său SIEM — acesta a fost lansat la începutul anului 2019. Este vorba despre Azure Sentinel, care se bazează pe datele de la Azure Monitor și poate să se integreze cu soluții externe de securitate (de exemplu, NGFW sau WAF), lista acestora fiind în continuă expansiune. În plus, datorită integrării Microsoft Graph Security API, aveți oportunitatea de a conecta feed-uri proprii de Threat Intelligence la Sentinel, ceea ce îmbogățește capacitățile de analiză a incidentelor în cloud-ul dumneavoastră Azure. Se poate afirma că Azure Sentinel este primul SIEM „nativ” care a apărut în rândul furnizorilor de cloud (alte soluții precum Splunk sau ELK, care pot fi găzduite în cloud, de exemplu, AWS, au fost dezvoltate de furnizori de servicii cloud tradiționale). Azure Sentinel și Security Center ar putea fi considerate SOC-uri pentru cloud-ul Azure și s-ar putea limita la acestea (cu anumite precauții), dacă nu ați avea nicio altă infrastructură și toate resursele de calcul ar fi mutate în cloud, și acest cloud ar fi Microsoft Azure.

Dar, deoarece funcționalitățile încorporate ale Azure (chiar și cu un abonament la Sentinel) sunt adesea insuficiente pentru scopurile de monitorizare a securității informațiilor și integrarea acestui proces cu alte surse de evenimente de securitate (atât cloud, cât și interne), apare necesitatea de a exporta datele colectate în sisteme externe, printre care se numără și SIEM. Acest lucru se face atât prin API, cât și prin extensii speciale, care în prezent sunt disponibile oficial doar pentru următoarele SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight și ELK. Recent, au fost mai multe astfel de SIEM, dar începând cu 1 iunie 2019, Microsoft a încetat suportul pentru Azure Log Integration Tool (AzLog), care, la începuturile Azure, în lipsa unei standardizări corespunzătoare a lucrului cu log-urile (Azure Monitor nici măcar nu exista), permitea integrarea ușoară a SIEM externe cu cloud-ul Microsoft. Acum situația s-a schimbat, iar Microsoft recomandă platforma Azure Event Hub ca principal instrument de integrare pentru alte SIEM. Multe organizații au realizat deja această integrare, dar fiți atenți — ele pot captura nu toate log-urile Azure, ci doar pe unele (consultați documentația pentru SIEM-ul dumneavoastră).

Încheind o scurtă introducere în Azure, vreau să ofer o recomandare generală cu privire la acest serviciu cloud: înainte de a afirma ceva despre funcțiile de monitorizare a securității în Azure, este important să le configurați cu foarte mare atenție și să testați dacă acestea funcționează așa cum este descris în documentație și așa cum v-au explicat consultantii Microsoft (deoarece pot avea viziuni diferite asupra funcționalității funcțiilor Azure). Dacă aveți resurse financiare, puteți extrage foarte multe informații utile din Azure în ceea ce privește monitorizarea securității. Dacă resursele sunt limitate, așa cum se întâmplă în cazul AWS, va trebui să vă bazați doar pe propriile forțe și pe datele brute pe care vi le oferă Azure Monitor. Și amintiți-vă că multe dintre funcțiile de monitorizare vin cu un cost, iar politica de prețuri ar trebui cunoscută din timp. De exemplu, gratuit puteți stoca date timp de 31 de zile într-un volum de cel mult 5 GB pe client — depășirea acestor limite va necesita cheltuieli suplimentare (aproximativ 2+ dolari pentru stocarea fiecărui GB suplimentar de la client și 0,1 dolari pentru stocarea 1 GB în fiecare lună suplimentară). Lucrul cu telemetria aplicațiilor și metricele poate necesita, de asemenea, fonduri suplimentare, la fel ca și lucrul cu alertele și notificările (un anumit limită este disponibilă gratuit, dar aceasta poate să nu fie suficientă pentru nevoile dumneavoastră).

Exemplu: Monitorizarea securității în IaaS pe baza Google Cloud Platform

Google Cloud Platform, comparativ cu AWS și Azure, arată puțin novice, dar acest lucru este într-o oarecare măsură pozitiv. Spre deosebire de AWS, care a crescut treptat capacitățile sale, inclusiv cele de apărare, având probleme cu centralizarea; GCP, la fel ca și Azure, este gestionat mult mai bine centralizat, ceea ce reduce numărul de erori și timpul de implementare în organizație. Din punct de vedere al securității, GCP se află, paradoxal, între AWS și Azure. De asemenea, GCP are o înregistrare a evenimentelor unificată pentru întreaga organizație, dar aceasta este incompletă. Unele funcții sunt încă în stadiu beta, dar treptat această deficiență ar trebui să fie eliminată, iar GCP va deveni o platformă mai matură din perspectiva monitorizării securității.

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

Admin Activity — conține toate evenimentele legate de accesul administrativ, cum ar fi crearea unei mașini virtuale, modificarea permisiunilor etc. Acest jurnal este întotdeauna activ, indiferent de dorințele voastre, și păstrează datele timp de 400 de zile.
Data Access — conține toate evenimentele legate de activitățile utilizatorilor cloud asupra datelor (creare, modificare, citire etc.). În mod implicit, acest jurnal nu este activ, deoarece volumul său crește foarte repede. Din acest motiv, perioada sa de păstrare este de doar 30 de zile. De asemenea, nu toate evenimentele sunt înregistrate aici. De exemplu, nu sunt înregistrate evenimentele legate de resursele disponibile public tuturor utilizatorilor sau cele accesibile fără autentificare în GCP.
System Event — conține evenimentele sistemului care nu sunt legate de utilizatori sau acțiunile unui administrator care modifică configurația resurselor cloud. Este întotdeauna activ și păstrează datele timp de 400 de zile.
Access Transparency — este un exemplu unic de jurnal de înregistrare, care înregistrează toate acțiunile angajaților Google (deocamdată nu pentru toate serviciile GCP) care au acces la infrastructura dumneavoastră în cadrul îndeplinirii îndatoririlor lor de serviciu. Acest jurnal este păstrat timp de 400 de zile și nu este disponibil tuturor clienților GCP, ci doar în anumite condiții (fie suport de nivel Gold sau Platinum, fie existența a patru roluri de un anumit tip în cadrul suportului corporate). O funcție similară există, 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: "Numărul cazului: 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.comaccess_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"
}

Accesarea jurnalelor menționate se poate realiza în mai multe moduri (aproximativ la fel ca și pentru Azure și AWS) — prin interfața Log Viewer, prin API, prin Google Cloud SDK sau prin pagina Activitate a proiectului dvs., unde sunt de interes evenimentele. De asemenea, pot fi exportate în soluții externe pentru o analiză suplimentară. Ultimul aspect se realizează prin exportul jurnalelor în stocarea BigQuery sau Cloud Pub/Sub.

Pe lângă Stackdriver Logging, platforma GCP oferă și funcționalitatea Stackdriver Monitoring, care permite monitorizarea metricalor cheie (performanță, fiabilitate, stare generală etc.) a serviciilor și aplicațiilor cloud. Datele procesate și vizualizate pot facilita identificarea problemelor din infrastructura dvs. cloud, inclusiv în contextul securității. Totuși, trebuie menționat că această funcționalitate nu este foarte bogată în contextul securității informației, deoarece în prezent GCP nu are un substitut pentru AWS GuardDuty și nu poate identifica evenimentele dăunătoare dintre toate cele înregistrate (Google a dezvoltat Event Threat Detection, dar acesta se află în beta și este prea devreme să discutăm despre utilitatea sa). Stackdriver Monitoring ar putea fi utilizat ca un sistem de detectare a anomaliilor, care apoi vor fi investigate pentru a identifica cauzele apariției acestora. Însă, având în vedere lipsa pe piață a personalului calificat în domeniul securității informației, această sarcină pare a fi complicată în prezent.

De asemenea, merită menționat un listă a unora dintre modulele de securitate informațională care pot fi aplicate în cadrul cloud-ului dvs. GCP și care sunt similare cu ceea ce oferă AWS:

Cloud Security Command Center — este echivalentul AWS Security Hub și Azure Security Center.
Cloud DLP — descoperirea automată și editarea (de exemplu, mascarea) datelor stocate în cloud, conform mai mult de 90 de politici de clasificare prestabilite.
Cloud Scanner — scanner de vulnerabilități cunoscute (XSS, Flash Injection, biblioteci neactualizate etc.) în App Engine, Compute Engine și Google Kubernetes.
Cloud IAM — gestionarea accesului la toate resursele GCP.
Cloud Identity — gestionarea conturilor de utilizatori, dispozitive și aplicații GCP dintr-o consolă unificată.
Cloud HSM — protecția cheilor criptografice.
Cloud Key Management Service — gestionarea cheilor criptografice în GCP.
VPC Service Control — crearea unui perimeter securizat în jurul resurselor dumneavoastră GCP pentru a le proteja de scurgeri.
Titan Security Key — protecție împotriva phishing-ului.

Multe dintre aceste module generează evenimente de securitate, care pot fi trimise în stocarea BigQuery pentru analiză sau export în alte sisteme, inclusiv SIEM. Așa cum s-a menționat anterior, GCP este o platformă în dezvoltare activă, iar Google lucrează acum la o serie de module noi pentru securitate informatică. Printre acestea se numără Event Threat Detection (disponibil acum în versiune beta), care scanează jurnalele Stackdriver în căutarea unor urme de activitate neautorizată (analog GuardDuty în AWS), sau Policy Intelligence (disponibil în versiune alfa), care va permite dezvoltarea de politici inteligente de acces la resursele GCP.

Am realizat un mic rezumat al capacităților încorporate de monitorizare în platformele cloud populare. Dar aveți specialiști care să poată lucra cu jurnalele „brute” ale furnizorului IaaS (nu toți sunt pregătiți să achiziționeze capacități extinse de la AWS, Azure sau Google)? În plus, tuturor le este cunoscut dictonul „încrede-te, dar verifică”, care în domeniul securității este mai adevărat ca niciodată. Cât de mult aveți încredere în capacitățile încorporate ale furnizorului de cloud, care vă furnizează evenimente de securitate informatică? Cât de mult se concentrează acestea pe securitate?

Uneori merită să explorăm soluțiile de monitorizare a infrastructurilor cloud, care pot completa securitatea încorporată a cloud-ului, iar uneori astfel de soluții reprezintă singura opțiune pentru a obține informații despre securitatea datelor și aplicațiilor dvs. găzduite în cloud. În plus, sunt pur și simplu mai convenabile, deoarece se ocupă de toate sarcinile de analiză a jurnalelor necesare, generate de diversele servicii cloud ale diferitelor furnizori de cloud. Un exemplu de astfel de soluție suplimentară este Cisco Stealthwatch Cloud, care se concentrează pe o singură sarcină - monitorizarea anomaliilor de securitate în mediile cloud, inclusiv Amazon AWS, Microsoft Azure și Google Cloud Platform, dar și în cloud-uri private.

Exemplu: Monitorizarea securității cu Stealthwatch Cloud

AWS oferă o platformă flexibilă pentru calcul, dar această flexibilitate face ca erorile să fie mai ușor de comis de către companii, ceea ce duce la probleme de securitate. Iar modelul de securitate împărțit contribuie la aceasta. Executarea în cloud a software-ului cu vulnerabilități necunoscute (cele cunoscute pot fi gestionate, de exemplu, de AWS Inspector sau GCP Cloud Scanner), parole slabe, configurații incorecte, insideri etc. Toate acestea afectează comportamentul resurselor cloud, pe care Cisco Stealthwatch Cloud le poate monitoriza, fiind un sistem de monitorizare a securității și de detectare a atacurilor în cloud-urile publice și private.

Una dintre caracteristicile cheie ale Cisco Stealthwatch Cloud este capacitatea de a modela entități. Cu ajutorul său, se poate crea un model software (adică o simulare aproape în timp real) pentru fiecare dintre resursele dvs. cloud (fie că este vorba despre AWS, Azure, GCP sau altceva). Acestea pot include servere și utilizatori, precum și tipuri de resurse specifice mediului vostru cloud, cum ar fi grupuri de securitate și grupuri de scalare automată a serviciilor. Aceste modele folosesc ca intrare fluxuri de date structurate, furnizate de serviciile cloud. De exemplu, pentru AWS, acestea vor 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 din cadrul vostru (se poate vorbi despre profilarea întreagă a activității în cloud). Printre aceste roluri se numără un dispozitiv mobil Android sau Apple, un server Citrix PVS, un server RDP, un gateway de email, un client VoIP, un server terminal, un controller de domeniu, etc. Apoi, monitorizează constant comportamentul lor pentru a determina când are loc un comportament riscant sau amenințător. Puteți identifica atacuri de tip brute force, atacuri DDoS, scurgeri de date, accesuri neautorizate, acțiuni ale codului malițios, scanări de vulnerabilitate și alte amenințări. De exemplu, iată cum arată detectarea unei încercări de acces remote dintr-o țară atipică pentru organizația dvs. (Coreea de Sud) la un cluster Kubernetes prin SSH:

Iată cum arată o presupusă scurgere de informații dintr-o bază de date Postgress în țara cu care nu ați interacționat anterior:

În cele din urmă, iată cum arată un număr prea mare de încercări de acces nereușite prin SSH din China și Indonezia de pe un dispozitiv remote extern:

Sau, să presupunem că o instanță de server în VPC, conform politicii, nu ar trebui niciodată să fie un punct de destinație pentru accesul la distanță. Să presupunem în continuare că pe acest computer s-a efectuat un acces la distanță din cauza unei modificări eronate a politicii de reguli de firewall. Funcția de modelare a entităților va detecta și va raporta această activitate („Acces la distanță neobișnuit”) în aproape timp real și va indica apelul API specific AWS CloudTrail, Azure Monitor sau GCP Stackdriver Logging (inclusiv numele utilizatorului, data și ora, printre alte detalii) care a provocat modificarea regulii de firewall. Apoi, aceste informații pot fi trimise către SIEM pentru analiză.

Capabilități similare sunt implementate pentru orice mediu cloud susținut de Cisco Stealthwatch Cloud:

Modelarea entităților este o formă unică de automatizare a securității, care poate detecta probleme anterior necunoscute cu oamenii, procesele sau tehnologiile dumneavoastră. De exemplu, permite detectarea, printre altele, a următoarelor probleme de securitate:

A descoperit cineva un backdoor în software-ul pe care îl utilizăm?
Există vreun software sau dispozitiv terț în cloud-ul nostru?
Abuzează utilizatorul autorizat de privilegii?
A fost comisă vreo eroare de configurare care să permită accesul la distanță sau altă utilizare neintenționată a resurselor?
Există vreo scurgere de date de pe serverele noastre?
A încercat cineva să se conecteze la noi dintr-o locație geografică neobișnuită?
Cloud-ul nostru nu este infectat cu cod malițios?

Un eveniment detectat de securitate IT poate fi transmis sub formă de ticket corespunzător în Slack, Cisco Spark, sistemul de gestionare a incidentelor PagerDuty, precum și livrat către diverse SIEM, printre care Splunk sau ELK. În concluzie, se poate spune că, dacă compania dumneavoastră utilizează o strategie multi-cloud și nu se limitează la un singur furnizor de cloud, capacitățile de monitorizare a securității IT menționate mai sus, utilizarea Cisco Stealthwatch Cloud reprezintă o opțiune bună pentru a obține un set unificat de capacități de monitorizare a principalilor furnizori de cloud — Amazon, Microsoft și Google. Cel mai interesant este că, comparând prețurile pentru Stealthwatch Cloud cu licențele avansate de monitorizare a securității IT în AWS, Azure sau GCP, ar putea apărea că soluția Cisco este chiar mai ieftină decât capacitățile încorporate ale soluțiilor Amazon, Microsoft și Google. Este paradoxal, dar este adevărat. Și cu cât utilizați mai multe cloud-uri și capacitățile lor, cu atât avantajul unei soluții consolidate va deveni mai evident.

În plus, Stealthwatch Cloud poate monitoriza și cloud-uri private implementate în organizația dumneavoastră, de exemplu, bazate pe containere Kubernetes sau prin monitorizarea fluxurilor Netflow sau a traficului de rețea obținut prin mirroring în echipamentele de rețea (chiar și din producție autohtonă), date AD sau servere DNS etc. Toate aceste date vor fi îmbogățite cu informații de Threat Intelligence, colectate de departamentul Cisco Talos, care este cea mai mare grupare de cercetători în domeniul amenințărilor de securitate IT din lume.

Aceasta vă permite să implementați un sistem unitar de monitorizare atât pentru cloud-uri publice, cât și pentru cele hibride, pe care compania dumneavoastră îl poate utiliza. Informațiile colectate pot fi apoi analizate folosind capacitățile încorporate ale Stealthwatch Cloud sau trimise către SIEM-ul dumneavoastră (în mod implicit, se suportă Splunk, ELK, SumoLogic și câteva altele).

Încheiem această primă parte a articolului în care am discutat despre uneltele integrate și externe de monitorizare a securității pentru platformele IaaS/PaaS, care ne permit să detectăm și să reacționăm rapid la incidentele ce au loc în mediile de cloud utilizate de compania noastră. În partea a doua, vom continua subiectul și vom explora opțiunile de monitorizare a platformelor SaaS, folosind exemple precum Salesforce și Dropbox, și vom încerca să sintetizăm și să grupăm totul, creând un sistem unitar de monitorizare a securității pentru diferiți furnizori de cloud.

Sursa: habr.com