🥇Monitoreo de seguridad en la nube

Mover datos y aplicaciones a la nube presenta un nuevo desafío para los SOC corporativos, que no siempre están listos para monitorear la infraestructura de otras personas. Según Netoskope, la empresa promedio (aparentemente en EE. UU.) utiliza 1246 servicios en la nube diferentes, un 22% más que hace un año. 1246 servicios en la nube!!! 175 de ellos están relacionados con servicios de RRHH, 170 están relacionados con marketing, 110 están en el ámbito de la comunicación y 76 están relacionados con finanzas y CRM. Cisco utiliza “sólo” 700 servicios de nube externos. Así que estoy un poco confundido con estos números. Pero en cualquier caso, el problema no está en ellos, sino en el hecho de que la nube está empezando a ser utilizada de forma bastante activa por un número cada vez mayor de empresas que quisieran tener las mismas capacidades para monitorear la infraestructura de la nube que en su propia red. Y esta tendencia va en aumento - según según la Cámara de Cuentas Americana Para 2023, se cerrarán 1200 centros de datos en Estados Unidos (ya han cerrado 6250). Pero la transición a la nube no consiste simplemente en “mover nuestros servidores a un proveedor externo”. Nueva arquitectura de TI, nuevo software, nuevos procesos, nuevas restricciones... Todo esto trae cambios significativos no solo en el trabajo de TI, sino también en la seguridad de la información. Y si los proveedores han aprendido a lidiar de alguna manera con la seguridad de la propia nube (afortunadamente, hay muchas recomendaciones), entonces con el monitoreo de la seguridad de la información en la nube, especialmente en las plataformas SaaS, surgen dificultades importantes, de las que hablaremos.

Digamos que su empresa ha trasladado parte de su infraestructura a la nube... Detente. No de esta manera. Si la infraestructura ha sido transferida y recién ahora está pensando en cómo monitorearla, entonces ya ha perdido. A menos que sea Amazon, Google o Microsoft (y con reservas), probablemente no tendrá mucha capacidad para monitorear sus datos y aplicaciones. Es bueno que tengas la oportunidad de trabajar con registros. A veces, los datos de eventos de seguridad estarán disponibles, pero no tendrás acceso a ellos. Por ejemplo, Office 365. Si tiene la licencia E1 más barata, los eventos de seguridad no estarán disponibles en absoluto. Si tiene una licencia E3, sus datos se almacenan solo durante 90 días, y solo si tiene una licencia E5, la duración de los registros está disponible por un año (sin embargo, esto también tiene sus propios matices relacionados con la necesidad de separarlos). solicite al soporte técnico de Microsoft una serie de funciones para trabajar con registros). Por cierto, la licencia E3 es mucho más débil en términos de funciones de seguimiento que el Exchange corporativo. Para alcanzar el mismo nivel, necesita una licencia E5 o una licencia de Cumplimiento Avanzado adicional, lo que puede requerir dinero adicional que no se tuvo en cuenta en su modelo financiero para migrar a la infraestructura de la nube. Y este es sólo un ejemplo de subestimación de las cuestiones relacionadas con la supervisión de la seguridad de la información en la nube. En este artículo, sin pretender ser completo, quiero llamar la atención sobre algunos matices que conviene tener en cuenta a la hora de elegir un proveedor de nube desde el punto de vista de la seguridad. Y al final del artículo se le dará una lista de verificación que vale la pena completar antes de considerar que se ha resuelto el problema del monitoreo de la seguridad de la información en la nube.

Existen varios problemas típicos que provocan incidencias en entornos cloud, a los que los servicios de seguridad de la información no tienen tiempo de responder o no los ven en absoluto:

Los registros de seguridad no existen. Esta es una situación bastante común, especialmente entre los jugadores novatos en el mercado de soluciones en la nube. Pero no deberías renunciar a ellos de inmediato. Los pequeños actores, especialmente los nacionales, son más sensibles a los requisitos de los clientes y pueden implementar rápidamente algunas funciones requeridas cambiando la hoja de ruta aprobada para sus productos. Sí, esto no será un análogo de GuardDuty de Amazon o el módulo "Proactive Protection" de Bitrix, pero al menos algo.
La seguridad de la información no sabe dónde se almacenan los registros o no hay acceso a ellos. Aquí es necesario entablar negociaciones con el proveedor de servicios en la nube; tal vez él le proporcione dicha información si considera que el cliente es importante para él. Pero, en general, no es muy bueno cuando el acceso a los registros se proporciona "por decisión especial".
También sucede que el proveedor de la nube tiene registros, pero proporcionan un seguimiento y un registro de eventos limitados, que no son suficientes para detectar todas las incidencias. Por ejemplo, es posible que solo reciba registros de cambios en un sitio web o registros de intentos de autenticación de usuarios, pero no otros eventos, como el tráfico de red, lo que le ocultará toda una capa de eventos que caracterizan los intentos de piratear su infraestructura de nube.
Hay registros, pero el acceso a ellos es difícil de automatizar, lo que obliga a controlarlos no de forma continua, sino de forma programada. Y si no puede descargar los registros automáticamente, descargarlos, por ejemplo, en formato Excel (como ocurre con varios proveedores nacionales de soluciones en la nube), puede incluso generar reticencia por parte del servicio de seguridad de la información corporativa a manipularlos.
Sin seguimiento de registros. Esta es quizás la razón menos clara de la aparición de incidentes de seguridad de la información en entornos de nube. Parece que hay registros y es posible automatizar el acceso a ellos, pero nadie lo hace. ¿Por qué?

Concepto de seguridad en la nube compartida

La transición a la nube es siempre una búsqueda de un equilibrio entre el deseo de mantener el control sobre la infraestructura y transferirla a las manos más profesionales de un proveedor de la nube que se especialice en su mantenimiento. Y en el ámbito de la seguridad en la nube también hay que buscar este equilibrio. Además, dependiendo del modelo de prestación de servicios en la nube utilizado (IaaS, PaaS, SaaS), este equilibrio será diferente en todo momento. En cualquier caso, hay que recordar que todos los proveedores de la nube siguen hoy en día el llamado modelo de responsabilidad compartida y seguridad de la información compartida. La nube es responsable de algunas cosas, y de otras es responsable el cliente, colocando sus datos, sus aplicaciones, sus máquinas virtuales y otros recursos en la nube. Sería imprudente esperar que al pasar a la nube, traslademos toda la responsabilidad al proveedor. Pero tampoco es aconsejable crear usted mismo toda la seguridad al pasar a la nube. Se requiere un equilibrio, que dependerá de muchos factores: - estrategia de gestión de riesgos, modelo de amenazas, mecanismos de seguridad de los que dispone el proveedor de la nube, legislación, etc.

Por ejemplo, la clasificación de los datos alojados en la nube es siempre responsabilidad del cliente. Un proveedor de la nube o un proveedor de servicios externo solo puede ayudarlo con herramientas que le ayudarán a marcar datos en la nube, identificar violaciones, eliminar datos que violen la ley o enmascararlos usando un método u otro. Por otro lado, la seguridad física es siempre responsabilidad del proveedor de la nube, que no puede compartir con los clientes. Pero todo lo que hay entre datos e infraestructura física es precisamente el tema de discusión en este artículo. Por ejemplo, la disponibilidad de la nube es responsabilidad del proveedor, y configurar reglas de firewall o habilitar el cifrado es responsabilidad del cliente. En este artículo intentaremos analizar qué mecanismos de monitoreo de seguridad de la información ofrecen hoy en día varios proveedores de nube populares en Rusia, cuáles son las características de su uso y cuándo vale la pena buscar soluciones de superposición externas (por ejemplo, Cisco E- Mail Security) que amplían las capacidades de tu nube en términos de ciberseguridad. En algunos casos, especialmente si sigue una estrategia de múltiples nubes, no tendrá más remedio que utilizar soluciones externas de monitoreo de seguridad de la información en varios entornos de nube a la vez (por ejemplo, Cisco CloudLock o Cisco Stealthwatch Cloud). Bueno, en algunos casos te darás cuenta de que el proveedor de nube que has elegido (o que te han impuesto) no ofrece ninguna capacidad de monitoreo de seguridad de la información. Esto es desagradable, pero tampoco poco, ya que permite evaluar adecuadamente el nivel de riesgo asociado al trabajo con esta nube.

Ciclo de vida de monitoreo de seguridad en la nube

Para monitorear la seguridad de las nubes que utilizas, solo tienes tres opciones:

confíe en las herramientas proporcionadas por su proveedor de nube,
utilizar soluciones de terceros que monitorearán las plataformas IaaS, PaaS o SaaS que utiliza,
Cree su propia infraestructura de monitoreo en la nube (solo para plataformas IaaS/PaaS).

Veamos qué características tiene cada una de estas opciones. Pero primero, debemos comprender el marco general que se utilizará al monitorear las plataformas en la nube. Destacaría 6 componentes principales del proceso de monitoreo de la seguridad de la información en la nube:

Preparación de infraestructura. Determinar las aplicaciones e infraestructura necesarias para recopilar eventos importantes para la seguridad de la información en el almacenamiento.
Recopilación. En esta etapa, los eventos de seguridad se agregan de varias fuentes para su posterior transmisión para su procesamiento, almacenamiento y análisis.
Tratamiento. En esta etapa, los datos se transforman y enriquecen para facilitar el análisis posterior.
Almacenamiento. Este componente es responsable del almacenamiento a corto y largo plazo de los datos sin procesar y procesados recopilados.
Análisis. En esta etapa tienes la capacidad de detectar incidencias y responder a ellas de forma automática o manual.
Informes. Esta etapa ayuda a formular indicadores clave para las partes interesadas (gerencia, auditores, proveedor de la nube, clientes, etc.) que nos ayudan a tomar ciertas decisiones, por ejemplo, cambiar de proveedor o fortalecer la seguridad de la información.

Comprender estos componentes le permitirá decidir rápidamente en el futuro qué puede recibir de su proveedor y qué tendrá que hacer usted mismo o con la participación de consultores externos.

Servicios en la nube integrados

Ya escribí anteriormente que muchos servicios en la nube hoy en día no brindan ninguna capacidad de monitoreo de la seguridad de la información. En general, no prestan mucha atención al tema de la seguridad de la información. Por ejemplo, uno de los servicios rusos más populares para enviar informes a agencias gubernamentales a través de Internet (no mencionaré específicamente su nombre). Toda la sección sobre la seguridad de este servicio gira en torno al uso de CIPF certificado. La sección de seguridad de la información de otro servicio nacional en la nube para la gestión de documentos electrónicos no es diferente. Habla de certificados de clave pública, criptografía certificada, eliminación de vulnerabilidades web, protección contra ataques DDoS, uso de firewalls, copias de seguridad e incluso auditorías periódicas de seguridad de la información. Pero no se dice nada sobre monitoreo, ni sobre la posibilidad de acceder a eventos de seguridad de la información que puedan ser de interés para los clientes de este proveedor de servicios.

En general, por la forma en que el proveedor de la nube describe los problemas de seguridad de la información en su sitio web y en su documentación, se puede comprender la seriedad con la que se toma este problema. Por ejemplo, si lee los manuales de los productos “Mi Office”, no encontrará ni una palabra sobre seguridad, pero en la documentación del producto independiente “Mi Office. KS3”, diseñado para proteger contra el acceso no autorizado, existe una lista habitual de puntos del orden 17 de FSTEC, que implementa “My Office.KS3”, pero no se describe cómo lo implementa y, lo más importante, cómo integrar estos mecanismos con la seguridad de la información corporativa. Quizás dicha documentación exista, pero no la encontré en el dominio público, en el sitio web "Mi Oficina". Aunque tal vez simplemente no tengo acceso a esta información secreta.

Para Bitrix la situación es mucho mejor. La documentación describe los formatos de los registros de eventos y, curiosamente, el registro de intrusiones, que contiene eventos relacionados con amenazas potenciales a la plataforma en la nube. Desde allí puede extraer la IP, el nombre de usuario o invitado, el origen del evento, la hora, el agente de usuario, el tipo de evento, etc. Es cierto que puede trabajar con estos eventos desde el panel de control de la propia nube o cargar datos en formato MS Excel. Ahora es difícil automatizar el trabajo con registros de Bitrix y tendrá que hacer parte del trabajo manualmente (cargar el informe y cargarlo en su SIEM). Pero si recordamos que hasta hace relativamente poco tiempo no existía tal oportunidad, entonces esto es un gran progreso. Al mismo tiempo, me gustaría señalar que muchos proveedores de nube extranjeros ofrecen una funcionalidad similar "para principiantes": mire los registros con los ojos a través del panel de control o cargue los datos usted mismo (sin embargo, la mayoría carga datos en formato . formato csv, no Excel).

Sin considerar la opción de no registros, los proveedores de la nube generalmente le ofrecen tres opciones para monitorear eventos de seguridad: paneles, carga de datos y acceso a API. El primero parece resolverle muchos problemas, pero esto no es del todo cierto: si tiene varias revistas, tendrá que cambiar entre las pantallas que las muestran, perdiendo la imagen general. Además, es poco probable que el proveedor de la nube le brinde la capacidad de correlacionar eventos de seguridad y, en general, analizarlos desde el punto de vista de la seguridad (generalmente se trata de datos sin procesar, que debe comprender usted mismo). Hay excepciones y hablaremos más sobre ellas. Finalmente, vale la pena preguntarse qué eventos registra su proveedor de nube, en qué formato y cómo se corresponden con su proceso de monitoreo de seguridad de la información. Por ejemplo, identificación y autenticación de usuarios e invitados. El mismo Bitrix permite, en base a estos eventos, registrar la fecha y hora del evento, el nombre del usuario o invitado (si se cuenta con el módulo “Web Analytics”), el objeto accedido y otros elementos propios de un sitio web. . Pero los servicios de seguridad de la información corporativa pueden necesitar información sobre si el usuario accedió a la nube desde un dispositivo confiable (por ejemplo, en una red corporativa esta tarea la implementa Cisco ISE). ¿Qué pasa con una tarea tan simple como la función Geo-IP, que ayudará a determinar si una cuenta de usuario de un servicio en la nube ha sido robada? E incluso si el proveedor de la nube se lo proporciona, esto no es suficiente. El mismo Cisco CloudLock no solo analiza la geolocalización, sino que utiliza para ello el aprendizaje automático y analiza datos históricos de cada usuario y monitorea diversas anomalías en los intentos de identificación y autenticación. Sólo MS Azure tiene una funcionalidad similar (si tiene la suscripción adecuada).

Hay otra dificultad: dado que para muchos proveedores de la nube, el monitoreo de la seguridad de la información es un tema nuevo que recién están comenzando a abordar, constantemente cambian algo en sus soluciones. Hoy tienen una versión de la API, mañana otra, pasado mañana una tercera. También debes estar preparado para esto. Lo mismo ocurre con la funcionalidad, que puede cambiar y que debe tenerse en cuenta en su sistema de seguimiento de la seguridad de la información. Por ejemplo, Amazon inicialmente tenía servicios separados de monitoreo de eventos en la nube: AWS CloudTrail y AWS CloudWatch. Luego apareció un servicio separado para monitorear eventos de seguridad de la información: AWS GuardDuty. Después de un tiempo, Amazon lanzó un nuevo sistema de gestión, Amazon Security Hub, que incluye análisis de datos recibidos de GuardDuty, Amazon Inspector, Amazon Macie y varios otros. Otro ejemplo es la herramienta de integración de registros de Azure con SIEM: AzLog. Fue utilizado activamente por muchos proveedores de SIEM, hasta que en 2018 Microsoft anunció el cese de su desarrollo y soporte, lo que enfrentó un problema a muchos clientes que utilizaban esta herramienta (hablaremos de cómo se resolvió más adelante).

Por lo tanto, supervise cuidadosamente todas las funciones de seguimiento que le ofrece su proveedor de nube. O confíe en proveedores de soluciones externos que actuarán como intermediarios entre su SOC y la nube que desea monitorear. Sí, será más caro (aunque no siempre), pero pondrás toda la responsabilidad sobre los hombros de otra persona. ¿O no todo?... Recordemos el concepto de seguridad compartida y comprendamos que no podemos cambiar nada: tendremos que comprender de forma independiente cómo los diferentes proveedores de la nube brindan monitoreo de la seguridad de la información de sus datos, aplicaciones, máquinas virtuales y otros recursos. alojado en la nube. Y comenzaremos con lo que ofrece Amazon en esta parte.

Ejemplo: Monitoreo de seguridad de la información en IaaS basado en AWS

Sí, sí, entiendo que Amazon no es el mejor ejemplo debido a que es un servicio estadounidense y puede bloquearse como parte de la lucha contra el extremismo y la difusión de información prohibida en Rusia. Pero en esta publicación solo me gustaría mostrar en qué se diferencian las diferentes plataformas en la nube en sus capacidades de monitoreo de la seguridad de la información y a qué debe prestar atención al transferir sus procesos clave a la nube desde el punto de vista de la seguridad. Bueno, si algunos de los desarrolladores rusos de soluciones en la nube aprenden algo útil por sí mismos, será genial.

Lo primero que hay que decir es que Amazon no es una fortaleza impenetrable. A sus clientes les ocurren regularmente varios incidentes. Por ejemplo, los nombres, direcciones, fechas de nacimiento y números de teléfono de 198 millones de votantes fueron robados de Deep Root Analytics. La empresa israelí Nice Systems robó 14 millones de registros de suscriptores de Verizon. Sin embargo, las capacidades integradas de AWS le permiten detectar una amplia gama de incidentes. Por ejemplo:

impacto en la infraestructura (DDoS)
compromiso de nodo (inyección de comando)
compromiso de cuenta y acceso no autorizado
configuración incorrecta y vulnerabilidades
Interfaces y API inseguras.

Esta discrepancia se debe al hecho de que, como descubrimos anteriormente, el propio cliente es responsable de la seguridad de sus datos. Y si no se molestó en activar los mecanismos de protección y no activó las herramientas de seguimiento, entonces sólo se enterará del incidente a través de los medios de comunicación o de sus clientes.

Para identificar incidencias se puede utilizar una amplia gama de diferentes servicios de seguimiento desarrollados por Amazon (aunque suelen complementarse con herramientas externas como osquery). Entonces, en AWS, se monitorean todas las acciones del usuario, independientemente de cómo se lleven a cabo: a través de la consola de administración, la línea de comandos, el SDK u otros servicios de AWS. Todos los registros de la actividad de cada cuenta de AWS (incluido el nombre de usuario, la acción, el servicio, los parámetros de actividad y el resultado) y el uso de API están disponibles a través de AWS CloudTrail. Puede ver estos eventos (como los inicios de sesión de la consola de AWS IAM) desde la consola de CloudTrail, analizarlos utilizando Amazon Athena o "subcontratarlos" a soluciones externas como Splunk, AlienVault, etc. Los registros de AWS CloudTrail se colocan en su depósito de AWS S3.

Otros dos servicios de AWS brindan otras capacidades de monitoreo importantes. En primer lugar, Amazon CloudWatch es un servicio de monitoreo de recursos y aplicaciones de AWS que, entre otras cosas, le permite identificar diversas anomalías en su nube. Todos los servicios integrados de AWS, como Amazon Elastic Compute Cloud (servidores), Amazon Relational Database Service (bases de datos), Amazon Elastic MapReduce (análisis de datos) y otros 30 servicios de Amazon, utilizan Amazon CloudWatch para almacenar sus registros. Los desarrolladores pueden utilizar la API abierta de Amazon CloudWatch para agregar funcionalidad de monitoreo de registros a aplicaciones y servicios personalizados, lo que les permite ampliar el alcance del análisis de eventos dentro de un contexto de seguridad.

En segundo lugar, el servicio VPC Flow Logs le permite analizar el tráfico de red enviado o recibido por sus servidores AWS (externos o internos), así como entre microservicios. Cuando cualquiera de sus recursos de AWS VPC interactúa con la red, los registros de flujo de VPC registran detalles sobre el tráfico de la red, incluida la interfaz de red de origen y de destino, así como las direcciones IP, los puertos, el protocolo, la cantidad de bytes y la cantidad de paquetes que usted recibe. sierra. Aquellos con experiencia en seguridad de redes locales reconocerán esto como algo análogo a los hilos. NetFlow, que puede ser creado mediante conmutadores, enrutadores y firewalls de nivel empresarial. Estos registros son importantes para fines de monitoreo de la seguridad de la información porque, a diferencia de los eventos sobre las acciones de los usuarios y las aplicaciones, también le permiten no perderse las interacciones de la red en el entorno de nube privada virtual de AWS.

En resumen, estos tres servicios de AWS (AWS CloudTrail, Amazon CloudWatch y VPC Flow Logs) juntos brindan información bastante poderosa sobre el uso de su cuenta, el comportamiento del usuario, la administración de la infraestructura, la actividad de aplicaciones y servicios, y la actividad de la red. Por ejemplo, se pueden utilizar para detectar las siguientes anomalías:

Intenta escanear el sitio, buscar puertas traseras, buscar vulnerabilidades mediante ráfagas de “errores 404”.
Ataques de inyección (por ejemplo, inyección SQL) mediante ráfagas de “500 errores”.
Las herramientas de ataque conocidas son sqlmap, nikto, w3af, nmap, etc. a través del análisis del campo Agente de Usuario.

Amazon Web Services también ha desarrollado otros servicios con fines de ciberseguridad que permiten solucionar muchos otros problemas. Por ejemplo, AWS tiene un servicio integrado para auditar políticas y configuraciones: AWS Config. Este servicio proporciona una auditoría continua de sus recursos de AWS y sus configuraciones. Tomemos un ejemplo simple: digamos que desea asegurarse de que las contraseñas de usuario estén deshabilitadas en todos sus servidores y que el acceso solo sea posible según los certificados. AWS Config facilita la verificación de esto para todos sus servidores. Hay otras políticas que se pueden aplicar a sus servidores en la nube: "Ningún servidor puede usar el puerto 22", "Solo los administradores pueden cambiar las reglas del firewall" o "Solo el usuario Ivashko puede crear nuevas cuentas de usuario, y solo puede hacerlo los martes". " En el verano de 2016, el servicio AWS Config se amplió para automatizar la detección de infracciones de las políticas desarrolladas. Las reglas de AWS Config son esencialmente solicitudes de configuración continuas para los servicios de Amazon que utiliza, que generan eventos si se violan las políticas correspondientes. Por ejemplo, en lugar de ejecutar periódicamente consultas de AWS Config para verificar que todos los discos de un servidor virtual estén cifrados, se pueden utilizar las reglas de AWS Config para verificar continuamente los discos del servidor y garantizar que se cumpla esta condición. Y, lo más importante, en el contexto de esta publicación, cualquier infracción genera eventos que pueden ser analizados por su servicio de seguridad de la información.

AWS también tiene su equivalente a las soluciones tradicionales de seguridad de la información corporativa, que también generan eventos de seguridad que puedes y debes analizar:

Detección de intrusiones: AWS GuardDuty
Control de fugas de información - AWS Macie
EDR (aunque habla de puntos finales en la nube de manera un poco extraña): AWS Cloudwatch + osquery de código abierto o soluciones GRR
Análisis de flujo de red: AWS Cloudwatch + AWS VPC Flow
Análisis de DNS: AWS Cloudwatch + AWS Route53
AD - Servicio de directorio de AWS
Gestión de cuentas - AWS IAM
SSO - AWS SSO
análisis de seguridad - AWS Inspector
gestión de configuración - AWS Config
WAF-AWS WAF.

No describiré en detalle todos los servicios de Amazon que pueden resultar útiles en el contexto de la seguridad de la información. Lo principal es entender que todos ellos pueden generar eventos que podemos y debemos analizar en el contexto de la seguridad de la información, utilizando para ello tanto las capacidades integradas de la propia Amazon como soluciones externas, por ejemplo, SIEM, que pueden lleva los eventos de seguridad a tu centro de monitoreo y analízalos allí junto con eventos de otros servicios en la nube o de infraestructura interna, perímetro o dispositivos móviles.

En cualquier caso, todo comienza con las fuentes de datos que te brindan información sobre eventos de seguridad. Estas fuentes incluyen, entre otras:

CloudTrail: uso de API y acciones del usuario
Asesor de confianza: control de seguridad frente a las mejores prácticas
Config: inventario y configuración de cuentas y ajustes de servicios
Registros de flujo de VPC: conexiones a interfaces virtuales
IAM - servicio de identificación y autenticación
Registros de acceso de ELB: equilibrador de carga
Inspector: vulnerabilidades de la aplicación
S3 - almacenamiento de archivos
CloudWatch: actividad de la aplicación
SNS es un servicio de notificación.

Amazon, si bien ofrece tal variedad de fuentes de eventos y herramientas para su generación, tiene una capacidad muy limitada para analizar los datos recopilados en el contexto de la seguridad de la información. Tendrá que estudiar de forma independiente los registros disponibles, buscando en ellos indicadores relevantes de compromiso. AWS Security Hub, que Amazon lanzó recientemente, tiene como objetivo resolver este problema convirtiéndose en un SIEM en la nube para AWS. Pero hasta el momento está sólo al inicio de su andadura y está limitado tanto por el número de fuentes con las que trabaja como por otras restricciones que establece la arquitectura y las suscripciones de la propia Amazon.

Ejemplo: Monitoreo de seguridad de la información en IaaS basado en Azure

No quiero entrar en un largo debate sobre cuál de los tres proveedores de la nube (Amazon, Microsoft o Google) es mejor (sobre todo porque cada uno de ellos todavía tiene sus propias particularidades y es adecuado para resolver sus propios problemas); Centrémonos en las capacidades de monitoreo de la seguridad de la información que brindan estos actores. Hay que admitir que Amazon AWS fue uno de los primeros en este segmento y por tanto es el que más ha avanzado en cuanto a sus funciones de seguridad de la información (aunque muchos admiten que son difíciles de utilizar). Pero esto no significa que ignoraremos las oportunidades que nos brindan Microsoft y Google.

Los productos de Microsoft siempre se han distinguido por su “apertura” y en Azure la situación es similar. Por ejemplo, si AWS y GCP siempre parten del concepto de “lo que no está permitido está prohibido”, entonces Azure tiene exactamente el enfoque opuesto. Por ejemplo, al crear una red virtual en la nube y una máquina virtual en ella, todos los puertos y protocolos están abiertos y permitidos de forma predeterminada. Por tanto, tendrás que dedicar un poco más de esfuerzo a la configuración inicial del sistema de control de acceso en la nube de Microsoft. Y esto también le impone requisitos más estrictos en términos de monitoreo de la actividad en la nube de Azure.

AWS tiene una peculiaridad asociada con el hecho de que cuando monitorea sus recursos virtuales, si están ubicados en diferentes regiones, entonces tiene dificultades para combinar todos los eventos y su análisis unificado, para eliminar lo cual debe recurrir a varios trucos, como Cree su propio código para AWS Lambda que transportará eventos entre regiones. Azure no tiene este problema: su mecanismo de Registro de actividad rastrea toda la actividad en toda la organización sin restricciones. Lo mismo se aplica a AWS Security Hub, que Amazon desarrolló recientemente para consolidar muchas funciones de seguridad en un único centro de seguridad, pero sólo dentro de su región, lo que, sin embargo, no es relevante para Rusia. Azure tiene su propio Centro de seguridad, que no está sujeto a restricciones regionales, y brinda acceso a todas las funciones de seguridad de la plataforma en la nube. Además, para diferentes equipos locales puede proporcionar su propio conjunto de capacidades de protección, incluidos los eventos de seguridad gestionados por ellos. AWS Security Hub todavía está en camino de parecerse a Azure Security Center. Pero vale la pena agregar una mosca al ungüento: puede exprimir de Azure mucho de lo que se describió anteriormente en AWS, pero es más conveniente hacerlo solo para Azure AD, Azure Monitor y Azure Security Center. Todos los demás mecanismos de seguridad de Azure, incluido el análisis de eventos de seguridad, aún no se administran de la manera más conveniente. El problema lo resuelve en parte la API, que impregna todos los servicios de Microsoft Azure, pero esto requerirá un esfuerzo adicional por su parte para integrar su nube con su SOC y la presencia de especialistas calificados (de hecho, como con cualquier otro SIEM que funcione con API en la nube). Algunos SIEM, que se analizarán más adelante, ya son compatibles con Azure y pueden automatizar la tarea de monitorearlo, pero esto también tiene sus propias dificultades: no todos pueden recopilar todos los registros que tiene Azure.

La recopilación y el seguimiento de eventos en Azure se proporcionan mediante el servicio Azure Monitor, que es la herramienta principal para recopilar, almacenar y analizar datos en la nube de Microsoft y sus recursos: repositorios Git, contenedores, máquinas virtuales, aplicaciones, etc. Todos los datos recopilados por Azure Monitor se dividen en dos categorías: métricas, recopiladas en tiempo real y que describen indicadores clave de rendimiento de la nube de Azure, y registros, que contienen datos organizados en registros que caracterizan ciertos aspectos de la actividad de los recursos y servicios de Azure. Además, al utilizar la API del recopilador de datos, el servicio Azure Monitor puede recopilar datos de cualquier origen REST para crear sus propios escenarios de supervisión.

A continuación se muestran algunos orígenes de eventos de seguridad que Azure le ofrece y a los que puede acceder a través del Portal de Azure, la CLI, PowerShell o la API REST (y algunos solo a través de Azure Monitor/Insight API):

Registros de actividad: este registro responde a las preguntas clásicas de "quién", "qué" y "cuándo" con respecto a cualquier operación de escritura (PONER, PUBLICAR, ELIMINAR) en recursos de la nube. Los eventos relacionados con el acceso de lectura (GET) no se incluyen en este registro, como muchos otros.
Registros de diagnóstico: contiene datos sobre operaciones con un recurso particular incluido en su suscripción.
Informes de Azure AD: contiene tanto la actividad del usuario como la actividad del sistema relacionada con la administración de grupos y usuarios.
Registro de eventos de Windows y Syslog de Linux: contiene eventos de máquinas virtuales alojadas en la nube.
Métricas: contiene telemetría sobre el rendimiento y el estado de salud de sus servicios y recursos en la nube. Medido cada minuto y almacenado. En 30 días.
Registros de flujo del grupo de seguridad de red: contiene datos sobre eventos de seguridad de red recopilados mediante el servicio Network Watcher y el monitoreo de recursos a nivel de red.
Registros de almacenamiento: contiene eventos relacionados con el acceso a las instalaciones de almacenamiento.

Para la supervisión, puede utilizar SIEM externos o el Azure Monitor integrado y sus extensiones. Hablaremos de sistemas de gestión de eventos de seguridad de la información más adelante, pero por ahora veamos qué nos ofrece el propio Azure para el análisis de datos en el contexto de la seguridad. La pantalla principal para todo lo relacionado con la seguridad en Azure Monitor es el Panel de auditoría y seguridad de Log Analytics (la versión gratuita admite una cantidad limitada de almacenamiento de eventos durante solo una semana). Este panel está dividido en 5 áreas principales que visualizan estadísticas resumidas de lo que sucede en el entorno de nube que está utilizando:

Dominios de seguridad: indicadores cuantitativos clave relacionados con la seguridad de la información: la cantidad de incidentes, la cantidad de nodos comprometidos, nodos sin parches, eventos de seguridad de la red, etc.
Problemas notables: muestra la cantidad y la importancia de los problemas activos de seguridad de la información.
Detecciones: muestra patrones de ataques utilizados en su contra
Inteligencia de amenazas: muestra información geográfica sobre nodos externos que lo están atacando.
Consultas de seguridad comunes: consultas típicas que le ayudarán a controlar mejor la seguridad de su información.

Las extensiones de Azure Monitor incluyen Azure Key Vault (protección de claves criptográficas en la nube), Malware Assessment (análisis de protección contra códigos maliciosos en máquinas virtuales), Azure Application Gateway Analytics (análisis de, entre otras cosas, registros de firewall en la nube), etc. . Estas herramientas, enriquecidas con ciertas reglas para procesar eventos, le permiten visualizar varios aspectos de la actividad de los servicios en la nube, incluida la seguridad, e identificar ciertas desviaciones del funcionamiento. Pero, como suele suceder, cualquier funcionalidad adicional requiere una suscripción paga correspondiente, lo que requerirá de usted las correspondientes inversiones financieras, que deberá planificar con antelación.

Azure tiene una serie de capacidades de monitoreo de amenazas integradas en Azure AD, Azure Monitor y Azure Security Center. Entre ellos, por ejemplo, detección de interacción de máquinas virtuales con IP maliciosas conocidas (debido a la presencia de integración con los servicios Threat Intelligence de Microsoft), detección de malware en la infraestructura de la nube mediante la recepción de alarmas de máquinas virtuales alojadas en la nube, contraseña ataques de adivinanzas” en máquinas virtuales, vulnerabilidades en la configuración del sistema de identificación de usuarios, inicio de sesión en el sistema desde anonimizadores o nodos infectados, filtraciones de cuentas, inicio de sesión en el sistema desde ubicaciones inusuales, etc. Hoy en día, Azure es uno de los pocos proveedores de nube que ofrece capacidades integradas de Threat Intelligence para enriquecer los eventos de seguridad de la información recopilada.

Como se mencionó anteriormente, la funcionalidad de seguridad y, como resultado, los eventos de seguridad que genera no están disponibles para todos los usuarios por igual, sino que requieren una determinada suscripción que incluya la funcionalidad que necesita, que genera los eventos adecuados para el monitoreo de la seguridad de la información. Por ejemplo, algunas de las funciones descritas en el párrafo anterior para monitorear anomalías en cuentas están disponibles solo en la licencia premium P2 para el servicio Azure AD. Sin él, usted, como en el caso de AWS, tendrá que analizar los eventos de seguridad recopilados "manualmente". Y, además, dependiendo del tipo de licencia de Azure AD, no todos los eventos estarán disponibles para su análisis.

En Azure Portal, puede administrar consultas de búsqueda de registros de su interés y configurar paneles para visualizar indicadores clave de seguridad de la información. Además, allí puede seleccionar extensiones de Azure Monitor, que le permiten ampliar la funcionalidad de los registros de Azure Monitor y obtener un análisis más profundo de los eventos desde el punto de vista de la seguridad.

Si necesita no solo la capacidad de trabajar con registros, sino también un centro de seguridad integral para su plataforma en la nube Azure, incluida la administración de políticas de seguridad de la información, entonces puede hablar sobre la necesidad de trabajar con Azure Security Center, cuya mayoría de funciones útiles están disponibles por algo de dinero, por ejemplo, detección de amenazas, monitoreo fuera de Azure, evaluación de cumplimiento, etc. (en la versión gratuita, solo tienes acceso a una evaluación de seguridad y recomendaciones para eliminar los problemas identificados). Consolida todos los problemas de seguridad en un solo lugar. De hecho, podemos hablar de un nivel de seguridad de la información superior al que te proporciona Azure Monitor, ya que en este caso los datos recopilados a lo largo de tu fábrica en la nube se enriquecen utilizando muchas fuentes, como Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) y Microsoft Security Response Center (MSRC), sobre los cuales se superponen varios algoritmos sofisticados de aprendizaje automático y análisis de comportamiento, que en última instancia deberían mejorar la eficiencia de la detección y respuesta a las amenazas. .

Azure también tiene su propio SIEM: apareció a principios de 2019. Este es Azure Sentinel, que se basa en datos de Azure Monitor y también puede integrarse con ellos. soluciones de seguridad externas (por ejemplo, NGFW o WAF), cuya lista crece constantemente. Además, a través de la integración de la API de seguridad de Microsoft Graph, tiene la capacidad de conectar sus propias fuentes de Threat Intelligence a Sentinel, lo que enriquece las capacidades para analizar incidentes en su nube de Azure. Se puede argumentar que Azure Sentinel es el primer SIEM "nativo" que apareció de los proveedores de la nube (los mismos Splunk o ELK, que se pueden alojar en la nube, por ejemplo, AWS, aún no han sido desarrollados por los proveedores de servicios de la nube tradicionales). Azure Sentinel y Security Center podrían llamarse SOC para la nube de Azure y podrían limitarse a ellos (con ciertas reservas) si ya no tuvieras ninguna infraestructura y transfirieras todos tus recursos informáticos a la nube y sería la nube de Microsoft Azure.

Pero dado que las capacidades integradas de Azure (incluso si tiene una suscripción a Sentinel) a menudo no son suficientes para monitorear la seguridad de la información e integrar este proceso con otras fuentes de eventos de seguridad (tanto en la nube como internas), existe una Es necesario exportar los datos recopilados a sistemas externos, entre los que se puede incluir SIEM. Esto se hace utilizando la API y extensiones especiales, que actualmente están oficialmente disponibles solo para los siguientes SIEM: Splunk (Azure Monitor Add-On para Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight y ELK. Hasta hace poco, había más SIEM de este tipo, pero a partir del 1 de junio de 2019, Microsoft dejó de admitir la herramienta de integración de registros de Azure (AzLog), que en los albores de la existencia de Azure y en ausencia de una estandarización normal del trabajo con registros (Azure Monitor ni siquiera existía todavía) facilitó la integración de SIEM externo con la nube de Microsoft. Ahora la situación ha cambiado y Microsoft recomienda la plataforma Azure Event Hub como principal herramienta de integración para otros SIEM. Muchos ya han implementado dicha integración, pero tenga cuidado: es posible que no capturen todos los registros de Azure, sino solo algunos (consulte la documentación de su SIEM).

Para concluir una breve excursión a Azure, me gustaría dar una recomendación general sobre este servicio en la nube: antes de decir algo sobre las funciones de monitoreo de seguridad de la información en Azure, debe configurarlas con mucho cuidado y probar que funcionan como está escrito en la documentación y como le dijeron los consultores de Microsoft (y pueden tener diferentes puntos de vista sobre la funcionalidad de las funciones de Azure). Si tiene los recursos financieros, puede obtener mucha información útil de Azure en términos de monitoreo de seguridad de la información. Si sus recursos son limitados, entonces, como en el caso de AWS, tendrá que confiar únicamente en sus propias fuerzas y en los datos sin procesar que le proporciona Azure Monitor. Y recuerde que muchas funciones de seguimiento cuestan dinero y es mejor familiarizarse con la política de precios con antelación. Por ejemplo, de forma gratuita puede almacenar 31 días de datos hasta un máximo de 5 GB por cliente; exceder estos valores requerirá que desembolse dinero adicional (aproximadamente $2+ por almacenar cada GB adicional del cliente y $0,1 por almacenar almacenando 1 GB cada mes adicional). Trabajar con telemetría y métricas de aplicaciones también puede requerir fondos adicionales, así como trabajar con alertas y notificaciones (hay un cierto límite disponible de forma gratuita, que puede no ser suficiente para sus necesidades).

Ejemplo: Monitoreo de seguridad de la información en IaaS basado en Google Cloud Platform

Google Cloud Platform parece joven en comparación con AWS y Azure, pero esto es en parte bueno. A diferencia de AWS, que aumentó sus capacidades, incluidas las de seguridad, de forma paulatina, teniendo problemas con la centralización; GCP, al igual que Azure, se administra mucho mejor de forma centralizada, lo que reduce los errores y el tiempo de implementación en toda la empresa. Desde el punto de vista de la seguridad, GCP está, curiosamente, entre AWS y Azure. También tiene un registro de evento único para toda la organización, pero está incompleto. Algunas funciones aún están en modo beta, pero gradualmente esta deficiencia debería eliminarse y GCP se convertirá en una plataforma más madura en términos de monitoreo de seguridad de la información.

La herramienta principal para registrar eventos en GCP es Stackdriver Logging (similar a Azure Monitor), que le permite recopilar eventos en toda su infraestructura de nube (así como de AWS). Desde una perspectiva de seguridad en GCP, cada organización, proyecto o carpeta tiene cuatro registros:

Actividad administrativa: contiene todos los eventos relacionados con el acceso administrativo, por ejemplo, crear una máquina virtual, cambiar los derechos de acceso, etc. Este registro siempre se escribe, independientemente de su deseo, y almacena sus datos durante 400 días.
Acceso a datos: contiene todos los eventos relacionados con el trabajo con datos por parte de los usuarios de la nube (creación, modificación, lectura, etc.). De forma predeterminada, este registro no se escribe, ya que su volumen aumenta muy rápidamente. Por este motivo, su vida útil es de sólo 30 días. Además, no todo está escrito en esta revista. Por ejemplo, los eventos relacionados con recursos a los que todos los usuarios pueden acceder públicamente o a los que se puede acceder sin iniciar sesión en GCP no se escriben en él.
Evento del sistema: contiene eventos del sistema no relacionados con los usuarios o acciones de un administrador que cambia la configuración de los recursos de la nube. Siempre se escribe y almacena durante 400 días.
Access Transparency es un ejemplo único de un registro que captura todas las acciones de los empleados de Google (pero aún no para todos los servicios de GCP) que acceden a su infraestructura como parte de sus tareas laborales. Este registro se almacena durante 400 días y no está disponible para todos los clientes de GCP, pero solo si se cumplen una serie de condiciones (ya sea soporte de nivel Gold o Platinum, o la presencia de 4 roles de un determinado tipo como parte del soporte corporativo). Una función similar también está disponible, por ejemplo, en Office 365 - Lockbox.

Ejemplo de registro: 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"
}

El acceso a estos registros es posible de varias maneras (de manera muy similar a como se discutió anteriormente en Azure y AWS): a través de la interfaz del Visor de registros, a través de la API, a través del SDK de Google Cloud o a través de la página Actividad de su proyecto para el cual están interesados en eventos. De la misma manera, se pueden exportar a soluciones externas para análisis adicionales. Esto último se realiza exportando registros al almacenamiento de BigQuery o Cloud Pub/Sub.

Además de Stackdriver Logging, la plataforma GCP también ofrece la funcionalidad Stackdriver Monitoring, que le permite monitorear métricas clave (rendimiento, MTBF, estado general, etc.) de los servicios y aplicaciones en la nube. Los datos procesados y visualizados pueden facilitar la búsqueda de problemas en su infraestructura de nube, incluso en el contexto de la seguridad. Pero cabe señalar que esta funcionalidad no será muy rica en el contexto de la seguridad de la información, ya que hoy GCP no tiene un análogo del mismo AWS GuardDuty y no puede identificar los malos entre todos los eventos registrados (Google ha desarrollado Event Threat Detección, pero todavía está en desarrollo en fase beta y es demasiado pronto para hablar de su utilidad). Stackdriver Monitoring podría usarse como un sistema para detectar anomalías, que luego se investigarían para encontrar las causas de su aparición. Pero dada la falta de personal calificado en el campo de la seguridad de la información de GCP en el mercado, esta tarea actualmente parece difícil.

También vale la pena dar una lista de algunos módulos de seguridad de la información que se pueden utilizar dentro de su nube GCP y que son similares a los que ofrece AWS:

Cloud Security Command Center es un análogo de AWS Security Hub y Azure Security Center.
Cloud DLP: descubrimiento y edición automáticos (por ejemplo, enmascaramiento) de datos alojados en la nube utilizando más de 90 políticas de clasificación predefinidas.
Cloud Scanner es un escáner de vulnerabilidades conocidas (XSS, Flash injection, bibliotecas sin parches, etc.) en App Engine, Compute Engine y Google Kubernetes.
Cloud IAM: controle el acceso a todos los recursos de GCP.
Cloud Identity: administre cuentas de aplicaciones, dispositivos y usuarios de GCP desde una única consola.
Cloud HSM: protección de claves criptográficas.
Servicio de gestión de claves en la nube: gestión de claves criptográficas en GCP.
Control de servicio de VPC: cree un perímetro seguro alrededor de sus recursos de GCP para protegerlos de fugas.
Titan Security Key: protección contra el phishing.

Muchos de estos módulos generan eventos de seguridad que se pueden enviar al almacenamiento de BigQuery para su análisis o exportación a otros sistemas, incluido SIEM. Como se mencionó anteriormente, GCP es una plataforma en desarrollo activo y Google ahora está desarrollando una serie de nuevos módulos de seguridad de la información para su plataforma. Entre ellos se encuentran Event ThreatDetection (ahora disponible en versión beta), que escanea los registros de Stackdriver en busca de rastros de actividad no autorizada (análogo a GuardDuty en AWS), o Policy Intelligence (disponible en alfa), que le permitirá desarrollar políticas inteligentes para acceso a los recursos de GCP.

Hice una breve descripción general de las capacidades de monitoreo integradas en plataformas de nube populares. Pero, ¿tiene especialistas que puedan trabajar con registros de proveedores de IaaS "sin procesar" (no todos están preparados para comprar las capacidades avanzadas de AWS, Azure o Google)? Además, muchos están familiarizados con el dicho “confía, pero verifica”, que es más cierto que nunca en el campo de la seguridad. ¿Cuánto confía en las capacidades integradas del proveedor de la nube que le envía eventos de seguridad de la información? ¿Cuánto se centran en la seguridad de la información?

A veces vale la pena buscar soluciones de monitoreo de infraestructura en la nube superpuestas que puedan complementar la seguridad en la nube incorporada y, a veces, dichas soluciones son la única opción para obtener información sobre la seguridad de sus datos y aplicaciones alojadas en la nube. Además, son simplemente más convenientes, ya que asumen todas las tareas de analizar los registros necesarios generados por diferentes servicios en la nube de diferentes proveedores de nube. Un ejemplo de una solución superpuesta de este tipo es Cisco Stealthwatch Cloud, que se centra en una sola tarea: monitorear las anomalías de seguridad de la información en entornos de nube, incluidos no solo Amazon AWS, Microsoft Azure y Google Cloud Platform, sino también nubes privadas.

Ejemplo: Monitoreo de la seguridad de la información usando Stealthwatch Cloud

AWS proporciona una plataforma informática flexible, pero esta flexibilidad facilita que las empresas cometan errores que generen problemas de seguridad. Y el modelo de seguridad de la información compartida no hace más que contribuir a ello. Ejecutar software en la nube con vulnerabilidades desconocidas (las conocidas pueden combatirse, por ejemplo, con AWS Inspector o GCP Cloud Scanner), contraseñas débiles, configuraciones incorrectas, información privilegiada, etc. Y todo esto se refleja en el comportamiento de los recursos de la nube, que pueden ser monitoreados por Cisco Stealthwatch Cloud, que es un sistema de detección de ataques y monitoreo de seguridad de la información. Nubes públicas y privadas.

Una de las características clave de Cisco Stealthwatch Cloud es la capacidad de modelar entidades. Con él, puede crear un modelo de software (es decir, una simulación casi en tiempo real) de cada uno de sus recursos en la nube (no importa si es AWS, Azure, GCP u otra cosa). Estos pueden incluir servidores y usuarios, así como tipos de recursos específicos de su entorno de nube, como grupos de seguridad y grupos de escalamiento automático. Estos modelos utilizan como entrada flujos de datos estructurados proporcionados por los servicios en la nube. Por ejemplo, para AWS, estos serían VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda y AWS IAM. El modelado de entidades descubre automáticamente la función y el comportamiento de cualquiera de sus recursos (puede hablar sobre crear perfiles de toda la actividad en la nube). Estos roles incluyen dispositivo móvil Android o Apple, servidor Citrix PVS, servidor RDP, puerta de enlace de correo, cliente VoIP, servidor de terminal, controlador de dominio, etc. Luego monitorea continuamente su comportamiento para determinar cuándo ocurre un comportamiento riesgoso o que amenaza la seguridad. Puede identificar adivinanzas de contraseñas, ataques DDoS, fugas de datos, acceso remoto ilegal, actividad de códigos maliciosos, escaneo de vulnerabilidades y otras amenazas. Por ejemplo, así es como se ve la detección de un intento de acceso remoto desde un país atípico para su organización (Corea del Sur) a un clúster de Kubernetes a través de SSH:

Y así es como se ve la supuesta filtración de información de la base de datos Postgress a un país con el que no hemos tenido interacción anteriormente:

Finalmente, así es como se ven demasiados intentos fallidos de SSH desde China e Indonesia desde un dispositivo remoto externo:

O bien, supongamos que la instancia del servidor en la VPC, por política, nunca debe ser un destino de inicio de sesión remoto. Supongamos además que esta computadora experimentó un inicio de sesión remoto debido a un cambio erróneo en la política de reglas del firewall. La función Entity Modeling detectará e informará esta actividad (“Acceso remoto inusual”) casi en tiempo real y señalará la llamada API específica de AWS CloudTrail, Azure Monitor o GCP Stackdriver Logging (incluido el nombre de usuario, la fecha y la hora, entre otros detalles). ), lo que provocó el cambio de la regla de la UIT. Y luego esta información se puede enviar a SIEM para su análisis.

Se implementan capacidades similares para cualquier entorno de nube compatible con Cisco Stealthwatch Cloud:

El modelado de entidades es una forma única de automatización de la seguridad que puede descubrir un problema previamente desconocido con su gente, procesos o tecnología. Por ejemplo, permite detectar, entre otras cosas, problemas de seguridad como:

¿Alguien ha descubierto una puerta trasera en el software que utilizamos?
¿Hay algún software o dispositivo de terceros en nuestra nube?
¿El usuario autorizado está abusando de sus privilegios?
¿Hubo un error de configuración que permitió el acceso remoto u otro uso no deseado de los recursos?
¿Hay una fuga de datos de nuestros servidores?
¿Alguien estaba intentando conectarse con nosotros desde una ubicación geográfica atípica?
¿Nuestra nube está infectada con código malicioso?

Un evento de seguridad de la información detectado se puede enviar en forma de un ticket correspondiente a Slack, Cisco Spark, el sistema de gestión de incidentes PagerDuty y también a varios SIEM, incluidos Splunk o ELK. En resumen, podemos decir que si su empresa utiliza una estrategia de múltiples nubes y no se limita a un solo proveedor de nube, las capacidades de monitoreo de seguridad de la información descritas anteriormente, entonces usar Cisco Stealthwatch Cloud es una buena opción para obtener un conjunto unificado de monitoreo. capacidades para los principales actores de la nube: Amazon, Microsoft y Google. Lo más interesante es que si comparamos los precios de Stealthwatch Cloud con licencias avanzadas para monitoreo de seguridad de la información en AWS, Azure o GCP, puede resultar que la solución de Cisco sea incluso más barata que las capacidades integradas de Amazon, Microsoft. y soluciones de Google. Es paradójico, pero es cierto. Y cuantas más nubes y sus capacidades utilice, más obvia será la ventaja de una solución consolidada.

Además, Stealthwatch Cloud puede monitorear las nubes privadas implementadas en su organización, por ejemplo, basadas en contenedores de Kubernetes o monitoreando los flujos de Netflow o el tráfico de red recibido a través de la duplicación en equipos de red (incluso de producción nacional), datos AD o servidores DNS, etc. Todos estos datos se enriquecerán con información de Threat Intelligence recopilada por Cisco Talos, el grupo no gubernamental de investigadores de amenazas a la ciberseguridad más grande del mundo.

Esto le permite implementar un sistema de monitoreo unificado para las nubes públicas e híbridas que su empresa pueda utilizar. La información recopilada puede luego analizarse utilizando las capacidades integradas de Stealthwatch Cloud o enviarse a su SIEM (Splunk, ELK, SumoLogic y varios otros son compatibles de forma predeterminada).

Con esto completamos la primera parte del artículo, en la que revisé las herramientas integradas y externas para monitorear la seguridad de la información de las plataformas IaaS/PaaS, que nos permiten detectar y responder rápidamente a incidentes que ocurren en los entornos de nube que nuestra empresa ha elegido. En la segunda parte, continuaremos con el tema y veremos opciones para monitorear plataformas SaaS usando el ejemplo de Salesforce y Dropbox, y también intentaremos resumir y juntar todo creando un sistema unificado de monitoreo de seguridad de la información para diferentes proveedores de nube.

Fuente: habr.com

Monitoreo de seguridad en la nube