🥇Vigilància de seguretat al núvol

Moure dades i aplicacions al núvol presenta un nou repte per als SOC corporatius, que no sempre estan preparats per supervisar la infraestructura d'una altra persona. Segons Netoskope, l'empresa mitjana (aparentment als EUA) utilitza 1246 serveis al núvol diferents, la qual cosa és un 22% més que fa un any. 1246 serveis al núvol!!! 175 d'ells estan relacionats amb serveis de RRHH, 170 estan relacionats amb màrqueting, 110 són en l'àmbit de les comunicacions i 76 són en finances i CRM. Cisco utilitza "només" 700 serveis externs al núvol. Així que estic una mica confós amb aquests números. Però, en qualsevol cas, el problema no està en ells, sinó en el fet que el núvol comença a ser utilitzat de manera força activa per un nombre creixent d'empreses que voldrien tenir les mateixes capacitats de monitorització de la infraestructura del núvol que a la seva pròpia xarxa. I aquesta tendència està creixent - segons segons la Cambra de Comptes dels Estats Units El 2023, 1200 centres de dades estaran tancats als Estats Units (6250 ja s'han tancat). Però la transició al núvol no és només "movem els nostres servidors a un proveïdor extern". Nova arquitectura informàtica, nou programari, nous processos, noves restriccions... Tot això comporta canvis significatius en el treball no només de la informàtica, sinó també de la seguretat de la informació. I si els proveïdors han après d'alguna manera a fer front a garantir la seguretat del propi núvol (afortunadament hi ha moltes recomanacions), aleshores amb el control de la seguretat de la informació al núvol, especialment a les plataformes SaaS, hi ha dificultats importants, de les quals parlarem.

Suposem que la vostra empresa ha traslladat part de la seva infraestructura al núvol... Atureu-vos. No d'aquesta manera. Si la infraestructura s'ha transferit, i ara només esteu pensant en com la controlareu, ja heu perdut. A menys que sigui Amazon, Google o Microsoft (i després amb reserves), probablement no tindreu molta capacitat per supervisar les vostres dades i aplicacions. És bo si teniu l'oportunitat de treballar amb registres. De vegades, les dades d'esdeveniments de seguretat estaran disponibles, però no hi tindreu accés. Per exemple, Office 365. Si teniu la llicència E1 més barata, els esdeveniments de seguretat no estan disponibles per a vosaltres. Si teniu una llicència E3, les vostres dades s'emmagatzemen només durant 90 dies, i només si teniu una llicència E5, la durada dels registres està disponible durant un any (no obstant això, això també té els seus propis matisos relacionats amb la necessitat de fer-ho per separat). sol·licitar una sèrie de funcions per treballar amb registres del suport de Microsoft). Per cert, la llicència E3 és molt més feble pel que fa a les funcions de supervisió que l'Exchange corporatiu. Per aconseguir el mateix nivell, necessiteu una llicència E5 o una llicència de compliment avançat addicional, que pot requerir diners addicionals que no s'han tingut en compte al vostre model financer per passar a la infraestructura del núvol. I aquest és només un exemple de subestimació dels problemes relacionats amb el control de la seguretat de la informació al núvol. En aquest article, sense pretendre ser complet, vull cridar l'atenció sobre alguns matisos que s'han de tenir en compte a l'hora d'escollir un proveïdor de núvol des del punt de vista de la seguretat. I al final de l'article es donarà una llista de verificació que val la pena completar abans de considerar que s'ha resolt el tema de la supervisió de la seguretat de la informació al núvol.

Hi ha diversos problemes típics que provoquen incidents en entorns de núvol, als quals els serveis de seguretat de la informació no tenen temps de respondre o no els veuen gens:

Els registres de seguretat no existeixen. Aquesta és una situació força habitual, especialment entre els jugadors novells del mercat de solucions al núvol. Però no hauríeu de renunciar a ells de seguida. Els petits jugadors, especialment els nacionals, són més sensibles als requisits dels clients i poden implementar ràpidament algunes funcions requerides canviant el full de ruta aprovat per als seus productes. Sí, això no serà un anàleg de GuardDuty d'Amazon o el mòdul de "Protecció proactiva" de Bitrix, però almenys alguna cosa.
La seguretat de la informació no sap on s'emmagatzemen els registres o no hi ha accés. Aquí cal entablar negociacions amb el proveïdor de serveis al núvol; potser proporcionarà aquesta informació si considera que el client és important per a ell. Però, en general, no és molt bo quan l'accés als registres es proporciona "per decisió especial".
També passa que el proveïdor del núvol té registres, però ofereixen un seguiment i un enregistrament d'esdeveniments limitats, que no són suficients per detectar totes les incidències. Per exemple, és possible que només rebeu registres de canvis al lloc o registres d'intents d'autenticació d'usuaris, però no altres esdeveniments, per exemple, sobre trànsit de xarxa, que us ocultaran tota una capa d'esdeveniments que caracteritzen els intents de piratejar la vostra infraestructura de núvol. .
Hi ha registres, però l'accés a ells és difícil d'automatitzar, la qual cosa obliga a fer-ne un seguiment no continuat, sinó de manera programada. I si no podeu descarregar els registres automàticament, la descàrrega de registres, per exemple, en format Excel (com passa amb diversos proveïdors nacionals de solucions al núvol), fins i tot pot provocar una reticència per part del servei de seguretat de la informació corporatiu a manipular-los.
Sense control de registre. Aquesta és potser la raó més poc clara de l'aparició d'incidents de seguretat de la informació en entorns de núvol. Sembla que hi ha registres, i és possible automatitzar-hi l'accés, però ningú ho fa. Per què?

Concepte de seguretat al núvol compartit

La transició al núvol és sempre la recerca d'un equilibri entre el desig de mantenir el control de la infraestructura i transferir-lo a les mans més professionals d'un proveïdor de núvol especialitzat en el seu manteniment. I en l'àmbit de la seguretat al núvol també s'ha de buscar aquest equilibri. A més, depenent del model de lliurament del servei al núvol utilitzat (IaaS, PaaS, SaaS), aquest saldo serà diferent tot el temps. En qualsevol cas, hem de recordar que tots els proveïdors de núvol avui dia segueixen l'anomenat model de responsabilitat compartida i seguretat de la informació compartida. El núvol és el responsable d'unes coses, i d'altres el client és responsable, col·locant les seves dades, les seves aplicacions, les seves màquines virtuals i altres recursos al núvol. Seria temerari esperar que en anar al núvol, traslladem tota la responsabilitat al proveïdor. Però també és imprudent crear tota la seguretat vostè mateix quan es mou al núvol. Cal un equilibri, que dependrà de molts factors: - estratègia de gestió del risc, model d'amenaça, mecanismes de seguretat a disposició del proveïdor del núvol, legislació, etc.

Per exemple, la classificació de les dades allotjades al núvol és sempre responsabilitat del client. Un proveïdor de núvol o un proveïdor de serveis extern només el pot ajudar amb eines que l'ajudaran a marcar dades al núvol, identificar infraccions, eliminar dades que infringeixen la llei o emmascarar-les mitjançant un mètode o un altre. D'altra banda, la seguretat física és sempre responsabilitat del proveïdor del núvol, que no pot compartir amb els clients. Però tot el que hi ha entre les dades i la infraestructura física és precisament el tema de discussió en aquest article. Per exemple, la disponibilitat del núvol és responsabilitat del proveïdor, i la configuració de regles del tallafoc o l'habilitació del xifratge és responsabilitat del client. En aquest article tractarem de veure quins mecanismes de control de seguretat de la informació ofereixen avui dia diversos proveïdors de núvol populars a Rússia, quines són les característiques del seu ús i quan val la pena buscar solucions de superposició externes (per exemple, Cisco E- Mail Security) que amplien les capacitats del vostre núvol en termes de ciberseguretat. En alguns casos, especialment si seguiu una estratègia multinúvol, no tindreu més remei que utilitzar solucions externes de control de seguretat de la informació en diversos entorns de núvol alhora (per exemple, Cisco CloudLock o Cisco Stealthwatch Cloud). Bé, en alguns casos us adonareu que el proveïdor de núvol que heu triat (o que us heu imposat) no ofereix cap capacitat de control de seguretat de la informació. Això és desagradable, però tampoc poc, ja que permet avaluar adequadament el nivell de risc associat a treballar amb aquest núvol.

Cicle de vida del seguiment de la seguretat al núvol

Per controlar la seguretat dels núvols que utilitzeu, només teniu tres opcions:

confieu en les eines proporcionades pel vostre proveïdor de núvol,
utilitzar solucions de tercers que supervisaran les plataformes IaaS, PaaS o SaaS que utilitzeu,
Creeu la vostra pròpia infraestructura de monitorització al núvol (només per a plataformes IaaS/PaaS).

Vegem quines característiques té cadascuna d'aquestes opcions. Però primer, hem d'entendre el marc general que s'utilitzarà per supervisar les plataformes en núvol. Destacaria 6 components principals del procés de monitorització de la seguretat de la informació al núvol:

Preparació de la infraestructura. Determinar les aplicacions i la infraestructura necessàries per a la recollida d'esdeveniments importants per a la seguretat de la informació a l'emmagatzematge.
Col · lecció. En aquesta etapa, els esdeveniments de seguretat s'agreguen de diverses fonts per a la posterior transmissió per al seu processament, emmagatzematge i anàlisi.
Tractament. En aquesta etapa, les dades es transformen i s'enriqueixen per facilitar l'anàlisi posterior.
Emmagatzematge. Aquest component és responsable de l'emmagatzematge a curt i llarg termini de les dades processades i en brut recopilades.
Anàlisi. En aquesta fase, teniu la capacitat de detectar incidències i respondre-hi automàticament o manualment.
Informes. Aquesta etapa ajuda a formular indicadors clau per als grups d'interès (direcció, auditors, proveïdor de núvol, clients, etc.) que ens ajuden a prendre determinades decisions, per exemple, canviar de proveïdor o reforçar la seguretat de la informació.

Entendre aquests components us permetrà decidir ràpidament en el futur què podeu prendre del vostre proveïdor i què haureu de fer vosaltres mateixos o amb la participació de consultors externs.

Serveis al núvol integrats

Ja vaig escriure més amunt que molts serveis al núvol avui dia no ofereixen cap capacitat de control de seguretat de la informació. En general, no presten molta atenció al tema de la seguretat de la informació. Per exemple, un dels serveis populars russos per enviar informes a les agències governamentals a través d'Internet (no esmentaré específicament el seu nom). Tot l'apartat sobre la seguretat d'aquest servei gira al voltant de l'ús de CIPF certificat. La secció de seguretat de la informació d'un altre servei domèstic al núvol per a la gestió de documents electrònics no és diferent. Parla de certificats de clau pública, criptografia certificada, eliminació de vulnerabilitats web, protecció contra atacs DDoS, ús de tallafocs, còpies de seguretat i fins i tot auditories periòdiques de seguretat de la informació. Però no hi ha ni una paraula sobre el seguiment, ni sobre la possibilitat d'accedir a esdeveniments de seguretat de la informació que puguin ser d'interès per als clients d'aquest proveïdor de serveis.

En general, per la manera com el proveïdor de núvol descriu els problemes de seguretat de la informació al seu lloc web i a la seva documentació, podeu entendre amb quina seriositat es pren aquest problema. Per exemple, si llegiu els manuals dels productes "My Office", no hi ha cap paraula sobre seguretat, sinó a la documentació del producte separat "My Office. KS3”, dissenyat per protegir contra l'accés no autoritzat, hi ha una llista habitual de punts de l'ordre 17 del FSTEC, que implementa “My Office.KS3”, però no es descriu com ho implementa i, el més important, com integrar aquests mecanismes amb la seguretat de la informació corporativa. Potser aquesta documentació existeix, però no la vaig trobar de domini públic al lloc web "La meva oficina". Encara que potser no tinc accés a aquesta informació secreta?...

Per a Bitrix, la situació és molt millor. La documentació descriu els formats dels registres d'esdeveniments i, curiosament, el registre d'intrusions, que conté esdeveniments relacionats amb amenaces potencials a la plataforma del núvol. Des d'allà podeu treure la IP, el nom de l'usuari o convidat, la font de l'esdeveniment, l'hora, l'agent d'usuari, el tipus d'esdeveniment, etc. És cert que podeu treballar amb aquests esdeveniments des del tauler de control del mateix núvol o carregar dades en format MS Excel. Ara és difícil automatitzar el treball amb els registres de Bitrix i haureu de fer part del treball manualment (penjar l'informe i carregar-lo al vostre SIEM). Però si recordem que fins fa relativament fa poc aquesta oportunitat no existia, això és un gran progrés. Al mateix temps, m'agradaria assenyalar que molts proveïdors de núvol estrangers ofereixen una funcionalitat similar "per a principiants": mireu els registres amb els vostres ulls a través del tauler de control o carregueu les dades a vosaltres mateixos (no obstant això, la majoria de dades de càrrega a . csv, no Excel).

Sense tenir en compte l'opció sense registres, els proveïdors de núvol solen oferir tres opcions per supervisar els esdeveniments de seguretat: taulers de control, càrrega de dades i accés a l'API. El primer sembla que us resol molts problemes, però això no és del tot cert: si teniu diverses revistes, haureu de canviar entre les pantalles que les mostren, perdent la imatge general. A més, és poc probable que el proveïdor de núvol us ofereixi la capacitat de correlacionar els esdeveniments de seguretat i, generalment, d'analitzar-los des del punt de vista de la seguretat (normalment esteu tractant amb dades en brut, que heu d'entendre vosaltres mateixos). Hi ha excepcions i en parlarem més endavant. Finalment, val la pena preguntar-se quins esdeveniments registra el vostre proveïdor de núvol, en quin format i com es corresponen amb el vostre procés de control de la seguretat de la informació? Per exemple, la identificació i autenticació d'usuaris i convidats. El mateix Bitrix permet, a partir d'aquests esdeveniments, registrar la data i l'hora de l'esdeveniment, el nom de l'usuari o convidat (si es disposa del mòdul “Anàlisi web”), l'objecte al qual s'accedeix i altres elements típics d'un lloc web. . Però els serveis de seguretat de la informació corporativa poden necessitar informació sobre si l'usuari ha accedit al núvol des d'un dispositiu de confiança (per exemple, en una xarxa corporativa aquesta tasca la implementa Cisco ISE). Què passa amb una tasca tan senzilla com la funció de geo-IP, que ajudarà a determinar si s'ha robat un compte d'usuari del servei al núvol? I fins i tot si el proveïdor del núvol us ho proporciona, això no és suficient. El mateix Cisco CloudLock no només analitza la geolocalització, sinó que utilitza l'aprenentatge automàtic per a això i analitza les dades històriques de cada usuari i supervisa diverses anomalies en els intents d'identificació i autenticació. Només MS Azure té una funcionalitat similar (si teniu la subscripció adequada).

Hi ha una altra dificultat: ja que per a molts proveïdors de núvol el control de la seguretat de la informació és un tema nou que tot just comencen a tractar, estan canviant constantment alguna cosa en les seves solucions. Avui tenen una versió de l'API, demà una altra, passat demà una tercera. També cal estar preparat per a això. El mateix passa amb la funcionalitat, que pot canviar, que s'ha de tenir en compte en el seu sistema de control de seguretat de la informació. Per exemple, Amazon inicialment tenia serveis de supervisió d'esdeveniments al núvol separats: AWS CloudTrail i AWS CloudWatch. Aleshores va aparèixer un servei separat per supervisar els esdeveniments de seguretat de la informació: AWS GuardDuty. Després d'un temps, Amazon va llançar un nou sistema de gestió, Amazon Security Hub, que inclou l'anàlisi de les dades rebudes de GuardDuty, Amazon Inspector, Amazon Macie i diversos altres. Un altre exemple és l'eina d'integració de registres d'Azure amb SIEM - AzLog. Va ser utilitzat activament per molts venedors de SIEM, fins que el 2018 Microsoft va anunciar el cessament del seu desenvolupament i suport, la qual cosa va enfrontar a molts clients que utilitzaven aquesta eina amb un problema (ja parlarem de com es va resoldre més endavant).

Per tant, vigileu acuradament totes les funcions de monitorització que us ofereix el vostre proveïdor de núvol. O confieu en proveïdors de solucions externs que actuaran com a intermediaris entre el vostre SOC i el núvol que voleu supervisar. Sí, serà més car (encara que no sempre), però passaràs tota la responsabilitat a les espatlles d'una altra persona. O no tot?... Recordem el concepte de seguretat compartida i entenem que no podem canviar res: haurem d'entendre de manera independent com els diferents proveïdors de núvol proporcionen un seguiment de la seguretat de la informació de les vostres dades, aplicacions, màquines virtuals i altres recursos. allotjat al núvol. I començarem amb el que Amazon ofereix en aquesta part.

Exemple: monitorització de la seguretat de la informació a IaaS basat en AWS

Sí, sí, entenc que Amazon no és el millor exemple pel fet que es tracta d'un servei nord-americà i es pot bloquejar com a part de la lluita contra l'extremisme i la difusió d'informació prohibida a Rússia. Però en aquesta publicació només m'agradaria mostrar com es diferencien les diferents plataformes al núvol en les seves capacitats de monitorització de la seguretat de la informació i a què hauríeu de prestar atenció quan transferiu els vostres processos clau als núvols des del punt de vista de la seguretat. Bé, si alguns dels desenvolupadors russos de solucions al núvol aprenen alguna cosa útil per ells mateixos, això serà fantàstic.

El primer que cal dir és que Amazon no és una fortalesa impenetrable. Els seus clients succeeixen regularment diversos incidents. Per exemple, els noms, adreces, dates de naixement i números de telèfon de 198 milions de votants van ser robats de Deep Root Analytics. L'empresa israeliana Nice Systems va robar 14 milions de registres de subscriptors de Verizon. Tanmateix, les capacitats integrades d'AWS us permeten detectar una àmplia gamma d'incidències. Per exemple:

impacte en la infraestructura (DDoS)
compromís del node (injecció d'ordres)
compromís del compte i accés no autoritzat
configuració incorrecta i vulnerabilitats
interfícies i API insegures.

Aquesta discrepància es deu al fet que, com hem vist anteriorment, el propi client és responsable de la seguretat de les dades del client. I si no es va molestar a activar els mecanismes de protecció i no va activar les eines de control, només coneixerà l'incident pels mitjans de comunicació o pels seus clients.

Per identificar incidències, podeu utilitzar una àmplia gamma de serveis de monitoratge diferents desenvolupats per Amazon (tot i que sovint es complementen amb eines externes com l'osquery). Així, a AWS, es supervisen totes les accions dels usuaris, independentment de com es portin a terme, mitjançant la consola de gestió, la línia d'ordres, l'SDK o altres serveis d'AWS. Tots els registres de l'activitat de cada compte d'AWS (inclosos el nom d'usuari, l'acció, el servei, els paràmetres d'activitat i el resultat) i l'ús de l'API estan disponibles a través d'AWS CloudTrail. Podeu veure aquests esdeveniments (com ara els inicis de sessió de la consola AWS IAM) des de la consola CloudTrail, analitzar-los mitjançant Amazon Athena o "subcontractar" a solucions externes com Splunk, AlienVault, etc. Els propis registres d'AWS CloudTrail es col·loquen al vostre cub d'AWS S3.

Altres dos serveis d'AWS ofereixen una sèrie d'altres capacitats de supervisió importants. En primer lloc, Amazon CloudWatch és un servei de monitorització de recursos i aplicacions d'AWS que, entre altres coses, us permet identificar diverses anomalies al vostre núvol. Tots els serveis d'AWS integrats, com ara Amazon Elastic Compute Cloud (servidors), Amazon Relational Database Service (bases de dades), Amazon Elastic MapReduce (anàlisi de dades) i 30 serveis més d'Amazon, utilitzen Amazon CloudWatch per emmagatzemar els seus registres. Els desenvolupadors poden utilitzar l'API oberta d'Amazon CloudWatch per afegir funcionalitats de supervisió de registres a aplicacions i serveis personalitzats, cosa que els permet ampliar l'abast de l'anàlisi d'esdeveniments en un context de seguretat.

En segon lloc, el servei VPC Flow Logs us permet analitzar el trànsit de xarxa enviat o rebut pels vostres servidors AWS (extern o intern), així com entre microserveis. Quan qualsevol dels vostres recursos d'AWS VPC interactua amb la xarxa, VPC Flow Logs registra detalls sobre el trànsit de xarxa, inclosa la interfície de xarxa d'origen i de destinació, així com les adreces IP, els ports, el protocol, el nombre de bytes i el nombre de paquets que teniu. va veure. Els que tinguin experiència amb la seguretat de la xarxa local ho reconeixeran com a anàleg als fils NetFlow, que es poden crear mitjançant commutadors, encaminadors i tallafocs de nivell empresarial. Aquests registres són importants per a la supervisió de la seguretat de la informació perquè, a diferència dels esdeveniments sobre les accions dels usuaris i les aplicacions, també us permeten no perdre't les interaccions de xarxa a l'entorn de núvol privat virtual d'AWS.

En resum, aquests tres serveis d'AWS (AWS CloudTrail, Amazon CloudWatch i VPC Flow Logs) en conjunt proporcionen una visió bastant potent sobre l'ús del vostre compte, el comportament dels usuaris, la gestió de la infraestructura, l'activitat d'aplicacions i serveis i l'activitat de la xarxa. Per exemple, es poden utilitzar per detectar les anomalies següents:

Intents d'escanejar el lloc, cercar portes del darrere, buscar vulnerabilitats mitjançant ràfegues d'"errors 404".
Atacs d'injecció (per exemple, injecció SQL) mitjançant ràfegues de "500 errors".
Les eines d'atac conegudes són sqlmap, nikto, w3af, nmap, etc. mitjançant l'anàlisi del camp User Agent.

Amazon Web Services també ha desenvolupat altres serveis amb finalitats de ciberseguretat que us permeten resoldre molts altres problemes. Per exemple, AWS té un servei integrat per auditar polítiques i configuracions: AWS Config. Aquest servei ofereix una auditoria contínua dels vostres recursos d'AWS i les seves configuracions. Posem un exemple senzill: suposem que voleu assegurar-vos que les contrasenyes d'usuari estan desactivades a tots els vostres servidors i que l'accés només és possible basat en certificats. AWS Config fa que sigui fàcil comprovar-ho per a tots els vostres servidors. Hi ha altres polítiques que es poden aplicar als vostres servidors al núvol: "Cap servidor pot utilitzar el port 22", "Només els administradors poden canviar les regles del tallafoc" o "Només l'usuari Ivashko pot crear nous comptes d'usuari, i pot fer-ho només els dimarts. " L'estiu del 2016, el servei AWS Config es va ampliar per automatitzar la detecció d'infraccions de les polítiques desenvolupades. Les regles d'AWS Config són essencialment sol·licituds de configuració contínues per als serveis d'Amazon que feu servir, que generen esdeveniments si s'incompleixen les polítiques corresponents. Per exemple, en lloc d'executar periòdicament consultes d'AWS Config per verificar que tots els discs d'un servidor virtual estan xifrats, les regles d'AWS Config es poden utilitzar per comprovar contínuament els discs del servidor per assegurar-se que es compleix aquesta condició. I, el més important, en el context d'aquesta publicació, qualsevol infracció genera esdeveniments que poden ser analitzats pel vostre servei de seguretat de la informació.

AWS també té el seu equivalent a les solucions tradicionals de seguretat de la informació corporativa, que també generen esdeveniments de seguretat que podeu i heu d'analitzar:

Detecció d'intrusions - AWS GuardDuty
Control de fuites d'informació - AWS Macie
EDR (tot i que parla de punts finals al núvol una mica estrany) - AWS Cloudwatch + solucions d'osquery de codi obert o GRR
Anàlisi de Netflow - AWS Cloudwatch + AWS VPC Flow
Anàlisi DNS - AWS Cloudwatch + AWS Route53
AD - Servei de directori AWS
Gestió de comptes - AWS IAM
SSO - AWS SSO
anàlisi de seguretat - AWS Inspector
gestió de la configuració - AWS Config
WAF - AWS WAF.

No descriuré amb detall tots els serveis d'Amazon que poden ser útils en el context de la seguretat de la informació. El més important és entendre que tots ells poden generar esdeveniments que podem i hem d'analitzar en el context de la seguretat de la informació, utilitzant per a això tant les capacitats integrades del mateix Amazon com solucions externes, per exemple, SIEM, que pot portar els esdeveniments de seguretat al vostre centre de monitorització i analitzar-los allà juntament amb esdeveniments d'altres serveis al núvol o d'infraestructura interna, perímetre o dispositius mòbils.

En qualsevol cas, tot comença amb les fonts de dades que us proporcionen esdeveniments de seguretat de la informació. Aquestes fonts inclouen, però no es limiten a:

CloudTrail: ús de l'API i accions de l'usuari
Trusted Advisor: comprovació de seguretat amb les millors pràctiques
Configuració: inventari i configuració de comptes i paràmetres del servei
Registres de flux de VPC: connexions a interfícies virtuals
IAM - servei d'identificació i autenticació
Registres d'accés ELB - Equilibrador de càrrega
Inspector - vulnerabilitats de l'aplicació
S3: emmagatzematge de fitxers
CloudWatch - Activitat de l'aplicació
SNS és un servei de notificacions.

Amazon, tot i que ofereix aquest ventall de fonts d'esdeveniments i eines per a la seva generació, té una capacitat molt limitada per analitzar les dades recollides en el context de la seguretat de la informació. Haureu d'estudiar de manera independent els registres disponibles, buscant-hi indicadors rellevants de compromís. AWS Security Hub, que Amazon va llançar recentment, pretén resoldre aquest problema convertint-se en un SIEM al núvol per a AWS. Però fins ara només es troba al començament del seu viatge i està limitat tant pel nombre de fonts amb què treballa com per altres restriccions establertes per l'arquitectura i les subscripcions del mateix Amazon.

Exemple: supervisió de la seguretat de la informació a IaaS basat en Azure

No vull entrar en un llarg debat sobre quin dels tres proveïdors de núvol (Amazon, Microsoft o Google) és millor (sobretot perquè cadascun d'ells encara té les seves particularitats específiques i és adequat per resoldre els seus problemes); Ens centrem en les capacitats de control de seguretat de la informació que proporcionen aquests jugadors. Cal reconèixer que Amazon AWS va ser un dels primers en aquest segment i, per tant, ha avançat més pel que fa a les seves funcions de seguretat de la informació (tot i que molts admeten que són difícils d'utilitzar). Però això no vol dir que ignorarem les oportunitats que Microsoft i Google ens ofereixen.

Els productes de Microsoft sempre s'han distingit per la seva "obertura" i a Azure la situació és similar. Per exemple, si AWS i GCP sempre procedeixen del concepte de "el que no està permès està prohibit", llavors Azure té l'enfocament exactament oposat. Per exemple, quan es crea una xarxa virtual al núvol i una màquina virtual en ella, tots els ports i protocols estan oberts i permesos de manera predeterminada. Per tant, haureu de dedicar una mica més d'esforç a la configuració inicial del sistema de control d'accés al núvol de Microsoft. I això també us imposa requisits més estrictes pel que fa a l'activitat de supervisió al núvol Azure.

AWS té una peculiaritat associada al fet que quan controleu els vostres recursos virtuals, si es troben en diferents regions, aleshores teniu dificultats per combinar tots els esdeveniments i la seva anàlisi unificada, per eliminar-los, cal recórrer a diversos trucs, com ara Creeu el vostre propi codi per a AWS Lambda que transportarà esdeveniments entre regions. Azure no té aquest problema: el seu mecanisme de registre d'activitat fa un seguiment de tota l'activitat a tota l'organització sense restriccions. El mateix s'aplica a AWS Security Hub, que Amazon va desenvolupar recentment per consolidar moltes funcions de seguretat dins d'un únic centre de seguretat, però només dins de la seva regió, que, però, no és rellevant per a Rússia. Azure té el seu propi Centre de seguretat, que no està subjecte a restriccions regionals, proporcionant accés a totes les funcions de seguretat de la plataforma al núvol. A més, per a diferents equips locals pot proporcionar el seu propi conjunt de capacitats de protecció, inclosos els esdeveniments de seguretat gestionats per ells. AWS Security Hub encara està en camí de ser similar a Azure Security Center. Però val la pena afegir una mosca a la pomada: podeu extreure d'Azure molt del que es va descriure anteriorment a AWS, però això només es fa més convenientment per a Azure AD, Azure Monitor i Azure Security Center. Tots els altres mecanismes de seguretat d'Azure, inclosa l'anàlisi d'esdeveniments de seguretat, encara no es gestionen de la manera més convenient. El problema es resol en part per l'API, que impregna tots els serveis de Microsoft Azure, però això requerirà un esforç addicional per integrar el vostre núvol amb el vostre SOC i la presència d'especialistes qualificats (de fet, com amb qualsevol altre SIEM que funcioni amb el núvol). API). Alguns SIEM, dels quals parlarem més endavant, ja són compatibles amb Azure i poden automatitzar la tasca de supervisar-lo, però també tenen les seves pròpies dificultats: no tots poden recollir tots els registres que té Azure.

La recollida i el seguiment d'esdeveniments a Azure es proporciona mitjançant el servei Azure Monitor, que és l'eina principal per recopilar, emmagatzemar i analitzar dades al núvol de Microsoft i els seus recursos: dipòsits Git, contenidors, màquines virtuals, aplicacions, etc. Totes les dades recopilades per Azure Monitor es divideixen en dues categories: mètriques, recopilades en temps real i que descriuen els indicadors clau de rendiment del núvol Azure, i registres, que contenen dades organitzades en registres que caracteritzen determinats aspectes de l'activitat dels recursos i serveis d'Azure. A més, utilitzant l'API Data Collector, el servei Azure Monitor pot recopilar dades de qualsevol font REST per crear els seus propis escenaris de supervisió.

A continuació, es mostren algunes fonts d'esdeveniments de seguretat que us ofereix Azure i a les quals podeu accedir mitjançant l'Azure Portal, la CLI, el PowerShell o l'API REST (i algunes només mitjançant l'API Azure Monitor/Insight):

Registres d'activitats: aquest registre respon a les preguntes clàssiques "qui", "què" i "quan" sobre qualsevol operació d'escriptura (POSA, PUBLICACIÓ, SUPRIMIR) als recursos del núvol. Els esdeveniments relacionats amb l'accés de lectura (GET) no s'inclouen en aquest registre, com molts d'altres.
Registres de diagnòstic: conté dades sobre les operacions amb un recurs determinat inclòs a la vostra subscripció.
Informes d'Azure AD: conté tant l'activitat dels usuaris com l'activitat del sistema relacionada amb la gestió de grups i usuaris.
Windows Event Log i Linux Syslog: conté esdeveniments de màquines virtuals allotjades al núvol.
Mètriques: conté telemetria sobre el rendiment i l'estat de salut dels vostres serveis i recursos al núvol. Mesurat cada minut i emmagatzemat. en un termini de 30 dies.
Registres de flux del grup de seguretat de la xarxa: conté dades sobre els esdeveniments de seguretat de la xarxa recopilats mitjançant el servei Network Watcher i la supervisió de recursos a nivell de xarxa.
Registres d'emmagatzematge: conté esdeveniments relacionats amb l'accés a les instal·lacions d'emmagatzematge.

Per a la supervisió, podeu utilitzar SIEM externs o Azure Monitor integrat i les seves extensions. Més endavant parlarem dels sistemes de gestió d'esdeveniments de seguretat de la informació, però de moment vegem què ens ofereix el mateix Azure per a l'anàlisi de dades en el context de la seguretat. La pantalla principal de tot allò relacionat amb la seguretat a Azure Monitor és el tauler de control de seguretat i auditoria de Log Analytics (la versió gratuïta admet una quantitat limitada d'emmagatzematge d'esdeveniments durant només una setmana). Aquest tauler es divideix en 5 àrees principals que visualitzen estadístiques de resum del que està passant a l'entorn del núvol que utilitzeu:

Dominis de seguretat: indicadors quantitatius clau relacionats amb la seguretat de la informació: el nombre d'incidències, el nombre de nodes compromesos, nodes sense pegat, esdeveniments de seguretat de xarxa, etc.
Problemes notables: mostra el nombre i la importància dels problemes actius de seguretat de la informació
Deteccions: mostra els patrons d'atacs utilitzats contra vostè
Intel·ligència d'amenaces: mostra informació geogràfica sobre nodes externs que us estan atacant
Consultes de seguretat habituals: consultes típiques que us ajudaran a controlar millor la seguretat de la vostra informació.

Les extensions d'Azure Monitor inclouen Azure Key Vault (protecció de claus criptogràfiques al núvol), Malware Assessment (anàlisi de la protecció contra codi maliciós en màquines virtuals), Azure Application Gateway Analytics (anàlisi, entre altres coses, dels registres del tallafocs del núvol), etc. . Aquestes eines, enriquides amb determinades regles de processament d'esdeveniments, permeten visualitzar diversos aspectes de l'activitat dels serveis al núvol, inclosa la seguretat, i identificar determinades desviacions del funcionament. Però, com passa sovint, qualsevol funcionalitat addicional requereix una subscripció de pagament corresponent, que requerirà les inversions financeres corresponents, que cal planificar amb antelació.

L'Azure té una sèrie de capacitats integrades de supervisió d'amenaces que s'integren a Azure AD, Azure Monitor i Azure Security Center. Entre ells, per exemple, detecció d'interacció de màquines virtuals amb IPs malicioses conegudes (per la presència d'integració amb serveis Threat Intelligence de Microsoft), detecció de programari maliciós a la infraestructura del núvol mitjançant la recepció d'alarmes de màquines virtuals allotjades al núvol, contrasenya. endevinar atacs ” a màquines virtuals, vulnerabilitats en la configuració del sistema d'identificació d'usuaris, inici de sessió al sistema des d'anonimitzadors o nodes infectats, filtracions de comptes, inici de sessió al sistema des d'ubicacions inusuals, etc. Azure avui és un dels pocs proveïdors de núvol que us ofereix capacitats integrades d'intel·ligència d'amenaces per enriquir els esdeveniments de seguretat de la informació recopilada.

Com s'ha esmentat anteriorment, la funcionalitat de seguretat i, en conseqüència, els esdeveniments de seguretat generats per aquesta no estan disponibles per a tots els usuaris per igual, però requereixen una determinada subscripció que inclogui la funcionalitat que necessiteu, que genera els esdeveniments adequats per al seguiment de la seguretat de la informació. Per exemple, algunes de les funcions descrites al paràgraf anterior per al seguiment d'anomalies en els comptes només estan disponibles a la llicència premium P2 per al servei Azure AD. Sense ell, vostè, com en el cas d'AWS, haurà d'analitzar els esdeveniments de seguretat recollits "manualment". I, a més, depenent del tipus de llicència d'Azure AD, no tots els esdeveniments estaran disponibles per a l'anàlisi.

Al portal d'Azure, podeu gestionar tant les consultes de cerca dels registres que us interessen com la configuració de taulers per visualitzar els indicadors clau de seguretat de la informació. A més, allà podeu seleccionar les extensions d'Azure Monitor, que us permeten ampliar la funcionalitat dels registres d'Azure Monitor i obtenir una anàlisi més profunda dels esdeveniments des del punt de vista de la seguretat.

Si necessiteu no només la capacitat de treballar amb registres, sinó un centre de seguretat complet per a la vostra plataforma de núvol Azure, inclosa la gestió de polítiques de seguretat de la informació, podeu parlar de la necessitat de treballar amb Azure Security Center, la majoria de les funcions útils de les quals estan disponibles per alguns diners, per exemple, detecció d'amenaces, supervisió fora d'Azure, avaluació de compliment, etc. (en la versió gratuïta, només teniu accés a una avaluació de seguretat i recomanacions per eliminar els problemes identificats). Consolida tots els problemes de seguretat en un sol lloc. De fet, podem parlar d'un nivell de seguretat de la informació superior al que t'ofereix Azure Monitor, ja que en aquest cas les dades recollides al llarg de la teva fàbrica de núvols s'enriqueixen amb moltes fonts, com ara Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) i Microsoft Security Response Center (MSRC), on es superposen diversos algorismes sofisticats d'aprenentatge automàtic i d'anàlisi del comportament, que en última instància haurien de millorar l'eficiència de detecció i resposta a les amenaces. .

Azure també té el seu propi SIEM: va aparèixer a principis del 2019. Es tracta d'Azure Sentinel, que es basa en dades d'Azure Monitor i també es pot integrar amb. solucions de seguretat externes (per exemple, NGFW o WAF), la llista de les quals creix constantment. A més, mitjançant la integració de l'API de seguretat de Microsoft Graph, teniu la possibilitat de connectar els vostres propis canals d'intel·ligència d'amenaces a Sentinel, la qual cosa enriqueix les capacitats d'anàlisi d'incidències al vostre núvol Azure. Es pot argumentar que Azure Sentinel és el primer SIEM "natiu" que va aparèixer dels proveïdors de núvol (els mateixos Splunk o ELK, que es poden allotjar al núvol, per exemple, AWS, encara no estan desenvolupats pels proveïdors de serveis al núvol tradicionals). Azure Sentinel and Security Center es podria anomenar SOC per al núvol Azure i es podria limitar a ells (amb certes reserves) si ja no teníeu cap infraestructura i transferís tots els vostres recursos informàtics al núvol i seria el núvol de Microsoft Azure.

Però com que les capacitats integrades d'Azure (fins i tot si teniu una subscripció a Sentinel) sovint no són suficients per supervisar la seguretat de la informació i integrar aquest procés amb altres fonts d'esdeveniments de seguretat (tant al núvol com interns), hi ha una cal exportar les dades recollides a sistemes externs, als quals pot incloure SIEM. Això es fa tant mitjançant l'API com amb extensions especials, que actualment només estan disponibles oficialment per als SIEM següents: Splunk (complement d'Azure Monitor per a Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight i ELK. Fins fa poc, hi havia més SIEM d'aquest tipus, però a partir de l'1 de juny de 2019, Microsoft va deixar de donar suport a l'eina d'integració de registres d'Azure (AzLog), que en els albors de l'existència d'Azure i en absència d'una estandardització normal del treball amb registres (Azure). El monitor encara no existia) va facilitar la integració de SIEM extern amb el núvol de Microsoft. Ara la situació ha canviat i Microsoft recomana la plataforma Azure Event Hub com a principal eina d'integració per a altres SIEM. Molts ja han implementat aquesta integració, però aneu amb compte: és possible que no capturen tots els registres d'Azure, sinó només alguns (consulteu la documentació del vostre SIEM).

Concloent una breu excursió a Azure, m'agradaria donar una recomanació general sobre aquest servei al núvol: abans de dir res sobre les funcions de supervisió de la seguretat de la informació a Azure, hauríeu de configurar-les amb molta cura i comprovar que funcionen tal com està escrit a la documentació i tal com us van dir els consultors a Microsoft (i poden tenir diferents punts de vista sobre la funcionalitat de les funcions d'Azure). Si teniu els recursos financers, podeu extreure molta informació útil d'Azure pel que fa a la supervisió de la seguretat de la informació. Si els vostres recursos són limitats, aleshores, com en el cas d'AWS, haureu de confiar només en les vostres pròpies forces i en les dades en brut que us proporciona Azure Monitor. I recordeu que moltes funcions de control costen diners i és millor familiaritzar-se amb la política de preus amb antelació. Per exemple, de forma gratuïta podeu emmagatzemar 31 dies de dades fins a un màxim de 5 GB per client; si supereu aquests valors, us caldrà desembolsar diners addicionals (aproximadament 2 $ o més per emmagatzemar cada GB addicional del client i 0,1 $ per emmagatzemant 1 GB cada mes addicional). Treballar amb la telemetria i les mètriques de l'aplicació també pot requerir fons addicionals, així com treballar amb alertes i notificacions (un cert límit està disponible de forma gratuïta, que pot ser que no sigui suficient per a les vostres necessitats).

Exemple: monitorització de la seguretat de la informació a IaaS basat en Google Cloud Platform

Google Cloud Platform sembla un jove en comparació amb AWS i Azure, però això és en part bo. A diferència d'AWS, que va augmentar les seves capacitats, incloses les de seguretat, progressivament, tenint problemes amb la centralització; GCP, com Azure, es gestiona molt millor de manera centralitzada, cosa que redueix els errors i el temps d'implementació a tota l'empresa. Des del punt de vista de la seguretat, GCP es troba, curiosament, entre AWS i Azure. També té una única inscripció a l'esdeveniment per a tota l'organització, però està incompleta. Algunes funcions encara es troben en mode beta, però a poc a poc s'hauria d'eliminar aquesta deficiència i GCP es convertirà en una plataforma més madura pel que fa a la supervisió de la seguretat de la informació.

L'eina principal per registrar esdeveniments a GCP és Stackdriver Logging (similar a Azure Monitor), que us permet recollir esdeveniments a tota la vostra infraestructura de núvol (així com des d'AWS). Des d'una perspectiva de seguretat a GCP, cada organització, projecte o carpeta té quatre registres:

Activitat de l'administrador: conté tots els esdeveniments relacionats amb l'accés administratiu, per exemple, la creació d'una màquina virtual, el canvi de drets d'accés, etc. Aquest registre sempre s'escriu, independentment del vostre desig, i emmagatzema les seves dades durant 400 dies.
Accés a les dades: conté tots els esdeveniments relacionats amb el treball amb dades per part dels usuaris del núvol (creació, modificació, lectura, etc.). Per defecte, aquest registre no està escrit, ja que el seu volum augmenta molt ràpidament. Per aquest motiu, la seva vida útil és de només 30 dies. A més, no tot està escrit en aquesta revista. Per exemple, els esdeveniments relacionats amb recursos que són accessibles públicament per a tots els usuaris o que són accessibles sense iniciar sessió a GCP no s'hi escriuen.
Esdeveniment del sistema: conté esdeveniments del sistema no relacionats amb els usuaris o accions d'un administrador que canvia la configuració dels recursos del núvol. Sempre s'escriu i s'emmagatzema durant 400 dies.
La transparència d'accés és un exemple únic de registre que recull totes les accions dels empleats de Google (però encara no per a tots els serveis de GCP) que accedeixen a la vostra infraestructura com a part de les seves tasques laborals. Aquest registre s'emmagatzema durant 400 dies i no està disponible per a tots els clients de GCP, però només si es compleixen una sèrie de condicions (suport de nivell Or o Platí, o la presència de 4 rols d'un determinat tipus com a part del suport corporatiu). Una funció similar també està disponible, per exemple, a Office 365 - Lockbox.

Exemple de registre: 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"
}

L'accés a aquests registres és possible de diverses maneres (de la mateixa manera que s'ha parlat anteriorment d'Azure i AWS): mitjançant la interfície Log Viewer, l'API, l'SDK de Google Cloud o la pàgina d'activitat del vostre projecte per al qual estan interessats en els esdeveniments. De la mateixa manera, es poden exportar a solucions externes per a una anàlisi addicional. Això últim es fa exportant els registres a l'emmagatzematge BigQuery o Cloud Pub/Sub.

A més de Stackdriver Logging, la plataforma GCP també ofereix la funcionalitat de monitorització de Stackdriver, que us permet supervisar les mètriques clau (rendiment, MTBF, salut general, etc.) dels serveis i aplicacions al núvol. Les dades processades i visualitzades poden facilitar la cerca de problemes a la vostra infraestructura de núvol, inclòs en el context de la seguretat. Però cal tenir en compte que aquesta funcionalitat no serà molt rica en el context de la seguretat de la informació, ja que avui GCP no té un anàleg del mateix AWS GuardDuty i no pot identificar-ne de dolents entre tots els esdeveniments registrats (Google ha desenvolupat Event Threat Detection, però encara està en desenvolupament en versió beta i és massa aviat per parlar de la seva utilitat). Stackdriver Monitoring es podria utilitzar com a sistema per detectar anomalies, que després s'investigarien per trobar les causes de la seva aparició. Però atesa la manca de personal qualificat en l'àmbit de la seguretat de la informació GCP al mercat, actualment aquesta tasca sembla difícil.

També val la pena donar una llista d'alguns mòduls de seguretat de la informació que es poden utilitzar dins del vostre núvol GCP i que són similars al que ofereix AWS:

Cloud Security Command Center és un anàleg d'AWS Security Hub i Azure Security Center.
Cloud DLP: descobriment i edició automàtics (p. ex. emmascarament) de dades allotjades al núvol mitjançant més de 90 polítiques de classificació predefinides.
Cloud Scanner és un escàner de vulnerabilitats conegudes (XSS, Flash Injection, biblioteques sense pegats, etc.) a App Engine, Compute Engine i Google Kubernetes.
Cloud IAM: controleu l'accés a tots els recursos de GCP.
Cloud Identity: gestioneu els comptes d'usuaris, dispositius i aplicacions de GCP des d'una sola consola.
Cloud HSM: protecció de claus criptogràfiques.
Servei de gestió de claus al núvol: gestió de claus criptogràfiques a GCP.
Control del servei VPC: creeu un perímetre segur al voltant dels vostres recursos de GCP per protegir-los de les fuites.
Clau de seguretat de Titan: protecció contra el phishing.

Molts d'aquests mòduls generen esdeveniments de seguretat que es poden enviar a l'emmagatzematge de BigQuery per analitzar-los o exportar-los a altres sistemes, inclòs SIEM. Com s'ha esmentat anteriorment, GCP és una plataforma en desenvolupament actiu i Google està desenvolupant una sèrie de nous mòduls de seguretat de la informació per a la seva plataforma. Entre ells hi ha Event Threat Detection (ara disponible en versió beta), que escaneja els registres de Stackdriver a la recerca de rastres d'activitat no autoritzada (anàloga a GuardDuty a AWS), o Policy Intelligence (disponible en alfa), que us permetrà desenvolupar polítiques intel·ligents per a accés als recursos de GCP.

Vaig fer una breu visió general de les capacitats de monitorització integrades a les plataformes de núvol populars. Però, teniu especialistes capaços de treballar amb registres de proveïdors d'IaaS "crues" (no tothom està preparat per comprar les capacitats avançades d'AWS o Azure o Google)? A més, molts estan familiaritzats amb l'adagio "confia, però verifica", que és més cert que mai en l'àmbit de la seguretat. Quant confieu en les capacitats integrades del proveïdor de núvol que us envien esdeveniments de seguretat de la informació? Fins a quin punt se centren en la seguretat de la informació?

De vegades val la pena mirar les solucions de supervisió de la infraestructura del núvol que poden complementar la seguretat integrada al núvol i, de vegades, aquestes solucions són l'única opció per obtenir informació sobre la seguretat de les vostres dades i aplicacions allotjades al núvol. A més, simplement són més còmodes, ja que s'encarreguen de totes les tasques d'anàlisi dels registres necessaris generats per diferents serveis al núvol de diferents proveïdors de núvol. Un exemple d'aquesta solució de superposició és Cisco Stealthwatch Cloud, que se centra en una única tasca: supervisar les anomalies de seguretat de la informació en entorns de núvol, que inclouen no només Amazon AWS, Microsoft Azure i Google Cloud Platform, sinó també núvols privats.

Exemple: Monitorització de la seguretat de la informació mitjançant Stealthwatch Cloud

AWS ofereix una plataforma informàtica flexible, però aquesta flexibilitat facilita que les empreses cometin errors que generen problemes de seguretat. I el model de seguretat de la informació compartida només contribueix a això. Execució de programari al núvol amb vulnerabilitats desconegudes (les conegudes es poden combatre, per exemple, amb AWS Inspector o GCP Cloud Scanner), contrasenyes febles, configuracions incorrectes, insiders, etc. I tot això es reflecteix en el comportament dels recursos del núvol, que poden ser monitoritzats per Cisco Stealthwatch Cloud, que és un sistema de monitorització de la seguretat de la informació i detecció d'atacs. núvols públics i privats.

Una de les característiques clau de Cisco Stealthwatch Cloud és la capacitat de modelar entitats. Amb ell, podeu crear un model de programari (és a dir, una simulació gairebé en temps real) de cadascun dels vostres recursos al núvol (no importa si es tracta d'AWS, Azure, GCP o una altra cosa). Aquests poden incloure servidors i usuaris, així com tipus de recursos específics del vostre entorn al núvol, com ara grups de seguretat i grups d'escala automàtica. Aquests models utilitzen fluxos de dades estructurats proporcionats pels serveis al núvol com a entrada. Per exemple, per a AWS aquests serien VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda i AWS IAM. El modelatge d'entitats descobreix automàticament el paper i el comportament de qualsevol dels vostres recursos (pots parlar de perfilar tota l'activitat del núvol). Aquestes funcions inclouen dispositiu mòbil Android o Apple, servidor Citrix PVS, servidor RDP, passarel·la de correu, client VoIP, servidor de terminal, controlador de domini, etc. A continuació, supervisa contínuament el seu comportament per determinar quan es produeix un comportament arriscat o que amenaça la seguretat. Podeu identificar endevinar contrasenyes, atacs DDoS, fuites de dades, accés remot il·legal, activitat de codi maliciós, exploració de vulnerabilitats i altres amenaces. Per exemple, això és el que sembla detectar un intent d'accés remot des d'un país atípic per a la vostra organització (Corea del Sud) a un clúster de Kubernetes mitjançant SSH:

I així es veu la suposada filtració d'informació de la base de dades Postgress a un país amb el qual no hem trobat interacció anteriorment:

Finalment, aquest és el que semblen massa intents SSH fallits de la Xina i Indonèsia des d'un dispositiu remot extern:

O bé, suposeu que la instància del servidor de la VPC no ha de ser mai, per política, una destinació d'inici de sessió remota. Suposem, a més, que aquest ordinador ha experimentat un inici de sessió remot a causa d'un canvi erroni en la política de regles del tallafoc. La funció de modelització d'entitats detectarà i informarà d'aquesta activitat ("Accés remot inusual") gairebé en temps real i apuntarà a la trucada específica de l'API d'AWS CloudTrail, Azure Monitor o GCP Stackdriver Logging (incloent nom d'usuari, data i hora, entre altres detalls). ) que va provocar el canvi a la regla de l'ITU. I després aquesta informació es pot enviar a SIEM per a l'anàlisi.

S'implementen capacitats similars per a qualsevol entorn de núvol compatible amb Cisco Stealthwatch Cloud:

El modelatge d'entitats és una forma única d'automatització de la seguretat que pot descobrir un problema prèviament desconegut amb la vostra gent, processos o tecnologia. Per exemple, permet detectar, entre altres coses, problemes de seguretat com ara:

Algú ha descobert una porta posterior al programari que utilitzem?
Hi ha algun programari o dispositiu de tercers al nostre núvol?
L'usuari autoritzat està abusant dels privilegis?
Hi va haver un error de configuració que va permetre l'accés remot o un altre ús no desitjat dels recursos?
Hi ha una fuga de dades dels nostres servidors?
Algú estava intentant connectar-se amb nosaltres des d'una ubicació geogràfica atípica?
El nostre núvol està infectat amb codi maliciós?

Un esdeveniment de seguretat de la informació detectat es pot enviar en forma d'un bitllet corresponent a Slack, Cisco Spark, el sistema de gestió d'incidències PagerDuty, i també es pot enviar a diversos SIEM, inclosos Splunk o ELK. En resum, podem dir que si la vostra empresa utilitza una estratègia multinúvol i no es limita a cap proveïdor de núvols, les capacitats de monitorització de seguretat de la informació descrites anteriorment, utilitzar Cisco Stealthwatch Cloud és una bona opció per obtenir un conjunt unificat de monitorització. capacitats per als principals jugadors del núvol: Amazon, Microsoft i Google. El més interessant és que si comparem els preus de Stealthwatch Cloud amb les llicències avançades de monitorització de seguretat de la informació a AWS, Azure o GCP, pot resultar que la solució de Cisco serà fins i tot més barata que les capacitats integrades d'Amazon, Microsoft. i solucions de Google. És paradoxal, però és cert. I com més núvols i les seves capacitats utilitzeu, més evident serà l'avantatge d'una solució consolidada.

A més, Stealthwatch Cloud pot supervisar núvols privats desplegats a la vostra organització, per exemple, basant-se en contenidors Kubernetes o supervisant els fluxos de Netflow o el trànsit de xarxa rebut mitjançant la duplicació en equips de xarxa (fins i tot produïts a nivell nacional), dades AD o servidors DNS, etc. Totes aquestes dades s'enriquiran amb informació d'intel·ligència d'amenaces recollida per Cisco Talos, el grup no governamental més gran del món d'investigadors d'amenaces a la ciberseguretat.

Això us permet implementar un sistema de monitorització unificat tant per als núvols públics com híbrids que la vostra empresa pugui utilitzar. La informació recollida es pot analitzar mitjançant les capacitats integrades de Stealthwatch Cloud o enviar-la al vostre SIEM (Splunk, ELK, SumoLogic i diversos altres són compatibles de manera predeterminada).

Amb això, completarem la primera part de l'article, en la qual vaig repassar les eines integrades i externes per al seguiment de la seguretat de la informació de les plataformes IaaS/PaaS, que ens permeten detectar i respondre ràpidament a les incidències que es produeixen en els entorns del núvol que la nostra empresa ha escollit. A la segona part, continuarem amb el tema i veurem les opcions de monitorització de plataformes SaaS utilitzant l'exemple de Salesforce i Dropbox, i també intentarem resumir-ho tot creant un sistema de control de la seguretat de la informació unificat per a diferents proveïdors de núvol.

Font: www.habr.com

Monitorització de la seguretat al núvol