🥇Vixilancia da seguridade na nube

Mover datos e aplicacións á nube presenta un novo desafío para os SOC corporativos, que non sempre están preparados para supervisar a infraestrutura doutras persoas. Segundo Netoskope, a empresa media (aparentemente en Estados Unidos) usa 1246 servizos na nube diferentes, o que supón un 22% máis que hai un ano. 1246 servizos na nube!!! 175 deles están relacionados con servizos de RRHH, 170 están relacionados con mercadotecnia, 110 son no ámbito das comunicacións e 76 son en finanzas e CRM. Cisco usa "só" 700 servizos de nube externos. Entón estou un pouco confuso con estes números. Pero, en calquera caso, o problema non está neles, senón no feito de que a nube comeza a ser utilizada de forma bastante activa por un número cada vez maior de empresas que desexan ter as mesmas capacidades de vixilancia da infraestrutura na nube que na súa propia rede. E esta tendencia está crecendo - segundo segundo a Cámara de Contas Americana Para 2023, 1200 centros de datos estarán pechados nos Estados Unidos (6250 xa pecharon). Pero a transición á nube non é só "movemos os nosos servidores a un provedor externo". Nova arquitectura informática, novo software, novos procesos, novas restricións... Todo isto trae importantes cambios no traballo non só da informática, senón tamén da seguridade da información. E se os provedores aprenderon a facer fronte dalgunha maneira a garantir a seguridade da propia nube (afortunadamente hai moitas recomendacións), entón coa vixilancia da seguridade da información na nube, especialmente nas plataformas SaaS, hai importantes dificultades, das que falaremos.

Digamos que a túa empresa trasladou parte da súa infraestrutura á nube... Pare. Non deste xeito. Se a infraestrutura foi transferida, e só agora estás a pensar en como a supervisarás, entón xa perdiches. A non ser que sexa Amazon, Google ou Microsoft (e despois con reservas), probablemente non teña moita capacidade para supervisar os seus datos e aplicacións. É bo se tes a oportunidade de traballar con rexistros. Ás veces, os datos de eventos de seguranza estarán dispoñibles, pero non terás acceso a eles. Por exemplo, Office 365. Se tes a licenza E1 máis barata, os eventos de seguridade non están dispoñibles para ti. Se tes unha licenza E3, os teus datos gárdanse só durante 90 días, e só se tes unha licenza E5, a duración dos rexistros está dispoñible durante un ano (non obstante, isto tamén ten os seus propios matices relacionados coa necesidade de solicitar unha serie de funcións para traballar con rexistros do soporte de Microsoft). Por certo, a licenza E3 é moito máis débil en termos de funcións de seguimento que o Exchange corporativo. Para acadar o mesmo nivel, necesitas unha licenza E5 ou unha licenza de conformidade avanzada adicional, que pode requirir diñeiro adicional que non se incluíu no teu modelo financeiro para pasar á infraestrutura na nube. E este é só un exemplo de subestimación dos problemas relacionados coa vixilancia da seguridade da información na nube. Neste artigo, sen pretender ser completo, quero chamar a atención sobre algúns matices que se deben ter en conta á hora de elixir un provedor de nube dende o punto de vista da seguridade. E ao final do artigo entregarase unha lista de verificación que paga a pena completar antes de considerar que se resolveu o tema da vixilancia da seguridade da información na nube.

Existen varios problemas típicos que dan lugar a incidentes en contornas de nube, aos que os servizos de seguridade da información non teñen tempo para responder ou non os ven en absoluto:

Os rexistros de seguridade non existen. Esta é unha situación bastante común, especialmente entre os xogadores novatos no mercado de solucións na nube. Pero non debes renunciar a eles de inmediato. Os pequenos xogadores, especialmente os domésticos, son máis sensibles aos requisitos dos clientes e poden implementar rapidamente algunhas funcións necesarias cambiando a folla de ruta aprobada para os seus produtos. Si, este non será un análogo de GuardDuty de Amazon ou o módulo "Proactive Protection" de Bitrix, pero polo menos algo.
A seguridade da información non sabe onde se almacenan os rexistros ou non hai acceso a eles. Aquí é necesario entrar en negociacións co fornecedor de servizos na nube - quizais el proporcione esa información se considera que o cliente é importante para el. Pero, en xeral, non é moi bo cando o acceso aos rexistros se proporciona "por decisión especial".
Tamén ocorre que o provedor da nube ten rexistros, pero proporcionan un seguimento e rexistro de eventos limitados, que non son suficientes para detectar todas as incidencias. Por exemplo, só pode recibir rexistros de cambios nun sitio web ou rexistros de intentos de autenticación de usuarios, pero non outros eventos, como o tráfico de rede, que lle ocultarán toda unha capa de eventos que caracterizan os intentos de piratear a súa infraestrutura na nube.
Hai rexistros, pero o acceso a eles é difícil de automatizar, o que obriga a supervisalos non de forma continua, senón de forma programada. E se non pode descargar rexistros automaticamente, entón a descarga de rexistros, por exemplo, en formato Excel (como ocorre con varios provedores de solucións na nube nacionais), pode incluso provocar unha reticencia por parte do servizo de seguridade da información corporativa a xogar con eles.
Sen seguimento do rexistro. Esta é quizais a razón máis pouco clara para a aparición de incidentes de seguridade da información en ambientes de nube. Parece que hai rexistros, e é posible automatizar o acceso a eles, pero ninguén o fai. Por que?

Concepto de seguridade na nube compartida

A transición á nube é sempre unha procura dun equilibrio entre o desexo de manter o control sobre a infraestrutura e trasladalo ás mans máis profesionais dun provedor de nube especializado en mantelo. E no ámbito da seguridade na nube, tamén hai que buscar ese equilibrio. Ademais, dependendo do modelo de prestación de servizos na nube utilizado (IaaS, PaaS, SaaS), este saldo será diferente todo o tempo. En calquera caso, hai que lembrar que todos os provedores de nube hoxe seguen o denominado modelo de responsabilidade compartida e seguridade da información compartida. A nube é responsable dunhas cousas, e doutras é o cliente, colocando os seus datos, as súas aplicacións, as súas máquinas virtuais e outros recursos na nube. Sería imprudente esperar que ao ir á nube, trasladaremos toda a responsabilidade ao provedor. Pero tampouco é prudente crear toda a seguridade por ti mesmo cando te mudes á nube. É necesario un equilibrio, que dependerá de moitos factores: - estratexia de xestión de riscos, modelo de ameazas, mecanismos de seguridade dos que dispón o provedor da nube, lexislación, etc.

Por exemplo, a clasificación dos datos aloxados na nube é sempre responsabilidade do cliente. Un provedor de nube ou un provedor de servizos externo só pode axudarlle con ferramentas que lle axuden a marcar os datos na nube, identificar infraccións, eliminar datos que infrinxir a lei ou enmascarar mediante un método ou outro. Por outra banda, a seguridade física é sempre responsabilidade do provedor da nube, que non pode compartir cos clientes. Pero todo o que hai entre os datos e a infraestrutura física é precisamente o tema de discusión neste artigo. Por exemplo, a dispoñibilidade da nube é responsabilidade do provedor e a configuración das regras do firewall ou a habilitación do cifrado é responsabilidade do cliente. Neste artigo trataremos de analizar cales son os mecanismos de vixilancia da seguridade da información que ofrecen hoxe varios provedores de nube populares en Rusia, cales son as características do seu uso e cando paga a pena buscar solucións de superposición externas (por exemplo, Cisco E- Mail Security) que amplían as capacidades da túa nube en termos de ciberseguridade. Nalgúns casos, especialmente se está a seguir unha estratexia multinube, non terá máis remedio que utilizar solucións externas de vixilancia da seguridade da información en varios ambientes de nube á vez (por exemplo, Cisco CloudLock ou Cisco Stealthwatch Cloud). Ben, nalgúns casos darás conta de que o provedor de nube que elixiches (ou che impuxo) non ofrece ningunha capacidade de vixilancia da seguridade da información. Isto é desagradable, pero tampouco pouco, xa que permite avaliar adecuadamente o nivel de risco asociado ao traballo con esta nube.

Ciclo de vida de monitorización da seguridade na nube

Para supervisar a seguridade das nubes que utilizas, só tes tres opcións:

confía nas ferramentas proporcionadas polo teu provedor de nube,
utilizar solucións de terceiros que supervisarán as plataformas IaaS, PaaS ou SaaS que use,
crea a túa propia infraestrutura de monitorización na nube (só para plataformas IaaS/PaaS).

Vexamos que características ten cada unha destas opcións. Pero primeiro, necesitamos comprender o marco xeral que se utilizará ao supervisar as plataformas na nube. Destacaría 6 compoñentes principais do proceso de vixilancia da seguridade da información na nube:

Preparación de infraestruturas. Determinación das aplicacións e infraestruturas necesarias para a recollida de eventos importantes para a seguridade da información no almacenamento.
Colección. Nesta fase, os eventos de seguridade son agregados de varias fontes para a súa posterior transmisión para procesamento, almacenamento e análise.
Tratamento. Nesta fase, os datos transfórmanse e enriquecen para facilitar a posterior análise.
Almacenamento. Este compoñente é responsable do almacenamento a curto e longo prazo dos datos procesados e en bruto recollidos.
Análise. Nesta fase, ten a capacidade de detectar incidentes e responder a eles de forma automática ou manual.
Informes. Esta etapa axuda a formular indicadores clave para as partes interesadas (dirección, auditores, provedor de nube, clientes, etc.) que nos axuden a tomar determinadas decisións, por exemplo, cambiar de provedor ou reforzar a seguridade da información.

A comprensión destes compoñentes permitirache decidir rapidamente no futuro o que podes tomar do teu provedor e o que terás que facer ti mesmo ou coa participación de consultores externos.

Servizos na nube integrados

Xa escribín anteriormente que moitos servizos na nube hoxe en día non ofrecen ningunha capacidade de vixilancia da seguridade da información. En xeral, non prestan moita atención ao tema da seguridade da información. Por exemplo, un dos populares servizos rusos para enviar informes a axencias gobernamentais a través de Internet (non vou mencionar especificamente o seu nome). Todo o apartado sobre a seguridade deste servizo xira arredor do uso de certificados CIPF. A sección de seguridade da información doutro servizo doméstico na nube para a xestión de documentos electrónicos non é diferente. Fálase de certificados de chave pública, criptografía certificada, eliminación de vulnerabilidades web, protección contra ataques DDoS, uso de cortalumes, copias de seguridade e mesmo auditorías periódicas de seguridade da información. Pero non hai unha palabra sobre a vixilancia, nin sobre a posibilidade de acceder a eventos de seguridade da información que poidan ser de interese para os clientes deste provedor de servizos.

En xeral, pola forma en que o fornecedor da nube describe os problemas de seguridade da información no seu sitio web e na súa documentación, podes comprender o serio que toma este problema. Por exemplo, se le os manuais dos produtos "My Office", non hai unha palabra sobre seguridade, pero na documentación do produto separado "My Office. KS3”, deseñado para protexer contra accesos non autorizados, hai unha lista habitual de puntos da orde 17 do FSTEC, que implementa “My Office.KS3”, pero non se describe como o implementa e, o máis importante, como integrar estes mecanismos coa seguridade da información corporativa. Quizais exista esa documentación, pero non a atopei no dominio público, no sitio web "A miña oficina". Aínda que quizais non teña acceso a esta información secreta?...

Para Bitrix, a situación é moito mellor. A documentación describe os formatos dos rexistros de eventos e, curiosamente, o rexistro de intrusións, que contén eventos relacionados con potenciais ameazas para a plataforma na nube. Desde alí podes sacar a IP, o nome do usuario ou convidado, a orixe do evento, a hora, o axente de usuario, o tipo de evento, etc. É certo que podes traballar con estes eventos dende o panel de control da propia nube ou cargar datos en formato MS Excel. Agora é difícil automatizar o traballo cos rexistros de Bitrix e terás que facer parte do traballo manualmente (cargando o informe e cargándoo no teu SIEM). Pero se lembramos que ata hai pouco tempo non existía tal oportunidade, entón este é un gran progreso. Ao mesmo tempo, gustaríame sinalar que moitos provedores estranxeiros de nube ofrecen unha funcionalidade similar "para principiantes": mira os rexistros cos teus ollos a través do panel de control ou carga os datos a ti mesmo (non obstante, a maioría carga datos en . csv, non Excel).

Sen ter en conta a opción sen rexistros, os provedores de nube adoitan ofrecerche tres opcións para supervisar eventos de seguridade: paneis, carga de datos e acceso á API. O primeiro parece resolver moitos problemas para ti, pero isto non é totalmente certo: se tes varias revistas, tes que cambiar entre as pantallas que as amosan, perdendo a imaxe xeral. Ademais, é improbable que o provedor da nube che ofreza a capacidade de correlacionar eventos de seguridade e, en xeral, analizalos desde o punto de vista da seguridade (normalmente estás a tratar con datos brutos, que debes entender ti mesmo). Hai excepcións e falaremos delas máis adiante. Por último, paga a pena preguntar que eventos rexistra o teu provedor de nube, en que formato e como se corresponden co teu proceso de vixilancia da seguridade da información? Por exemplo, identificación e autenticación de usuarios e convidados. O mesmo Bitrix permítelle, en función destes eventos, rexistrar a data e a hora do evento, o nome do usuario ou convidado (se dispón do módulo "Análise web"), o obxecto ao que se accede e outros elementos típicos dun sitio web. . Pero os servizos de seguridade da información corporativa poden necesitar información sobre se o usuario accedeu á nube desde un dispositivo de confianza (por exemplo, nunha rede corporativa esta tarefa é implementada por Cisco ISE). Que pasa con unha tarefa tan sinxela como a función xeo-IP, que axudará a determinar se roubou unha conta de usuario do servizo na nube? E aínda que o fornecedor da nube, isto non é suficiente. O mesmo Cisco CloudLock non só analiza a xeolocalización, senón que utiliza a aprendizaxe automática para iso e analiza os datos históricos de cada usuario e supervisa varias anomalías nos intentos de identificación e autenticación. Só MS Azure ten unha funcionalidade similar (se tes a subscrición adecuada).

Hai outra dificultade: xa que para moitos provedores de nube a vixilancia da seguridade da información é un tema novo co que están empezando a tratar, están cambiando constantemente algo nas súas solucións. Hoxe teñen unha versión da API, mañá outra, pasadomañá unha terceira. Tamén debes estar preparado para iso. O mesmo ocorre coa funcionalidade, que pode cambiar, que debe ser tida en conta no seu sistema de vixilancia da seguridade da información. Por exemplo, Amazon inicialmente tiña servizos separados de seguimento de eventos na nube: AWS CloudTrail e AWS CloudWatch. Entón apareceu un servizo separado para supervisar eventos de seguridade da información: AWS GuardDuty. Despois dun tempo, Amazon lanzou un novo sistema de xestión, Amazon Security Hub, que inclúe análise dos datos recibidos de GuardDuty, Amazon Inspector, Amazon Macie e varios outros. Outro exemplo é a ferramenta de integración de rexistros de Azure con SIEM - AzLog. Foi utilizado activamente por moitos provedores de SIEM, ata que en 2018 Microsoft anunciou o cese do seu desenvolvemento e soporte, o que enfrontou a moitos clientes que usaban esta ferramenta cun problema (falaremos de como se resolveu máis adiante).

Polo tanto, supervisa coidadosamente todas as funcións de vixilancia que che ofrece o teu provedor de nube. Ou confía en provedores de solucións externos que actuarán como intermediarios entre o teu SOC e a nube que queres supervisar. Si, será máis caro (aínda que non sempre), pero trasladarás toda a responsabilidade aos ombreiros doutra persoa. Ou non todo?... Lembremos o concepto de seguridade compartida e entendamos que non podemos cambiar nada; teremos que entender de forma independente como os diferentes provedores de nube proporcionan un seguimento da seguridade da información dos teus datos, aplicacións, máquinas virtuais e outros recursos. aloxado na nube. E comezaremos co que Amazon ofrece nesta parte.

Exemplo: seguimento da seguridade da información en IaaS baseado en AWS

Si, si, entendo que Amazon non é o mellor exemplo debido a que se trata dun servizo estadounidense e pode ser bloqueado como parte da loita contra o extremismo e a difusión de información prohibida en Rusia. Pero nesta publicación gustaríame mostrar como se diferencian as diferentes plataformas na nube nas súas capacidades de vixilancia da seguridade da información e a que debes prestar atención ao transferir os teus procesos clave ás nubes desde o punto de vista da seguridade. Ben, se algúns dos desenvolvedores rusos de solucións na nube aprenden algo útil por si mesmos, iso será xenial.

O primeiro que hai que dicir é que Amazon non é unha fortaleza impenetrable. Varios incidentes ocorren regularmente aos seus clientes. Por exemplo, os nomes, enderezos, datas de nacemento e números de teléfono de 198 millóns de votantes foron roubados de Deep Root Analytics. A empresa israelí Nice Systems roubou 14 millóns de rexistros de subscritores de Verizon. Non obstante, as capacidades integradas de AWS permítenche detectar unha ampla gama de incidentes. Por exemplo:

impacto na infraestrutura (DDoS)
compromiso de nodo (inxección de comandos)
compromiso da conta e acceso non autorizado
configuración incorrecta e vulnerabilidades
interfaces e API inseguras.

Esta discrepancia débese a que, como descubrimos anteriormente, o propio cliente é responsable da seguridade dos datos do cliente. E se non se molestou en activar os mecanismos de protección e non acendeu ferramentas de vixilancia, entón só aprenderá sobre o incidente polos medios ou polos seus clientes.

Para identificar incidencias, pode utilizar unha ampla gama de servizos de vixilancia diferentes desenvolvidos por Amazon (aínda que estes adoitan ser complementados con ferramentas externas como osquery). Así, en AWS, todas as accións dos usuarios son monitorizadas, independentemente de como se realicen: a través da consola de xestión, liña de comandos, SDK ou outros servizos de AWS. Todos os rexistros da actividade de cada conta de AWS (incluído o nome de usuario, a acción, o servizo, os parámetros de actividade e o resultado) e o uso da API están dispoñibles a través de AWS CloudTrail. Podes ver estes eventos (como inicios de sesión na consola AWS IAM) desde a consola CloudTrail, analizalos mediante Amazon Athena ou "externalizalos" a solucións externas como Splunk, AlienVault, etc. Os propios rexistros de AWS CloudTrail colócanse no seu depósito de AWS S3.

Outros dous servizos de AWS proporcionan outras capacidades de vixilancia importantes. En primeiro lugar, Amazon CloudWatch é un servizo de monitorización de recursos e aplicacións de AWS que, entre outras cousas, permite identificar varias anomalías na túa nube. Todos os servizos de AWS integrados, como Amazon Elastic Compute Cloud (servidores), Amazon Relational Database Service (bases de datos), Amazon Elastic MapReduce (análise de datos) e outros 30 servizos de Amazon, usan Amazon CloudWatch para almacenar os seus rexistros. Os desenvolvedores poden usar a API aberta de Amazon CloudWatch para engadir a funcionalidade de seguimento de rexistros a aplicacións e servizos personalizados, o que lles permite ampliar o alcance da análise de eventos nun contexto de seguranza.

En segundo lugar, o servizo VPC Flow Logs permítelle analizar o tráfico de rede enviado ou recibido polos seus servidores AWS (externo ou interno), así como entre microservizos. Cando calquera dos seus recursos AWS VPC interactúa coa rede, os rexistros de fluxo de VPC rexistran detalles sobre o tráfico da rede, incluíndo a interface de rede de orixe e destino, así como os enderezos IP, os portos, o protocolo, o número de bytes e o número de paquetes que serra. Os que teñan experiencia coa seguridade da rede local recoñecerán isto como análogo aos fíos NetFlow, que se pode crear mediante interruptores, enrutadores e cortalumes de grao empresarial. Estes rexistros son importantes para o seguimento da seguridade da información porque, a diferenza dos eventos sobre as accións dos usuarios e aplicacións, tamén permiten non perder as interaccións de rede no contorno de nube privada virtual de AWS.

En resumo, estes tres servizos de AWS (AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs) en conxunto proporcionan unha visión bastante poderosa sobre o uso da túa conta, o comportamento do usuario, a xestión da infraestrutura, a actividade de aplicacións e servizos e a actividade da rede. Por exemplo, pódense utilizar para detectar as seguintes anomalías:

Intentos de escanear o sitio, buscar portas traseiras, buscar vulnerabilidades a través de ráfagas de "erros 404".
Ataques de inxección (por exemplo, inxección de SQL) mediante ráfagas de "500 erros".
As ferramentas de ataque coñecidas son sqlmap, nikto, w3af, nmap, etc. mediante a análise do campo User Agent.

Amazon Web Services tamén desenvolveu outros servizos con fins de ciberseguridade que che permiten resolver moitos outros problemas. Por exemplo, AWS ten un servizo integrado para auditar políticas e configuracións: AWS Config. Este servizo ofrece unha auditoría continua dos teus recursos de AWS e das súas configuracións. Poñamos un exemplo sinxelo: digamos que quere asegurarse de que os contrasinais de usuario están desactivados en todos os seus servidores e de que o acceso só é posible en función dos certificados. AWS Config facilita comprobar isto en todos os seus servidores. Hai outras políticas que se poden aplicar aos teus servidores na nube: "Ningún servidor pode usar o porto 22", "Só os administradores poden cambiar as regras do firewall" ou "Só o usuario Ivashko pode crear novas contas de usuario, e pode facelo só os martes. " No verán de 2016, o servizo AWS Config ampliouse para automatizar a detección de infraccións das políticas desenvolvidas. As regras de AWS Config son esencialmente solicitudes de configuración continuas para os servizos de Amazon que utilizas, que xeran eventos se se incumpren as políticas correspondentes. Por exemplo, en lugar de executar periodicamente consultas de AWS Config para verificar que todos os discos dun servidor virtual están cifrados, as regras de AWS Config pódense utilizar para comprobar continuamente os discos do servidor para garantir que se cumpra esta condición. E, o máis importante, no contexto desta publicación, calquera infracción xera eventos que poden ser analizados polo seu servizo de seguridade da información.

AWS tamén ten o seu equivalente ás solucións tradicionais de seguridade da información corporativa, que tamén xeran eventos de seguridade que pode e debe analizar:

Detección de intrusións - AWS GuardDuty
Control de fugas de información - AWS Macie
EDR (aínda que fala de puntos finais na nube de forma un pouco estraña) - AWS Cloudwatch + osquery de código aberto ou solucións GRR
Análise de Netflow: AWS Cloudwatch + AWS VPC Flow
Análise DNS - AWS Cloudwatch + AWS Route53
AD - Servizo de directorio de AWS
Xestión de contas - AWS IAM
SSO - AWS SSO
análise de seguridade - AWS Inspector
xestión de configuración - AWS Config
WAF - AWS WAF.

Non vou describir en detalle todos os servizos de Amazon que poden ser útiles no contexto da seguridade da información. O principal é entender que todos eles poden xerar eventos que podemos e debemos analizar no contexto da seguridade da información, utilizando para este fin tanto as capacidades integradas da propia Amazon como solucións externas, por exemplo, SIEM, que pode leva os eventos de seguridade ao teu centro de monitorización e analízaos alí xunto con eventos doutros servizos na nube ou de infraestrutura interna, perímetro ou dispositivos móbiles.

En calquera caso, todo comeza coas fontes de datos que che proporcionan eventos de seguridade da información. Estas fontes inclúen, pero non se limitan a:

CloudTrail: uso da API e accións do usuario
Trusted Advisor: comprobación de seguridade contra as mellores prácticas
Config - inventario e configuración de contas e axustes de servizo
Rexistros de fluxo de VPC: conexións a interfaces virtuais
IAM - servizo de identificación e autenticación
Rexistros de acceso ELB - Balanceador de carga
Inspector - vulnerabilidades das aplicacións
S3 - almacenamento de ficheiros
CloudWatch - Actividade da aplicación
SNS é un servizo de notificacións.

Amazon, aínda que ofrece tal variedade de fontes de eventos e ferramentas para a súa xeración, ten unha capacidade moi limitada para analizar os datos recollidos no contexto da seguridade da información. Terá que estudar de forma independente os rexistros dispoñibles, buscando indicadores relevantes de compromiso neles. AWS Security Hub, que Amazon lanzou recentemente, ten como obxectivo resolver este problema converténdose nunha nube SIEM para AWS. Pero ata agora só está no inicio da súa andaina e está limitado tanto polo número de fontes coas que traballa como por outras restricións establecidas pola arquitectura e subscricións da propia Amazon.

Exemplo: vixilancia da seguridade da información en IaaS baseado en Azure

Non quero entrar nun longo debate sobre cal dos tres provedores de nube (Amazon, Microsoft ou Google) é mellor (sobre todo porque cada un deles aínda ten as súas particularidades específicas e é axeitado para resolver os seus propios problemas); Centrémonos nas capacidades de vixilancia da seguridade da información que proporcionan estes xogadores. Hai que recoñecer que Amazon AWS foi un dos primeiros neste segmento e, polo tanto, foi o que máis avanzou en canto ás súas funcións de seguridade da información (aínda que moitos admiten que son de difícil utilización). Pero isto non significa que ignoraremos as oportunidades que Microsoft e Google nos brindan.

Os produtos de Microsoft sempre se distinguiron pola súa "apertura" e en Azure a situación é semellante. Por exemplo, se AWS e GCP sempre proceden do concepto de "o que non está permitido está prohibido", entón Azure ten o enfoque exactamente oposto. Por exemplo, ao crear unha rede virtual na nube e unha máquina virtual nela, todos os portos e protocolos están abertos e permitidos por defecto. Polo tanto, terás que gastar un pouco máis de esforzo na configuración inicial do sistema de control de acceso na nube de Microsoft. E isto tamén lle impón requisitos máis estritos en canto á actividade de seguimento na nube Azure.

AWS ten unha peculiaridade asociada ao feito de que cando supervisas os teus recursos virtuais, se están situados en diferentes rexións, tes dificultades para combinar todos os eventos e a súa análise unificada, para eliminar os que cómpre recorrer a varios trucos, como Crea o teu propio código para AWS Lambda que transportará eventos entre rexións. Azure non ten este problema: o seu mecanismo de rexistro de actividade rastrexa toda a actividade en toda a organización sen restricións. O mesmo aplícase a AWS Security Hub, que foi desenvolvido recentemente por Amazon para consolidar moitas funcións de seguridade nun único centro de seguridade, pero só dentro da súa rexión, que, con todo, non é relevante para Rusia. Azure ten o seu propio Centro de seguridade, que non está suxeito a restricións rexionais, que proporciona acceso a todas as funcións de seguridade da plataforma na nube. Ademais, para diferentes equipos locais pode proporcionar o seu propio conxunto de capacidades de protección, incluíndo eventos de seguridade xestionados por eles. AWS Security Hub aínda está camiño de ser similar ao Azure Security Center. Pero paga a pena engadir unha mosca ao ungüento: podes sacar de Azure moito do que se describiu anteriormente en AWS, pero só se fai máis conveniente para Azure AD, Azure Monitor e Azure Security Center. Todos os demais mecanismos de seguridade de Azure, incluída a análise de eventos de seguranza, aínda non se xestionan da forma máis conveniente. O problema resólvese en parte a API, que impregna todos os servizos de Microsoft Azure, pero isto requirirá un esforzo adicional para integrar a túa nube co teu SOC e a presenza de especialistas cualificados (de feito, como ocorre con calquera outro SIEM que traballe coa nube). API). Algúns SIEM, dos que se comentará máis adiante, xa son compatibles con Azure e poden automatizar a tarefa de supervisalo, pero tamén teñen as súas propias dificultades: non todos poden recoller todos os rexistros que ten Azure.

A recollida e seguimento de eventos en Azure realízase mediante o servizo Azure Monitor, que é a principal ferramenta para recoller, almacenar e analizar datos na nube de Microsoft e os seus recursos: repositorios Git, contedores, máquinas virtuais, aplicacións, etc. Todos os datos recollidos por Azure Monitor divídense en dúas categorías: métricas, recollidas en tempo real e que describen indicadores clave de rendemento da nube de Azure, e rexistros, que conteñen datos organizados en rexistros que caracterizan determinados aspectos da actividade dos recursos e servizos de Azure. Ademais, usando a API de recopilador de datos, o servizo Azure Monitor pode recoller datos de calquera fonte REST para crear os seus propios escenarios de vixilancia.

Aquí tes algunhas fontes de eventos de seguranza que che ofrece Azure e ás que podes acceder a través do Azure Portal, a CLI, a PowerShell ou a API REST (e algunhas só a través da API de Azure Monitor/Insight):

Rexistros de actividade: este rexistro responde ás preguntas clásicas de "quen", "que" e "cando" con respecto a calquera operación de escritura (PUT, POST, DELETE) nos recursos da nube. Os eventos relacionados co acceso de lectura (GET) non están incluídos neste rexistro, como moitos outros.
Rexistros de diagnóstico: contén datos sobre operacións cun recurso específico incluído na súa subscrición.
Informes de Azure AD: contén a actividade do usuario e a actividade do sistema relacionada coa xestión de grupos e usuarios.
Rexistro de eventos de Windows e Syslog de Linux: contén eventos de máquinas virtuais aloxadas na nube.
Métricas: contén telemetría sobre o rendemento e o estado de saúde dos teus servizos e recursos na nube. Medido cada minuto e almacenado. dentro de 30 días.
Rexistros de fluxo do grupo de seguridade da rede: contén datos sobre eventos de seguranza da rede recollidos mediante o servizo Network Watcher e a supervisión de recursos a nivel de rede.
Rexistros de almacenamento: contén eventos relacionados co acceso ás instalacións de almacenamento.

Para a supervisión, pode usar SIEM externos ou o Azure Monitor integrado e as súas extensións. Máis adiante falaremos dos sistemas de xestión de eventos de seguridade da información, pero de momento vexamos o que nos ofrece o propio Azure para a análise de datos no contexto da seguridade. A pantalla principal de todo o relacionado coa seguridade en Azure Monitor é o Log Analytics Security and Audit Dashboard (a versión gratuíta admite unha cantidade limitada de almacenamento de eventos durante só unha semana). Este panel divídese en 5 áreas principais que visualizan estatísticas resumidas do que está a suceder no contorno de nube que estás a usar:

Dominios de seguridade: indicadores cuantitativos clave relacionados coa seguridade da información: número de incidentes, número de nós comprometidos, nodos sen parchear, eventos de seguranza da rede, etc.
Problemas notables: mostra o número e a importancia dos problemas activos de seguridade da información
Deteccións: mostra patróns de ataques usados contra ti
Intelixencia de ameazas: mostra información xeográfica sobre nodos externos que te están atacando
Consultas de seguridade comúns: consultas típicas que che axudarán a controlar mellor a seguridade da túa información.

As extensións de Azure Monitor inclúen Azure Key Vault (protección de claves criptográficas na nube), Malware Assessment (análise da protección contra código malicioso en máquinas virtuais), Azure Application Gateway Analytics (análise, entre outras cousas, dos rexistros do firewall na nube), etc. . Estas ferramentas, enriquecidas con determinadas regras para procesar eventos, permiten visualizar diversos aspectos da actividade dos servizos na nube, incluída a seguridade, e identificar certas desviacións do funcionamento. Pero, como adoita suceder, calquera funcionalidade adicional require unha subscrición de pago correspondente, que requirirá dos investimentos financeiros correspondentes, que debes planificar con antelación.

Azure ten unha serie de capacidades integradas de vixilancia de ameazas que están integradas en Azure AD, Azure Monitor e Azure Security Center. Entre elas, por exemplo, a detección de interacción de máquinas virtuais con IPs maliciosas coñecidas (debido á presenza de integración con servizos Threat Intelligence de Microsoft), detección de malware na infraestrutura da nube mediante a recepción de alarmas de máquinas virtuais aloxadas na nube, contrasinal. adiviñando ataques ” en máquinas virtuais, vulnerabilidades na configuración do sistema de identificación de usuarios, inicio de sesión no sistema desde anonimizadores ou nodos infectados, filtracións de contas, inicio de sesión no sistema desde localizacións pouco habituais, etc. Azure é hoxe un dos poucos provedores de nube que che ofrece capacidades integradas de intelixencia de ameazas para enriquecer os eventos de seguridade da información recollida.

Como se mencionou anteriormente, a funcionalidade de seguridade e, en consecuencia, os eventos de seguridade xerados por ela non están dispoñibles para todos os usuarios por igual, pero requiren unha determinada subscrición que inclúa a funcionalidade que necesita, que xera os eventos axeitados para a vixilancia da seguridade da información. Por exemplo, algunhas das funcións descritas no parágrafo anterior para supervisar anomalías nas contas só están dispoñibles na licenza premium P2 para o servizo Azure AD. Sen el, vostede, como no caso de AWS, terá que analizar "manualmente" os eventos de seguridade recollidos. E, ademais, dependendo do tipo de licenza de Azure AD, non todos os eventos estarán dispoñibles para a análise.

No portal de Azure, pode xestionar consultas de busca de rexistros de interese para vostede e configurar paneis para visualizar os indicadores clave de seguridade da información. Ademais, alí pode seleccionar as extensións de Azure Monitor, que permiten ampliar a funcionalidade dos rexistros de Azure Monitor e obter unha análise máis profunda dos eventos desde o punto de vista da seguridade.

Se necesitas non só a capacidade de traballar con rexistros, senón un centro de seguridade completo para a túa plataforma na nube Azure, incluída a xestión da política de seguridade da información, podes falar sobre a necesidade de traballar con Azure Security Center, a maioría das funcións útiles das cales están dispoñibles por algún diñeiro, por exemplo, detección de ameazas, seguimento fóra de Azure, avaliación do cumprimento, etc. (na versión gratuíta, só tes acceso a unha avaliación de seguridade e recomendacións para eliminar os problemas identificados). Consolida todos os problemas de seguridade nun só lugar. De feito, podemos falar dun nivel de seguridade da información superior ao que che proporciona Azure Monitor, xa que neste caso os datos recollidos en toda a túa factoría na nube enriquécense mediante moitas fontes, como Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) e Microsoft Security Response Center (MSRC), nos que se superpoñen varios sofisticados algoritmos de aprendizaxe automática e de análise de comportamento, que deberían, en definitiva, mellorar a eficiencia de detección e resposta ás ameazas. .

Azure tamén ten o seu propio SIEM: apareceu a principios de 2019. Trátase de Azure Sentinel, que depende dos datos de Azure Monitor e que tamén se pode integrar. solucións de seguridade externas (por exemplo, NGFW ou WAF), cuxa lista está en constante crecemento. Ademais, a través da integración da API de seguridade de Microsoft Graph, tes a posibilidade de conectar as túas propias fontes de Threat Intelligence a Sentinel, o que enriquece as capacidades para analizar incidentes na túa nube Azure. Pódese argumentar que Azure Sentinel é o primeiro SIEM "nativo" que apareceu dos provedores de nube (os mesmos Splunk ou ELK, que poden aloxarse na nube, por exemplo, AWS, aínda non están desenvolvidos polos provedores de servizos na nube tradicionais). Azure Sentinel and Security Center podería chamarse SOC para a nube Azure e podería limitarse a eles (con certas reservas) se xa non tivese ningunha infraestrutura e transferise todos os seus recursos informáticos á nube e sería a nube de Microsoft Azure.

Pero dado que as capacidades integradas de Azure (aínda que teñas unha subscrición a Sentinel) moitas veces non son suficientes para supervisar a seguridade da información e integrar este proceso con outras fontes de eventos de seguridade (tanto na nube como internas), existe unha necesario exportar os datos recollidos a sistemas externos, aos que pode incluír SIEM. Isto faise tanto mediante a API como con extensións especiais, que actualmente só están dispoñibles oficialmente para os seguintes SIEM: Splunk (Azure Monitor Add-On para Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight e ELK. Ata hai pouco, había máis SIEM deste tipo, pero a partir do 1 de xuño de 2019, Microsoft deixou de apoiar a ferramenta de integración de rexistros de Azure (AzLog), que nos albores da existencia de Azure e a falta dunha normalización normal do traballo con rexistros (Azure). Monitor aínda non existía) facilitou a integración de SIEM externo coa nube de Microsoft. Agora a situación cambiou e Microsoft recomenda a plataforma Azure Event Hub como principal ferramenta de integración para outros SIEM. Moitos xa implementaron esa integración, pero teña coidado: poden non capturar todos os rexistros de Azure, senón só algúns (busque na documentación do seu SIEM).

Concluíndo unha breve excursión a Azure, gustaríame dar unha recomendación xeral sobre este servizo na nube: antes de dicir nada sobre as funcións de vixilancia da seguridade da información en Azure, debes configuralas con moito coidado e probar que funcionan tal e como está escrito na documentación e como lle dixeron os consultores a Microsoft (e poden ter diferentes puntos de vista sobre a funcionalidade das funcións de Azure). Se tes os recursos financeiros, podes extraer moita información útil de Azure en canto á vixilancia da seguridade da información. Se os teus recursos son limitados, entón, como no caso de AWS, terás que confiar só nas túas propias forzas e nos datos brutos que che proporciona Azure Monitor. E recorda que moitas funcións de seguimento custan cartos e é mellor familiarizarse coa política de prezos con antelación. Por exemplo, de forma gratuíta, podes almacenar 31 días de datos ata un máximo de 5 GB por cliente; para superar estes valores, esixe que desembolsar diñeiro adicional (aproximadamente 2 $ máis por almacenar cada GB adicional do cliente e 0,1 $ para almacenando 1 GB cada mes adicional). Traballar coa telemetría e as métricas das aplicacións tamén pode requirir fondos adicionais, así como traballar con alertas e notificacións (un determinado límite está dispoñible de xeito gratuíto, que pode non ser suficiente para as túas necesidades).

Exemplo: seguimento da seguridade da información en IaaS baseado en Google Cloud Platform

Google Cloud Platform parece un novo en comparación con AWS e Azure, pero isto é en parte bo. A diferenza de AWS, que aumentou as súas capacidades, incluídas as de seguridade, paulatinamente, tendo problemas de centralización; GCP, como Azure, xestionase moito mellor de forma centralizada, o que reduce os erros e o tempo de implementación en toda a empresa. Desde o punto de vista da seguridade, GCP está, curiosamente, entre AWS e Azure. Tamén ten unha única inscrición no evento para toda a organización, pero está incompleta. Algunhas funcións aínda están en modo beta, pero aos poucos esta deficiencia debería ser eliminada e GCP converterase nunha plataforma máis madura en canto á vixilancia da seguridade da información.

A principal ferramenta para rexistrar eventos en GCP é Stackdriver Logging (similar a Azure Monitor), que che permite recoller eventos en toda a túa infraestrutura na nube (así como desde AWS). Desde unha perspectiva de seguranza en GCP, cada organización, proxecto ou cartafol ten catro rexistros:

Actividade do administrador: contén todos os eventos relacionados co acceso administrativo, por exemplo, a creación dunha máquina virtual, o cambio de dereitos de acceso, etc. Este rexistro sempre está escrito, independentemente do seu desexo, e almacena os seus datos durante 400 días.
Acceso a datos: contén todos os eventos relacionados co traballo con datos por parte dos usuarios da nube (creación, modificación, lectura, etc.). Por defecto, este rexistro non está escrito, xa que o seu volume aumenta moi rapidamente. Por este motivo, a súa vida útil é de só 30 días. Ademais, non todo está escrito nesta revista. Por exemplo, os eventos relacionados con recursos que son accesibles publicamente para todos os usuarios ou aos que se poden acceder sen iniciar sesión en GCP non se escriben nel.
Evento do sistema: contén eventos do sistema non relacionados cos usuarios ou accións dun administrador que cambia a configuración dos recursos da nube. Sempre está escrito e almacenado durante 400 días.
A transparencia de acceso é un exemplo único de rexistro que recolle todas as accións dos empregados de Google (pero aínda non para todos os servizos de GCP) que acceden á túa infraestrutura como parte das súas funcións laborais. Este rexistro gárdase durante 400 días e non está dispoñible para todos os clientes de GCP, pero só se se cumpren unha serie de condicións (soporte de nivel Gold ou Platinum, ou presenza de 4 roles dun determinado tipo como parte do soporte corporativo). Unha función similar tamén está dispoñible, por exemplo, en Office 365 - Lockbox.

Exemplo de rexistro: Transparencia de acceso

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

O acceso a estes rexistros é posible de varias maneiras (do mesmo xeito que se comentaron anteriormente en Azure e AWS): a través da interface Log Viewer, a través da API, a través do SDK de Google Cloud ou a través da páxina Actividade do proxecto para o que están interesados en eventos. Do mesmo xeito, pódense exportar a solucións externas para unha análise adicional. Isto último realízase exportando rexistros a BigQuery ou ao almacenamento Cloud Pub/Sub.

Ademais de Stackdriver Logging, a plataforma GCP tamén ofrece a funcionalidade de monitorización de Stackdriver, que permite supervisar as métricas clave (rendemento, MTBF, saúde xeral, etc.) dos servizos e aplicacións na nube. Os datos procesados e visualizados poden facilitar a localización de problemas na túa infraestrutura na nube, incluso no contexto da seguridade. Pero hai que ter en conta que esta funcionalidade non será moi rica no contexto da seguridade da información, xa que hoxe GCP non ten un análogo do mesmo AWS GuardDuty e non pode identificar os malos entre todos os eventos rexistrados (Google desenvolveu Event Threat Detection, pero aínda está en desenvolvemento en versión beta e é demasiado cedo para falar da súa utilidade). Stackdriver Monitoring podería utilizarse como un sistema para detectar anomalías, que despois serían investigadas para atopar as causas da súa aparición. Pero dada a falta de persoal cualificado no ámbito da seguridade da información GCP no mercado, esta tarefa parece difícil actualmente.

Tamén paga a pena dar unha lista dalgúns módulos de seguridade da información que se poden usar na túa nube GCP e que son similares aos que ofrece AWS:

Cloud Security Command Center é un análogo de AWS Security Hub e Azure Security Center.
Cloud DLP: descubrimento e edición automáticas (por exemplo, enmascaramento) de datos aloxados na nube mediante máis de 90 políticas de clasificación predefinidas.
Cloud Scanner é un escáner de vulnerabilidades coñecidas (XSS, Flash Injection, bibliotecas sen parches, etc.) en App Engine, Compute Engine e Google Kubernetes.
Cloud IAM: controla o acceso a todos os recursos de GCP.
Cloud Identity: xestiona as contas de usuarios, dispositivos e aplicacións de GCP desde unha única consola.
Cloud HSM: protección de claves criptográficas.
Cloud Key Management Service: xestión de claves criptográficas en GCP.
Control do servizo VPC: crea un perímetro seguro ao redor dos teus recursos GCP para protexelos de fugas.
Chave de seguranza Titan: protección contra phishing.

Moitos destes módulos xeran eventos de seguranza que se poden enviar ao almacenamento de BigQuery para a súa análise ou exportación a outros sistemas, incluído SIEM. Como se mencionou anteriormente, GCP é unha plataforma en desenvolvemento activo e Google está a desenvolver unha serie de novos módulos de seguridade da información para a súa plataforma. Entre elas están Event Threat Detection (agora dispoñible en versión beta), que analiza os rexistros de Stackdriver en busca de rastros de actividade non autorizada (análoga a GuardDuty en AWS) ou Policy Intelligence (dispoñible en versión alfa), que che permitirá desenvolver políticas intelixentes para acceso aos recursos de GCP.

Fixen unha breve visión xeral das capacidades de monitorización integradas nas plataformas de nube populares. Pero tes especialistas que sexan capaces de traballar con rexistros de provedores de IaaS "en bruto" (non todos están preparados para comprar as capacidades avanzadas de AWS ou Azure ou Google)? Ademais, moitos están familiarizados co adagio "confía, pero verifica", que é máis certo que nunca no ámbito da seguridade. Canto confías nas capacidades integradas do provedor de nube que che envían eventos de seguridade da información? Canto se centran na seguridade da información?

Ás veces paga a pena buscar solucións de monitorización de infraestruturas de nube superpostas que poidan complementar a seguridade integrada na nube e, ás veces, tales solucións son a única opción para obter información sobre a seguridade dos teus datos e aplicacións aloxadas na nube. Ademais, son simplemente máis cómodos, xa que asumen todas as tarefas de análise dos rexistros necesarios xerados por diferentes servizos na nube de diferentes provedores de nube. Un exemplo desta solución de superposición é Cisco Stealthwatch Cloud, que se centra nunha única tarefa: supervisar as anomalías de seguridade da información en ambientes de nube, incluíndo non só Amazon AWS, Microsoft Azure e Google Cloud Platform, senón tamén nubes privadas.

Exemplo: Monitorización da seguridade da información mediante Stealthwatch Cloud

AWS ofrece unha plataforma informática flexible, pero esta flexibilidade facilita ás empresas cometer erros que provocan problemas de seguridade. E o modelo de seguridade da información compartida só contribúe a iso. Execución de software na nube con vulnerabilidades descoñecidas (as coñecidas pódense combater, por exemplo, mediante AWS Inspector ou GCP Cloud Scanner), contrasinais débiles, configuracións incorrectas, insiders, etc. E todo isto reflíctese no comportamento dos recursos da nube, que poden ser monitorizados por Cisco Stealthwatch Cloud, que é un sistema de monitorización da seguridade da información e detección de ataques. nubes públicas e privadas.

Unha das características fundamentais de Cisco Stealthwatch Cloud é a capacidade de modelar entidades. Con el, podes crear un modelo de software (é dicir, unha simulación case en tempo real) de cada un dos teus recursos na nube (non importa se é AWS, Azure, GCP ou outra cousa). Estes poden incluír servidores e usuarios, así como tipos de recursos específicos para o seu contorno de nube, como grupos de seguridade e grupos de escala automática. Estes modelos usan fluxos de datos estruturados proporcionados polos servizos na nube como entrada. Por exemplo, para AWS estes serían VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. O modelado de entidades descobre automaticamente o papel e o comportamento de calquera dos teus recursos (podes falar de perfilar toda a actividade na nube). Estes roles inclúen dispositivos móbiles Android ou Apple, servidor Citrix PVS, servidor RDP, pasarela de correo, cliente VoIP, servidor de terminal, controlador de dominio, etc. A continuación, supervisa continuamente o seu comportamento para determinar cando se produce un comportamento de risco ou ameaza para a seguridade. Podes identificar adiviñar contrasinais, ataques DDoS, fugas de datos, acceso remoto ilegal, actividade de código malicioso, exploración de vulnerabilidades e outras ameazas. Por exemplo, isto é o que parece detectar un intento de acceso remoto desde un país atípico para a súa organización (Corea do Sur) a un clúster de Kubernetes mediante SSH:

E así se ve a suposta filtración de información da base de datos Postgress a un país co que non atopamos interacción anteriormente:

Finalmente, isto é o que parecen moitos intentos SSH fallidos de China e Indonesia desde un dispositivo remoto externo:

Ou, supoña que a instancia do servidor no VPC, por política, nunca será un destino de inicio de sesión remoto. Supoñamos ademais que este ordenador experimentou un inicio de sesión remoto debido a un cambio erróneo na política de regras do firewall. A función de modelado de entidades detectará e informará desta actividade ("Acceso remoto inusual") case en tempo real e apuntará á chamada á API específica de AWS CloudTrail, Azure Monitor ou GCP Stackdriver Logging (incluíndo nome de usuario, data e hora, entre outros detalles). ). o que provocou o cambio da regra da ITU. E entón esta información pódese enviar a SIEM para a súa análise.

Impléntanse capacidades similares para calquera ambiente de nube compatible con Cisco Stealthwatch Cloud:

O modelado de entidades é unha forma única de automatización de seguridade que pode descubrir un problema previamente descoñecido coas túas persoas, procesos ou tecnoloxía. Por exemplo, permite detectar, entre outras cousas, problemas de seguridade como:

Alguén descubriu unha porta traseira no software que usamos?
Hai algún software ou dispositivo de terceiros na nosa nube?
O usuario autorizado está a abusar dos privilexios?
Houbo un erro de configuración que permitiu o acceso remoto ou outro uso non desexado dos recursos?
Hai algunha fuga de datos dos nosos servidores?
Alguén estaba tentando conectar connosco desde unha localización xeográfica atípica?
A nosa nube está infectada con código malicioso?

Pódese enviar un evento de seguridade da información detectado en forma de ticket correspondente a Slack, Cisco Spark, o sistema de xestión de incidentes PagerDuty e tamén enviarse a varios SIEM, incluído Splunk ou ELK. Para resumir, podemos dicir que se a súa empresa usa unha estratexia multi-nube e non se limita a ningún provedor de nube, as capacidades de supervisión da seguridade da información descritas anteriormente, entón usar Cisco Stealthwatch Cloud é unha boa opción para obter un conxunto unificado de supervisión. capacidades para os principais xogadores na nube: Amazon, Microsoft e Google. O máis interesante é que se comparas os prezos de Stealthwatch Cloud con licenzas avanzadas para a vixilancia da seguridade da información en AWS, Azure ou GCP, pode resultar que a solución de Cisco será aínda máis barata que as capacidades integradas de Amazon, Microsoft. e solucións de Google. É paradoxal, pero é certo. E cantas máis nubes e as súas capacidades uses, máis evidente será a vantaxe dunha solución consolidada.

Ademais, Stealthwatch Cloud pode supervisar as nubes privadas despregadas na túa organización, por exemplo, baseándose en contedores de Kubernetes ou supervisando os fluxos de Netflow ou o tráfico de rede recibido a través da duplicación en equipos de rede (mesmo de produción nacional), datos AD ou servidores DNS, etc. Todos estes datos enriqueceranse coa información de Threat Intelligence recollida por Cisco Talos, o grupo non gobernamental máis grande do mundo de investigadores de ameazas de ciberseguridade.

Isto permítelle implementar un sistema de vixilancia unificado tanto para nubes públicas como híbridas que a súa empresa poida utilizar. A información recollida pódese analizar mediante as capacidades integradas de Stealthwatch Cloud ou enviarse ao seu SIEM (Splunk, ELK, SumoLogic e varios outros son compatibles por defecto).

Con isto, completaremos a primeira parte do artigo, na que repasei as ferramentas integradas e externas para o seguimento da seguridade da información das plataformas IaaS/PaaS, que nos permiten detectar e responder rapidamente ás incidencias que se producen nos contornos de nube que a nosa empresa escolleu. Na segunda parte, continuaremos co tema e analizaremos as opcións para supervisar as plataformas SaaS co exemplo de Salesforce e Dropbox, e tamén tentaremos resumir e xuntar todo creando un sistema unificado de vixilancia da seguridade da información para diferentes provedores de nube.

Fonte: www.habr.com

Monitorización da seguridade na nube