🥇Monitoreo de seguridad en la nube

La migración de datos y aplicaciones a la nube presenta un nuevo desafío para los SOC empresariales, que no siempre están preparados para monitorear la infraestructura de terceros. Según datos de Netskope, la empresa promedio (aparentemente en EE. UU.) utiliza 1246 diferentes servicios en la nube, lo que representa un aumento del 22% en comparación con el año pasado. ¡1246 servicios en la nube! 175 de ellos están relacionados con servicios de recursos humanos, 170 con marketing, 110 en el área de comunicaciones y 76 en finanzas y CRM. En Cisco se utilizan “solo” 700 servicios en la nube externos. Por lo tanto, estos números me generan un poco de desconcierto. Pero en cualquier caso, el problema no radica en ellos, sino en que cada vez más empresas comienzan a utilizar la nube con la esperanza de tener las mismas capacidades de monitoreo de infraestructura en la nube que en su propia red. Y esta tendencia está en aumento; según datos de la Oficina de Responsabilidad Gubernamental de EE. UU., en 2023 se espera que se cierren 1200 centros de datos (6250 ya han cerrado). Pero el cambio a la nube no es simplemente “vamos a trasladar nuestros servidores a un proveedor externo”. Es una nueva arquitectura de TI, nuevo software, nuevos procesos, nuevas restricciones... Todo esto introduce cambios significativos no solo en TI sino también en seguridad informática. Y aunque los proveedores han aprendido a manejar la seguridad de la nube (afortunadamente hay muchas recomendaciones disponibles), el monitoreo de la seguridad en la nube, especialmente en plataformas SaaS, presenta desafíos significativos, y de ello hablaremos.

Supongamos que su empresa ha trasladado parte de su infraestructura a la nube… Detente. No es así. Si la infraestructura ya ha sido trasladada y ahora te preguntas cómo la vas a monitorear, ya estás perdido. Si no es Amazon, Google o Microsoft (y aun así con reservas), es probable que no tengas muchas opciones para monitorear tus datos y aplicaciones. Es bueno si te dan acceso a los logs. A veces, los datos sobre eventos de seguridad estarán disponibles, pero no tendrás acceso a ellos. Por ejemplo, en Office 365. Si tienes la licencia más barata E1, no tendrás acceso a eventos de seguridad. Con la licencia E3, los datos se almacenan solo por 90 días y solo con la E5, la duración de los logs está disponible durante un año (aunque aquí también hay matices, relacionados con la necesidad de solicitar funciones específicas de log a Microsoft Support). Por cierto, la licencia E3 es mucho más limitada en términos de funciones de monitoreo que un Exchange corporativo. Para lograr el mismo nivel, necesitas una licencia E5 o una licencia adicional de Advanced Compliance, que podrían requerir costos adicionales no incluidos en tu modelo financiero para la migración a la infraestructura en la nube. Y este es solo un ejemplo de la subestimación de las cuestiones relacionadas con el monitoreo de la seguridad en la nube. En este artículo, sin pretender ser exhaustivo, quiero señalar algunos matices que debes considerar al elegir un proveedor de nube desde el punto de vista de la seguridad. Al final del artículo, se proporcionará una lista de verificación que debes completar antes de considerar que el tema del monitoreo de la seguridad en la nube está resuelto.

Se pueden identificar varios problemas típicos que conducen a incidentes en entornos en la nube, a los que los servicios de seguridad no pueden reaccionar o no los ven en absoluto:

No existen logs de seguridad. Esta es una situación bastante común, especialmente entre los nuevos actores en el mercado de soluciones en la nube. Pero no hay que descartarlos de inmediato. Los jugadores más pequeños, especialmente los locales, son más sensibles a las demandas de los clientes y pueden implementar rápidamente funciones demandadas, alterando su hoja de ruta aprobada. Sí, no será un equivalente de GuardDuty de Amazon o del módulo “Protección Proactiva” de Bitrix, pero al menos algo.
La ciberseguridad no sabe dónde se almacenan los registros o si tiene acceso a ellos. Aquí es necesario negociar con el proveedor de servicios en la nube; tal vez él proporcione esa información si considera al cliente importante para sí mismo. Pero en general, no es buena práctica que el acceso a los registros se conceda "por decisión especial".
También puede ocurrir que el proveedor de la nube tenga registros, pero estos ofrecen una monitorización limitada y un registro de eventos insuficiente para detectar todos los incidentes. Por ejemplo, pueden proporcionarle solo los registros de cambios en el sitio o los registros de intentos de autenticación de usuarios, pero no otros eventos, como el tráfico de red, lo que oculta una serie de sucesos característicos de los intentos de penetración en su infraestructura en la nube.
Los registros existen, pero acceder a ellos es difícil de automatizar, lo que obliga a monitorizarlos no de forma continua, sino en intervalos programados. Y si además no se pueden exportar los registros automáticamente, la carga de registros, por ejemplo, en formato Excel (como ocurre con algunos proveedores locales de soluciones en la nube), puede llevar a que el departamento corporativo de ciberseguridad no quiera lidiar con ellos.
No hay monitorización de registros. Esta es, quizás, la razón más confusa de los incidentes de ciberseguridad en entornos en la nube. Parece que hay registros y que se puede automatizar el acceso a ellos, pero nadie lo hace. ¿Por qué?

Concepto de seguridad compartida en la nube

La transición a la nube siempre implica buscar un equilibrio entre el deseo de mantener el control sobre la infraestructura y confiarla a manos más profesionales de un proveedor de nube que se especializa en su mantenimiento. Y en el ámbito de la seguridad de los entornos en la nube, también es necesario buscar ese equilibrio. Más aún, dado que dependiendo del modelo de prestación de servicios en la nube utilizado (IaaS, PaaS, SaaS), este equilibrio variará con el tiempo. En cualquier caso, hay que recordar que hoy en día todos los proveedores de nube siguen el llamado modelo de responsabilidad compartida y seguridad compartida. El proveedor de nube es responsable de algunos aspectos, mientras que el cliente que aloja sus datos, aplicaciones, máquinas virtuales y otros recursos en la nube es responsable de otros. Sería imprudente pensar que al mudarnos a la nube podemos trasladar toda la responsabilidad al proveedor. Pero tampoco es razonable construir toda la seguridad de forma independiente al hacer la transición a la nube. Se necesita un equilibrio que dependerá de una variedad de factores: — la estrategia de gestión de riesgos, el modelo de amenazas, los mecanismos de protección que tenga el proveedor de nube, las regulaciones, etc.

Por ejemplo, la clasificación de los datos almacenados en la nube siempre es responsabilidad del cliente. El proveedor de nube o el proveedor de servicios externo solo puede ayudarle con herramientas que faciliten la etiquetación de datos en la nube, identificar infracciones, eliminar datos que infrinjan la legislación o enmascararlos mediante algún método. Por otro lado, la seguridad física siempre es responsabilidad del proveedor de nube, la cual no puede compartir con los clientes. Todo lo que se encuentra entre los datos y la infraestructura física es el tema de discusión de este artículo. Por ejemplo, la disponibilidad de la nube es responsabilidad del proveedor, mientras que la configuración de las reglas de CISO o la habilitación de la encriptación son responsabilidades del cliente. En este artículo intentaremos ver 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 aplicación y cuándo es conveniente considerar soluciones externas (por ejemplo, Cisco E-mail Security) que amplían las capacidades de su nube en términos de ciberseguridad. En algunos casos, especialmente si se sigue una estrategia multicloud, no tendrá más opción que usar soluciones externas de monitoreo de seguridad de la información en varios entornos de nube (por ejemplo, Cisco CloudLock o Cisco Stealthwatch Cloud). En otros casos, se dará cuenta de que el proveedor de nube que ha elegido (o le ha sido impuesto) no ofrece ninguna opción para el monitoreo de seguridad de la información. Esto es desagradable, pero también es útil, ya que permite evaluar adecuadamente el nivel de riesgo asociado con trabajar con esa nube.

Ciclo de vida del monitoreo de seguridad en la nube

Para monitorear la seguridad de las nubes que utiliza, tiene solo tres opciones:

confiar en las herramientas proporcionadas por su proveedor de nube,
utilizar soluciones de terceros que monitorearán las plataformas IaaS, PaaS o SaaS que está utilizando,
construir su propia infraestructura de monitoreo de entornos de nube (solo para plataformas IaaS/PaaS).

Veamos cuáles son las características de cada una de estas opciones. Pero primero necesitamos entender el esquema general que se utilizará para monitorear las plataformas en la nube. Identificaría 6 componentes principales del proceso de monitoreo de seguridad en la nube:

Preparación de la infraestructura. Definición de las aplicaciones y la infraestructura necesarias para la recolección de eventos importantes para la seguridad, en un almacenamiento.
Recolección. En esta etapa, los eventos de seguridad se agregan desde diversas fuentes para su posterior transmisión para procesamiento, almacenamiento y análisis.
Procesamiento. En esta etapa, los datos se transforman y enriquecen para facilitar su análisis posterior.
Almacenamiento. Este componente es responsable del almacenamiento a corto y largo plazo de los datos procesados y 'crudos' recogidos.
Análisis. En esta etapa, usted tiene la oportunidad de detectar incidentes y responder a ellos de manera automática o manual.
Informes. Esta etapa ayuda a formar para las partes interesadas (dirección, auditores, proveedor de la nube, clientes, etc.) indicadores clave que nos ayudarán a tomar decisiones, como cambiar de proveedor o fortalecer la seguridad.

Entender estos componentes le permitirá en el futuro decidir rápidamente qué puede obtener de su proveedor y qué tendrá que hacer usted mismo o con la ayuda de consultores externos.

Funciones integradas de los servicios en la nube

Ya he mencionado anteriormente que muchos servicios en la nube hoy en día no ofrecen ninguna posibilidad de monitoreo de seguridad de la información. En general, prestan poca atención al tema de la seguridad. Por ejemplo, uno de los servicios rusos populares para enviar informes a las autoridades estatales a través de Internet (no mencionaré su nombre intencionalmente). Todo el apartado sobre la seguridad de este servicio gira en torno a la aplicación de sistemas certificados de seguridad de información. La sección sobre seguridad de otro servicio en la nube nacional para la documentación electrónica es mucho más extensa. Habla sobre certificados de clave pública, criptografía certificada, eliminación de vulnerabilidades web, protección contra ataques DDoS, aplicación de estándares de seguridad, copias de seguridad e incluso auditorías regulares de seguridad de la información. Pero no menciona nada sobre la monitorización, ni sobre la posibilidad de acceder a eventos de seguridad que puedan ser de interés para los clientes de este proveedor de servicios.

En general, a partir de cómo un proveedor de servicios en la nube describe en su sitio web y en la documentación los temas de seguridad de la información, se puede entender cuán seriamente se toman este asunto. Por ejemplo, si se leen las guías de los productos "Mi Oficina", no hay ni una palabra sobre seguridad, mientras que en la documentación de un producto específico "Mi Oficina. KS3", destinado a proteger contra accesos no autorizados, hay simplemente una enumeración de los puntos del 17º decreto del FSTEK que cumple "Mi Oficina.KS3", pero no se explica cómo lo hace y, lo más importante, cómo integrar estos mecanismos con la seguridad de la información corporativa. Puede que dicha documentación exista, pero no la encontré en el acceso público en el sitio de "Mi Oficina". Aunque tal vez simplemente no tenga acceso a esta información secreta...

La situación para la misma plataforma Bitrix es significativamente mejor. En la documentación se describen los formatos de los registros de eventos y, lo que es interesante, el registro de intrusiones, que contiene eventos relacionados con amenazas potenciales para la plataforma en la nube. Desde allí, puede extraer la IP, el nombre de usuario o de visitante, el origen del evento, la hora, el User Agent, el tipo de evento, etc. Sin embargo, trabajar con estos eventos solo puede hacerse a través del panel de control de la nube misma, o puede exportar los datos en formato MS Excel. Automatizar el trabajo con los registros de Bitrix es actualmente complicado y tendrá que realizar parte del trabajo manualmente (exportando el informe y cargándolo en su SIEM). Pero si recordamos que relativamente hace poco no existía tal posibilidad, esto representa un gran avance. Cabe destacar que muchos proveedores de nube extranjeros también ofrecen funciones similares

Si no se considera la opción de no contar con registros, los proveedores de nube suelen ofrecerle tres opciones para monitorear eventos de seguridad: paneles de control, exportación de datos y acceso a través de API. La primera parece resolver muchos problemas por usted, pero no es del todo así: al tener múltiples registros, se debe alternar entre las pantallas que los muestran, perdiendo la visión general. Además, es poco probable que el proveedor de la nube le brinde la posibilidad de correlacionar eventos de seguridad y analizarlos desde la perspectiva de la seguridad (generalmente se trata de datos en bruto que debe analizar por su cuenta). Existen excepciones y de ello hablaremos más adelante. Por último, vale la pena preguntar qué eventos registra su proveedor de nube, en qué formato, y cuán alineados están con su proceso de monitoreo de seguridad de la información (SI). Por ejemplo, la identificación y autenticación de usuarios y visitantes. El mismo Bitrix le permite registrar, a partir de estos datos de eventos, la fecha y hora del evento, el nombre del usuario o del visitante (si cuenta con el módulo “Web Analytics”), el objeto al que se accedió y otros elementos típicos de un sitio web. Pero los servicios corporativos de SI pueden requerir información sobre si el usuario accedió a la nube desde un dispositivo de confianza (por ejemplo, en la red corporativa, esta tarea la realiza Cisco ISE). ¿Y una tarea tan sencilla como la función de geo-IP, que ayuda a determinar si la cuenta del usuario del servicio en la nube ha sido robada? E incluso si el proveedor de nube se la proporciona, eso es insuficiente. Cisco CloudLock no solo analiza la geolocalización, sino que utiliza aprendizaje automático y analiza datos históricos de cada usuario y rastrea diversas anomalías en los intentos de identificación y autenticación. Una funcionalidad similar solo la tiene MS Azure (con la suscripción correspondiente).

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

Por lo tanto, sigue de cerca todas las funciones de monitoreo que te ofrece tu proveedor de nube. O confía en proveedores externos de soluciones que actúen como intermediarios entre tu SOC y la nube que deseas monitorear. Sí, esto será más costoso (aunque no siempre), pero así transfieres toda la responsabilidad a otros. ¿O no toda? Recordemos el concepto de seguridad compartida y entendamos que no podremos transferir nada: tendrás que entender por ti mismo cómo los diferentes proveedores de nube garantizan el monitoreo de la seguridad de tus datos, aplicaciones, máquinas virtuales y otros recursos alojados en la nube. Y comenzaremos con lo que ofrece Amazon en este área.

Ejemplo: Monitoreo de Seguridad de la Información en IaaS basado en AWS

Sí, entiendo que Amazon no es el mejor ejemplo ya que es un servicio estadounidense y puede ser bloqueado en el marco de la lucha contra el extremismo y la difusión de información prohibida en Rusia. Pero en esta publicación, me gustaría simplemente mostrar cuán diferentes son las plataformas en la nube en cuanto a sus capacidades de monitoreo de seguridad de la información y qué aspectos deben considerarse al transferir procesos clave a la nube desde la perspectiva de la seguridad. Y si algunos de los desarrolladores rusos de soluciones en la nube obtienen algo útil de esto, sería genial.

Primero hay que decir que Amazon no es una fortaleza inexpugnable. Sus clientes enfrentan regularmente diversos incidentes. Por ejemplo, en Deep Root Analytics se robaron nombres, direcciones, fechas de nacimiento y teléfonos de 198 millones de votantes. A la empresa israelí Nice Systems se le robaron 14 millones de registros de abonados 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 comandos)
compromiso de cuenta y acceso no autorizado
configuraciones incorrectas y vulnerabilidades
interfaces y API no protegidas.

Esta discrepancia se debe a que, como hemos descubierto anteriormente, la seguridad de los datos del cliente es responsabilidad del propio cliente. Y si no se ha preocupado por activar los mecanismos de protección y no ha implementado herramientas de monitoreo, solo se enterará del incidente a través de los medios de comunicación o de sus propios clientes.

Para detectar incidentes, se puede utilizar una amplia gama de servicios de monitoreo desarrollados por Amazon (aunque a menudo se complementan con herramientas externas, como osquery). Así, en AWS se rastrean todas las acciones de los usuarios, independientemente de cómo se realicen: 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 acciones de cada cuenta de AWS (incluyendo el nombre del usuario, la acción, el servicio, los parámetros de actividad y su resultado) y el uso de la API están disponibles a través del servicio AWS CloudTrail. Puede ver estos eventos (por ejemplo, el inicio de sesión en la consola de AWS IAM) desde la consola de CloudTrail, analizarlos con Amazon Athena o

dejar que sean procesados por soluciones externas, como Splunk, AlienVault, etc. Los propios registros de AWS CloudTrail se almacenan en su bucket de AWS S3. Dos servicios adicionales de AWS proporcionan otra serie de importantes capacidades de monitoreo. En primer lugar, Amazon CloudWatch es un servicio de monitoreo de recursos y aplicaciones de AWS, que permite, entre otras cosas, detectar distintas 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 usar la API abierta de Amazon CloudWatch para agregar funciones de monitoreo de registros a aplicaciones y servicios personalizados, lo que permite ampliar el rango de eventos analizados en el contexto de la ciberseguridad.

En segundo lugar, el servicio VPC Flow Logs permite analizar el tráfico de red que es enviado o recibido por sus servidores de AWS (desde afuera o desde adentro), así como entre microservicios. Cuando alguno de sus recursos de AWS VPC interactúa con la red, el servicio VPC Flow Logs registra información sobre el tráfico de red, incluyendo la interfaz de red de origen y destino, así como direcciones IP, puertos, protocolo, número de bytes y cantidad de paquetes que han sido vistos. Aquellos con experiencia en seguridad de redes locales reconocerán esto como análogo a los flujos. NetFlow, que pueden ser generados por conmutadores, enrutadores y cortafuegos de nivel empresarial. Estos registros son importantes para los fines de monitorización de ciberseguridad, ya que, a diferencia de los eventos sobre acciones de usuarios y aplicaciones, permiten no pasar por alto también las interacciones de red en un entorno de nube privada virtual AWS.

Por lo tanto, estos tres servicios de AWS — AWS CloudTrail, Amazon CloudWatch y VPC Flow Logs — juntos proporcionan una representación suficientemente efectiva del uso de su cuenta, el comportamiento de los usuarios, la gestión de la infraestructura, la actividad de aplicaciones y servicios, así como la actividad de red. Por ejemplo, con su ayuda se pueden detectar las siguientes anomalías:

Intentos de escaneo del sitio, búsqueda de puertas traseras, búsqueda de vulnerabilidades a través de picos en “errores 404”.
Ataques de inyección (por ejemplo, inyección SQL) a través de picos en “errores 500”.
Herramientas conocidas para ataques como sqlmap, nikto, w3af, nmap, etc. a través del análisis del campo User Agent.

Amazon Web Services ha desarrollado otros servicios con fines de ciberseguridad que permiten abordar muchas otras tareas. Por ejemplo, en AWS hay un servicio integrado para la auditoría de políticas y configuraciones: AWS Config. Este servicio proporciona una auditoría continua de sus recursos de AWS y sus configuraciones. Consideremos un ejemplo simple: supongamos que desea asegurarse de que las contraseñas de los usuarios estén desactivadas en todos sus servidores y que el acceso sea posible solo mediante certificados. AWS Config facilita la verificación de esto para todos sus servidores. Existen otras políticas que pueden aplicarse a sus servidores en la nube: "Ningún servidor puede usar el puerto 22", "Solo los administradores pueden modificar 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, se amplió el servicio AWS Config para automatizar la detección de violaciones de las políticas diseñadas. Las AWS Config Rules son, en esencia, consultas continuas de configuración de los servicios de Amazon que usted utiliza, que generan eventos en caso de violaciones de las políticas correspondientes. Por ejemplo, en lugar de realizar consultas periódicas a AWS Config para verificar que todos los discos del servidor virtual estén cifrados, se pueden utilizar AWS Config Rules para comprobar de forma continua los discos del servidor en cuanto al cumplimiento de esta condición. Y lo más importante, en el contexto de esta publicación, cualquier violación genera eventos que pueden ser analizados por su servicio de seguridad de la información.

AWS también cuenta con sus equivalentes a las soluciones tradicionales de ciberseguridad empresarial, que también generan eventos de seguridad que usted puede y debe analizar:

detección de intrusiones: AWS GuardDuty
control de filtraciones de información: AWS Macie
EDR (aunque hablar de dispositivos de punto en la nube suena un poco extraño): AWS Cloudwatch + soluciones de código abierto osquery o GRR
análisis de Netflow: AWS Cloudwatch + AWS VPC Flow
análisis de DNS: AWS Cloudwatch + AWS Route53
AD: AWS Directory Service
gestión de cuentas: AWS IAM
SSO: AWS SSO
análisis de seguridad: AWS Inspector
gestión de configuraciones: AWS Config
WAF: AWS WAF.

No voy a detallar todos los servicios de Amazon que pueden ser útiles en el contexto de la seguridad informática. 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 tanto las capacidades integradas de Amazon como soluciones externas, como SIEM, que pueden recoger eventos de seguridad en su centro de monitoreo y analizarlos allí junto con eventos de otros servicios en la nube o de la infraestructura interna, el perímetro o dispositivos móviles.

En cualquier caso, todo comienza con las fuentes de datos que le proporcionan eventos de seguridad de la información. Entre estas fuentes se pueden incluir, entre otras:

CloudTrail — uso de API y acciones de usuarios
Trusted Advisor — verificación de seguridad con respecto a las mejores prácticas
Config — inventario y configuración de cuentas y ajustes de servicios
VPC Flow Logs — conexiones con interfaces virtuales
IAM — servicio de identificación y autenticación
ELB Access Logs — registros del balanceador de carga
Inspector — vulnerabilidades en aplicaciones
S3 — almacenamiento de archivos
CloudWatch — actividad de aplicaciones
SNS — servicio de notificaciones.

Amazon, al ofrecer una amplia gama de fuentes de eventos y herramientas para su generación, está bastante limitado en sus capacidades para analizar los datos recopilados en el contexto de la seguridad de la información. Tendrá que estudiar por su cuenta los registros disponibles, buscando en ellos los indicadores relevantes de compromiso. AWS Security Hub, que Amazon lanzó recientemente, tiene como objetivo resolver este problema, actuando como un SIEM en la nube para AWS. Sin embargo, todavía está en sus primeras etapas y está limitado tanto en el número de fuentes con las que trabaja como en otras restricciones impuestas por la arquitectura y las suscripciones de Amazon.

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

No quiero entrar en un debate largo sobre cuál de los tres proveedores de nube (Amazon, Microsoft o Google) es mejor (especialmente porque cada uno tiene su propia especificidad y se ajusta a diferentes objetivos); centrémonos en las capacidades de monitoreo de seguridad que ofrecen estos actores. Hay que reconocer que Amazon AWS fue uno de los primeros en este segmento y, por lo tanto, ha avanzado más que los demás en términos de sus funciones de seguridad (aunque muchos reconocen que utilizarlas puede ser complicado). Sin embargo, eso no significa que ignoremos las capacidades que nos ofrecen Microsoft y Google.

Los productos de Microsoft siempre se han caracterizado por su “apertura” y en Azure la situación es similar. Por ejemplo, mientras que AWS y GCP siempre parten del concepto de “toda acción no permitida está prohibida”, Azure tiene un enfoque completamente 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 por defecto. Por lo 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. Esto también impone requisitos más estrictos en términos de monitoreo de actividades en la nube de Azure.

AWS tiene una característica particular en relación con la monitorización de sus recursos virtuales: si se encuentran en diferentes regiones, surgen dificultades para consolidar todos los eventos y analizarlos de manera unificada. Para solucionar esto, es necesario recurrir a diferentes trucos, como crear su propio código para AWS Lambda que transfiera eventos entre regiones. En Azure, no existe tal problema: su mecanismo de Activity Log rastrea toda la actividad dentro de toda la organización sin restricciones. Lo mismo ocurre con AWS Security Hub, que fue desarrollado recientemente por Amazon para consolidar muchas funciones de seguridad en un único centro de seguridad, pero solo dentro de su región, algo que, para Rusia, no es relevante. Azure cuenta con su propio Security Center, que no está sujeto a restricciones regionales, proporcionando acceso a todas las funciones de seguridad de la plataforma en la nube. Además, para diferentes equipos locales, puede ofrecer su propio conjunto de capacidades de protección, incluidos eventos de seguridad gestionados por ellos. AWS Security Hub aún está trabajando para asemejarse a Azure Security Center. Sin embargo, hay que agregar un punto negativo: se puede extraer mucho de Azure que anteriormente se describió en AWS, pero esto se realiza de manera más conveniente solo para Azure AD, Azure Monitor y Azure Security Center. Los demás mecanismos de protección de Azure, incluyendo el análisis de eventos de seguridad, aún se gestionan de una manera que no es la más conveniente. En parte, el problema se soluciona con un API que abarca todos los servicios de Microsoft Azure, pero esto requerirá un esfuerzo adicional por su parte para integrar su nube con su SOC y contar con personal calificado (como ocurre con cualquier otro SIEM que trabaje con APIs en la nube). Algunos SIEM, de los que se hablará a continuación, ya son compatibles con Azure y pueden automatizar la tarea de su monitorización, pero también presentan sus propios desafíos: no todos pueden extraer todos los registros que Azure tiene.

La recopilación y el monitoreo de eventos en Azure se lleva a cabo a través del servicio Azure Monitor, que es la herramienta principal para la recopilación, almacenamiento y análisis de datos en la nube de Microsoft y sus recursos: repositorios de Git, contenedores, máquinas virtuales, aplicaciones, etc. Todos los datos que recopila Azure Monitor se dividen en dos categorías: métricas, que se recopilan en tiempo real y describen los indicadores clave de rendimiento de la nube de Azure, y registros de actividad, que contienen datos organizados en entradas que caracterizan varios aspectos del funcionamiento de los recursos y servicios de Azure. Además, mediante la API de recopilador de datos, el servicio Azure Monitor puede recolectar datos de cualquier fuente REST para construir sus propios escenarios de monitoreo.

Aquí hay algunas fuentes de eventos de seguridad que Azure le ofrece y que puede acceder a través del Portal de Azure, CLI, PowerShell o REST API (y algunas solo a través de Azure Monitor / Insight API):

Los registros de actividad: este registro responde a las preguntas clásicas de “quién”, “qué” y “cuándo” en relación con cualquier operación de escritura (PUT, POST, DELETE) sobre recursos en la nube. Los eventos relacionados con el acceso de lectura (GET) no se registran en este registro, al igual que otros eventos.
Registros de diagnóstico: contiene datos sobre las operaciones realizadas con recursos incluidos en su suscripción.
Informes de Azure AD: contiene tanto la actividad del usuario como la actividad del sistema relacionada con la gestión de grupos y usuarios.
Registro de eventos de Windows y Syslog de Linux: contiene eventos de las máquinas virtuales alojadas en la nube.
Métricas: contiene telemetría sobre el estado de rendimiento y ‘salud’ de sus servicios y recursos en la nube. Se miden cada minuto y se almacenan durante 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 la supervisión de recursos a nivel de red.
Registros de almacenamiento: contiene eventos relacionados con el acceso a los almacenes.

Para la supervisión, puede utilizar SIEM externos o el Azure Monitor integrado y sus extensiones. Hablaremos sobre los sistemas de gestión de eventos de seguridad más adelante, pero por ahora veamos lo que Azure nos ofrece 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 Control de Seguridad y Auditoría de Log Analytics (la versión gratuita admite el almacenamiento de una cantidad limitada de eventos durante solo una semana). Este panel se divide en 5 áreas principales que visualizan estadísticas resumidas sobre lo que está sucediendo en el entorno en la nube que está utilizando:

Dominios de Seguridad — indicadores cuantitativos clave relacionados con la seguridad, como el número de incidentes, el número de nodos comprometidos, los nodos no parcheados, eventos de seguridad de red, etc.
Problemas Notables — muestra el número y la importancia de los problemas activos de seguridad
Detecciones — muestra los patrones de ataques utilizados en su contra
Inteligencia de Amenazas — muestra información geográfica sobre los nodos externos que lo atacan
Consultas de seguridad comunes — consultas típicas que le ayudarán a monitorear mejor su seguridad.

Como extensiones de Azure Monitor, podemos mencionar Azure Key Vault (protección de claves criptográficas en la nube), Malware Assessment (análisis de la protección contra malware en máquinas virtuales), Azure Application Gateway Analytics (análisis, entre otros, de registros de firewall en la nube), etc. Estas herramientas, enriquecidas con ciertas reglas de procesamiento de eventos, permiten visualizar diversos aspectos de las actividades de servicios en la nube, incluida la seguridad, y detectar desviaciones en su funcionamiento. Pero, como suele suceder, cualquier funcionalidad adicional requiere de una suscripción de pago correspondiente, lo que requerirá de inversiones financieras que debe planificar con anticipación.

Azure cuenta con una serie de capacidades integradas para la monitorización de amenazas, que están integradas en Azure AD, Azure Monitor y Azure Security Center. Entre ellas se incluyen, por ejemplo, la detección de interacciones de máquinas virtuales con direcciones IP maliciosas conocidas (gracias a la integración con los servicios de Threat Intelligence de Microsoft), la detección de malware en la infraestructura de la nube mediante señales de alarma de máquinas virtuales desplegadas en la nube, ataques de tipo 'fuerza bruta' en máquinas virtuales, vulnerabilidades en la configuración del sistema de identificación de usuarios, acceso desde anonymizers o nodos infectados, filtraciones de cuentas, acceso desde ubicaciones inusuales, etc. Hoy en día, Azure es uno de los pocos proveedores de servicios en la nube que ofrece capacidades integradas de Threat Intelligence para enriquecer los eventos de seguridad recopilados.

Como se mencionó anteriormente, la funcionalidad de protección y, por ende, los eventos de seguridad generados, no están disponibles para todos los usuarios de igual manera, y requieren una suscripción específica que incluya la funcionalidad deseada, que genera los correspondientes eventos para la monitorización de seguridad. Por ejemplo, parte de las funciones de monitorización de anomalías en las cuentas descritas en el párrafo anterior solo están disponibles en la licencia premium P2 para el servicio Azure AD. Sin ella, al igual que en AWS, tendrás que analizar los eventos de seguridad recopilados 'manualmente'. Además, dependiendo del tipo de licencia de Azure AD, no todos los eventos estarán disponibles para análisis.

En el portal de Azure, puedes gestionar tanto las consultas a los registros que te interesen como personalizar paneles para visualizar indicadores clave de seguridad. Además, allí puedes seleccionar extensiones de Azure Monitor que te 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 un centro de seguridad integral para su plataforma en la nube Azure, que incluya la gestión de políticas de ciberseguridad, se puede hablar de la necesidad de trabajar con Azure Security Center, cuyas funciones más útiles están disponibles por un costo adicional, como la detección de amenazas, monitoreo fuera de Azure, evaluación de cumplimiento, entre otros (en la versión gratuita solo tiene acceso a la evaluación de seguridad y recomendaciones para abordar problemas identificados). Concentra todas las cuestiones de seguridad en un solo lugar. En esencia, se puede hablar de un nivel más alto de seguridad cibernética que el que proporciona Azure Monitor, ya que en este caso los datos recolectados en toda su nube se enriquecen a través de múltiples 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 aplican varios algoritmos sofisticados de aprendizaje automático y análisis de comportamiento, lo que en última instancia debería mejorar la eficacia de la detección de amenazas y la respuesta a las mismas.

Azure también tiene su propio SIEM, que apareció a principios de 2019. Este es Azure Sentinel, que se basa en datos de Azure Monitor y también puede integrarse con soluciones de seguridad externas (por ejemplo, NGFW o WAF), cuya lista se actualiza constantemente. Además, gracias a la integración de Microsoft Graph Security API, tiene la posibilidad de conectar a Sentinel sus propios feeds de Threat Intelligence, lo que enriquece las capacidades para el análisis de incidentes en su nube Azure. Se puede afirmar que Azure Sentinel es el primer SIEM 'nativo' que ha surgido entre los proveedores de nube (las mismas Splunk o ELK, que se pueden alojar en la nube, por ejemplo, AWS, no fueron desarrolladas por proveedores de servicios de nube tradicionales). Azure Sentinel y Security Center podrían considerarse como el SOC para la nube Azure, y se podría limitar a ellos (con ciertas salvedades), si no tuviera otra infraestructura y hubiera trasladado todos sus recursos computacionales a la nube, y esta fuera la nube de Microsoft Azure.

Sin embargo, dado que las capacidades integradas de Azure (incluso con una suscripción a Sentinel) a menudo son insuficientes para el monitoreo de ciberseguridad y la integración de este proceso con otras fuentes de eventos de seguridad (tanto en la nube como internas), surge la necesidad de exportar los datos recopilados a sistemas externos, entre los cuales puede incluirse un SIEM. Esto se realiza tanto a través de API como mediante extensiones especiales que actualmente solo están disponibles oficialmente para los siguientes SIEM: Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight y ELK. Recientemente, había más SIEM, pero desde el 1 de junio de 2019, Microsoft ha dejado de dar soporte a Azure Log Integration Tool (AzLog), que en los primeros días de Azure y ante la falta de una normalización adecuada en el trabajo con logs (incluso Azure Monitor aún no existía), permitía una fácil integración de SIEM externos con la nube de Microsoft. Ahora la situación ha cambiado y Microsoft recomienda la plataforma Azure Event Hub como la herramienta principal de integración para otros SIEM. Muchos ya han realizado dicha integración, pero ten cuidado: pueden no capturar todos los logs de Azure, sino solo algunos (consulte la documentación de su SIEM).

Al concluir un breve recorrido por Azure, quiero hacer una recomendación general sobre este servicio en la nube: antes de afirmar algo acerca de las funciones de monitoreo de seguridad en Azure, es crucial configurarlas con mucho cuidado y probar que funcionen tal como se describe en la documentación y como te han explicado los consultores de Microsoft (quienes pueden tener diferentes opiniones sobre la efectividad de las funciones de Azure). Si cuentas con recursos financieros suficientes, puedes sacar mucho provecho de Azure en términos de monitoreo de seguridad. Sin embargo, si tus recursos son limitados, al igual que con AWS, tendrás que confiar solo en tus propias capacidades y en los datos en bruto que te proporciona Azure Monitor. Y recuerda que muchas funciones de monitoreo tienen un costo, así que es mejor familiarizarse con la política de precios con anticipación. Por ejemplo, puedes almacenar datos de forma gratuita durante 31 días con un volumen no superior a 5 GB por cliente; superar estos límites te costará un extra (aproximadamente más de 2 dólares por cada GB adicional y 0.1 dólares por cada GB adicional por mes). Trabajar con la telemetría de aplicaciones y métricas también podría requerir fondos adicionales, al igual que la gestión de alertas y notificaciones (hay un límite gratuito que podría no ser suficiente para tus necesidades).

Ejemplo: Monitoreo de seguridad en IaaS basado en Google Cloud Platform

Google Cloud Platform, en comparación con AWS y Azure, parece un recién llegado, pero en parte eso es algo positivo. A diferencia de AWS, que ha ido expandiendo sus capacidades, incluidas las de seguridad, de manera gradual y ha lidiado con problemas de centralización; GCP, al igual que Azure, se gestiona de manera mucho más centralizada, lo que reduce el número de errores y el tiempo de implementación en la empresa. Desde el punto de vista de la seguridad, GCP se sitúa, curiosamente, entre AWS y Azure. También cuenta con un registro de eventos unificado para toda la organización, pero es incompleto. Algunas funciones aún están en fase beta, aunque poco a poco este inconveniente debería ser solucionado, y GCP se convertirá en una plataforma más madura en términos de monitoreo de seguridad.

La herramienta principal para registrar eventos en GCP es Stackdriver Logging (similar a Azure Monitor), que permite recopilar eventos de toda su infraestructura en la nube (incluyendo AWS). Desde el punto de vista de la seguridad, en GCP cada organización, proyecto o carpeta tiene cuatro registros de auditoría:

Admin Activity — contiene todos los eventos relacionados con el acceso administrativo, como la creación de una máquina virtual, el cambio de permisos, etc. Este registro se escribe siempre, independientemente de su deseo, y almacena sus datos durante 400 días.
Data Access — incluye todos los eventos relacionados con las operaciones de los usuarios de la nube (creación, modificación, lectura, etc.). Por defecto, este registro no se crea, ya que su tamaño puede aumentar rápidamente. Por esta razón, su período de retención es solo de 30 días. Además, no todos los eventos se registran en este registro. Por ejemplo, no se registran eventos relacionados con recursos que son públicamente accesibles para todos los usuarios o que se pueden acceder sin iniciar sesión en GCP.
System Event — registra eventos del sistema que no están relacionados con los usuarios, o acciones del administrador que cambian la configuración de los recursos en la nube. Se graba siempre y se retiene durante 400 días.
Access Transparency — es un ejemplo único de registro que captura todas las acciones de los empleados de Google (aunque no está disponible para todos los servicios de GCP) que acceden a su infraestructura en el curso de sus funciones laborales. Este registro se conserva durante 400 días y no está disponible para todos los clientes de GCP, y solo bajo ciertas condiciones (o soporte de nivel Gold o Platinum, o tener cuatro roles de un tipo específico en el marco del soporte corporativo). Funciones similares están disponibles, por ejemplo, en Office 365 — Lockbox.

Ejemplo de registro: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "US"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "CA"
 }
 product: [
 0: "Almacenamiento en la Nube"
 ]
 reason: [
 detail: "Número de caso: bar123"
 type: "SUPPORT_INICIADO_POR_EL_CLIENTE"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "AVISO"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

El acceso a los registros mencionados es posible de varias maneras (de manera similar a Azure y AWS) — a través de la interfaz de Log Viewer, mediante API, utilizando Google Cloud SDK o a través de la página de Actividad de su proyecto, donde está interesado en los eventos. De la misma manera, también se pueden exportar a soluciones externas para un análisis adicional. Esto se realiza exportando los registros a BigQuery o Cloud Pub/Sub.

Además de Stackdriver Logging, la plataforma GCP ofrece funcionalidad adicional llamada Stackdriver Monitoring, que permite rastrear métricas clave (rendimiento, tiempo de inactividad, estado general, etc.) de los servicios y aplicaciones en la nube. Los datos procesados de manera especial y visualizados pueden facilitar la búsqueda de problemas en su infraestructura en la nube, incluyendo el contexto de seguridad. Sin embargo, es importante señalar que esta funcionalidad puede no ser muy completa en el ámbito de la ciberseguridad, ya que actualmente GCP no cuenta con un equivalente del AWS GuardDuty y no puede identificar eventos maliciosos entre todos los eventos registrados (Google ha desarrollado Event Threat Detection, pero por ahora está en beta y es temprano para evaluar su utilidad). Stackdriver Monitoring podría utilizarse como un sistema para la detección de anomalías, que luego serían investigadas para determinar su origen. Pero en un mercado donde hay escasez de personal calificado en ciberseguridad, esta tarea parece complicada en este momento.

También es importante listar algunos módulos de ciberseguridad que pueden aplicarse en su nube GCP, los cuales son similares a lo que ofrece AWS:

Cloud Security Command Center es el equivalente de AWS Security Hub y Azure Security Center.
Cloud DLP: detección y edición automática (por ejemplo, enmascaramiento) de datos alojados en la nube, de acuerdo a más de 90 políticas de clasificación predefinidas.
Cloud Scanner: escáner de vulnerabilidades conocidas (XSS, inyección de Flash, bibliotecas sin parches, etc.) en App Engine, Compute Engine y Google Kubernetes.
Cloud IAM: gestión de acceso a todos los recursos de GCP.
Cloud Identity: gestión de cuentas de usuario, dispositivos y aplicaciones de GCP desde una consola unificada.
Cloud HSM: protección de claves criptográficas.
Cloud Key Management Service: gestión de claves criptográficas en GCP.
VPC Service Control: creación de un perímetro seguro alrededor de sus recursos de GCP para protegerlos de fugas.
Titan Security Key: protección contra phishing.

Muchos de estos módulos generan eventos de seguridad que pueden ser enviados a BigQuery para análisis o exportados a otros sistemas, incluidos SIEM. Como se mencionó anteriormente, GCP es una plataforma en constante desarrollo y Google está trabajando en varios nuevos módulos de seguridad para su plataforma. Entre ellos se encuentra Event Threat Detection (actualmente disponible en beta), que escanea los registros de Stackdriver en busca de trazas de actividad no autorizada (similar a GuardDuty en AWS), o Policy Intelligence (disponible en alfa), que permitirá elaborar políticas de acceso inteligentes a los recursos de GCP.

He realizado un pequeño análisis de las capacidades integradas de monitoreo en las plataformas de nube más populares. Pero, ¿tienen especialistas capaces de trabajar con los registros 'en bruto' del proveedor de IaaS (no todos están dispuestos a comprar capacidades avanzadas de AWS, Azure o Google)? Además, es bien conocida la frase 'confía, pero verifica', que en el ámbito de la seguridad es más relevante que nunca. ¿Cuánto confía en las capacidades integradas del proveedor de nube que le ofrece eventos de seguridad? ¿Cuánto se enfocan realmente en la seguridad?

A veces es recomendable considerar soluciones de monitoreo de infraestructuras en la nube, que pueden complementar la seguridad integrada de la nube, y en ocasiones, tales soluciones son la única forma de obtener datos sobre la seguridad de sus datos y aplicaciones alojados en la nube. Además, son simplemente más convenientes, ya que asumen todas las tareas de análisis de los registros necesarios, generados por diferentes servicios en la nube de diversos proveedores de nube. Un ejemplo de tal solución de superposición es Cisco Stealthwatch Cloud, que se centra en una única tarea: el monitoreo de anomalías de seguridad en entornos de nube, que incluyen no solo Amazon AWS, Microsoft Azure y Google Cloud Platform, sino también nubes privadas.

Ejemplo: Monitoreo de seguridad con Stealthwatch Cloud

AWS proporciona una plataforma flexible para la computación, pero esta flexibilidad hace que las empresas sean más propensas a cometer errores que pueden conducir a problemas de seguridad. Y el modelo compartido de seguridad solo contribuye a esto. Ejecutar en la nube software con vulnerabilidades desconocidas (las conocidas pueden ser manejadas, por ejemplo, por AWS Inspector o GCP Cloud Scanner), contraseñas débiles, configuraciones incorrectas, insiders, etc. Y todo esto se refleja en el comportamiento de los recursos en la nube, que puede ser monitoreado por Cisco Stealthwatch Cloud, que es un sistema de monitoreo de seguridad y detección de ataques en nubes públicas y privadas.

Una de las características clave de Cisco Stealthwatch Cloud es la capacidad de modelar entidades. Con ello, se puede crear un modelo programático (es decir, una simulación casi en tiempo real) de cada uno de sus recursos en la nube (sin importar si se trata de AWS, Azure, GCP o algo diferente). Estos pueden incluir servidores y usuarios, así como tipos de recursos específicos de su entorno en la nube, como grupos de seguridad y grupos de escalado automático de servicios. Estos modelos utilizan como entrada flujos de datos estructurados proporcionados por los servicios en la nube. Por ejemplo, para AWS, se tratará de VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda y AWS IAM. La modelación de entidades detecta automáticamente el rol y el comportamiento de cualquiera de sus recursos (se puede hablar de la obtención de perfiles de toda la actividad en la nube). Entre estos roles se encuentran un dispositivo móvil Android o Apple, un servidor Citrix PVS, un servidor RDP, un gateway de correo electrónico, un cliente VoIP, un servidor terminal, un controlador de dominio, etc. Luego, realiza un seguimiento continuo de su comportamiento para determinar cuándo ocurre un comportamiento arriesgado o amenazante para la seguridad. Puede identificar intentos de fuerza bruta, ataques DDoS, filtraciones de datos, acceso remoto ilegal, actividades de malware, escaneos 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 una base de datos Postgress hacia un país con el que anteriormente no se había tenido interacción:

Finalmente, así es como se observa un número excesivo de intentos de acceso fallidos por SSH desde China e Indonesia desde un dispositivo remoto externo:

O supongamos que una instancia del servidor en VPC, de acuerdo con la política, nunca debe ser un punto de destino para el acceso remoto al sistema. Supongamos además que se produjo un ingreso remoto en este equipo debido a un cambio erróneo en la política de reglas de firewall. La función de modelado de entidades detectará y notificará esta actividad («Acceso remoto inusual») casi en tiempo real y señalará la llamada específica a la API de AWS CloudTrail, Azure Monitor o GCP Stackdriver Logging (incluyendo el nombre de usuario, la fecha y la hora, entre otros detalles) que provocó el cambio en la regla de MSE. A continuación, esta información puede ser entregada a SIEM para su análisis.

Funciones similares se implementan 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 detectar un problema previamente desconocido con su personal, procesos o tecnologías. Por ejemplo, permite identificar, entre otras cosas, los siguientes problemas de seguridad:

¿Se ha descubierto una puerta trasera en el software que utilizamos?
¿Hay algún software o dispositivo de terceros en nuestra nube?
¿Está un usuario autorizado abusando de sus privilegios?
¿Se cometió un error de configuración que permite el acceso remoto o el uso no intencionado de recursos?
¿Hay alguna filtración de datos desde nuestros servidores?
¿Alguien ha intentado conectarse con nosotros desde un lugar geográfico atípico?
¿Nuestra nube está infectada con código malicioso?

El evento de seguridad informática detectado puede ser enviado como un ticket correspondiente a Slack, Cisco Spark, el sistema de gestión de incidentes PagerDuty, y también puede ser transferido a varios SIEM, entre los cuales se encuentran Splunk o ELK. En resumen, se puede decir que si su empresa utiliza una estrategia multi-nube y no se limita a un solo proveedor de nube, las capacidades de monitoreo de seguridad informática descritas anteriormente hacen que el uso de Cisco Stealthwatch Cloud sea una buena opción para obtener un conjunto unificado de capacidades de monitoreo de los principales actores en la nube: Amazon, Microsoft y Google. Lo más interesante es que al comparar los precios de Stealthwatch Cloud con las licencias avanzadas de monitoreo de seguridad informática en AWS, Azure o GCP, puede resultar que la solución de Cisco es incluso más barata que las capacidades integradas de soluciones de Amazon, Microsoft y Google. Paradójicamente, así es. Y cuanto más nubes y sus capacidades utilice, más evidente será la ventaja de una solución consolidada.

Además, Stealthwatch Cloud puede monitorear nubes privadas desplegadas en su organización, como las basadas en contenedores Kubernetes o a través del monitoreo de flujos Netflow o del tráfico de red obtenido mediante la duplicación en el hardware de red (incluso de producción nacional), datos de AD o servidores DNS, etc. Toda esta información se enriquecerá con datos de Threat Intelligence recopilados por el departamento Cisco Talos, que es el mayor grupo de investigadores de amenazas de ciberseguridad del mundo sin fines de lucro.

Esto le permite implementar un sistema de monitoreo unificado tanto para nubes públicas como híbridas que su empresa puede utilizar. La información recopilada puede ser analizada utilizando las capacidades integradas de Stealthwatch Cloud o enviada a su SIEM (de forma predeterminada se admiten Splunk, ELK, SumoLogic y varios otros).

Con esto concluimos la primera parte del artículo, en la que he analizado las herramientas internas y externas para el monitoreo de la seguridad de las plataformas IaaS/PaaS, que nos permiten detectar y responder de manera eficiente a los incidentes que ocurren en los entornos en la nube elegidos por nuestra empresa. En la segunda parte continuaremos el tema y exploraremos las opciones de monitoreo de plataformas SaaS usando Salesforce y Dropbox como ejemplos, y también intentaremos resumir y unir todo, creando un sistema único de monitoreo de la seguridad de diferentes proveedores de nube.

Fuente: habr.com